食养原型一路都能点通，离真正可用还差什么

一份家庭菜单生成了，点采用，出现成功提示，再到计划里看到它。只沿着这条路走，原型已经能把事情讲明白。

但如果菜单生成以后，有一位参与的家人退出了呢？页面还停在刚才那份结果上，采用按钮也还在。这个时候继续点下去，看到成功，证明的是按钮有反应，还是这份菜单真的可以成为接下来要吃的安排？

我看食养规则与原型的差别，越来越愿意从这种中间发生了变化的地方看。正常路径不一定有错，它只是把条件保持不变了。真要做成可以持续使用的产品，就得接住人、资料和时间不再停在原地的情况。

九月这轮核对里，方案采用、记录删除、成员变化这些规则之间的冲突已经修正，规则层面的校审通过了，可以继续往下推进。这一点需要说清楚，不能因为页面还没补齐，就把已经确认的处理方式又说成没有定论。

对我来说，接下来要追的是这些约定怎么出现在用户面前。页面有没有表达，操作以后有没有真的生效，再次打开时结果还在不在，都需要分别检查。规则已经接上了，不代表原型、开发和验证也一起完成了。

点采用之前，还得再看一次

家庭候选方案采用前复检，是我觉得最能说明这种距离的边界。

生成菜单时，系统使用了当时的参与成员和健康资料。结果出来以后，用户未必立刻采用。哪怕只隔了一段时间，家庭关系、会员覆盖、档案完整度或健康情况，都可能已经改变。

按这轮已经确认的规则，正式采用前要重新检查全部参与成员。退出或被移出、失去覆盖、档案不足，以及需要重新评估的健康变化，会阻止采用，需要调整成员后重新生成。一般提醒类的变化，则可以提示后继续采用。

这不是所有变化都一律拦住。哪些是提醒，哪些会让原候选失去采用条件，规则已经作了区分。原型要表达的也不只是多加一个确认弹窗，而是当前到底发生了哪一种变化。

如果弹窗只问“确定采用吗”，用户点确定，并不能把一个已退出的成员重新放回家庭，也不能证明原来的健康资料仍然适用。让人确认意愿，与系统确认条件成立，解决的不是同一个问题。

但当时核对的原型，只能临时保留一份当前家庭方案，再次采用就把它整份覆盖。它还不能区分前后两份候选、在采用前复检，也没有把方案与历史长期保存下来的处理。页面上已有覆盖确认和已替换提示，能告诉人刚才做了什么，却还不能回答眼前这份方案现在能不能用。

我觉得原型在这里仍然有价值。它让人看见采用前后怎么走，也方便讨论提示放在哪里。只是不能让一个成功提示替尚未实现的检查作证。否则交接给下一位时，他看到的是流程已经完成，真正缺的条件反而不容易被问出来。

删除一条记录，不只是让卡片消失

另一个边界是饮食记录删除。单看界面，很容易把它理解成一个按钮、一段确认文案，然后列表少一张卡。

规则处理的事情要多一些。本人或者仍有权限的主理人，可以删除最近七天的记录；删除成功后，要撤销这条记录带来的打卡和营养贡献，餐次再根据当前时间恢复为待执行或无记录。删除前的内容只作内部留痕。

假设用户把晚饭记到了午饭，发现以后想改正。按这版规则，不能直接把记录移动到另一个日期或主餐，而是先删除原记录，再在允许的最近七天范围内重新记录。

这个处理未必是所有产品都会选的方向，但它是当前已经确定的边界。原型不能为了演示顺畅，顺手加一个“移动到晚餐”，然后让后续实现把它当作现成需求。

我会特别看删除后的午饭还剩什么。如果卡片没了，打卡却还亮着，用户看到的两个地方就在说不同的话。如果营养汇总仍算着原来的内容，下一次总结也会继续引用一条已经被撤销的记录。删除不是只影响它所在的列表。

餐次回到什么状态也不能随便设成未完成。未来还没到时间的一餐，可以待执行；已经过去而没有其他有效记录的一餐，是无记录。后者不等于没吃。用户是在纠正数据，不应该因为删除操作，被产品额外判了一次没有完成。

这类问题不靠把页面点得更快就能发现。需要从删除按钮往外看：哪里引用过这条记录，哪里显示了它的贡献，操作人的权限此刻还在不在。当时的饮食记录原型还只能在一次打开的演示里走通，删除、补记过去的饮食、区分操作人，以及权限失效后的处理，都没有补齐。我会把这些继续留在待办里，不能因为列表已经能显示记录，就把记录管理这一段划掉。

家人退出了，剩下的饭不能照旧算

采用前检查完，也不代表后面永远不用再管。已经采用的家庭方案，如果在未来餐次之前发生阻断变化，规则要求保留已过历史，但整份方案的全部未过餐次停止作为有效家庭菜单，需要重新生成并采用。

这比“把退出的家人从名单里删掉”影响更大。

我理解它的原因在于，家庭菜单本来就是针对一组人生成的。名单变化以后，不能只改变页面上的参与人数，就假定菜单仍然适合现在这桌人。规则明确不允许只移除变化成员后继续用旧菜单，也不是只停掉与那个人有关的某一道菜。

同时，过去已经进入历史的餐次不改写。一个人今天退出，不能让昨天那份安排看起来从来没有照顾过他。未来是否还能使用，和过去发生过什么，需要分别保存。

这对界面的影响不止一行“成员已退出”。用户可能正在看菜单，也可能已经打开采购清单。如果菜单不再有效，清单却仍像之前一样引导他采购，流程各自能点通，合起来还是矛盾的。当时的采购页正是从那一份当前家庭方案计算内容，还没有补上菜单失效时停止沿用清单、方案替换后处理清单的逻辑。

因此我不太愿意拿“页面齐了”当作这一段的完成标准。真正需要跟过去的是同一次变化：它怎样影响未来安排，旧历史为什么还能看，下一步怎样重新生成。不是每一页各补一段说明，就能自然接起来。

还有一些问题，测试暂时没能回答

看到测试里有通过，也有大量失败，我更想知道的是，它到底检查到了哪一步。当时针对相关功能的测试确实跑过，但多数页面组件的检查还没走到判断产品行为对不对，就被测试环境的故障挡住了。

这让我没法直接拿失败结果判断产品有多少问题，也不能因为原因出在环境，就当作功能已经过关。采用时有没有拦住失效方案，删除后汇总有没有撤销贡献，仍然需要等环境修好、重新运行以后才能核对。对产品经理而言，这里该留下的是尚未得到答案的问题，而不是给整份结果简单贴一个通过或失败的标签。

专业和法务依赖也没有随规则校审一起消失。营养估算、过敏原映射等需要专业数据，家庭健康资料共享需要相应依据，照片与删除留痕的保存期限也还要外部承接。原型用固定示例可以展示结果，却不能因此证明这些前提已经解决。

下一次再看采用按钮，我想先保留那份已经生成的菜单，让参与条件发生变化，再看页面怎么回应。如果这时不能采用，用户需要知道该调整谁、从哪里重新生成，而不是反复点一个没有解释的按钮。这一步还值得继续往下做。