体质建议和慢病限制打架，菜单不能让用户自己裁决

做餐参 AI 的体质膳调，有个问题很难绕开：按体质挑出来的东西，碰上慢病限制，还能不能放进同一份菜单？再加上一项过敏信息，原本用来解释“为什么适合你”的理由，可能马上就要让路。

把两边的建议分别写完整不难，麻烦在它们最终面对的是同一个人。不能上面说适合，下面又提醒不适合，最后留一句“请按自身情况选择”。这句话对产品很省事，前面没处理完的矛盾却都交给用户了。

我看这部分方案时，更在意的不是还能增加多少种体质说明，而是出现冲突以后，菜单究竟改不改，为什么改，用户能不能找到被改的地方。体质膳调的介绍稿已经给了一个处理顺序：用户态和过敏在前，其次是慢病控制，再往后才是体质与季节。原稿的最高层列了经期、孕期、严重过敏、年龄极值等情况。

这是原型里的优先级，不是一张已经经过完整专业核准的健康规则表。尤其到了具体限制多少、哪些情况不能继续推荐，介绍稿没有提供足够的核准依据。我得先把这两件事分开，否则很容易把“冲突时先顾谁”写成“已经知道怎么安全处理”。

体质膳调的定位，本来就使这个冲突不太显眼。它和慢病饮食是并行的产品线，这里以体质组织内容，慢病约束作为过滤条件叠加进来。页面上最容易看见的是体质卡、调理方向和当天的餐单，用户也很可能是冲着这些内容来的。但一个条件在页面上不占主位，不代表冲突时它也排在后面。

我觉得这是做这类页面时容易松手的地方。既然叫体质膳调，就想让体质特点更鲜明，每一餐都能看出“为你搭配”的用心。可如果鲜明的那一部分恰好被更高优先级的限制挡住，产品需要允许它少一点，甚至不出现。不能为了让每个体质看起来都不一样，再把不该留下的推荐补回来。

排了先后，还没有定出分寸

拿一个不涉及具体食物的假设来看：某道菜因为体质规则进入候选，又因为用户已填的过敏信息触发限制。优先级至少能表达，不能让前一条推荐理由覆盖后一条限制。但替换成什么、替换后是否还有同类风险，并不会随着这张排序表自动得出答案。

慢病与体质之间也有类似距离。原稿举过食材冲突和按比例调整的例子，我不会直接把这些例子当成可供照着吃的结论。它们能说明设计者想表达哪种冲突，却不能代替专业判断。一个比例写进告警详情，前端也能跟着重算，看起来会很精确；这个数是否适用于当前人群、是否得到核准，是另一项工作。

对产品来说，这个区别有些别扭。页面需要一个可以展示的结果，原型也需要具体内容才能检查交互，总不能每个位置都写“待定”。但演示时需要数字，不构成正式推荐时使用这个数字的理由。我倾向于保留原型验证流程的用途，同时把尚未核准的限制条件留在后续确认范围里，而不是让演示内容随着页面一起变成既定规则。

有些信息缺了，也不适合直接按最宽松的情况继续。比如没有填写过敏信息，与明确表示没有相关过敏，并不是同一个输入状态。介绍稿给了优先级，却没有完整交代这些信息缺口该怎么处理。这里需要继续问，不能由我补一句“系统会自动判断”就跨过去。判断顺序只有在输入含义清楚时，才真正有东西可排。

我也不想反过来把所有拿不准的情况都挡在门外。那样原型会显得很谨慎，用户却可能不知道自己还差什么。哪些要补信息，哪些需要专业人员介入，哪些仍能提供有限范围的内容，应当分别确认。现在能做的是把问题留在具体环节，不用一句“安全优先”包住所有尚未决定的处理。

比起排序本身，介绍稿里几种提醒的去向更让我在意。它没有把问题全塞进一个横幅，而是分成食材级、单餐级和全天级。涉及某味食材，点击后定位到相应位置；涉及某一餐，回到餐卡；影响全天安排，再展开整体调整详情。

这让优先级不只停在规则文字里。用户不需要理解内部有几层判断，但如果页面说方案做了调整，他应该能顺着提醒看到调整落在哪里。否则，菜单是一份，风险提示是另一份，两者放在一起也只是显得信息很多。

点了“查看”，却找不到那味食材

原稿还有一个很小的分支：用户点提醒里的查看，但当天菜单没有出现那味冲突食材，原型会解释它已经被规避，而不是点了以后没有反应。

我觉得这个分支值得留下，因为菜单最后呈现的，往往只有筛选后还在的东西。被移走的内容看不见，用户也就不容易知道自己的限制有没有被用上。点击没有反应，他可能以为按钮坏了，也可能以为提醒和餐单根本没关联。给一个说明，至少能解释为什么找不到。

不过，“没有出现”和“已经主动规避”之间，仍然需要实际处理依据。一个食材本来就没进今天的候选，也会得到同样的表面结果。正式实现如果只是检查菜单里有没有它，就不能顺势说成系统为了用户专门移除了它。原型里的这个文案，我更愿意把它看成对实现提出的要求：想这样解释，就得能对应到真实发生的处理。

这也会影响我怎么检查页面。不能只检查点完有没有弹层，还要把几种情况分开看：确实调整过的，只有一餐受影响的，以及提示指向的食材并不在菜单里的。最后一种又要核对“不在”的原因。这里是在说我希望怎样继续验原型，不是已经做完的一轮测试记录。

介绍稿明确说已经有可交互原型，能切换档案、查看餐单、展开依据，数字与提醒也会联动。同时，它也列出了没有完成的部分，包括数据持久化、真实换菜算法和合规过滤器。这个差距不能被流畅的演示盖过去。特别是换菜，原菜单满足某些约束，不代表用户换完以后还满足；过滤器没有完成，也不能把现有推荐池直接描述为已经通过检查。

材料里涉及的医学解释、食材适用性和法规依据，同样需要另行核实。我能据此讨论产品想怎么组织建议，却不能据此证明检测准确、推荐安全或者具有什么效果。结果页即使放了“不替代医疗诊断”的提示，也不能替那些具体规则完成核准。

做到这里，我对“给一份已经处理过冲突的菜单”这件事，反而不敢说得太轻巧了。只展示最后的答案，确实能让页面干净；但前提是后面真的做了对应的处理，知道处理到哪一步，也知道什么还不能确定。

这部分原型让我愿意继续往下做的，是它开始让限制有了具体去处：有的影响一道菜，有的影响一餐，有的要解释全天的变化。接下来更费心的，应该是逐条确认这些变化凭什么发生。体质特点可以留在解释里，但不能为了让一份方案显得更懂用户，就把还没有把握的判断藏在菜单后面。