设计营养师服务，不能把下单当成交付

营养师服务的商品页能写清介绍，填好价格，也能一路点到购买成功。可再往后看，买完的人去哪里补充问题，营养师从哪里拿到这次要看的方案，什么东西交出来才算做完，这些还没有被一个购买按钮回答。

这里卖的不是一份餐食。用户不是付完钱等配送，营养师也不是接到订单以后做一顿饭送过去。餐参 AI 要承接的是专业服务：看已有资料、理解这次诉求，给出审核结论，必要时调整饮食安排。商品页上的“饮食计划定制”，如果只按字面往下接，很容易做出一个能买、却说不清怎么交的流程。

我看这部分时，会先把六月的上架原型和后来的一点五版本服务流程分开。前者在探索营养师怎样把服务放出来，后者把一次专业把关往下拆到了资料、沟通、交付和确认。它们不是同一天做完的完整交易系统，也不能把后来的规则倒填回六月，说当时已经全部想清楚。

六月的起点比较开放。营养师作为服务卖家，可以自主添加、修改服务和定价；平台提供预置模板，同时保留通用自建入口。这很容易理解，电话咨询、饮食计划定制和一段时间的陪伴，不可能靠同一份固定文案卖给所有人。

但开放意味着平台还得接住自己没有预先列全的服务。选了“其他”，到底往哪里交付？只进入一个聊天窗口，算不算已经有了承接？这是当时明确留着的问题，并没有因为原型能上架就得到答案。

模板也不是天然安全的捷径。原型曾按预置套用直接上架、通用自建提交审核来演示，但采用不采用这个审核口径、由谁审、驳回后怎么办，仍然待确认。五类服务目录、建议价格和工作台里的经营数字，也只是规划或演示内容，不能拿来证明当时有哪些服务已经在卖。

我更关心的是，模板帮营养师省下填写以后，是否把承诺写得更具体了。服务说明可以写得很好听，交付物、服务周期和用户能提出多少次反馈，却会直接影响购买之后的关系。如果这些还模糊，用户和营养师可能各自带着不同的理解走进同一张订单。

先让一项服务说得清楚

后来的用户端流程聚焦到了“营养师专业把关”这一项服务上。它没有把六月设想的全部服务形态一起展开，也不是要让营养师接管餐小参。餐小参继续负责生成方案、陪伴执行和后续评估，营养师在用户需要进一步确认时，审核这次的方案并给出明确结论。

这里有个我觉得很重要的取舍：方案不需要调优，也可以完成有效交付。

如果把付费服务的价值表达成“人工一定会改得更多”，营养师即使认为原方案合适，也像是必须换几道菜才交得出东西。用户则可能拿改动数量判断服务有没有用。后来的规则要求交付明确的审核结论和关键安排说明；确有必要时，再提出具体调优意见，由餐小参继续落实。

这让“看过以后认为可以保留”也有了表达的位置，但不是给一个笼统的“没问题”就结束。为什么可以保留，执行时有哪些重点，仍然需要说明。专业服务交的是判断和必要的安排，不是为了显示有人来过而留下修改痕迹。

买服务也不能偷偷采用原来的 AI 方案。用户选择先找营养师把关，原方案就仍然待采用。否则他明明还在等一个判断，执行页却已经开始催他按计划吃，两个流程表达的意思就相反了。

付款以后，先把这次的事交过去

后来的流程把支付成功和待接单分开了。支付成功页先确认购买结果，解释接下来需要补充资料；用户主动开始补充，提交以后，订单才进入待接单。付款完成，说明购买动作走完了，不说明营养师已经拿到了开展服务所需的信息。

已有资料不要求用户重填。当前方案、健康档案、过敏和禁忌跟着这次服务走，用户补的是这次尤其希望确认的问题。我觉得这是商品化以后容易忽略的一段：系统知道的和用户此刻想问的，不是同一份东西。前者需要带过去，后者需要留地方说。

到八月补入家庭共餐入口，携带的范围又变了。营养师看的不只是购买者自己的档案，还包括这一桌所有参与家人的资料；交付后采用的去向，也要回到家庭共餐的对应状态。不能只复用一个购买页，就默认后面所有对象都和个人七天计划一样。

订单详情因此要能同时找到原方案、交付结果、沟通入口和服务时间线。它不是付款凭证的加长版，而是用户回来查看这件事做到哪一步的地方。与此同时，“我的营养师”保留关注和服务关系，不必重复承担整套订单记录。认识哪位营养师，与某一次付费服务进行到了哪里，可以有关联，但不能靠同一个列表含糊地包住。

“已完成”旁边，还可能有一份待采用方案

最容易被混在一起的，是订单完成和方案生效。

这版流程在每次交付后留四十八小时确认期。首次交付后，用户可以采用，也可以提交一次反馈；第二次交付后，重新计算确认期。用户主动采用，订单正常完成，个人方案进入已有执行链路。这里不用再造一套营养师专属的执行页面。

但如果到期一直没有操作，规则只让订单自动完成，方案仍然待采用，绝不自动进入执行。

我更在意后半句。订单需要一个结束条件，否则一次服务可能永远挂着；饮食安排却不能因为计时结束，就被当作用户同意了。把两者拆开以后，“已完成”只描述这笔服务订单的状态，不再顺带替用户表达“我准备照着吃”。

这也会影响完成页该留下什么。历史沟通保留，方案仍然可以从订单里查看，继续发消息的入口则关闭。如果还需要后续服务，按这版规则重新购买，形成新订单。不能一边说订单已经结束，一边让输入框保持可用，给人一种原服务还在继续的预期。

还有一些承诺，这版选择暂时不写。购买页没有具体交付时间保证，因为还缺可靠的历史数据、服务时段和用户未回复时的计时规则。待接单页可以表达平台当时给出的预计接单时间，但接单和完成审核不是一回事，不能拿一个预计时间代替整段服务的承诺。

取消、退款和更换营养师也没有都做成用户端申请流程。一点五版本先留联系客服入口，由客服按订单状态和统一处理规范判断，原型不预设一定能退或能换。这是当前范围的选择，不是这些情况已经在真实服务里得到过验证。

回过头看，六月把服务展示出来是一个阶段，后来沿订单补齐资料和交付关系，是另一段工作。现有原型仍没有真实支付、真实人员分配和消息系统。能点到已完成，不能当作服务已经真的交过一轮。对我来说，下一步要核对的仍然很具体：营养师拿到的是否正是这次要审核的对象，用户收到的是否足以作决定，以及订单结束以后，那份还没采用的方案有没有被原样留下。