接手餐参 AI，功能不少，用户的路却没那么好认

换工作接手餐参 AI，先碰到的麻烦是，功能单独看都能理解，连起来却没那么容易。健康档案、饮食计划、打卡、今日分析，还有专家服务，都有各自要处理的事。可换成一个刚进来的用户，档案填完以后去哪儿，吃了几天以后看什么，专家给了调整又怎么接着吃，我没法很顺地把这条路讲下来。

这不是一个从空白开始的项目。慢病版已经有功能积累，也有继续扩展的方向。对接手的人来说，沿着模块逐个熟悉很自然，至少能知道产品里有什么。但知道入口在哪儿，和知道为什么此刻要进这个入口，还隔着一段。

我更想先弄清楚后面这一段。手头的用户主线梳理稿，把范围收在建档、获得方案、执行反馈、专家介入，再到用户采纳后继续执行。它是用来理解和检查产品的主线，不是这些环节都已经开发完成的证明。里面有不少应该怎样衔接的安排，仍要回到页面和实现去核对。

范围收窄以后，反而比较容易往下看了。课程、专家发帖、机构合作不是没有价值，只是暂时不能拿来回答一个用户今天怎么吃的问题。把它们都塞进来，图可以很完整，我对主路的疑问却还在。

填好了档案，不能只换来一个结论

第一处让我停下来的是建档到方案。

梳理稿里，基础信息、慢病标签和可以补充的指标，先形成健康画像，再作为饮食方案的依据。这个顺序看起来没什么争议。但如果建档结束后，只展示一页身体状况的分析，用户仍然要自己找饮食计划、判断下一步做什么，前面那一轮填写就还没有接到他想要的东西上。

我倾向于把第一次建档的出口看得更具体：接下来的页面要让人找到当天的安排，同时看得出安排与刚才填的信息有什么关系。不是再放一段泛泛的健康介绍，也不是把所有计算过程摊给他。计划详情、菜品卡和方案依据需要各自承担一点解释，才能让用户从“我提供了资料”走到“这份安排确实在使用我的资料”。

不过，尽快给出第一份方案也有一个限度。稿里把一些检测指标和报告列为可补充信息，不等于少填什么都不影响生成。哪些信息缺了还能往下走，哪些缺了必须先补，单靠这张主线图定不下来。我不想为了让路径显得顺，就把“建档完成”理解成所有必要条件都满足了。

还有换菜。它看起来属于拿到方案以后的便利功能，稿里却专门写了替换应继承原菜的热量预算。这提醒我，方案不是几张可以随意互换的菜品卡。用户改了一道菜，原先生成方案时使用的约束还要跟过去。这里先能确认的是产品要求，具体预算如何计算、替换是否满足健康限制，还不能靠交互本身证明。

顺着这一点往后看，执行反馈也不能只是计划页上的完成标记。稿里区分了按计划打卡、拍照记录和换菜，还要求记录回到健康画像及今日分析。假设某一餐换了菜，分析依据就应该跟着实际记录走，而不是继续拿原计划当作已经吃下去的内容。否则页面虽然前后都有数据，讲的却不是同一顿饭。这是我沿着主线会继续核对的地方，不是已经发现并修好的线上问题。

到了专家这里，不是多一个聊天入口

用户执行以后，有些疑问不会靠今日分析自动消失。梳理稿列了几种引入专家的条件：不信任方案、情况复杂、需要解释指标或报告，以及长期执行有困难。用户也可以主动购买服务。

我觉得这些入口背后的理由，比专家卡片放在哪里更值得先弄清楚。对建议不放心，和不知道怎么坚持，是两种不同的求助。产品如果只把人带到同一个服务列表，却没让后面的人知道他为什么来，前面记录的执行情况就很难派上用场。

但也不能为了少问一遍，就把完整档案直接交给专家。这是第二处明确的交接条件：专家查看健康数据，要先有用户授权。

稿里提出，专家看到的应当是用户健康画像的授权只读视图，而不是再建一份独立的专家端档案。这个安排对我理解两端关系很有帮助。同一份画像可以支撑不同的查看场景，但有了服务订单、有了会话，不应被含糊地当成已经获得全部数据权限。

落到页面上，服务入口、授权弹窗、会话里的状态就得对得上。用户需要知道接下来要提供什么，专家侧也不能把尚未授权误读成没有资料。这些是我认为需要检查的表达。具体授权范围怎么划、撤回后怎么处理，当前这份梳理稿还不足以给出完整答案，不能因为写了“授权”两个字，就觉得权限问题结束了。

我在这里也有一点犹豫。授权增加了一步，用户正想赶快把问题说清楚，多一个动作就可能打断他。可省掉这一步所换来的顺畅，是建立在默认别人可以看他的健康资料上。对这段路，我宁愿把为什么需要授权说明白，而不是把它藏起来。

专家介入也不该成为所有异常提示唯一的出口。有问题就引导购买，很容易让前面的自助方案显得只是铺垫。梳理稿把专家放在特定问题出现之后，我更愿意沿着这个方向理解：先让求助理由成立，再讨论服务如何承接，而不是先安排一个转化位置。

最后一处衔接，是专家的调整怎么回到当前方案。

稿里写的是在原有方案上做局部调整，送回用户端，用户查看后可以采纳，也可以带着疑问继续沟通。专家提交、用户收到、用户看过，都还不代表当前饮食安排已经变了。真正更新的条件是用户采纳。

如果只看专家端，很容易把提交结果当作工作完成；只看用户端的一张新方案卡，也容易觉得交付已经发生。但用户下一次打开计划准备吃饭时，到底看到哪一份，才是这条主线需要回答的事。

因此我更在意方案卡要不要展示改了哪里、为什么改，以及“有疑问”会把人带回什么地方。按稿里的安排，有疑问时原方案不变，继续沟通；采纳以后，当前方案更新，后续打卡和分析再基于它继续。这里的状态不是为了把流程画复杂，是两份内容短暂并存时，不能让人猜今天该照哪份做。

这次梳理没有让我得到一个已经跑通的完整产品，也没有回答所有细节。它先帮我把接手时那种模糊的不顺，落到了可以继续追问的位置：第一份方案凭什么生成，专家在什么条件下看资料，调整又在什么时候进入日常安排。

再回到那些熟悉的功能名字，我才比较知道该怎么看它们。不是每个模块各自介绍完就算理解了，而是沿着一个人的当前饮食方案往前走，看看每次换页面、换角色时，他还要不要重新解释自己，或者猜一次下一步。主线先理到这里，后面的页面和规则才有地方逐项核对。