从七天到一顿：一起吃饭，不必共用整份饮食方案

只是要安排一家人今晚的饭，为什么还得先决定谁退出自己的饮食计划？看家庭共餐前后两版的关系时，这个问题很难绕开。个人方案已经有了，家里也想一起吃，照原来的结构却只能选一边。饭还没开始排，先要处理两份计划谁生效。

七天家庭方案原本想解决的，是一家人怎么吃同一桌饭，而不是把每个人的菜单并排摆出来。要顾及不同成员的健康情况、过敏和忌口，也要知道哪些菜可以大家一起吃。以七天为单位组织，能把连续安排放到一起看，并不是一个完全没有道理的起点。

麻烦出在它同时成了一份需要成员加入、共同执行的方案。个人也有七天计划，家庭又有七天计划，再套上同一时间只能执行一份的规则，两边就撞上了。为了让执行关系清楚，只能要求个人和家庭之间切换。

这条限制不是吃饭本身要求的。它是两份七天方案摆在一起以后，产品为了处理冲突补出来的条件。

七月二十七日的调整，改的就是这个地方：家庭共餐不再是一份七天共同执行的方案对象，而是由家庭主理人选择一起吃饭的人、日期和餐次，按顿定制。个人计划可以继续留着，参加某顿家庭共餐，不占用那一份个人或专项计划的位置。

我觉得这比把页面上的“七天”换成“一顿”要多改一层。如果只是生成天数变少，成员仍然要先加入另一份计划，原来的冲突还在。真正需要拿掉的是计划之间的整体切换，让决定回到某一顿饭上。

不妨用一个假设来对照。一个人已有个人饮食计划，只准备周二晚饭在家和家人一起吃，周三午饭仍按自己的安排。旧关系要求先说明他此刻属于哪份计划；按顿以后，只要说明周二晚餐跟家里吃，个人计划不必因为这一次共餐被整份替换。

这不表示同一顿可以同时执行两套安排。新版保留的是个人计划与家庭共餐并存，具体到一顿，仍要分清这顿按个人计划吃，还是跟家里吃。否则两份菜单都留下来，用户还是不知道该看哪份。把整体互斥取消以后，这个更小的对应关系反而要交代得更明白。

今天为谁做饭

旧版先确定一批成员，再生成七天方案。新版仍然要先确定参与者，只是这个动作不再意味着把人放进一份长期共同执行的计划。“今天为谁做饭”比“谁加入家庭方案”更贴近这次要处理的事情。

参与成员按顿可以不同，这个变化会往后影响很多地方。继续沿用刚才的假设，周二晚餐是三个人，周四晚餐只有其中两个人，那么两顿饭汇总的约束就不应不加区别地沿用。这里不是说少一个人就一定能换某道菜，而是这桌饭要照顾谁，需要重新明确，不能由家庭通讯录代替。

家庭成员列表表示家里有哪些人，参与者列表表示这顿谁来吃，两者有关联，却不是同一个范围。资料填得完整，也不代表已经选好参与者，更不代表已经有一份共餐安排。把这些状态分开，页面才不至于在档案完成后就显示出“饭已安排好”的意思。

选了人，才谈得上综合他们的健康约束。健康情况、过敏、忌口需要结构化，不能只有一段自由填写的描述，然后期待系统自然理解“这桌饭要照顾的”是什么。原型明确了这个方向，但这还不是一套已经能正确处理所有家庭差异的营养算法。

我更在意的是资料不要因此多出一份。共餐需要用到家人的档案，不等于共餐页应该再做一个编辑器。新版仍然让档案页作为唯一的编辑入口，成员资料保持同一来源。否则个人那边改了忌口，家庭这边还留着旧值，入口虽然更方便，下一顿饭用的却可能不是同一份信息。

可以一次安排几餐，但要知道是哪几餐

按顿不意味着只能一顿一顿重复操作。新版允许一次选一天或多天，也允许选一个或多个餐次。主理人可以一次把接下来几次共餐排进去，但每份安排最后仍要落到具体日期和餐次上。

日期相同，午餐和晚餐可能不是同一批人；餐次相同，不同日期也可能有不同的参与者。只写“这几天的家庭菜单”，这些差异就又被揉到一起了。我看这版流程时，会把日期、餐次和参与成员放在一起核对：这份菜单具体是哪顿的，谁会跟着吃，和这个人原有计划里的哪一顿对应？

这种对应也不应该悄悄改写过去。新版取消了计划对象层面的切换，但历史餐次仍保留原归属。一个人后来参加家庭共餐，不意味着他之前按个人计划吃的饭都变成家庭记录；下一顿不再参加，也不需要把前一顿的记录挪回去。

原来的“增减成员就重新生成整份家庭方案、形成新版本”，在这个模型里也不再沿用。每顿本来就独立定制，变化应该先落在相关餐次上。不过，这不能直接推出所有修改、覆盖和取消操作都已经设计完了。原型说明了新的组织关系，具体页面怎样防止误改，还需要沿着实际操作继续核对。

这也提醒我，不要把“按顿”理解成把原来的七天方案切成七天乘几餐的小格子就结束。格子里仍然需要有人、有日期、有这一顿的安排。缺少它们之间的关系，只是把一个大对象拆成了许多小对象，并没有让使用者少作不必要的选择。

至于共餐的内容，目标也没有变成每位成员单独生成一套餐。还是一桌共同吃的菜，再根据参与者调整选择、份量和做法，必要时说明某道菜针对哪位成员作了特殊调整。要是最后输出三份互不相关的菜单，虽然每个人都有结果，家庭主理人面对的仍是分别做三顿饭，离共餐的任务又远了。

个人记录也没有顺手塞进来。家庭共餐只保留共同用餐记录，不提供逐成员个人打卡。主理人能安排这桌饭，并不因此就能替每个人报告实际吃了什么、吃了多少。我觉得暂时守住这个范围是有必要的，否则为了让数据看着完整，反而容易让一条家庭记录承担它没有表达的信息。

服务页后来用“个人饮食”和“家庭共餐”作为两个顶层入口，也是同一变化的延续。进来先选这次怎样吃，再去选涉及的人，比先切到某个人、再猜他的家庭安排在哪里更直接。家庭食养改名、入口提升可以在界面上很快看出来，但对我来说，真正值得对照的仍然是个人计划有没有被保留。

这次还只能谈原型里的关系调整，没有真实方案生成、营养计算或持久化，也没有用户实际尝试后的反馈来证明它更好用。它至少去掉了一条原先由方案结构带出来的限制：为了今晚和家里吃饭，不必先放弃自己的整份计划。接着往下看原型时，我会先找周二晚餐落在哪里，再找周三午餐是否还在原来的安排里。两顿都能说清楚，才算把这次变化表达到了用户面前。