用LLM实时解析糖尿病饮食日记：提示词设计、营养换算与血糖管理

1. 这个项目要解决什么问题

先说个很多人忽略的事实：糖尿病患者最难的往往不是打针吃药，而是每天想清楚“我到底吃了多少”。我参与这个项目之前，和某医院内分泌科的医生聊过，他说门诊里最头疼的就是患者复诊时拿来的饮食日记——“早餐：稀饭一碗、咸鸭蛋半个”，这种记录听起来清清楚楚，但医生根本没法判断这顿早餐会对血糖产生多大冲击，因为关键信息全都没有：稀饭是大米粥还是小米粥，一碗是多大的碗，煮得有多烂，咸鸭蛋是水煮还是油煎，有没有配着馒头吃。

这就是LLM实时解析饮食日记这个项目最核心的出发点：把患者随手写的、口语化的、充满模糊量词的饮食记录，通过大语言模型实时转换成结构化的营养数据，再进一步给出对血糖管理有实际指导价值的反馈。它解决的痛点不是“记录”本身，而是记录之后“无法量化、无法对比、无法决策”的三重困境。

这个项目适合三类人参考：一是做医疗健康类应用的开发者，二是想用LLM做垂直场景落地的算法工程师，三是对糖尿病干预方案有探索兴趣的产品经理。文章里我会把提示词设计、结构化输出、营养换算逻辑、误差控制方案全部拆开讲，也会把踩过的坑原原本本分享出来。

2. 整体设计思路与方案选型

2.1 为什么非要用LLM，而不是规则引擎或OCR

一开始团队里也有人提过，饮食日记解析是不是可以用关键词匹配加营养数据库查询就能搞定，毕竟食材和常见菜品是有限的。我实测过这条路，规则系统应付“米饭100g、鸡胸肉80g”这种标准格式确实没问题，患者一旦写成“中午去食堂打了一份红烧肉饭，肉有点肥，米饭剩下小半碗”，规则引擎直接崩溃。它无法理解“有点肥”意味着脂肪和热量上浮，“小半碗”意味着主食摄入量大约在50克熟重左右。

LLM带来的是三层能力的跃升：第一是模糊量词的常识推理，它能结合语境判断“一小碗”“半份”“巴掌大”大概对应多少克；第二是复杂菜品的成分拆解，它能根据菜名推测主要原料和烹饪方式，比如“地三鲜”知道是茄子土豆青椒过油，“鱼香肉丝”知道是咸甜口、含糖量不能忽略；第三是对话式追问，当信息不足时模型可以主动问“这碗粥是多大的碗”“肉大概几块”，这在传统规则系统里几乎不可能实现。

选型时我们对比过几种方案。第一类是纯手工营养师标注，准确率当然最高，但成本无法规模化，一位营养师一天处理几十份日记就到极限了。第二类是OCR识别加结构化模板，对拍照的标签类食物有效，但中餐菜品组合千变万化，模板覆盖不过来。第三类就是LLM端到端解析，允许输出有噪声，通过后处理校验和用户修正兜底。最终选了第三类，理由很实际：迭代速度最快，患者的使用门槛最低，而且随着模型能力提升，准确率天花板明显更高。

2.2 核心功能框架与数据流设计

整个系统的数据流设计成五个环节：输入采集、LLM解析、营养映射、血糖关联分析、结果反馈修正。输入采集支持两种方式，一种是患者主动打字记录，另一种是在微信对话里直接发语音转文字，考虑到中老年糖尿病患者的使用习惯，语音输入的比例其实很高。LLM解析环节负责从自由文本中抽取出食物条目、份量描述、烹饪方法、进餐时间和餐次标签。

营养映射是关键技术环节。LLM输出的食物名不会自动告诉你碳水化合物有多少克，我们需要把解析结果和食物成分数据库做关联。这个数据库来自公开的食物成分表数据，覆盖了谷薯类、蔬菜水果类、肉蛋奶类、油脂类共三十多个亚类的常用食材和常见菜品，每条数据包含能量、蛋白质、脂肪、碳水化合物、膳食纤维等核心字段。但数据库里的条目不可能覆盖所有表述，比如“红烧肉饭”并不在表里，系统就会按“米饭 + 红烧肉”两个条目合成计算，红烧肉的原料比例由LLM给出，营养成分由数据库查表得出。

血糖关联分析是真正体现“管理更精准”的地方。解析出的碳水化合物总量会结合进餐时间，估算餐后血糖波动区间，同时给出对应的胰岛素剂量建议。剂量建议依赖两个参数：患者的胰岛素敏感系数和碳水化合物系数，这两个参数在真实场景中差异很大，系统设计成可配置项，由医生根据患者情况设定，不会让患者自己瞎填。反馈修正环节则允许患者对AI解析结果进行逐项确认，比如发现AI估算的米饭量比实际少，直接点击修正，修正后的数据会重新参与血糖分析。

3. 实时解析与营养计算的核心细节

3.1 提示词工程：让模型学会看食谱而不是写诗

LLM解析饮食日记，成败一大半在提示词设计。第一版我写得很简单，就像聊天一样告诉模型“请解析下面的饮食日记”，结果输出五花八门：有的给出了一段描述性文字，有的给出了表格，有的甚至开始点评患者的饮食结构。后来我彻底放弃“聊天式提示词”，改用严格的角色定义加输出约束加少样本示例的三段式结构。

角色定义部分我会写明“你是一名专业营养师助手，负责将用户的饮食记录解析为结构化的JSON数据”。这不是一句废话，角色设定直接影响模型的组织信息方式，相当于告诉它该调动哪部分先验知识。输出约束部分我会给出明确的JSON Schema，包含餐次、时间、食物列表、每项食物的名称、份量描述、估算重量克数、烹饪方式、碳水化合物克数、蛋白质克数、脂肪克数和膳食纤维克数。少样本示例通常放三到五个，覆盖常见对话、模糊描述、多菜品混合等场景。

温度参数我调到了0.2，这是一个很关键的细节。温度太高会让模型在份量估算时天马行空，比如把“一个鸡蛋”估出130克；温度太低虽然稳定，但中文口语的灵活性会被压制。0.2是我实测下来准确率和多样性的平衡点，如果使用更大参数量的模型，温度可以进一步调到0.1。

3.2 结构化输出的JSON设计

LLM解析环节的产出是一个JSON对象，这个JSON结构决定了后续所有逻辑的展开方式。我前后改了三版才定下来最终的Schema，核心设计思路是“食物条目可独立修正、营养素字段可空可补、来源信息全程保留”。

{ "meal_type": "lunch", "meal_time": "2024-05-20 12:15", "food_items": [ { "food_name": "红烧肉", "amount_description": "大约五块，每块三厘米见方", "estimated_weight_grams": 120, "cooking_method": "炖", "ingredients_estimate": [ {"name": "猪五花肉", "weight_grams": 80, "confidence": "high"}, {"name": "食用油", "weight_grams": 15, "confidence": "medium"}, {"name": "冰糖", "weight_grams": 10, "confidence": "medium"} ], "nutrition": { "carbohydrate_grams": 8.5, "protein_grams": 15.2, "fat_grams": 32.1, "fiber_grams": 0.3 } } ], "total_nutrition": { "carbohydrate_grams": 78.5, "protein_grams": 22.4, "fat_grams": 46.8, "fiber_grams": 4.2 }, "warnings": [ "该餐脂肪含量偏高，建议调整烹饪方式" ], "requires_confirmation": true }

份量描述字段必须保留患者的原始表述，“大约五块”“小半碗”这些词后续会用于误差判断；营养成分字段允许estimated_weight_grams为null，比如患者只说了“吃了一盘炒青菜”，模型无法从“一盘”推导出任何合理重量，这时营养字段就只给范围估计值，明确标注待确认。饮食记录中经常出现多餐连着记的情况，所以还设计了meal_type枚举值和meal_time倒序排序逻辑。

这里要强调一个我踩过的坑：别让模型直接输出“g”以外的计量单位，非常容易出bug。从“一两饭”“一个包子”“半根油条”统一换算到克，这个事必须由后续的量化模块负责，模型只负责把患者的话转换成可计算的中间表示。如果把计量单位换算也塞给模型，它会犯低级错误，比如把“一两”换算成60克而不是50克。

3.3 碳水化合物的一个精确计算例子

碳水计算是糖尿病管理的核心指标，直接决定餐前胰岛素追加量。这里分享一个典型计算过程。假设患者记录“午餐：二米饭一碗（约250g）、西红柿炒鸡蛋（两个鸡蛋 + 一个西红柿）、清炒西兰花半盘（约120g）、饭后一个中等大小苹果”。

LLM解析后输出：二米饭250克熟重，其中大米和小米各一半；西红柿炒鸡蛋这道菜，两个鸡蛋大约100克蛋液、一个西红柿大约150克；清炒西兰花120克；苹果中等大小约200克。关键换算在这一步：二米饭熟重250克，不能直接用生米的碳水系数计算。大米煮熟后含水量大幅增加，100克熟米饭的碳水化合物大约25克，小米略高一点约27克。所以二米饭一顿的碳水化合物就是125克乘26克每百克，约32.5克。这个数据如果错按生米算，碳水会飙到80多克，胰岛素剂量直接翻倍，非常危险。

西红柿炒鸡蛋里的碳水主要来自西红柿，两个鸡蛋几乎不含碳水，150克西红柿约4克碳水。西兰花富含膳食纤维，净碳水很低，120克约4克碳水，其中膳食纤维占2.5克，严格算的话可以减掉这部分。苹果200克可食部约28克碳水，加上前面的32.5克、4克、4克，这餐总碳水约68.5克，需要追加的胰岛素单位数就由这个数值除以患者的碳水系数得出。整个过程的核心原则是：熟食必须用熟食的系数，混合菜品必须拆解到原料，不同食物种类的碳水密度差异巨大，全凭感觉估算误差必然失控。

3.4 模糊量词的量化映射表

这里分享一套量化策略。LLM从患者描述中抽出的量词表述，有明确的就带上克数，模糊的则使用映射表兜底。这套表的数值来源是营养师经验结合食物成分表的常见食用份量，不算精确，但比让用户凭空回忆要可靠得多。

映射表在实际使用中会触发“用户确认”机制。系统发现解析结果使用了默认估算值，就会在反馈卡片上提示“我按一小碗150克估算的米饭，如果不对请点击修改”。这种设计不是为了烦人，而是让误差在记录时就暴露，而不是到复诊时才发现一周的记录全都偏了。

4. 实操路径与关键模块实现

4.1 系统架构与模型选型

整体架构分三层：前端交互层、LLM解析服务层、营养决策层。交互层承接对话式记录和结果展示，用微信小程序实现，患者发送语音或文字后，前端将内容传给解析服务。解析服务层内置两个模块，第一个是对话管理模块，负责多轮上下文维护，比如用户纠正“刚才那碗粥是大碗”，系统要能回溯到前一条记录进行修正；第二个是LLM调用模块，负责将对话历史组装成完整提示词并调用模型接口，解析响应延迟控制在两秒以内，用户体感接近实时。

模型选型上我试过通用大模型和医疗垂类微调模型。医疗垂类在识别专业术语上略好一点，但通用模型在“常识推理”和“量词理解”上明显更强，比如面对“吃了老婆饼，里面没有老婆”这种玩笑式记录，通用模型不会把“老婆”当食物成分。最终选用通用大模型加少量领域提示词、后处理纠错的方式，效果稳，迭代快，不需要标注数据做微调。

4.2 实时解析服务的核心逻辑

实时解析不只是调用接口那么简单。对话记录会先进入预处理管道做抽稀和去噪，比如患者发了一整段长语音，中间夹杂“今天下雨路上堵车”，这些无关信息不能直接丢进提示词，既浪费token又容易干扰模型判断，预处理阶段会按语义匹配抽取和食物、时间、餐次相关的高价值句子。

预处理之后的提示词组装很有讲究，对话历史保留最近三轮。患者在记录饮食时经常有连带修正，比如“中午吃了碗牛肉面，不对，不是牛肉面，是排骨面”，如果只把最后一句话给模型，它不知道前面那条错误记录要作废。带上完整上下文后模型才能正确理解“=是修正而非新增”。

服务层用Python异步框架实现，模型调用部分使用流式输出优化首字延迟。患者说完一句话，平均500毫秒内就能看到解析结果开始流式渲染，完整JSON一般在1.2秒到1.8秒之间输出完毕。这个响应速度在真实对话中很重要——超过三秒，很多中老年用户就会觉得“卡了”然后重复发送，导致重复解析和数据冲突。

4.3 后处理校验与营养数据库关联

LLM输出原始JSON之后，还要过三道后处理关卡才能进入营养计算流水线。第一道是字段完整性校验，检查食物条目是否缺少食品名称、重量估算、营养字段，如果缺失则标记为“待确认”而不是直接报错。第二道是数值合理性校验，比如碳水化合物为负数、蛋白质超过200克、一顿总热量超过3000千卡，这类明显异常直接拦截打回重解析。第三道是食物名与成分表关联，把LLM输出的food_name跟数据库做模糊匹配，匹配不上的会进入同义词映射表查询，比如“番茄”对应数据库的“西红柿”，“土豆”对应“马铃薯”。

营养映射采用“组合拆分”策略：数据库里有整菜品记录的就直接用整菜品数据；没有整菜品记录的，按LLM给出的ingredients_estimate拆成原料，分别查表再加权求和。以“鱼香肉丝”为例，数据库虽然有这道菜，但不同餐馆的鱼香肉丝配比差异极大，而糖尿病患者最怕的就是这种隐藏糖分。系统会展示分解结果：瘦肉70克约3克碳水、木耳30克约3克碳水、胡萝卜20克约2克碳水、白糖15克约15克碳水、食用油20克约0克碳水。算下来一份鱼香肉丝的碳水主要来源是糖，接近总碳水的一半，这个信息对患者来说是巨大的认知冲击，很多人第一次意识到“吃鱼香肉丝等于在吃糖”。

4.4 血糖辅助决策逻辑设计

营养数据最终要落到“下一针胰岛素打多少”和“餐后血糖会多高”这两个问题上才算完成闭环。血糖辅助决策模块把总碳水克数除以患者的碳水化合物系数，得出推荐的餐前胰岛素追加量，再结合当前血糖值和趋势，给出低血糖风险提示。这套逻辑不直接输出“你该打多少单位”，而是给出范围建议并附带“请咨询主治医生”的确认提示，毕竟糖尿病用药决策受运动、情绪、注射部位影响太大，算法只能做辅助参考。

血糖波动预测采用的是简化模型：预估餐后血糖峰值等于当前血糖加总碳水乘血糖生成指数调整系数，再减去体内活性胰岛素影响。这个模型不追求精准，目的是帮患者形成“我吃了什么导致血糖高了”的因果直觉。系统里还会积累历史数据，一周后生成对比报告，显示“同样吃面条，为什么周三血糖比周一低”，患者能直观看到加蔬菜、先吃菜后吃主食等操作对血糖的实际影响。

5. 常见问题与排查技巧实录

5.1 份量估算偏差的三大高频场景

第一个高频坑是圆形食物的尺寸估算，“一个橘子”“一个猕猴桃”“一个西红柿”在患者描述里千差万别。实际测试中，同一个“橘子”记录对应的重量从80克到220克都有。排查发现，患者说“一个橘子”时根本不会意识到橘子有大小之分。解决方案是在对话追问阶段增加引导问句：“这个橘子大概多大，比你的拳头大还是小？”，把尺寸输入后，系统按体积等比换算重量，误差从平均35%降到12%左右。

第二个坑是“碗”的容量差异。同一个小碗，家庭米饭碗和日式拉面碗的真实容量可以差出四倍。后来系统加入了一个“碗型选择”交互控件，患者记录主食时长按弹出三个碗型图标供选择，配合默认估算值使用，这个改动虽然简单，却把主食碳水的平均误差压到了20%以内。

第三个坑是复合菜品中“看不见的原料”。“宫保鸡丁”里的花生米，“麻婆豆腐”里的肉末和红油，“扬州炒饭”里的青豆火腿丁，患者描述时基本不会提及，但这些原料有的碳水化合物不低，有的脂肪含量爆表。破解方案是给LLM提示词里注入一份“菜品陷阱清单”，要求模型遇到已知的高糖油复合菜时，必须强制补充原料估算。

5.2 幻觉数据的拦截与纠错

大模型幻觉在饮食解析场景里的后果比较严重，它会把“一个馒头”的营养价值编成完全合理但错误的数据，比如任意给出80克碳水，实际馒头按150克算也只有75克碳水，虽然不算离谱，但这种系统性偏差积累起来会误导剂量计算。拦截幻觉的防线是“交叉验证评分”：系统会用食物成分数据库独立计算一次营养值，和LLM输出的数值对比，偏差超过30%就标记为“AI估算可能不准，请确认”。

针对极端幻觉，比如“一顿饭吃了三斤红烧肉还只点评说‘蛋白质摄入高’，后续食物列表里却只有两块”，这种日志级错误更常见的原因是对话管理丢上下文。排查后发现，当患者连续记录两顿饭后，模型会把第二条记录的部分信息误并入第一条。修复方式是给提示词里加一条硬规则：“每次解析前先识别餐次边界标记，如果新记录中出现新的餐次词，立即开启新一轮，不允许跨餐次合并”。

5.3 断网离线与弱网容错方案

糖尿病饮食记录的场景集中在家里和医院，但实测中依然会遇到电梯、地下停车场、地铁里弱网导致的请求超时。第一版设计成必须实时返回解析结果，弱网场景下体验很差，患者经常看到“服务器开小差了”之后直接放弃记录。后来改成“本地暂存 + 后台补传”方案：前端先把患者的原始记录存在本地数据库，网络恢复后再自动上传解析。解析完成后推送通知，患者看到结果后也能进行确认修正。

还有一个不少团队踩过却没重视的坑：时区问题。某次有一个患者凌晨一点加餐记录，前端显示时间正确，但服务端存的时间戳按UTC处理，导致数据被算到前一天。血糖管理对进餐时间精度要求很高，差一天直接影响数据统计。排查定位后发现是服务器配置的时区不正确，修复方案很简单：时间传递统一用ISO8601带时区偏移量，存储层全部转成某固定时区的时间戳。

6. 在不同场景下的扩展应用空间

这个系统做完之后，团队内部复盘时意识到框架本身并不局限于糖尿病，饮食结构化解析能力可以被其他慢病管理直接复用。高血压人群需要精准控制的是钠摄入量，把营养成分字段扩展出钠含量和钾含量，提示词加入“关注高盐菜品并估算用盐量”，同一套流程就能跑起来。痛风患者需要关注的是嘌呤含量，数据库增加嘌呤字段后，之前的中餐菜品分解逻辑几乎原样复用。

妊娠期糖尿病是另一个高价值场景，它的特殊性在于饮食管理更加严格，餐后血糖标准比普通糖尿病患者要求更高，而且漏记一餐直接影响产检评估。这个群体相对年轻，对话式记录接受度很高，语音输入的占比超过六成，数据完整率比普通患者明显更高。团队正在针对这个场景做“饮食照片辅助识别”的扩展，未来患者拍一张餐盘照片，视觉模型先输出菜品区域和食物类型，再交给LLM做份量和营养成分推理，形成双重实时解析。

企业健康管理场景也在接触，某公司想把这套系统内嵌到员工体检后的慢病管理服务里。这个场景的特点是用户规模大、数据量大，对实时性的要求更高。我给的方案是解析服务分层：轻量规则引擎先处理标准格式记录，LLM只处理规则引擎无法覆盖的长尾描述，这样既控制了成本，又保证了大多数常见饮食的响应速度。

7. 已知的局限性与健康管理伦理边界

任何AI辅助医疗场景都不能回避伦理问题。饮食日记解析直接涉及患者的治疗决策，如果数据解析出错，误导了胰岛素剂量，后果可能很严重。所以系统的每个推荐都带“仅供参考”的提示，胰岛素剂量建议的页面会要求患者确认“我已经咨询过医生，了解调整剂量需要结合血糖监测”。有一次产品会议上有人提议把剂量建议改成“一键推荐”，我坚决反对，这个改动表面提升效率，实际上把责任风险全推给了算法。

另一个重要边界是避免“病人与AI建立过度依赖”。系统不止一次遇到老年患者表达“AI说我今天可以吃两块蛋糕”这种理解偏差。对策是当天的饮食记录中如果出现高糖高油食物，系统不只有警告文案，还会切换话术风格，通俗解释为什么这类食物需要控制，并把“怎么吃更安全”的建议放在“能不能吃”的告诫前面。

数据隐私保护上，饮食日记连情绪状态、作息时间都能推断出来，属于高度敏感的个人健康数据，必须全链路加密传输和存储。我在整体设计文档里特别加了一条：任何日志不得包含患者ID和原文内容，在线调试时只能使用脱敏后的虚拟数据。实际运行中也出现过安全扫描发现的隐患：一次版本迭代时，调试日志误把完整的对话文本打印出来了，排查后立即修复并加强了审核流程。

8. 写在最后的几点实在话

这个项目做到稳定上线，我最深的体会是：LLM在垂直场景里的价值不在于“能不能读懂一句话”，而在于“读懂之后能不能形成可靠的数据闭环”。饮食日记解析如果只是把文字转成JSON，那和聊天机器人没有本质区别；真正的难点在数据交叉验证、误差兜底和用户修正机制这些不太起眼的地方。

实际运行中还有一个小技巧可以分享：定期把用户修正过的解析结果拿回来做复盘，找出修正频率最高的食物和量词，反向优化提示词。这个机制跑通之后，系统对特定用户群表达习惯的适配速度明显加快，前两个月的修正比例从31%下降到了16%，后面基本稳定。数据反馈闭环带来的进步，比任何线上评测指标都真实。

还有一点提醒所有想复刻这个项目的团队：不要一开始就追求覆盖所有饮食场景。我见过最多的失败案例是试图在第一版就把八大菜系、所有小吃的解析精度做到完美，结果团队被长尾场景拖死，核心场景反而没跑顺。先聚焦你最了解的目标人群的一日三餐，把碳水、蛋白质、脂肪这三项算准了，再逐步扩品类和场景，这才是可持续的节奏。饮食记录这件事，患者的坚持是最大的壁垒，而技术能做的，是让“坚持”这件事尽量不费力。