餐参 AI

CONTRIBUTIONS

主导从 1.0 优化到 1.5 构建的整体产品工作，明确产品主线与版本取舍。

1. 统一综合定制：合并需求入口，把健康约束、偏好与目标纳入同一份方案。
2. 设计餐小参 Agent：围绕服务对象与状态，连接信息、方案和下一步行动。
3. 串联营养师双端：从专业审核与解释，到用户确认采用，再接回日常计划。

餐参AI 1.5：从功能堆积到一条清晰的饮食服务主线

2026 年 3 月，我加入弃疾数智科技，担任产品总监，开始负责餐参AI的产品工作。餐参AI做的是饮食服务：结合用户的健康情况、饮食偏好和目标，给出能落到日常生活里的饮食方案，过程中由餐小参 Agent 组织信息与行动，也可以按需引入营养师的专业支持。

我最初接的是 1.0 的优化工作。后来业务方向发生变化，继续在原有结构上修补已经不太合适，工作也就转向了 1.5 的重构。现在 1.5 已经上线，回头看，这段时间花力气最多的地方，是把原本散开的功能重新理出一条线。

功能越堆越多，主线却看不清了

我接手时，1.0 已经做了两年，换过三任产品经理。不同阶段留下了不同的组织方式，饮食计划、场景定制、健康相关能力都有，但放在一起，用户还是得自己找路。一个入口能解决什么，和旁边的入口有什么关系，产品没有把这些交代清楚。

饮食定制尤其明显。之前有五六个入口，体质调理、慢病膳食等各走各的路径，分得太散。可一个人完全可能同时有这几种需要。让他先选自己属于哪一类，再去看对应的方案，我觉得这个顺序就不太对：我们把理解和选择的负担留给了用户。

图 1｜1.0 餐小参问询入口。

图 2｜1.0 场景饮食定制。

所以这轮调整，我先明确了一个方向：围绕用户日常怎么吃，把综合方案做好。旅行支持、宴请场景在这个版本里删除了，它们各有使用情境，但继续展开会把精力分散出去。营养师两端原先铺得也比较大，其他服务扩展先缓一缓，先把一次服务从购买到采用接通。

体质、慢病这些需求则要留下，只是不再各占一个入口。我没有打算把旧功能全部推翻，取舍时还是要看它和日常饮食安排的关系。有些场景这轮先退出，有些能力合到一起，健康兜底和方案衔接反而要做得更扎实。这个区别对我很重要。如果首页简洁了，用户原本需要的健康支持却没了，减法就做偏了。

图 3｜重构范围与各模块的关系。

收拢范围之后，餐小参和营养师服务也要围绕同一份方案工作。前者帮助用户理解当前情况、往下一步走，后者按需审核和把关，最后都得回到日常饮食安排里。

入口合起来，背后的判断也得一起改

我希望餐小参更懂一个完整的人。慢病、体质、喜欢吃什么、想达到什么目标，这些情况会同时存在，不能让用户在几个标签里选一个，就只按那一项来考虑。统一定制的入口，是让用户把自己的情况和需要交代清楚，再由产品综合处理。

图 4｜合并入口，保留需求。

这里有一条不能让步：健康必须兜底。饮食偏好和目标只能在健康约束内满足，不能因为用户选了一个目标，就把原有的健康要求放到一边。最终给出去的也应该是一份综合方案，几种需求怎么兼顾，要在生成时处理好。否则用户拿到几份菜单，还得自己判断听哪份的、怎么拼在一起。

真正难改的地方就在这里。页面上合并几个入口相对直接，算法逻辑却要整体大改。以前按分散需求组织的生成依据，要变成对综合信息的判断；如果背后还各算各的，前面只留一个按钮也解决不了问题。

我负责把这件事拆成明确的产品逻辑：生成前要拿到什么信息，缺资料时停在哪里，健康约束怎么兜底，偏好和目标又怎样进入同一份方案。健康相关规则由我和专业人员共同梳理，算法团队再基于产品需求实现。餐小参与营养师服务如何衔接，也在我的设计范围里。

回看这部分工作，我需要把用户为什么要经过这些步骤说明白，也要让专业人员和算法团队知道各自要处理什么。只把入口画到一起，后面还有很长一段工作没做完。尤其是健康要求与偏好、目标同时出现时，产品需求得讲清它们的先后关系，不能只写一句“综合考虑”就交给算法团队。专业边界也需要一起梳理，不能靠我对页面流程的判断代替。

资料没齐，先别急着生成

既然要综合判断，就得先拿到综合信息。我在生成前保留了明确的门槛：必填健康资料还没完善，先引导用户补齐，不能继续生成方案。等结果出来再加一句健康提醒，补不回生成时缺少的依据。

这和“少填一点，尽快看到结果”的体验诉求确实有张力。我也希望收集过程能轻一些，但不能把必要信息一起省掉。更值得优化的是怎么收集、怎么解释，让用户知道现在为什么需要这些资料，以及补完之后可以继续做什么。

图 5｜缺资料时补齐，再回到条件复核。

补资料这一步还得接回原来的生成流程。用户补完以后，要重新检查条件，不能把人带到另一个功能就不管了。信息完整只是进入综合判断的必要条件，后面仍然要遵循专业规则。

我更在意的是，暂时不能生成时，用户有没有一条清楚的路可以继续走。如果只看到一个拦截提示，却不知道缺什么、为什么要补、补完去哪里，这个门槛就很容易变成一次莫名其妙的中断。

餐小参要知道，现在该帮谁做什么

设计餐小参这个 Agent 时，我关注的是它能不能接住前后的事情。用户可能还在补资料，也可能已经有了方案，正在理解或考虑是否采用。当前走到了哪里，会直接影响它应该提供什么帮助。只看这一轮问了什么，容易把服务割成一段段孤立的对话。

个人和家庭的流程里，还得先分清服务对象。操作账号的人不一定就是接受饮食服务的人；替家人操作时，资料和方案应该归到对应成员身上。我在设计里把对象放在前面，就是为了让后续解释和行动都沿用正确的上下文。

图 6｜餐小参的对象与状态衔接设计。

顺着这个思路，资料缺失就引导补齐；方案待采用，就帮助理解并进入确认；专业服务交付后，再把用户采用的方案接回日常计划。用户做了新的选择，状态也要跟着更新，下一步才能接得上。对我来说，这比继续增加它能回答的问题更值得先做好。它需要知道用户已经完成了哪一步，还有哪一步等待确认，才不至于每次对话都像重新开始。

这些是我组织餐小参流程时的考虑。具体能做什么，要受规则和当前状态约束，AI 辅助理解与表达，关键确认仍交给用户。我不希望它在对话里讲了一套安排，等用户真的去执行时，又回到另一套资料或方案里。

营养师服务，先把最小闭环做好

营养师两端这次先收在一条流程里：用户购买服务，营养师接单，审核或调整当前饮食方案并解释，用户确认采用后，再同步日常计划。先让这一次服务能完整走完，其他扩展后面再做。

整理流程时，我很在意“交付”和“采用”之间的那一段。站在订单角度，营养师交了方案，工作似乎就完成了。但用户还需要看懂结论，决定要不要照着吃。这一步不能被订单状态代替。

图 7｜营养师双端的交付与采用流程。

交付也不必每次都改菜单。审核之后，如果当前方案可以保留，就应该允许营养师保留原方案，把审核结论和重点安排解释清楚。调整过的方案当然也要说清理由。用户付费获得的是专业判断，不能拿改了多少道菜来衡量这次服务的价值。

因此，订单完成和方案采用在设计里是两个状态。营养师已经交付，用户还没确认采用，就不应该自动开始执行。等用户主动确认，再把方案同步到日常计划，这个动作才算接上。

两端使用的资料也要尽量接续。用户已经有档案和当前方案，就复用这些内容，只补充这次想解决的问题；营养师围绕同一批资料审核，没必要让用户从头再描述一遍。如果交付后还有反馈，流程里也保留了再次审核和交付的路径。最终采用的方案仍然回到原来的执行链路，不另外起一套计划。

上线之后，我还想继续看什么

1.5 上线后，我对这一阶段的判断是：整体主线更明确，操作链路更清楚了。之前散在不同入口里的需求，现在可以放进同一份综合方案里考虑，餐小参和营养师服务也有了更清楚的衔接位置。

接下来我还想沿着用户实际走的过程看一遍。补资料时，他能不能理解为什么需要这些信息；收到营养师的解释，是否真的看懂了保留或调整方案的理由；到了确认采用这一步，又能不能顺利进入日常执行。这些是我后续会继续关注的地方，仅仅把流程接起来，还不能替代对使用过程的观察。

这次重构让我更在意，删掉一个入口之后，原来的需求究竟由哪里承接。界面可以更简单，但慢病、体质、偏好这些事情不会跟着消失。我们要在背后把它们的关系理顺，用户才有可能少做一些选择，把注意力留给今天怎么吃。

保存完整复盘，离线阅读正文与全部 7 张配图。

下载完整文档（ZIP · Markdown + 配图） ↓