食养会员到期，不该让已确认的共餐安排作废

假设一家人把周末的共餐安排好了，菜单已经生成，也确认采用了，还没到吃饭那天，家庭会员先到期了。再打开产品，原来那顿饭还能不能看，还能不能照着准备？

如果只看账号状态，答案很容易变成不能。家庭共餐是会员能力，会员到期，入口就锁起来。但站在准备这顿饭的人那边，他并没有要求产品再排一桌菜。他只是想接着用已经确认的那份安排。

我看餐参的会员规则时，觉得这里不能只留一个“到期”判断。套餐是不是有效，和一份已经获得的服务还能不能继续，是两件需要分别回答的事。前者决定能不能开始新的服务，后者关系到原来的事情会不会做到一半被收走。

这也是我理解食养会员与内容订阅有些不同的地方。菜单不是看完就结束的一篇文章。用户确认以后，后面还有采购、备料和吃饭，产品给出的安排已经可能影响到线下准备。不能因为这些动作没有发生在页面上，就当作它们不存在。

已经确认的那顿饭

八月十日的会员产品规则，把家庭共餐的保护条件写得比较具体：会员到期前已经生成并确认的安排，继续查看和执行；不能新增、重新生成或安排新的家庭共餐。

这里的“生成”和“确认”，我觉得一个都不能省。

生成说明产品已经给出了结果，确认说明用户选择了这份安排。如果只写“已生成的继续使用”，一份还在比较、没有决定采用的候选，也可能被算进去。如果只写“已有安排不受影响”，读的人又不知道草稿、候选和已确认结果是不是同一种安排。

回到开头那个假设，用户打开原来的共餐详情，查看菜品和准备信息，延续的是原来的结果。假如他想把参加的人换一批，再让系统重新排一次，就不能因为从同一张页面进去，仍然算作查看旧安排。页面没有换，不代表服务没有变。

我不想把这种区别藏在按钮点下去之后。看原来的菜单时突然弹出购买提示，很容易让人以为旧结果也被锁住了；所有按钮都照常开放，又会让人以为家庭会员仍然有效。比较合适的表达，应当让用户在操作之前就知道：这份已经确认的安排可以继续，新的安排需要重新具备家庭会员权限。

这不是已经验证过的页面效果，是我沿着规则看界面时会提出的要求。具体哪个按钮保留、哪个动作需要拦截，还得逐项对上，不能靠一句“到期保护”替它们作答。

两份文件之间，还有一句话要核对

问题没有到这里就结束。八月十二日的会员需求文档，第十三章用的是另一种表达：已经开始执行的个人食养周期、家庭共餐周期，可以继续完成。页面提示也是“会员已到期，本周期仍可继续完成”。

“到期前已经生成并确认”和“已经开始执行”，并不完全一样。

一顿饭已经确认，但安排在到期之后，算不算已经开始执行？如果一个家庭安排里有多顿饭，是第一顿开始就算整个周期开始，还是要分别判断？前一份文字直接覆盖了已确认的安排，后一份把保护范围放在已经开始的周期上。这一点不核清楚，同一个例子就可能得到不同结果。

八月十日文件的覆盖说明指向八月十二日文档的最新修订，不能因此在文章里把两句揉成一个更顺口的承诺。后续文档有优先级，不等于两种措辞已经没有差别。我能确认的是，前一版明确写过保护已生成并确认的家庭共餐；后一版采用了已开始执行周期的口径。具体到“已经确认、尚未开始”的情形，仍应核对最新规则要保护到哪里。

这不是挑字眼。它会影响一顿尚未到时间的饭能否继续，也会影响页面要保存什么状态。若开发只拿到“已开始”，产品侧却一直按“已确认”解释，双方都可能觉得自己照着文档做了。

对我来说，这种时候宁可把例子留下来，不急着把段落修得毫无缝隙。把待确认的条件写清楚，比提前宣布已有统一口径更有用。

保留结果，不等于延长全部会员权益

另一处容易混的是，把这项保护理解成会员宽限期。既然原来的共餐还能用，是不是其他家庭服务也该继续？

八月十日那版规则没有这样写。它区分了已有结果与继续生成的能力，也区分了用户自己的资料与会员服务。健康档案、身体指标和手动记餐可以继续使用，历史方案、周报和菜谱可以继续查看。它们不是为了催续费才临时放开的东西。

这个出发点我认同。用户的资料留在产品里，不能因为没有续费，就突然变成需要重新购买的资料。可是历史结果保留，也不能自动推出可以不断生成新方案。前者是在保留已经形成的东西，后者要求产品继续提供服务。

拿家庭共餐来说，“再看一遍”和“再排一遍”在口语里只差一个字，产品要做的事情却不同。看一遍，是取回原来的安排；排一遍，要重新处理这次的成员、日期、餐次和相应约束。即使最后生成的菜看起来相似，也不能因此把后一个动作归入旧安排的查看权限。

还有一个我不愿跳过去的情形：原来那份安排需要变了，怎么办？比如用户不再打算按原来的成员组合共餐。保护旧结果的规则，并没有顺带承诺到期后可以免费重做。此时既不能暗中给他生成新的，也不能一句“原方案还能用”就忽略条件已经变化。涉及新安排的部分，要回到新服务权限和相应业务规则里判断。

把权限拆细不是为了多拦几次，而是避免让一个笼统的状态替所有动作作决定。有的地方应该继续，有的地方应该停。用户需要知道停在哪里，以及为什么停在这里。

到期不是把所有事情清零

从产品经理的角度，我更在意的是时间不一定对齐。会员按套餐计算有效期，吃饭按具体日期发生，个人食养又有自己的七天周期。不能要求所有服务恰好在会员到期那一刻一起结束。

如果一定要整齐，最简单的做法就是一到期全停。但这种整齐只方便系统解释，未必方便用户继续原来的生活安排。反过来，无限延续也不合适，那就失去了新服务与旧结果的边界。规则要处理的恰恰是中间这一段：已经答应完成的事情，做到哪里算完成。

这也解释了为什么原型里的到期提示，只能证明一种表达可以被看见，不能证明正式系统已经处理好了所有情况。文件里把真实支付、权益校验、时间任务和跨设备同步留给后续正式系统设计。演示时切换到“已到期”，和一个账号真的在某个时间跨过到期点，证据不是一回事。

我现在愿意保留的判断很具体：讨论会员到期，不应先问哪些页面都要锁，而应先拿出一份用户已经确认的安排，看看他接下来本来要做什么。新服务可以有明确的购买边界，旧安排也应该有清楚的保护范围。至于“已确认但还没开饭”到底按哪一版处理，这句话还需要核实，不能由一篇文章替产品作出最后决定。