四周，是「活着」最短的诚实测试

有两个词经常被当成同义词用，而这个混淆会让项目失去证据：上线和活着。上线是一个日期，活着是一个带时长、带阈值的观察。

规则本身

上线后连续四周仍在使用，才算活。窗口一关，停用率超过百分之三十的功能进「未活」清单。这张清单是交付阶段的必备产出，不是失败的自白。

两个操作细节让规则成立。观察窗口不能被提前关闭，哪怕客户很满意、下一个项目在等。未活清单必须写下来，因为没有被记录的死亡无法变成教训：六段解剖的第六段不能空着，也不能写「无」，「过程顺利」不能当作没有死亡的证据。

激活不是上线

激活指的是目标用户在日常工作里形成了稳定的使用习惯。不是演示会上的掌声，而是三个月后没人催、系统依然被高频使用。挡住它的通常不是缺功能，而是三条：不顺手、不可信、跟他无关。

这个定义让激活成为行为指标，而不是表态指标。评审会上人人都说好用，另一个窗口里的表格还开着——表格才是数据。由此可以推出一条检验：如果系统只在厂商团队在场时才被使用，那不是激活，是伴舞。

上线取舍怎么排序

截止日期到了而完整范围没做完时，决定很少是「上或不上」，而是「上哪一片」。有一份最终验收把切口写得很具体：五十七项检查，三十六项通过、十八项失败、三项跳过。当时的读法不是「照上」，而是分割判决——最小 Demo 那一片可以上，完整版不可以。含糊的判决，无论偏哪边，都是把未验证的风险转交给生产环境。

四条规则给这个取舍排序：

1. 上线的那一片必须包含口径表里锁定的最高优先级指标。
2. 这一片的证据要走到业务端点，不能停在系统边界。
3. 这一片能在 FDE 不进循环的情况下被观察四周。
4. 被排除的东西写进书面的范围外清单，不写进口头承诺。

第二条是多数上线悄悄失败的地方。返回 200 只证明系统接受了请求，不证明动作完成，更不证明业务端点收到结果。证据必须从「接受」走过「处理」「完成动作」，一直到「业务端点收到」；四段里只有最后一段算上线判据。

值得挂在墙上的那个数

如果只能挂一个数，挂四周存活率：第四个完整周仍在使用的功能数，除以这一批上线的功能总数。把停用率放在旁边，因为三成那条线才是把比率变成决定的东西。

它不是验收指标本身。口径表决定每一行怎么量，这个比率只回答一件事：这些行加起来，还算不算活着。

挂在墙上而不是放进看板，理由是行为上的。健康分真正的用处不是那个分数，而是它逼着团队每周把所有客户挨个过一遍。没有人每周为它争一句的指标，是装饰。

这条规则不接受什么

它不接受一句没有数字、没有窗口的「在用」。也不接受上线那一周庆祝、很久以后才复盘，因为到那时所有人都记得上线，没人记得使用是哪一周停的。

它同样不接受相反的错，把死亡当丑闻。有一个记录在案的部署，最后没有一个死掉的子系统：二十三家门店的浪费金额降了一半以上，没有返工、没有中断，死掉的是「拍脑袋报配送量」这件事本身。这是正当结果，应该和失败写在同一段里。同一套方法里的另一个教学案例给出相反图景：三个交付物全死，三个不同死因——数据源不稳定、工作流改动幅度超过收益、只有 IT 负责人签字而没有业务方接盘。一个项目可以同时死于三种方式，所以复盘要点名死因，而不是清点尸体。

收官测试

第四周结束时问两句：哪些功能还在被用，其余每一个的停用率是多少。超过三成的，客户在会上怎么说都不算活。然后把这张清单带进撤离，因为一个没活下来的功能，不该被当成活的交给接班人。窗口本身由交付阶段定义，窗口里量什么由口径表决定。