日落条款，第一天就写

撤离是所有人都放到最后规划、因而都规划得很差的一个阶段。解法是把日落条款写在启动时：它不是违约退出条款，而是「一次交付怎样算结束」的定义。它放在项目章程第一页，故意不放进合同——终止条款读起来是威胁，项目定义读起来是约定。

五项字段

字段	必须写清什么
触发日期	自验收日起满 X 个月，六到十二个月之间。项目周期三个月以内取六，三到六个月取九，超过六个月取十二。
评审输出	日落评审要交出三张清单：功能存活清单、待交接工作清单、待撤离人员清单。缺任何一张，视为撤离未完成。
延续条件	只有客户书面同意才加 X 个月。口头同意不算，未签字的聊天截图不算，未签字的会议纪要也不算。
压缩例外	只认人身安全或重大公共利益，且必须留下记录。除此之外没有加速通道。
撤离后角色	FDE 从「工作流的一部分」转为「应急联系人」：工作时间内四小时首次响应、二十四小时给处置建议，非工作时间十二小时与四十八小时。退出条件是客户书面表示不再需要，或日落评审后满 X 个月没有应急请求。

第二项在实际操作中最容易被软化。「评审输出」听起来像一场会，其实是一份交付物清单；只交出两张清单的撤离，就是没撤完。

为什么写在章程，不写进合同

它是共同预期，不是执行手段。放进合同，它宣告这段关系有终点——事实如此，但读起来像筹码。放在章程第一页，它宣告「做完」长什么样，同一件事实，没有威胁的口气。

延续条件也只有在没人需要它的时候先谈好才有用。客户在临近触发日时才第一次听说这场评审，他会把它当成一张意外的账单；在启动时读到过的客户，会把它当成自己签过的排期。

撤离的顺序

四步，顺序固定：交接、断奶、四周法则、日落触发。

交接排第一，因为后面每一步都依赖它。接班人手册由接班人写，不由 FDE 口述代笔。这条规矩看起来低效，恰恰是全部要点：FDE 写的手册什么也检验不了，因为要被移走的就是 FDE 本人。接班人写不出来，说明组织没有学会这套系统，诚实的读法是这次部署还没完成。

断奶按风险从低到高，每撤掉一环观察一次，再撤下一环。四周法则必须已经通过，这也是交付阶段的观察窗口不能为了赶撤离日期而缩短的原因。最后才是日落评审，产出那三张清单。

有一个记录在案的合同展示了另一端的样子：客户核心对接人失联，三项合同任务同日逾期，fallback 写进了待办，却没有完成记录。这是六型死因里的第五型——唯一的推动者走了。日落条款拦不住一个人离职，但一个具名的延续条件和一份评审输出清单，能让这次消失出现在排期上，而不是出现在结尾。

什么留给客户，什么带回产品

留给客户的是：跑着的系统、接班人手册、它现在支撑的工作流，以及背后的数据。客户应该能在不打电话的前提下操作它、扩展它、解释它。

带回产品组织的是另一半工作。六段解剖，第六段要有具体死因，不能写「无」。至少一条方法库条目，五个字段齐全：触发场景、失败模式、识别信号、避免动作、边界条件。脱敏三层——实体、数字、时间——任何一层不过，条目就不成立。再往后，是可复用组件，和越来越小的定制面。

最后这一项才是在检验这套模式到底有没有成立。一个健康的部署业务，标志是每个后续客户的定制量递减。这个数不降，做的就是按人天计费的外包，只是换了一套更好听的说法。

成功的样子：不再被需要

这个角色自己的判据是反的：客户哪天不再需要你，才说明你干成了。事后版的检验是，团队撤场之后系统是否依然被使用；如果不是，发生过的叫陪伴，不叫激活。

所以日落条款不是终止条款。它是那份约定里让「做完了」有日期、有评审人、有归档的那一部分。启动时把五项字段填满，指定评审人，把触发日期放在客户在需要它之前就能看见的地方；然后在评审前跑一遍四周法则，让附件对承诺保持诚实，按五阶段方法的固定顺序完成交接。