AI 起草、营养师精修，都不能替用户说“就按这个吃”

营养师把方案里的菜换了，分量调了，说明也写完了，用户明天打开饮食安排，要不要直接看到修改后的那份？看餐参 AI 这版流程时，我更在意这个地方。站在编辑器里，事情似乎已经做完了；站在吃饭的人那边，他可能连修改的内容都还没看过。

如果按下“下发”，就顺手把正在执行的安排换掉，营养师提交得很顺，用户却少了一步选择。原来的菜准备到哪了，新建议能不能照着做，这些事不能从“专业人士已经改过”里推出来。六月这版原型最后明确的关系是：先把调整送给用户，用户查看、采纳，并选择同步到个人饮食方案后，才覆盖原方案。没采纳，用户端不做任何改变。

这中间的停顿，不是为了多加一个确认框。它决定了营养师交过来的究竟是一份建议，还是已经替用户排好的执行安排。

不从一张空表开始

营养师面对的是一份完整的 AI 草案。可以换菜、调分量、增减菜和加餐，也可以给某道菜加批注，解释做法，最后再写整体说明。这样安排，不是让营养师给 AI 的结果盖个章，也不是把每次服务都变成从头配七天的饭。

我觉得这里要保留两个东西：原方案作为起点，专业判断有实际修改的空间。只有起点没有空间，营养师只能认可或退回；只有空间没有起点，页面就会越做越像一个什么都能配的工具，原来“基于现有方案精修”的任务反而不见了。

原型里有过模板库，后来整个拿掉了。模板单独看很合理，配餐工具似乎就该有。但套用一份模板，往往意味着把已有安排整份换掉，和这次工作的出发点不一样。用户已经有计划，营养师要看的也是这份计划适不适合他，而不是从库里另挑一份看起来不错的菜单。

另一处调整更能说明这个分寸。早期曾经用改动比例来提醒营养师少改，超过两成就标红。后来这个限制被撤了，因为这个数没有足够依据。换几道菜才叫精修，不能靠一个比例替专业判断作答。留下的是改动前后对比、每天改了几处，以及提交时的调整摘要。

这比要求“尽量少改”更具体。改得多不自动等于不好，改得少也不自动等于谨慎。能看清改了什么，才有继续讨论的基础。至于正餐不能被删空，最后至少保留一道菜，那是在防止结构被破坏，和限制营养师只能改多少不是一回事。

改好了，还得知道检查的是哪一份

七天方案也会把编辑器里的小问题放大。营养师当前看的是某一天，提交的却是整周。如果校验只跟着屏幕上的这一天走，切到一个没有提醒的日期再提交，并不能说明其他六天也没有问题。

这版原型后来补了全周检查，提示能指出问题出在哪一天。我在意的不是多出一个检查结果，而是提交的范围和检查的范围终于对上了。页面展示一天，是为了方便编辑，不能因此把这一屏当成整份方案。

不过，检查能运行，不等于里面的数值已经可靠。菜库、每道菜的营养数据、样例用户和最初的目标热量，都有演示成分。后续确认了目标热量默认沿用用户端计算口径，营养师可以手动覆盖；这仍不能证明原型里的每一份配餐已经经过真实营养数据验证。

尤其是病种阈值。材料里把方向和数值分得很清楚：采用营养层面的参考建议稿，但仍待营养、医学团队核定背书，不是临床定稿。不能因为界面能标红，就把那条红线写成已经获专业认可的标准。

原型还允许营养师在触发提示后填写理由，坚持下发。这个设计给人工判断留了位置，同时要求理由留痕、可审计。我不会把它理解成填一句话就证明安全。理由只能说明为什么作这个选择，不能代替专业核准；审计要做，也不等于正式系统已经把记录和追溯全部做完。

用户收到的，不该只是一句“已优化”

接下来才到用户这一边。只发一张“营养师已调整”的卡片，用户知道有人处理过，却不知道自己该不该接受。调整详情因此带上了营养师说明和改动前后对比，下面才是采纳或提出疑问的入口。

假设某道菜没有换，只是分量变了，如果只展示最终菜单，用户可能根本留意不到。另一种情况是菜换了，但为什么换没有说清，用户也难判断自己原先提的问题有没有被照顾到。这些不是实际发生过的反馈，是我看详情页时会拿来核对的情形：展示的内容，够不够让一个人作决定？

“已送达”“已查看”“已采纳”也不能只是时间轴上顺次亮起来的三个点。早期有过模拟推进的演示，后续原型改成用户侧点开详情，才改变查看状态；用户侧点击采纳，才带动营养师侧卡片变化。这里说的是原型内的交互联动，不是真实消息系统已经打通。

这个区别看着细，却会影响营养师怎样理解后续工作。已送达只能说明调整到了用户面前，不能说明用户读懂；已查看也不能拿来表示接受。把它们合成一个“成功”，演示省事了，双方对进度的理解却可能不一样。

确认同步以后，调整直接覆盖原方案，而不是再叠加一份实施中的方案。这和当时个人饮食方案同时只保留一份实施中的规则相连。否则用户可能同时面对原版和精修版，两份都写着要执行，下一顿到底按哪份走，反而需要自己猜。

覆盖的前提不能丢。为了保持方案唯一，就在下发时直接覆盖，技术上也许少一个等待状态，产品上却把用户的决定一起省了。反过来，为了保留选择而让两份都进入执行，也没有把问题处理完。待采纳的新建议和正在执行的安排，需要暂时并存，但不能混成同一种状态。

这也让我觉得，“执行”最好再往后看一层。采纳表示用户愿意把它作为接下来的安排，不等于他已经照着吃了。原型把当前饮食方案和实际饮食记录放在健康画像里的两个位置，可以分别看计划与记录；不能因为计划更新了，就顺便写出用户已经完成的结果。

到这里，AI 起草、营养师精修、用户采纳才各自有了位置。我更愿意沿着这几个动作检查页面，而不是只问方案有没有成功下发。营养师改完以后，用户还可以先看、再问，也可以不采用。下一次打开原来的饮食安排，它没有因为另一端按了提交就悄悄变掉，这件事值得在流程里认真留住。