云汇纪恒VOLUME IV · METHODOLOGY
FDE 工程手册
卷四 · 方法：五阶段全流程
有一家烘焙连锁的老板，发来三十页需求文档，目标是「降低浪费率」。我第二天到了现场，第三天拿着第七个问题的答案去找他，说原报价作废，我们用另一种方式做。零硬件投入。
开篇
有一家烘焙连锁的老板，发来三十页需求文档，目标是「降低浪费率」。我第二天到了现场，第三天拿着第七个问题的答案去找他，说原报价作废，我们用另一种方式做。零硬件投入。
后来这件事做成了，那一年按客户的口径算，省下来的钱是七位数。这件事的整个过程里，我没有一次用过三十页文档里那套方案。
这一卷讲的就是那条另辟的路。它由五个阶段构成：侦察、定义、交付、回灌、撤离。这五个词在不同的书里被叫过不同的名字，但组合起来只回答一件事——一个 FDE 在客户现场，怎么活下来，并且活成下一单的资产。
这本书到这里，卷一讲的是时代，卷二讲的是这个岗位是什么，卷三讲的是诚实与立法者思维。卷四把前三卷的判断翻译成一份可以照着干的工序。这一卷是全书工序那一侧的核心。
引言 为什么先讲方法论
先把承重论断摆出来，因为它决定了这一卷后面每一页怎么读。
第五章到第九章的顺序不能换。
侦察不够就进定义，等于在沙地上画施工图。定义不收敛就进交付，等于在合同里埋地雷。交付完不撤离，等于把项目做成了赘生物。交付完不回灌，等于把方法论做成了单次生意。
这一句话是这本手册全部方法论的地基，可以被压缩到五个字：不可越律。它在卷三的立法者思维里有一行对应物——死亡条款。在卷一的执行成本分析里有一行对应物——瓶颈前移。卷四把这两行展开成五个可被叫停的闸门。
再补一句关于这一卷为什么是全书核心。
前面三卷，时代、定义、原则，它们解决的是「该不该做」和「凭什么做」。但 FDE 这件事在中国现场最稀缺的是工序，而非判断。一百个方向正确的人，中间九十五个死在执行上。死法不复杂——切入的时间不对，报价的口径不成立，交付到一半客户换了负责人，回灌没做完就开了下一个项目，撤离没做干净被拴成长期外包。
每一个死法都对应这一卷的一个阶段。每一个阶段都对应一条判据。判据当场可执行，被执行就可以被否决。
在展开正文之前，先把外部的统计坐标定一下。2026 年公开的几份调查里，独立机构给出的数字在同一方向上叠合：
- 试点转生产： 约 88% 的企业 AI 智能体试点走不到生产环境。
- 项目回报： 约 28% 的 AI 项目「完全产生回报」，其余 72% 分布在回报不足的区间。
- 损益影响： MIT NANDA 对 150 位高管与 350 位员工的调查发现，约 95% 的试点没有可测量的损益影响；差别几乎不来自模型质量，而来自接近方式。
来源：
1. Turion.AI《Enterprise AI Agent ROI: The 2026 Reality Check》（2026-05-06，公开报道），汇总 Forrester/Anaconda 与 IDC/Lenovo 数据；本卷仅引用统计结果，不展开机构口径细节。
2. Gartner Q1 2026 Infrastructure & Operations Survey（2026-04-07，公开摘要），Agent Mode AI 复述。
3. MIT NANDA《State of AI in Business 2025》，Agent Mode AI 与 Webber Wentzel 文档复述。
失败原因的拆解也指向同一个方向：
- 工具调用错误、记忆与状态问题、未处理的边界情形，三者合计约占事故的 68%。
- 公众讨论里最常被点名的「幻觉」，约占 12%。
来源： Presenc AI《AI Agent Failure-Mode Statistics 2026》（2026-05-07，公开数据汇总）。
这些数字告诉一线从业者一件事——绝大多数死法不在模型那一端，而在部署纪律那一端。卷四要做的，就是把部署纪律翻译成一份可以照着干的工序。
第五章 侦察：找到真问题，而不是被指定的那个问题
侦察阶段回答一个问题：这件事三个月后彻底失败，谁受伤最重。
这一问题的答案决定 FDE 的姿态——是接单做项目，还是先停下三件事再动：报价、判断、方案。
侦察的退出条件只有一条：七问清单中至少一条已被现场数据验证。这条未达，侦察不结束，强行进入下一阶段视为违规。
侦察有三个固定动作——七问清单、三张图、影子系统识别——以及一个翻译动作：从描述剥出执行。四个动作按序执行，跳问、合并、提前全部削弱信号。
开篇故事中的「三十页需求文档」具体是哪几节。
三十页文档的具体节标题未在磁盘证据里留存。下文用客户行业的通用文档骨架替代抽象那一份的还原。烘焙连锁的文档大致包含这些节（顺序与命名按行业通用惯例，本卷不引用具体节标题作为证据）：
- 现状描述——各门店的报损金额区间与门店数。
- 目标陈述——「降低浪费率」一句话。
- 期望方案——视觉识别、客流统计、电子价签等多条并列选项。
- 数据采集说明——期望新增的传感器与摄像设备清单。
- 算法描述——客流曲线、时段分析、报损预测等术语罗列。
- 集成与对接——与门店 ERP、总部财务系统的对接方案。
- 工期与报价——按节估算的工作量与人天。
- 验收口径——「报废率下降 X%」一类语句。
- 风险与免责——数据所有权、模型偏差、合规责任。
- 附录——产品参数、设备型号、合作案例。
三十页里有大约三页在做决策，其余二十七页是在描述客户听到过的方法与卖过的产品。开篇那一幕「第三天拿着第七个问题的答案去找他」，之所以敢推翻前两节文档里的整套方案，是因为第七问给出的信息比前二十七页都更接近真问题。卷四侦察阶段反复回到这一句话上：文档不是答案，文档是客户曾经接触过的路径。路径不等于真问题。
5.1 七问清单
七问清单是一份固定顺序的问题集。没有一个关于技术。出处：序章下第九章。卷四逐问展开。
七问清单在传统软件工程的「需求获取」（requirements elicitation）学术语汇里，属于最早期的方法家族：访谈、现场观察、文档审阅。它与传统做法有两点关键不同：
- 对需求位置的假设不同。 传统需求获取假设「需求已经在那里等着被取出来」；七问清单认为真正的需求在文档之外，在三张图和影子系统里。
- 最终产出不同。 传统需求获取的产出是规格说明书；七问清单的产出是侦察工单，里面空着的格子就是下一步任务单。
这两点不同让七问清单在 AI 时代变得更值钱：模型可以读文档，但模型读不到三张图与影子系统。这一段把七问与古典 elicitation 方法家族的关系点明，是为了让一条早已存在的工程传统不被遗忘，同时让这条传统在 AI 时代被重新定义边界。
第一问：这件事三个月后彻底失败，谁受伤最重？
这一问定甲方。任何一个项目的推动者名单上，可能有七八个名字，但真正能定义「受伤最重」的那个人只有一个。他的痛点跟项目目标之间有一条等价关系——他感受到的痛，跟 FDE 想要解决的痛，必须是同一种。
这一问经常被错答。错答有两种形态：把「谁最支持这件事」当成「谁受伤最重」，或者把「老板」当成他的下属感受痛。两种错答都会让项目在第一周就站错位置。
在一家烘焙连锁的案例里，这条问的答案指向「总部配送负责人」——只要配送量继续拍脑袋，他的 KPI 完不成，但他没有权力改这件事。
素材来源： 案例六段稿-脱敏版 A6 第一段、第六段，脱敏口径：地点全抹、岗位代替姓名；公司真实数字按用户口述确认。
识别出这一岗位之后，所有后续动作围绕他的真实工作流展开。
follow-up 脚本（建议在侦察头两天问出）：
- 「这件事如果三个月后还是老样子，你会向谁汇报？你汇报时的口径是什么？」
- 「如果今天让你向你的上司承认这件事彻底失败，你会用什么词？那个词对应的部门目标是什么？」
- 「这条目标在你个人考核里占多大比重？其他几项加起来有没有比它重？」
三条追问把「受伤最重」从抽象的形容词拉回可被验证的具体场景。第一条锁定汇报链与口径；第二条拉出口径里的潜台词——通常带出 KPI 与岗位绑定；第三条锁定这位推动者是不是真正能感受到痛的人。如果三项追问回答前后不一致，说明第一问的答案尚未收敛，侦察继续。
第二问：过去两年做过类似项目吗？结果如何？
这一问拿暗礁图。一家公司从来不是第一次做这类事。每一次前任供应商留下的痕迹，都写在那套系统里、那批已离职员工的记忆里、那份没人愿意提的验收报告里。
错答的形态更隐蔽。客户说「没做过」或「做过但没成功」，这两种回答都需要追问。追问的方式是：你能告诉我当时做这件事的人是谁吗？他现在还在你这吗？接下来他说的话里，会出现大量被简化或回避的细节。那些细节里藏着暗礁。
这一问可以跟第一问合并成一段问，但意味着会失去两个独立的信号——支持者的真实性，与历史失败的真实次数。
follow-up 脚本：
- 「当时签合同的那家公司现在还在吗？那个项目上线了吗？上线多久了？现在还有人在用吗？」
- 「如果让那家公司的对接人写一段三句话的项目复盘，你觉得他会怎么写？」
- 「你愿不愿意让我跟那个人单独聊十分钟？十分钟就够。」
第三条尤其关键。前任供应商的对接人是暗礁图最便宜的获取路径。如果客户拒绝提供联系方式，暗礁图的获取成本会升高三到五倍。客户拒绝的原因通常比暗礁本身更值得记录——拒绝里藏着他对前任失败的羞耻、对当下合作的紧张，或对自家内部矛盾的回避。
第三问：做成了，谁手上的东西会贬值？
这一问进入第三张图（谁会输）。一个项目上线后被替代掉的旧工作方式，背后站着既得利益的人。新系统在技术上的优越性不会自动说服他们。
需要找出的是岗位，不是名字。岗位的其他职责占比，决定了应对策略。占比高的岗位（他的全部职能都建立在旧工作流上），高风险，需要在第一周之内把他变成盟友或让他上级明确表态。占比低的岗位，低风险，给一个能保住颜面的过渡方案就行。
错答的形态：以为这件事没人输。永远不会没人输。任何被新系统替代的劳动，最终都会变成某个人的时间。这条时间被挪用到一个新工作流里，这个新工作流的对接人就是天然的盟友。
follow-up 脚本：
- 「如果这套系统上线了，你现在每天上午十点前做的那些事会变成什么？还会有人做吗？做的人会是谁？」
- 「那位同事除了做这件事之外还做什么？占比大概多少？」
- 「如果他明确反对，你会站在哪一边？你有权力让他中立吗？」
第四问：这个部门的人每天早上第一件事是什么？
这一问见真实节奏。流程文档上的开始时间跟实际开始时间之间，经常有一到两小时的差额。差额的构成是：开会、刷手机、等系统、跟隔壁聊天。这段差额是实际工作的起点。
真实节奏跟流程节奏是两件事。FDE 第一次到现场必须看一次早上九点的前十五分钟——不在会议室里，在岗位旁边的工位上。
follow-up 脚本：
- 「你九点到工位后第一个动作是什么？通常几点开始处理今天必须做完的那件事？」
- 「如果九点之前有客户在群里@你，你会怎么处理？会记在哪个表里吗？」
- 「下午五点之后，下班前的最后一件事通常是什么？」
第三问尤其见真实节奏与流程节奏的差额。下班前最后一件事常常是某个无法推给次日的工作，这正是流程文档不会记录但影子系统会承载的部分。
第五问：公司里最不受欢迎的那张表是哪张？谁填？给谁看？
这一问见伤口。最不受欢迎的表，意味着每周都有一个人在填它但没有任何决策者因为它调整过什么。这是一份「流血的伤口」，也是最快的信任切入点。
填表的人就是潜在的盟友，因为他对痛觉最敏感。给谁看这一栏必须问——表有时候是给审计看的，有时候是给上层看的，有时候是给某个不存在的部门看的。给谁看决定了填它的真实动机。
follow-up 脚本：
- 「那张表上次因为内容改过决策是什么时候？谁改的？改了什么？」
- 「填表的人最近跟你抱怨过它吗？他抱怨哪一行？」
- 「如果你有权利把那张表扔掉，你会扔掉哪几栏？留下哪几栏？」
第三条会揭示一个常见但隐蔽的事实：表里的某些栏目对决策毫无意义，但因为填写惯性或合规要求而存在。这类栏目是工作流改造方案里第一批应当被移除的对象。FDE 在侦察阶段就应当识别它们，而不是等到定义阶段。
第六问：明天要替你做一个决定，我需要知道什么？现在存在哪里？
这一问直达影子系统。正式系统只记录官方叙事，真实决策依赖系统外的信息。影子系统是 Excel、微信群、手写台账、纸质单据、某个人的记忆。
这条问的执行方式是「现场看到」，而非「问出来」。FDE 应该能够打开员工的桌面，看到并行的 Excel 文件；能够进入微信群，看到非正式沟通的频次；能够在会议室的白板上看到还没有被擦掉的前一天讨论的痕迹。问出来永远不如看到。
影子系统的清单完成之前，禁止把任何工作流改造方案写到合同里。烘焙连锁这个案例里，影子系统的可见证据是「配送量拍脑袋」——每家店的要货量根据昨天的销售决定，不在正式系统里。
素材来源： 案例六段稿-脱敏版 A6 第一段、第二段。
这条影子系统本身就是六段解剖第二段（钱在哪漏）的入口。
follow-up 脚本：
- 「明天你替老板做一个决定，你打开的第一个东西是什么？电脑？手机？纸质本？某个群？」
- 「那个决定的信息是从哪来的？它最终会落到哪份表里？」
- 「如果我今天拿走你的手机和电脑，让你用纸笔把那个决定做完，你能做吗？」
第七问：内部有人反对过这件事吗？理由是什么？
这一问见盟友。真正反对过这件事的人，往往是这家公司里唯一说真话的人。他的理由可能过时、可能偏激、可能带着部门利益。但他敢说出来，意味着他在这家公司里至少还有说话的窗口。
找到这个人，请他吃饭。这一步是整套方法论里成本最低的一步，同时收益最高的一步。反对者掌握的信息密度通常高于支持者，因为他必须不断修正自己的反对理由，以应对被驳斥。
错答的形态：以为「没有反对」是好事。没有反对只意味着两种情况——这件事没人在意，或者所有人都在意但没人敢说话。两种情况都属于高风险。
follow-up 脚本：
- 「能给我一个名字吗——在这家公司里，最早、最坚定反对这件事的人？」
- 「他的反对理由里，哪一条你觉得其实是对的、但被忽略了？」
- 「我能请他吃顿饭吗？你不用在场，地点也可以我来选。」
这七问的提问顺序是设计过的，不能改。第一问定甲方，第二问避地雷，第三问开三张图，第四问见节奏，第五问见伤口，第六问见影子系统，第七问见盟友。跳问或合并都削弱信号。
5.2 三张图
三张图是侦察阶段的核心产出。三张图画完再动方案，画不出「谁会输」等于没看见风险。
第一张：钱怎么流。
写四件事。预算科目从哪儿来、谁批、批的额度上限是多少、超过上限走什么流程。最后一条最关键。报价落在上限上面一点点，会拖三个月；落在下面一点点，可能两周就签了。
这一张图的口径常见错误：以为预算是变量的。预算经常是常量，日历才是变量。某公司三十万以上要上会，每季度开一次。一个四十八万的报价，被一次季度会议卡五个月。
第二张：权怎么走。
写两层。
明面层——架构图上的汇报线。
实际层——这件事真正拍板的是谁，他凭什么能拍板。
实际层那一行必须写「凭什么」。凭什么的常见答案：他是老板的亲戚，他是元老，他手上握着最大客户的关系，他是唯一懂那套老系统的人，他管着钱。
最后一种最好办。最难办的是倒数第二种——那个唯一懂老系统的人，他的权力来源就是这套系统没人能碰。FDE 动这套系统，等于动他的命根子。
第三张：谁会输。
写得非常具体，具体到岗位（不写名字）。某岗位当前每周投入约 X 小时在某事上，项目上线后该工作量归零。该岗位在公司内的其他职能占比约 Y。风险等级高/中/低。
最后那一行不是走过场，它决定实施顺序。高风险岗位要么先变成盟友，要么在项目开始前让上级明确表态。绝对不能假装这个问题不存在，指望靠技术绕过去。
识别技术性反对和利益性反对的语言差别。技术性反对是具体的、可解的、会给方案的——「这个接口的并发扛不住，你得加个队列」。利益性反对穿上技术衣服之后是发散的、不可解的、每解决一个就长出一个新的。判断标准很简单：数一数已经解决了几个。解决到第三个还在长新的，那就不是技术问题，停下来去找那个人单独吃饭。
5.3 影子系统识别
影子系统是侦察阶段识别完成、定义阶段改造完成、交付阶段拆除——如果它可以被拆除——的一个对象。
识别方式有三种。第一种直接问第六问。第二种现场观察员工屏幕。第三种查会议室白板残留。
影子系统的清单完成之前，禁止把任何工作流改造方案写到合同里。理由：工作流改造方案必须基于真实业务流，而真实业务流只有影子系统能记录。
影子系统的常见形态：私人 Excel、微信群传输、纸质单据、手写台账、某个人的记忆。形态本身不重要，重要的是它代表的——正式系统在那个环节失效，而失效的原因通常是那个环节的真实规则没法被填进表单里，技术极少是首要原因。
改造方案按这个理解展开：如果一个影子系统能被并入正式系统，改造可行；如果它必须消失才能让新工作流跑通，那它在消失前必须先被替代，不能留空窗期。
5.4 从描述剥出执行
客户描述的是希望与症状，FDE 翻译成可执行动作。翻译不出来就回侦察，不把翻译不下去的部分写进报价。
烘焙连锁这个案例里，客户描述的是「我们要预测每个门店每个时段卖多少蛋糕」——这是症状。翻译成可执行描述是「客流曲线 × 门店点位特征 × 产品保鲜窗口 → 逐店逐时段需求模型」——这是可执行动作。两者之间差着三个动作：客流曲线取数、特征建模、保鲜窗口测量。三个动作都有具体的工程实现路径。
翻译的动作清单通常不写在一份文档里，而是写在 FDE 自己的判断日志里。判断日志的格式固定：第一周判断、实际情况、第几周因为什么信号发现。第三行是它的全部价值——结论会过时，信号不会。
5.5 侦察阶段常见死法
侦察阶段的死法有四种，按出现频率排序。
第一种，七问跳问或合并。后果是信号削弱，进入定义阶段时发现关键空白——谁受伤最重、暗礁图、谁会输——这些格子是空的，无法报价或报价后被驳回。
第二种，三张图漏张。后果是合同里埋雷。最常见的是漏「谁会输」——项目上线后被高风险岗位隐性抵抗，六个月后被悄悄下线。
第三种，影子系统未识别。后果是工作流改造方案跟真实业务流错位。常见表现是系统上线后没人用，因为新流程绕开了真实决策路径。
第四种，翻译动作在路上丢。客户描述里有一部分 FDE 没听懂就过去了。后果是方案完整但执行路径残缺，到交付阶段才发现关键模块无法实现。
5.6 侦察阶段验收判据
侦察完成的唯一条件：七问清单全部回答且至少一条被现场数据验证；三张图绘制完成；影子系统清单完成；核心症状已翻译为可执行描述。
七问清单未答全的格子必须空着，不许编。空着的格子本身就是侦察下一步的任务单。
5.7 侦察阶段案例佐证
案例一：烘焙连锁（A6）——七问清单与影子系统。
侦察背景：客户发来三十页需求文档，目标「降低浪费率」。第七问答案让原报价作废。
素材来源： 白皮书 m2-原则与方法.md 第四章引言。
第七问不能直接公布，但第七问的执行路径与结论有一段被记录：配送量拍脑袋是这家公司的影子系统。
素材来源： 案例六段稿-脱敏版 A6 第二段。
三张图第三张（谁会输）的可见部分：凭经验报数的岗位会输——工作量被数据口径替代。
素材来源： 案例六段稿-脱敏版 A6 第三段。
第四段（判断错在哪）的可记录部分：进场时判断聚焦在生产端，第五周前后发现真问题在需求预测端。纠偏信号是客流曲线与要货记录放在一起错位一目了然。
素材来源： 案例六段稿-脱敏版 A6 第四段。
案例二：酒业现场（A5）——画像 v0.1 几乎全错。
侦察背景：连续三天现场。第一版画像 v0.1 把对象理解成「酒业龙头 20+ 店」，现场会议直接标注「几乎全错」。
素材来源： 案例六段稿-脱敏版 A5 第四段。
现场蒸馏出的侦察规则：客户名称、企业边界和真实赚钱方式未确认前，不能直接画方案。
第五段（什么活了）落地为：4 张营销图（蓝黄主调、中秋送礼、53 系列、门店）；商业计划书 v0.1 到 v1.0 修订完成；现场企业讲座和工作坊完成。
素材来源： 案例六段稿-脱敏版 A5 第五段。
案例三：定制家具（序章下第六章）——一张手写便条。
侦察背景：进场第一周判断问题在生产排程，第五周发现真实问题在销售口头承诺。纠偏信号是车间里出现一张手写便条，贴着「此单客户要求圆角，销售王某说过」。
素材来源： 序章下-已发布.txt 第六章，作者本人素材。
这条案例是侦察阶段第四段（信号可迁移部分）全部用法的原型——结论会过时，信号不会。手写便条作为一条系统外信息通道的物理证据，在任何行业的车间里都能复用。
5.8 三个案例的对照读法
三个案例对应三个行业、三个侦察阶段的失败模式、共同指向一条侦察规则。
烘焙连锁是「客户给了三十页文档，FDE 必须读完之后敢于全盘推翻」。侦察阶段的核心动作是从文档的二十七页路径描述里，抽出第七问给出的真问题（配送量拍脑袋）。它代表的侦察规则是：路径不等于真问题；客户听过的方案不等于客户该走的方案。
酒业现场是「客户边界在第一版画像里被压错」。v0.1 把多业务线的客户压成单一门店模型，被现场会议推翻。它代表的侦察规则是：客户名称、企业边界和真实赚钱方式未确认前，不能直接画方案。第一版画像必须允许自己错，且错必须发生在方案落地之前。
定制家具是「第一周判断在第五周被一张手写便条打掉」。它代表的侦察规则是：系统外信息通道（手写便条/Excel/微信群/白板）才是真实业务流的物理证据。第一周判断再自信也要保留被推翻的余地。
三条规则的共同点落在一条侦察纪律上——允许自己错。侦察阶段的产出不在于方案写得多整齐，而在于允许自己被真实信号击中。允许自己错，才可能在第五周、第十周、第十五周被纠偏信号发现并更新判断。纪律的具体形态是判断日志——第一周判断、实际情况、第几周因为什么信号发现——以及三张图上故意留出的空格。三张图上的空格有其自身的功能——它们既是侦察未完成的痕迹，又是定义阶段继续补齐的入口。空格本身就在驱动项目往前走。
这三条规则的差异：烘焙连锁代表「文档型客户」的侦察路径，重在剔除；酒业现场代表「现场型客户」的侦察路径，重在补全；定制家具代表「车间型客户」的侦察路径，重在观察。FDE 在侦察头一周应当能判断自己落在哪一类，然后选择对应的入口动作。
5.9 侦察阶段的两个常见误判
误判一：把「客户说出来的」当成「客户真正想要的」。客户公司内部对项目的目标经常有三种版本——老板说的、文档写的、群里讨论的。三种版本可能完全不一致。FDE 在第一周内至少要拿到前两个版本并对照，第三个版本通常在第二周才会暴露。烘焙连锁这一案例里，老板说的「降低浪费率」和文档里三十页罗列的功能，进入定义阶段后这些都在被改写——真问题不在生产端而在需求预测端。
素材来源： 案例六段稿-脱敏版 A6 第四段。
误判二：把「已经识别到的」当成「已经理解了的」。三张图绘制完成后最容易出现的陷阱是「画过了就完了」。事实上三张图是侦察阶段的阶段性产出，不是侦察的结论。结论是「哪些格子还空着」。空着的格子在定义阶段必须填齐，否则它们会以合同漏项的形式浮出来。
侦察阶段的产出记录在一个固定文件里——侦察工单。包含七问清单答案（答不出来的格子保留空白）、三张图、影子系统清单、翻译动作清单、未答问题清单、未识别信号清单。侦察工单当日落盘，不允许跨日补写——隔一天就掉三成。
第六章 定义：把模糊切成可被数字判死刑
定义阶段回答一个问题：做完了用哪个数字判死刑。
这一个问题的答案如果不能用一句话写出来，这个项目还没有进入定义阶段。
定义的退出条件：验收口径表被客户签字。签字之前任何争议按侦察执行，签字之后任何争议按口径表执行。
定义的关键动作只有一件：把「三个月后的事」切成能被数字判死的验收标准。形式是一张五栏口径表。
6.1 口径表五栏
表格有五栏，缺一栏不成立。
第一栏：指标定义。这一栏回答「算什么」。指标定义必须可被一句话拆解，不能使用「提升效率」「降低成本」「客户满意度」这类不可拆解的词。
第二栏：数据源。这一栏回答「数字从哪来」。数据源必须是客户自己的系统，不是 FDE 自带的口径。FDE 自带口径的验收方式是采购方对供应商的验收方式，不是 FDE 工作的应有模式。
第三栏：统计窗口。这一栏回答「算多久」。统计窗口不少于四周。短于四周的统计窗口不可证伪。
第四栏：剔除规则。这一栏回答「什么不算」。剔除规则必须在验收会议之前写明。规则必须具体到维度——季节性、设备故障期、特殊客户折扣——而不是「特殊情况」这种通笼。
第五栏：争议仲裁人。这一栏回答「扯皮听谁」。必须是客户方的一个具体岗位，不能写「双方协商」。协商是不可执行条款。
6.2 把模糊切成可证伪的四类翻译
把客户描述的模糊语转换成可证伪的口径，翻译不外乎四类。
第一类：把「提升效率」翻译成「中位数时间下降」。
常见形态：客户说「提升效率」。翻译形态：从 A 时间戳到 B 时间戳的中位数下降 X 小时。数据来源是客户工单系统或流程记录。
第二类：把「降低成本」翻译成「金额下降」。
常见形态：客户说「降低成本」。翻译形态：单位成本下降 X 元，或总成本下降 X%。数据来源是客户财务系统。
第三类：把「提升满意度」翻译成「可观测行为」。
常见形态：客户说「提升满意度」。翻译形态：复购率上升 X%、退款率下降 X%、投诉率下降 X%。客户满意度本身不可证伪，必须翻译成可观测行为。
第四类：把「提升收入」翻译成「收入口径与基线对照」。
常见形态：客户说「提升收入」。翻译形态：同期收入比基线增长 X%，基线必须明确。绝对收入数字不可证伪，必须有基线对照。
6.3 定义阶段的关键决策：报价
定义阶段最被低估的动作是报价。
报价是定义阶段的验证，而非定义阶段的结论。一份报价单能写出来，意味着：
- 七问清单已经有答案
- 三张图已经画完
- 影子系统已经识别
- 口径表已经填齐
其中任何一项没完成，报价单写不出来，因为不知道跟谁报价、报多少、按什么口径收钱。
报价单的结构按四块写。第一块：项目目标。三句话以内。第二块：交付物清单。每条交付物对应一条验收口径。第三块：报价总额与付款节点。付款节点必须按里程碑释放，不可一次性预收。第四块：什么不在范围。明确写出来，避免范围漂移。
一个反例是 A1 留学服务案例。在这个项目里，报价 180 万，客户拒绝且未给出具体拒绝原因。
素材来源：
1. 案例六段稿-脱敏版 A1 第三段。
2. 案例六段稿-脱敏版 A1 第四段、第六段；案例池-补全调研 QC。
最接近的三句原话都在拒绝之前——「你不能把我叫的叫退堂鼓」（预算有限但愿意投入）、「挣多少钱都是一人一半」（要风险共担）、「没有人能操控AI技术」（怕烂尾）。
素材来源： 案例六段稿-脱敏版 A1 第四段；案例池-补全调研 QC。
合理推断的死因分级：价格与风险错位——七位数固定前置与客户期望的风险共担方式冲突；价值错位——客户第一优先级是获客，报价可承诺的是系统指标，明确不保增量。
素材来源： 案例六段稿-脱敏版 A1 第六段；案例池-补全调研 QC。
这个案例的教官价值不在 180 万这个数字本身，在两个反复出现的教训。第一，「做完调查不等于有权报价」——调查回答「客户需要什么」，报价资格回答「客户愿意以什么方式为什么付费」，A1 只答了第一题。
素材来源： 案例六段稿-脱敏版 A1 第四段。
第二，最高优先级指标若被否决，全案否决——不允许「主指标不达标辅指标达标」的项目宣告成功。
6.4 定义阶段常见死法
定义阶段有五种死法。
第一种，口径表五栏缺栏。后果是项目验收时扯皮。最常见的是缺争议仲裁人——客户说这个数字不对，FDE 说这个数字没问题，双方各自有理，扯三个月。
第二类，最高优先级指标被否决但项目继续。后果是项目交付后客户不认账。常见话术：客户说「主指标没达到但辅指标达到了，整体算成功」。这条不接受。
第三类，报价单收费结构与人天挂钩。后果是激励扭曲——FDE 待得越久越赚钱，激励方向跟客户利益相反。
第四类，付款节点未与里程碑挂钩。后果是项目进行到一半 FDE 失去主动权。客户不付款，FDE 没钱继续，谈判筹码消失。
第五类，范围未写明。后果是项目交付时范围漂移。FDE 做了 A，客户要求 B 作为 A 的附加项，「因为反正你已经做到了」。
6.5 定义阶段验收判据
定义阶段完成的判据：口径表五栏填齐且客户签字；最高优先级指标至少一条；任何指标的统计窗口不少于四周；不允许出现「提升 N%」而无基线；报价单四块齐备且付款节点全部按里程碑释放。
6.6 定义阶段案例佐证
案例一：杭州健康管理（A2+A4）——口径表写进合同。
这个案例的承重证据是合同原文。「验收合格的唯一判断标准」条款：未在附件一开发文档、附件二 Demo 原型明确记载的功能、性能或页面，不属于验收范围。
素材来源： 案例六段稿-脱敏版 A2 第三段，证。
合同的另一组落地证据：首付款固定五位数不可退还，余款按 20%/25%/25%/20%/10% 绑定需求确认、两次初验、终验和质保金。
素材来源： 案例六段稿-脱敏版 A2 第一段、案例池-本地素材 A2，证。
这一段的承重论断：付款节点全部按里程碑释放，不预收大额前期款。
合同总价 40 万。
合理推断说明： 谈判记录从 45 万让到 42 万、又经 43 万压到 40 万；「40 万含首年服务器租赁、部署落地和运维质保」。合同原件总价栏空白，这一数字未升级为实证。
素材来源： 案例池-补全调研 QB。
第六段记录了一个 FDE 应得的诚实标注：终验、正式上线、实际回款均未记录，交付证据止于本地/mock 边界的自动化验证。
素材来源： 案例六段稿-脱敏版 A2 第六段。
本案的写法价值在这条边界上——「一套把做什么、做成什么样、怎么算钱全部前置锁死的做法，和一个诚实停在半路的记录」。
案例二：Melody 时尚电商（A3）——从平台化到定制化。
v3 报价按「卖平台」给出数十万级多档公司签报价，访谈推翻该假设：v4 改为定制路线——个人签、数十万级起步，交付边界为控价、数据、看板、陪跑培训，独立站另计。
素材来源： 案例六段稿-脱敏版 A3 第四段。
这个案例的承重论断：定义阶段必须接受访谈的否决权。客户对话可以推翻之前所有方案。同时，报价中的关键防御条款——不承诺业绩、客户数、绝对不检测或百分百抓取——必须在签合同之前写进去。
案例三：烘焙连锁（A6）——口径就是浪费金额。
这个案例的口径表只有一行：指标定义=报废金额/同期营收；数据源=客户财务系统；统计窗口=季度；剔除规则=设备故障导致的报废剔除；争议仲裁人=客户 CFO。改造前后从 130 万压到 60 万。
素材来源： 案例六段稿-脱敏版 A6 数字口径，证。
这个案例的承重论断：当业务漏点单一而清晰时，验收口径可以极少。一行口径表比二十行更值，前提是它对应了真实的业务漏点。
6.7 定义阶段四类翻译的对照读法
下面把「客户原话 → 可证伪口径」的翻译路径按三个行业铺开。客户原话按行业惯例造，不绑定具体案例。
零售业场景。客户原话常见形态：「提高门店效率」「降低损耗」「让会员更满意」「让销售更好」。翻译路径：
- 效率 → 单店日报损金额、坪效、客单流转时长。数据源：门店日报、客流计数系统。
- 损耗 → 月度报废金额、报废率。数据源：财务系统、库存系统。
- 满意度 → 复购率、退款率、投诉率。数据源：CRM、售后工单。
- 销售 → 同期销售比基线增长率、客单价同比、连带率。数据源：POS、ERP。
制造业场景。客户原话常见形态：「缩短交付周期」「降低不良率」「让产线更稳」「让排程更准」。翻译路径：
- 交付周期 → 工单从入库到出库的中位时长。数据源：MES、工单系统。
- 不良率 → 月度不良品数量 / 同期产量。数据源：QA 记录、SPC。
- 产线稳定 → 故障停机小时 / 月度运行小时。数据源：设备日志、运维工单。
- 排程准确 → 排程变更次数 / 月度排程总数。数据源：APS、调度系统。
医疗与服务业场景。客户原话常见形态：「提升服务质量」「让客户更满意」「减少返工」「让数据更准」。翻译路径：
- 服务质量 → 报告出具时长、报告一次通过率、医生审核驳回率。数据源：业务系统、QA 记录。
- 客户满意 → 投诉率、退款率、复诊率。数据源：CRM、客服工单。
- 返工 → 返工工单占比。数据源：工单系统、操作日志。
- 数据准确 → 字段缺失率、字段错误率、OCR/AI 草稿被人工修改率。数据源：业务系统、模型日志。
对照读完，规律浮出来：每一类客户原话在不同行业里的翻译都落在「时间戳对、金额对、行为对、基线对」四种之一。所谓「提升效率」「降低成本」「提升满意度」「提升收入」的原文，四类翻译合起来只走这四条路。FDE 在定义阶段拿到客户原话，第一动作就是分类——四类里的一类或多类。分不出类，客户原话就还是空话；分类清楚，口径表五栏就自然落格。
6.8 定义阶段的两个常见误判
误判一：把「客户同意」当成「口径表签字」。客户在会议中口头同意的数字，与客户在文件上签字的数字，是两种不同强度的承诺。前者随时可能被反悔，后者构成合同义务。FDE 应在每一次会议结束前，把会上确认的所有数字形成一份口径表草稿，记录口头确认。次日会议前把这张草稿发给客户确认或修改。签字版本只在交付会议前才正式产生。
误判二：把「防御条款」当成「不友好条款」。定义阶段最容易丢的部分是防御条款——不承诺业绩、不承诺绝对检测、不承诺百分百抓取、知识产权归属、数据所有权。这些条款在签合同之前不提，签合同之后提，客户会认为甲方在事后刁难。Melody 时尚电商案例的 v4 报价里，防御性条款写在交付范围之前——首笔款降低试错成本，对持续计算和远程支持防御性定价，不承诺业绩、客户数、绝对不检测或百分百抓取。
素材来源： 案例六段稿-脱敏版 A3 第四段。
这一组条款的承重价值在于：FDE 把不可控的部分从自身责任里划掉，让可控的部分变得可证明。
防御条款的写作原则：每条款必须对应一个具体的失败场景。无法对应场景的防御条款是装饰——客户会感觉到 FDE 在「无理由推卸责任」，反而失去信任。
6.9 定义阶段的报价反验
报价是定义阶段的反验。报价单写不出来，意味着侦察还没完成。
报价单写出来后，再做一次反验：把报价单里的每一项交付物，反向映射到七问清单的某一问。如果有任一交付物找不到对应的侦察证据，那项交付物应该从范围里删除，或者侦察步骤必须回炉补齐。
报价单写出来后再做一次正向校验：把报价单交给一个不在项目里但熟悉 FDE 工作方式的人读，让他标出任何「听起来像承诺但口径不明确」的句子。这些句子是定义阶段的灰色地带，必须在签合同前消灭。
6.10 定义阶段话术样本
侦察结束、定义阶段开场时，FDE 与客户之间最常出现的对话节点有三处：报价话术、拒绝话术、防御条款话术。话术是一种承重接口——它在侦察阶段与定义阶段之间承担语言层面的承接动作，让客户的预期与 FDE 的边界在同一时间被校准。下面给出三组样本（话术样本中的人名一律按岗位代替，不写真实姓名）。
样本一：报价开场话术。
FDE：「这周内我会发一份口径表草稿和报价单给各位。口径表有五栏，是这件事完成后用什么数字算成功。报价单是四块结构，前三块对应交付物和付款节点，第四块是不在范围里的事——这一块通常最重要。请各位在签字之前把它当合同条款读，不是当 PPT 读。有任何不对的地方，写在表上发回来，下周一开会前定稿。」
这段话术的承重作用：把口径表与报价单同台处理；把第四块（不在范围）显式抬到第一块同等重要的位置；让客户在签字前进入合同条款阅读模式，而不是 PPT 旁观模式。FDE 把这次开场的语言本身当作侦察的最后一项——客户的回应会暴露他对范围的态度。
样本二：拒绝话术（当客户要求把范围外的事塞进交付里）。
FDE：「这件事我能做，但做完之后它会从报价单里溢出来。要么这一项单独补一份小报价单，按里程碑走；要么我们把它排到下一期，下一期有独立的范围与口径表。这一期里我能为您做的，是把这一项作为下一期的种子记录在六段解剖第六段里——它的死因是范围外延，它的教训是可迁移。」
这段话术的承重作用：把范围外延处理为单点决策，而不是情绪对抗；用「下一期」和「六段解剖第六段」两个具体名词把客户的临时要求沉淀为可追溯的资产。
样本三：防御条款话术。
FDE：「合同里会写明三件事——知识产权归客户；不承诺业绩、客户数与绝对检测率；数据所有权归客户。这些条款的本质是划掉不可控——把不可控的部分从我的责任里划掉。划掉之后，剩下的就是我能用数字证明的部分；这部分才是您真正需要验收的。」
这段话术的承重作用：把防御条款与可证明部分正面绑定。FDE 用「划掉不可控才能证明可控」的句式，让客户看到条款背后的逻辑而不是条款本身的锋利。
6.11 定义阶段与立法的关系
定义阶段在卷三的立法者思维里对应「判断法典」。判断法典是抽象的、可被引用的判断标准；定义阶段的具体产出——口径表——是判断法典在单一项目里的实例化。
两者关系：判断法典是工具，口径表是工具在某客户场景下的实例化。FDE 在多个项目里反复使用判断法典，会发现有些条目被反复引用——这些条目是判断法典的承重条目；有些条目只被引用一次——这些条目是项目级补充。
口径表的有效期是项目周期。过期后归入方法库，作为下一个项目的参考文本。
第七章 交付：在客户环境里跑通，由四周法则判活
交付阶段回答一个问题：用什么工程手段把定义变成在生产环境跑的东西。
交付的退出条件：原型在客户生产环境跑通四周。四周未达，阶段不结束。
交付的关键动作按顺序：原型第一周交付、客户环境部署、上下文工程与编排、评估集、四周观察窗口。
7.1 原型第一周
第一周必须交原型。这条是 Palantir 在 2008 年前后沉淀下来的硬规则。第一周不交原型，FDE 在客户眼里等同于咨询顾问，可以无限期汇报却永远不交付。
原型可以丑，但要在客户的真实数据上跑。不可用合成数据替代。合成数据跑通的原型跟客户实际需要的原型，是两个不同的东西。
第一周交付的另一个功能：暴露 FDE 自己的第一周判断。原型交付意味着客户对需求的回应被显化——客户要么说「这不是我想要的」，要么说「这就是我要的」。前者早暴露好，后者可以让后续七周交付更聚焦。
交付阶段的第一周交付判定标准。
一个原型合格的最低条件按以下五项判定：
第一项，跑在客户真实数据上。客户真实数据的最小子集是「能让原型走完一次端到端闭环的子集」，不是「数据全集」。端到端闭环的标志是——输入来自客户的环境（业务系统、文件、接口、传感器），输出回到客户的环境（界面、工单、推送、表单）。中间链路哪怕是 mock，只要闭环成立，原型算「真实数据上跑」。纯合成数据或脱敏样本不进入合格判定。
第二项，包含至少一个失败模式的可观测出口。原型在客户真实数据上跑时一定会有失败——接口超时、字段缺失、边界条件触发异常。原型的合格条件不是「没有失败」，而是「失败暴露出来且能定位」。FDE 在交付原型的同一次演示里必须能定位至少一个失败点——失败点的位置、原因、影响范围。这一项对应的工程动作是日志、链路追踪、错误提示三件齐备。
第三项，覆盖口径表里的最高优先级指标。原型哪怕只跑一条数据链路，那条链路必须对接口径表上的最高优先级指标。无最高优先级指标对齐的原型只是技术玩具，不是合格交付。
第四项，标注已知未知。FDE 在原型交付时必须把当前未验证的假设、未覆盖的边界、未对接的系统、未确认的口径逐项列出。每条标「已知未知」四字。这一项对应的工程动作是 README 或风险清单一页纸。
第五项，留下「不喜欢的权利」。客户在第一次演示后必须能直接说「这不是我想要的」——FDE 不在合同上签字之前，客户保留一切不喜欢的权利。原型合格的条件里没有「客户必须喜欢」这一栏，但有「客户能不接受且无代价」这一栏。
第一周交付的合格原型与不合格原型的差别，可以总结为一句话：合格原型承认自己丑、不全、有失败，并且把丑/不全/失败全部暴露在客户面前；不合格原型掩饰丑/不全/失败，让客户在第三周或第四周才发现。
7.2 客户环境部署
客户环境部署不是 demo 环境部署。demo 通过不等于客户通过——客户的数据、客户的网络、客户的设备、客户的员工操作习惯共同构成运行环境。
部署要包含三项验证。数据流验证：原始数据是否按真实路径进入系统？是否在传输过程中丢失或被篡改？权限验证：谁能看到什么，操作日志是否留痕？失败回退路径：系统挂了之后业务能不能继续运转？三项验证任何一项未过，不进入下一项。
B1 商单系统生产化验收案例是一个反面证据。最终 QA 57 项测试 36 通过、18 失败、3 跳过；常见失败 403 ORIGIN_NOT_ALLOWED（cookie-auth mutation）；明文记录 FAIL / launch blocked；P0/MVP demo Go 与完全体 No-Go 分层。
素材来源： 案例池-本地素材 B1，证。
这个案例的承重论断：本地通过不等于上线。18 项失败中任何一项都可能让生产环境崩。决断是分层——demo 级别可以 Go，完全体 No-Go。决断不能模糊，因为模糊的下场是让生产环境承担未验证的风险。
7.3 上下文工程与编排
编排按现场复杂度选择。单系统在单系统内部启用单链路；跨系统协调启用多智能体协同。两种模式按场景并行，而非替代关系。
上下文隔离是底线。一个任务的失败不能污染另一个任务的状态。跨任务共享状态视为违规——它会把一个局部的失败扩散到整个工作流。
B4 微信接口事故案例是一个反面证据。发送实验造成数据库损坏。新增快照、只读副本、数据安全红线；测试 199/199 GREEN；S1–S4 证据分层——/send 返回 200 只能证明队列处理到 S1，不能证明收件人收到。
素材来源： 案例池-本地素材 B4，证。
这个案例的承重论断：返回成功不等于业务交付成功。技术验证的链路必须延伸到业务端点，而不是停在 HTTP 状态码。
把上面两条案例放在一起读，编排阶段的工程底线已经清晰：本地的「全绿」、HTTP 的「200」、队列里的「处理成功」，三类信号任何一项单独成立都不等于业务端点成功。FDE 在交付阶段必须把链路证据从 S1 延伸到 S4——S1（系统接受请求）→ S2（系统处理请求）→ S3（系统完成动作）→ S4（业务端点收到结果）。
7.4 上下文工程与编排的四种模式
公开的智能体编排综述把多智能体协同整理成四种主要模式，每一种都有清晰的取舍。FDE 在交付阶段选择编排模式时，应回到现场复杂度本身做匹配，而不是追逐某一种流行写法。下面四种模式按对 FDE 现场工作的相关性整理。
第一种，subagent（中心化编排）。一个主管智能体把子智能体当作工具调用，子智能体无状态，由主管智能体负责上下文路由、组合与状态保存。这种模式强在「强上下文隔离」——每个子智能体只看自己的任务上下文，跨任务状态不污染；弱在「多一跳模型调用」，每次结果都要回到主管智能体汇总。对 FDE 工作的意义：当一个项目里有多个互相独立的工作流节点（图像分析、表单填写、通知推送）时，subagent 模式可以避免一个节点的失败污染另一节点。对应上面 B4 的事故教训——子智能体之间不共享状态，跨任务污染被结构性切断。
第二种，handoff（状态驱动的移交）。当前激活的智能体通过工具调用把控制权移交给下一个智能体；状态在移交过程中持续存在。对应 FDE 现场场景：当工作流有清晰的顺序依赖（先采集、后清洗、再分析、最后推送）时，handoff 模式让状态自然贯通。对应 B3 PPT Host 的旁白流水线——run1 失败两次是因为陈旧 app_userdata 状态没刷新，handoff 模式强制每次刷新才能移交，对这一类失败有直接治疗作用。
第三种，router（路由器并行分发与合成）。路由器把请求分类后并行分发给多个专精智能体，再把结果合成为一个统一响应。对应 FDE 现场场景：当一个项目需要并行处理多源数据（监控视频、温湿度、客流计数、库存系统）时，router 模式可以让多源同时进入、并行处理、统一汇总。这一模式与 B2 EVA 视频案例的代理指标问题直接相关——多源数据被汇总后，原始的可证伪指标可能丢失；FDE 必须保留每一条原始链路的可证伪证据。
第四种，skills（按需加载的轻量化模式）。单个智能体在运行时按需加载专精提示与工具——把多专精智能体的能力用一个智能体加按需上下文切换来模拟。对应 FDE 现场场景：当工作流需要频繁切换专精角色（数据分析师 / 报表作者 / 业务沟通）但又不想付出多智能体的工程成本时，skills 模式是一种工程效率更高的折中。代价是上下文会随调用累积——长任务后期 token 开销上升、上下文开始堆积。
四种模式的对照表（用于现场选型时自查）：
- 强隔离、低耦合：选 subagent。
- 强顺序、强状态：选 handoff。
- 多源并行、统一汇总：选 router。
- 单智能体、角色切换频繁：选 skills。
FDE 在交付阶段选择编排模式时必须回答两个问题：（一）这个项目的失败模式主要是工具调用错误（subagent 与 handoff 更合适），还是多源数据汇总错误（router 与 skills 更合适）？（二）业务端点的可证伪链路能不能从 S1 延伸到 S4？两个问题的答案决定编排模式的入口。
7.5 评估集
评估集是 FDE 自带的质量门。形式是一组固定输入与期望输出，每轮改动后跑一遍，分数下降超过阈值就回滚。
评估集不进客户合同，但进项目仓库。不上传客户生产数据，只用脱敏样本或公开基准。
评估集的设计原则：覆盖真实失败模式，而不是覆盖常规路径。常规路径大部分变更不会破坏，失败模式才是变更的代价。
B2 EVA 视频条件性 PASS 案例是一个关于评估集阈值的边界案例。QA 代理阈值（码率 ≥ 2 Mbps，非用户规格）实测 825 kbps；用户规格判定 100% 满足；结论「条件性 PASS → 送 CTO 最终签发」，未见签发记录。
素材来源： 案例池-本地素材 B2，证。
这个案例的承重论断：代理指标不等于验收口径。代理指标是 FDE 用来快速判断的指标，验收口径是客户签字的那一行。两者一致时无事，不一致时以验收口径为准。
7.6 四周观察窗口
四周观察窗口内不允许重大变更。四周内任何变更都按 A/B 或灰度执行。四周内的数据只用于稳定性观察，不用于效果证明。
把四周内的「看起来有效」写成「已经有效」，视为造假。
B3 PPT Host 48h 验收案例是一个关于清洁状态的边界案例。run1 两次失败（stale app_userdata 状态）→ 清洁状态第三次通过；run2 第二台独立机器首次 PASS，1800 帧/60 秒，逐页 SHA-256 一致；旁白流水线前两次静音（陈旧快照）→ refresh 后成功。
素材来源： 案例池-本地素材 B3，证。
这个案例的承重论断：失败必须保留，清洁状态才算通过，跨机复现是底线。单一环境通过不能说明可复现，第二台机器的独立通过才能说明。
7.7 交付阶段常见死法
交付阶段有六种死法。
第一种，原型未在客户真实数据上跑。后果是交付到生产环境时遇到数据格式边界条件，原型与生产的差异被一次性暴露。
第二种，部署跳过三项验证中的某一项。后果是上线后该验证项对应的失败模式被显化——数据不同步、权限越界、回退路径无效。
第三种，多智能体协同中跨任务共享状态。后果是局部失败扩散到全局，恢复时间长。
第四种，评估集用客户生产数据。后果是合规风险，以及 FDE 自己的判断被客户数据污染。
第五种，四周内做重大变更。后果是效果数据不可证伪，验收时扯皮。
第六种，跨机不复现。后果是单台环境通过不等于真实通过，两台环境差异暴露时系统被推翻。
7.8 交付阶段验收判据
交付完成的判据：原型第一周交且跑在客户真实数据上；客户生产环境部署三项验证全部通过；评估集就位；四周观察通过；客户口径表上的最高优先级指标数字变化符合定义。
7.9 交付阶段案例佐证
案例一：烘焙连锁（A6）——零硬件交付。
这个案例的交付部分承重证据：没有新装摄像机，直接用门店已有监控设备的客流统计能力把数据要出来；温湿度传感器低成本补齐产品保鲜窗口的实测数据。
素材来源： 案例六段稿-脱敏版 A6 第五段，骨+实。
这个案例的承重论断：交付阶段的工程实现路径不一定是新增硬件。在很多场景里，数据已经存在，只是没人去要。FDE 工作的逆向部分（从「厂商说取不了数」到「协议文档里写着能做」）在卷六展开。
案例二：杭州健康管理（A2）——波次交付。
8 模块纯前端 Mock Demo 先做出来；S02–S09 后端切片——时间轴排序、权限矩阵（401/403/200）、报告上传与 OCR/AI 草稿、医生审核发布、方案与预警、预约订单、运维 API——每波次记录已实现项与阻塞项，typecheck/test/build/smoke 全过。
素材来源： 案例六段稿-脱敏版 A2 第五段，证。
这个案例的承重论断：交付阶段按波次切，每个波次一个可验证的微观目标。波次间的依赖关系写明，阻塞项单列。这种节奏避免单次大爆炸式交付的失控。
案例三：商单系统（B1）——本地通过不等于上线。
已在 7.2 铺垫。这个案例的承重论断把 7.2 重写一次：本地通过不等于上线，部署分层是工程底线。
7.10 评估集的具体设计
评估集不是「测试用例集合」。测试用例验证功能是否正确，评估集验证变化是否正确。
评估集的设计步骤。第一步：列出这个项目最容易被破坏的三个失败模式。失败模式指系统在某种条件下会做出错误判断——比如客流统计在摄像头夜间切换红外模式后飘移。它跟 bug 不同，bug 是单点错误，失败模式是系统性偏移。第二步：为每个失败模式构造一个固定输入。固定输入的形式是脱敏后的真实样本或合成样本，不能用客户生产数据。第三步：每个固定输入对应一个期望输出。期望输出由 FDE 与客户对齐得出，写在评估集文件里。
评估集的使用规则。每轮代码改动或模型调整后跑一遍。分数下降超过阈值的改动回滚并修复。阈值由 FDE 设定，建议从 5% 开始——下降超过 5% 即视为可疑。
评估集不进客户合同。它是 FDE 的质量门，但客户只看到结果。这意味着评估集的设计责任完全落在 FDE 身上。评估集设计得不合理，整个交付过程的可信度都受影响。
7.11 交付阶段与立法的关系
交付阶段在卷三的立法者思维里对应「议案审议」——提案被审议、修改、通过、落地的过程。原型是提案，客户环境部署是审议通过，评估集是审议标准，四周观察是落地后的校准。
交付阶段的失败模式很多，但都跟跳过或压缩审议环节有关。原型第一周交付是审议时间；客户环境部署三项验证是审议内容；评估集是审议标准；四周观察是审议后的冷静期。任意一项被压缩，对应着审议的某项纪律被放宽——结果是项目的不确定性永久上升。
7.12 交付阶段与统计坐标的对照
把 2026 年公开统计放回交付阶段做对照。
- 约 88% 的企业 AI 智能体试点走不到生产环境。
- 工具调用错误约占 28%。
- 记忆与状态问题约占 22%。
- 未处理的边界情形约占 18%。
来源：
1. Turion.AI《Enterprise AI Agent ROI: The 2026 Reality Check》，汇总 Forrester/Anaconda 与 IDC/Lenovo 数据。
2. Presenc AI《AI Agent Failure-Mode Statistics 2026》。
把交付阶段的六种死法对应回去：
- 「原型未在客户真实数据上跑」对应边界情形（unhandled edge cases）——合成数据没暴露的字段缺失、格式漂移、时区差异，在真实数据上一次性暴露。
- 「部署跳过三项验证」对应工具调用错误——数据流、权限、回退三项任何一项未过，错误就会随接口一起扩散。
- 「跨任务共享状态」对应记忆与状态问题——共享状态把局部失败放大成全局污染。
- 「评估集用客户生产数据」对应合规与边界双重失败。
- 「四周内做重大变更」对应效果数据不可证伪——效果数据在不稳定环境里被证伪的概率更高。
- 「跨机不复现」对应生产环境与开发环境不一致——单点通过不等于普遍通过。
六种死法与三组统计原因在结构上一致。本卷不主张把每一个失败都归因到统计里的某一格——但本卷主张：当交付阶段某一类失败反复出现时，回到统计坐标里找它所在的格子，格子里其他企业的失败样本会帮助 FDE 判断这是局部问题还是模式问题。
第八章 回灌：让第三单明显便宜于第二单
回灌阶段回答一个问题：做完这件事给方法库留下什么。
回灌的退出条件：六段解剖第六段写满并归档。
回灌的关键动作有三件：第三个客户法则、六段解剖、脱敏三层检查。
8.1 第三个客户法则
同一个补丁做到第三个客户，从项目补丁变成产品特性或方法库条目。
第一、第二件客户只回灌项目记录；第三件客户必须回灌抽象后的方法条目。理由：前两件是单次经验，第三件起才形成可迁移判断。
「第三个客户」是最低门槛，不是最优门槛。门槛应按行业复杂度上调——复杂行业（医疗、金融）可能需要五到八个客户才能形成可迁移的判断。
这条法则可以自检。把最近三个项目的实际投入工时排出来，看趋势线。持平或上升，说明回灌机制没有建立。显著下降，说明回灌机制在工作。
回灌的产出形式：产品特性（代码级别的复用）、方法库条目（流程级别的复用）、失败清单（教训级别的复用）。三种形式可同时存在。
8.2 六段解剖
六段解剖是回灌阶段的核心产出。固定六段——靠什么真正赚到钱、钱在哪个环节漏掉、三张图、判断错在哪里、什么真的跑起来了、什么死了，以及死因。
完整模板在卷七附录 B。六段空着或写「无」的记录不成立。
第四段（判断错在哪里）的写法是三行——第一周判断、实际情况、第几周因为什么信号发现。第三行最值钱。烘焙连锁案例的第四段可记录部分是：进场时判断聚焦在生产端，真问题在需求预测端，纠偏信号是客流曲线与要货记录放在一起错位一目了然。
素材来源： 案例六段稿-脱敏版 A6 第四段。
第六段（什么死了）的死因分六型。
一，需求本身不成立。
二，找错了人——做给了没有决策权、没有痛感的岗位。
三，工作流改动幅度超过收益。
四，数据源不稳定。
五，唯一的推动者走了。
六，我们自己没跟上。
死因可多选，选不进则自述。
白皮书 m2 给出过一个零售客户项目的写法示例。这个项目里死掉了三条：
- 客流热力图： 数据源不稳定。摄像头夜间切换红外模式后，客流计数严重漂移，热力图结论不可用。如果重来，会在侦察阶段第七天增加一次夜场实测。
- 会员画像模块： 工作流改动幅度超过收益。门店店长每日的会员识别动作超过三十分钟，省下来的券成本覆盖不了工时投入。
- 总部看板： 找错了人。对接人是 IT 主管，业务侧无人承接收盘。如果重来，会拒绝在只有 IT 主管签字的场景下启动。
素材来源： 白皮书 m2-原则与方法.md 第五章，回灌阶段第六段写法示例。
烘焙连锁的第六段可记录部分：死掉的是拍脑袋报数这件事本身。
素材来源： 案例六段稿-脱敏版 A6 第六段。
死因类型 3 的反向成立——新工作流收益（每年 70 万量级）远大于改动成本（零新增摄像机 + 低成本传感器），所以旧方式死得很干脆。
杭州健康管理案例的第六段记录了两条死亡：
- 推进链断过一次： 客户核心对接人微信失联，合同草拟、需求文档整合、沟通复盘三项同日逾期。fallback 被写进待办，但没有看到完成记录。这是死因类型 5 的变体：唯一的推动者掉了。
- 大而全的一期死了： 多租户加盟体系、真实设备接入、完整 AI 训练平台被逐项移出一期。这属于死因类型 3：工作流改动幅度超过收益。
素材来源： 案例六段稿-脱敏版 A2 第六段，证。
8.3 脱敏三层检查
六段解剖写完后，必须经过脱敏三层检查。任意一层未过，整篇回炉。
第一层：实体层。
去掉公司名、地址、人名、独有的产品名和商标。脱敏的真正标准是让同行猜出来，而不是去掉名字就算完成。做法：写完之后，找一个本行业里的人来读，问他「你猜这是谁」，能猜出来重写。
第二层：数字层。
绝对经营数据全部模糊化——营收、利润、成本、单价、客户数量，一律改成量级或比例。流程数据原样保留——工单处理时长、审批经过几个环节、一条信息被重复录入几次、某个岗位每周花多少小时做某事。
为什么分两层？因为流程数据是这套记录的全部价值所在，把它模糊掉记录就废了；流程数据本身很难反推出商业机密。经营数据反过来，对读者实际帮助有限，泄露风险却极高。
第三层：时间层。
项目结束之后满十二个月方可公开。时间一律模糊到季度，不写具体月份。涉及具体业务动作的时间点一律改成相对时序——「我们进场时，他们刚上线某类系统不久」。
警惕时间线的泄露。事件时序本身也是指纹。留下因果，去掉坐标。
8.4 回灌阶段常见死法
回灌阶段有三种死法。
第一种，六段解剖第六段空着或写「无」。后果是这条记录不进入方法库，下一个项目无法复用这个教训。
第二种，六段解剖未经过脱敏三层检查。后果是泄露风险，撤回成本极高。
第三种，回灌未到第三个客户就停止。后果是项目经历变成单次经验，无法形成可迁移判断。
8.5 回灌阶段验收判据
回灌完成的判据：第三个客户的抽象条目已归档；六段解剖第六段写满并归档；脱敏三层检查通过。
8.6 回灌阶段案例佐证
案例一：烘焙连锁（A6）——零硬件这条经验的可迁移性。
这个案例的回灌价值：FDE 工作的逆向部分——数据已存在，只是没人去要——可以抽象为方法库条目。条目内容：侦察阶段叠加一项「数据存在性清单」，列出每个工作流节点上的现有数据源（监控、传感器、ERP、台账），识别未被启用的数据。
这条条目在下一个跨行业的项目里会被复用——任何客户场景里都存在「数据已存在但未被启用」的可能性。
案例二：杭州健康管理（A2）——退款和固件级方法条目。
两条可迁移条目。第一条：合同首付款不可退还 + 里程碑付款 + 验收唯一标准条款 + 合规责任划分——这是「把口头承诺改造成合同范围」的方法条目。第二条：合同化关键期核心对接人失联时的 fallback 强制写进待办——这是「唯一推动者掉了」的预防条目。
案例三：侦察失败（A1）——报价资格的方法条目。
这个案例的回灌价值可以从第六段反推：若重来——先定义四周可判定的最小交付，用客户数据验证价值感知，再决定报价；没有价值证据，就停在侦察和定义阶段。
素材来源： 案例六段稿-脱敏版 A1 第六段。
这条方法条目被归档后，下一个报价之前 FDE 必须自问：客户的数据是否已经验证了价值感知？没有，停在侦察和定义阶段。
8.7 方法库条目的格式
方法库条目是六段解剖的可迁移部分。格式固定五条。
第一条：触发场景。什么样的项目会出现这个条目对应的场景。场景描述应该包括行业范围、规模区间、典型动机。
第二条：失败模式。在该场景下，哪个六型死因最常见。这一条直接对应六段解剖第六段。
第三条：识别信号。如何在该场景的侦察阶段就识别出这个失败模式的迹象。信号可迁移。
第四条：避免动作。识别信号后应采取的具体动作。动作可执行。
第五条：边界条件。这个动作在什么条件下失效。失效条件写在条目末尾，让下一个使用者自查。
把烘焙连锁的「数据存在性清单」作为条目化的例子展开：
第一条触发场景——「客户提出新硬件方案的现场改造类项目。行业范围：零售连锁、制造业车间、物业与园区。规模区间：年营收八位数及以上。典型动机：客户希望在当前流程里加一层新的感知或识别能力。」
第二条失败模式——「死因类型 4：数据源不稳定。客户对已有数据的访问能力被低估，导致重复建设传感器与采集链路。」
第三条识别信号——「客户陈述中存在以下任一信号：（a）要求新装摄像头/传感器；（b）客户提到某类数据'取不出来'；（c）现场未走过供应商协议文档、未询问运维人员是否已启用统计能力；（d）客户的供应商列表里没有当前在用硬件的协议方。」
第四条避免动作——「进场头三天完成一次'数据存在性清单'——对每个工作流节点列出现有数据源（监控、传感器、ERP、台账）、当前是否启用、启用所需动作（协议对接 / 配置调整 / 权限申请）。清单完成后与客户的 IT 与运维逐一对照，标注未启用数据。未启用数据对应的'新硬件方案'改为'协议打通方案'。」
第五条边界条件——「本条目在以下条件失效：（a）客户项目合规要求强制新增采集设备（如医疗影像合规要求）；（b）现场确实未部署任何感知设备，需要从零开始；（c）客户对数据所有权有强约束，已有数据不可被新工作流使用。失效条件下，应在侦察阶段第二周明确告知客户并就硬件方案重启对话，不在数据存在性清单上拖延。」
按这五条写出来的条目可以在下一个项目里被引用、改写、合并。引用时只需标「来源 A6 数据存在性清单」；改写时保留五条结构不动；合并时识别信号与避免动作可以多组并列。这种格式固定的好处是：FDE 在多个项目后看到一份条目，不需要重新理解结构，直接对照项目场景就能判断是否适用。
8.8 回灌与组织记忆
回灌在卷八对应「组织记忆」与「魂壳分离」。方法库条目是组织记忆在单条知识层面的形态。条目归档的位置是 FDE 自己的项目仓库（壳），条目的内容是组织记忆（魂）。壳可以更换，魂必须可移植——这是 Open TSC 与卷八的核心论断之一。
回灌阶段常见的一种失败是：六段解剖写得很完整，但没有被抽象为方法库条目。结果是下一个项目还要从头做一遍侦察。条目化是回灌的承重部分，没有条目化就没有组织记忆。
条目化的最低动作：每完成一个项目，至少抽象出一条方法库条目。条目不一定来自成功——失败往往产出更多条目。
第九章 撤离：让系统在没有 FDE 的情况下继续活
撤离阶段回答一个问题：什么时候离开、留下什么、带走什么。
撤离的退出条件：四周法则通过且日落条款触发。
撤离的关键动作按顺序：交接、断奶、四周法则、日落条款触发。
9.1 交接
交接是把工作流的所有权归还客户。形式：操作手册、值班清单、异常处理路径、回归测试用例。
操作手册不可由 FDE 自己写，必须由客户指定的接班人写，FDE 校对——只有接班人写得出来，才能证明工作流真正被客户掌握。
交接的失败信号：操作手册里的某一段，FDE 校对时发现接班人写反了。这个信号正面说明 FDE 校对到位，反面说明工作流还没被接班人真正掌握。补的办法是 FDE 陪接班人现场跑一遍，让接班人重新写一遍。
9.2 断奶
断奶是降低 FDE 在工作流中的存在感。每两周抽离一个动作，直到 FDE 完全不在循环。
抽离顺序按风险从低到高。先抽离日报推送（出错代价低，验证成本低）。再抽离异常告警（出错代价中等，验证成本中等）。再抽离模型训练与评估（出错代价高，验证成本高）。风险高的最后抽，且每次抽离后做两周观察。
断奶的失败信号：FDE 抽离一个动作后，客户立刻打电话来说不会了。补的办法是回到上一个状态，让客户重新适应后再次抽离。
9.3 四周法则
上线后连续四周仍在使用的东西才算活。四周内任何功能的使用率按周统计，四周后停用率超过 30% 的功能列为「未活」，写进六段解剖第六段。
六段解剖第五段只写活着的东西。烘焙连锁案例的第五段可见：改造现有监控取数、温湿度传感器、按店按日的配送调整，三项持续使用。
素材来源： 案例六段稿-脱敏版 A6 第五段。
四周法则的失败信号：项目上线后四周内使用率漂亮，第三周开始掉，第四周见真章。任何「上线即成功」的论断在四周法则下都不成立。
9.4 日落条款
日落条款在项目启动时写明。形式：项目自验收日起满 X 个月触发日落评审；客户书面同意延续则延 X 个月，否则项目关闭。
日落评审输出三项：功能存活清单（基于四周法则）；待交接工作（未完成或新增的工作流交接）；待撤离人员（FDE 自身或其他相关人员）。三项任何一项缺失，视为撤离未完成。
日落条款不进合同，但进项目章程第一页。失效条件：当客户业务面临人身安全或重大公共利益风险，本法的阶段顺序可被压缩，但五阶段不得跳过——压缩记录必须在六段解剖第四段写明。这一条在白皮书 v1.0 已经定下。
素材来源： 白皮书 m2-原则与方法.md 第四章法条失效条件。
9.5 撤离阶段常见死法
撤离阶段有三种死法。
第一种，操作手册由 FDE 自己写。后果是手册的语言是 FDE 的语言，接班人看不懂；交接在纸面完成，工作流依然依赖 FDE。
第二种，断奶过程中跳过观察期。后果是抽离过早，客户还没建立新习惯就被丢下，工作流崩溃。
第三种，四周法则被提前到一周或两周。后果是「看起来有效」被错误写成「已经有效」，未活的功能被当成活的功能计入项目成功。
9.6 撤离阶段验收判据
撤离完成的判据：交接完成且接班人手册存在；断奶完成且 FDE 不在工作流循环内；四周法则通过；日落条款触发且评审输出归档。
9.7 撤离阶段案例佐证
撤离阶段的案例佐证回到序章下第七章的一段话——任何一个新系统上线的头两周，使用率都很好看，因为大家在配合，因为领导在看，因为新鲜。第三周开始掉。第四周见真章。四周之后还在用的东西，是真的解决了问题。
素材来源： 序章下-已发布.txt 第七章，作者本人素材。
这条素材是撤离阶段四周法则的原型，而非单一案例的佐证。
9.8 撤离阶段日落条款的格式模板
日落条款的格式固定五项字段，下面把每一项展开成可直接抄入项目章程第一页的模板。
第一项：触发日期。
模板写法：
日落触发日：[项目名称] 自验收日起满 X 个月触发日落评审。
X 的取值范围：6 ≤ X ≤ 12。短于 6 个月的日落条款几乎等于不设日落——项目验收后客户还未真正使用。
长于 12 个月的日落条款带来一个问题：日落评审与项目下一次大版本周期重叠，评审失去独立性。X 的选取规则：项目周期在 3 个月以内，X 取 6；项目周期在 3–6 个月，X 取 9；项目周期在 6 个月以上，X 取 12。客户业务面临季节性高峰（如零售业的节前、制造的季初），日落评审应避开高峰前两周。
第二项：评审输出。
模板写法：
日落评审输出（必须齐备三项，缺一项视为撤离未完成）：
1. 功能存活清单——基于四周法则，列出本项目所有交付物在四周观察窗口后的使用率，
停用率超过 30% 的功能列入「未活」清单。
2. 待交接工作清单——未完成的工作流交接、新增的工作流交接、客户方内部
尚未接手的工作项。
3. 待撤离人员清单——本项目的 FDE 是否撤离、辅助实施人员是否撤离、
客户方是否有外部顾问需要撤离。第三项：延续条件。
模板写法：
延续条件：客户书面同意延续，则日落评审日 + X 个月触发下一次日落评审。
书面形式包括：邮件回复（客户方决策岗位签字）、签字盖章的延续通知函、
或合同补充协议中的延续条款。
不接受：口头同意、未签字的微信截图、未签字的会议纪要。第四项：压缩例外。
模板写法：
压缩例外：当客户业务面临人身安全风险或重大公共利益风险，本法的阶段顺序可被压缩，
五阶段不得跳过。压缩记录必须在六段解剖第四段写明，包括：
1. 压缩的具体理由（人身安全 / 重大公共利益，分别对应的事实）。
2. 被压缩的阶段及被压缩的动作清单。
3. 压缩对四周法则与日落评审的影响。
4. 压缩后 FDE 的持续责任范围与责任期限。第五项：FDE 在撤离后的角色。
模板写法：
FDE 在撤离后的角色：日落条款触发后，FDE 在项目内的角色由「工作流的一部分」
转为「应急联系人」。应急联系人有响应时限的承诺，没有日常参与的承诺。
响应时限承诺示例：
- 工作时间内：4 小时内首次响应，24 小时内给出处置建议。
- 非工作时间：12 小时内首次响应，48 小时内给出处置建议。
应急联系人身份的退出条件：客户方书面通知 FDE 不再需要应急支持，
或日落评审通过后 X 个月未触发任何应急请求。五项字段写完后，项目章程第一页的日落条款即告完成。条款不进合同——它的目的是把退出机制前置写明，让客户在签字前就清楚整个项目的时间边界。
9.9 撤离阶段断奶话术样本
撤离阶段最常出现的对话节点是「客户希望 FDE 留下来」。这一节点对应断奶动作与日落条款第五项的边界。下面给出三组样本。
样本一：客户要求 FDE 长期驻场。
FDE：「这件事做完之后，我留下来对您不一定是好事——留下来的话，我成了您工作流的一部分，撤离就做不干净；做不干净，我下一个项目就要被推迟，您下一个项目也找不到合适的人。这份日落条款写明了，我撤离之后的角色是应急联系人，响应时限写在里面了——4 小时首次响应，24 小时处置建议。这是我能给的最稳的承诺。」
样本二：客户发现断奶后某动作不会做。
FDE：「我们回到上一个状态，您再适应一周。这一周您不用记新流程——只要把旧流程跑一遍。跑完之后我们再断一次，这次我会把容易忘的那一步单独标红。」
样本三：客户希望保留 FDE 在内部群里的可见性。
FDE：「我可以留在群里，但只读不回复。您@我的时候，我会按应急联系人的响应时限回应。日常问题您团队的接班人处理。这样他们有成长的空间，我有撤离的空间——两边都不卡。」
这三组样本的共同点是把撤离的纪律显式说出来。撤离不显式说，纪律就只存在于 FDE 心里；说出来，纪律变成双方共同持有的边界，客户预期被校准。
9.10 撤离与超级个体的天花板
撤离阶段在卷八对应「超级个体的天花板」。一年四到六个完整项目，每个项目都要撤离——撤离是项目数量的乘数。如果一个项目撤离不彻底，FDE 的实际可承接项目数会下降三分之一。
撤离的核心动作是断奶——抽离 FDE 在工作流中的存在感。断奶不彻底意味着 FDE 永远处于被召回的状态，被召回意味着 FDE 没在下一个项目里。这条机制是结构问题，需要结构方法解决：在日落条款的第五项里写明 FDE 在撤离后的角色，让客户预期清晰。
9.11 撤离与统计坐标的对照
撤离阶段的失败往往不表现为「撤不下来」，而表现为「看起来撤下来了，下个月又回来」。这类反复召回是撤离不彻底的结构表现。把 2026 年公开统计放回撤离阶段做对照：
- 约 35%–45% 的 AI 智能体部署在上线后 12 个月内被弃用，弃用率约为聊天机器人的两倍。
- 约 19% 的投产智能体从未回本。
来源：
1. Presenc AI《AI Agent Failure-Mode Statistics 2026》。
2. Gartner Agentic AI Pulse 2026，经 Turion.AI 复述。
这两组数字告诉一线从业者：上线只是起点的四分之一，后三个四分之一分别落在四周法则、断奶、日落评审。
把撤离阶段的三种死法对应回去：
- 「操作手册由 FDE 自己写」对应召回常态化——手册语言是 FDE 的语言，接班人日常操作时遇到 FDE 不在场的故障依然只能求救。
- 「断奶跳过观察期」对应弃用加速——客户还没建立新习惯就被丢下，工作流被迫回到旧习惯或干脆停滞。
- 「四周法则被提前」对应错误归因——把「看起来有效」误写为「已经有效」，导致撤场时点错误，留下未活的尾巴。
三组死法的共同点是结构性的：撤离的纪律不在撤离那一周养成，而在撤离前四周到十二周持续养成。日落条款的 X 个月有其自身的功能——它既是缓冲器，也是 FDE 主动设计的撤离节奏锚点。缓冲器设得过短，撤离动作被压缩；缓冲器设得过长，FDE 自身的项目数被压缩。这一平衡是 FDE 工作量与项目质量的承重点。
9.12 五阶段的跨阶段衔接
五阶段不是五个互不相关的工序节拍，它们之间存在明确的衔接动作。衔接动作失败，是项目最大的一类隐性死法——单看每个阶段都「完成」了，但阶段与阶段之间的接口没接好，结果是项目整体失效。
侦察到定义的衔接。侦察阶段的产出是侦察工单，定义阶段的输入是侦察工单。衔接失败表现为：FDE 在定义阶段引用侦察工单时发现格子是空的，或格子里的内容与定义阶段的对话对不上。这一衔接的承重动作是「侦察工单作为正式附件进入定义会议」。任何对侦察工单的修订都当场落盘，不允许「回头再补」。
定义到交付的衔接。定义阶段的产出是口径表与报价单，交付阶段的输入是这两份文件加上客户的签字。衔接失败表现为：交付阶段的工程师读口径表时发现指标无法被现有数据验证，或报价单的交付物与客户对「交付」的隐含理解不一致。这一衔接的承重动作是「交付工程师必须读口径表与报价单原文」，不允许由 FDE 转述。FDE 转述必然走样。
交付到回灌的衔接。交付阶段的产出是上线运行的工作流，回灌阶段的输入是上线四周后的实际数据。衔接失败表现为：交付工程师与回灌 FDE 不是同一个人，回灌阶段拿到的项目记录里六段解剖第四段是空白。这一衔接的承重动作是「交付工程师在最后一周亲手把第一周判断写进六段解剖第四段」。第一周判断只有交付时还在场的那个人写得出来。
回灌到撤离的衔接。回灌阶段的产出是方法库条目与脱敏六段稿，撤离阶段的输入是这两份资产加上客户的延续决策。衔接失败表现为：方法库条目未写完时 FDE 已经离开下一个项目，方法库条目被冻结在「半成品」。这一衔接的承重动作是「方法库条目在 FDE 离开下一个项目之前必须完成」。延后会冻结。
撤离到下一个项目的侦察的衔接。撤离阶段的产出是工作流与接班人手册，下一个项目的侦察阶段输入是上一份方法库条目。衔接失败表现为：FDE 在下一个项目里凭印象开始侦察，方法库条目被绕过。这一衔接的承重动作是「FDE 进入下一个项目的第一周必须读上一份方法库条目」。这条动作是闭合的关键。
五处衔接的共同点：每个阶段的产出必须被下一阶段的输入引用，而不是被「知道一下」。引用的物理形态是文档、链接、附件、签字——可被搜索引擎找到、被审查者抽查、被下一个 FDE 直接拿来用。不被引用的产出，等于不存在。
9.13 五阶段与卷三立法者思维的双向对应
卷三建立的双法典（规则法典 / 判断法典）在卷四里落到五阶段上。每一阶段都对应双法典里的具体条目，规则法典条目约束「不能做什么」，判断法典条目约束「怎么判断做到了什么」。
侦察阶段对应的法典条目。规则法典：「不允许跳过七问清单的任何一问」「不允许在三张图未画完前开始报价」「不允许在影子系统清单未完成前写出工作流改造方案」。判断法典：「七问清单的答案是否由现场数据验证」「三张图上的格子是否还有空白」「影子系统是否被识别并被标注形态」。侦察阶段的合规检查，是规则法典条目与判断法典条目的逐项对照。
定义阶段对应的法典条目。规则法典：「不允许接受'提升效率'一类不可拆解的指标定义」「不允许在五栏缺栏的情况下签字」「不允许在防御条款未写之前签合同」。判断法典：「指标定义是否能被一句话拆解」「争议仲裁人是否是客户方具体岗位」「防御条款是否对应具体失败场景」。定义阶段的合规检查，让口径表的每一栏都被法典条目约束。
交付阶段对应的法典条目。规则法典：「不允许原型在合成数据上跑」「不允许跳过三项验证」「不允许四周内做重大变更」「不允许跨任务共享状态」。判断法典：「原型是否跑在客户真实数据上」「三项验证是否每一项都签字」「四周法则是否被严格执行」「业务端点证据是否延伸到 S4」。交付阶段的合规检查，对应到统计坐标里的三组失败原因——工具调用、记忆状态、边界情形。
回灌阶段对应的法典条目。规则法典：「不允许第六段写'无'」「不允许回灌未到第三个客户就停止」「不允许未通过脱敏三层检查就归档」。判断法典：「第六段死因是否按六型标注」「方法库条目是否按五条字段完整」「脱敏三层是否每一层都被同行测试」。回灌阶段的合规检查，是项目记录变成可迁移判断的关键门槛。
撤离阶段对应的法典条目。规则法典：「不允许 FDE 自己写操作手册」「不允许四周法则被提前」「不允许日落条款的五项字段缺项」「不允许断奶跳过观察期」。判断法典：「接班人手册是否由接班人写」「四周法则是否基于真实使用数据」「日落评审输出是否三项齐备」「FDE 是否已被完全抽离工作流循环」。撤离阶段的合规检查，决定项目能否承接下一个项目。
双法典在五阶段上的对应不是装饰。这一对应让「方法论」从一个被反复书写的承诺集合变成一份可以被逐项核对的工作清单。每一条规则法典条目都对应一个可以被执行的动作；每一条判断法典条目都对应一个可以被验证的事实。FDE 在五阶段里的每一个动作，都可以在双法典上找到它的法理来源与失效条件。这种结构对应让方法论不再是「经验」——它是工程。
9.14 五阶段与「一人公司」（OPC）的接口
五阶段方法的另一个读者群是想做一人公司的年轻人。这一节把这套方法论与 OPC 的工作形态做一次显式对照，便于年轻读者把方法论带回自己的实际工作流。
OPC 在卷二与卷八里被定义为「一名人类 + 一个配对 Agent 的编制单位」。FDE 工作在 OPC 的语境下，五阶段的每一阶段都同时被一名人类与一个 Agent 共做。这与多人团队里五阶段的做法有两点不同：
第一，侦察阶段的现场观察需要人类独立完成。Agent 可以替人类读取影子系统的部分形态（OCR、表格解析、群消息摘要），但「看到员工工位上的并行的 Excel」「看到会议室白板的残留」这一类需要人在场的观察，必须由人类本人完成。Agent 的能力边界——在卷六展开——在这里被显式标出。
第二，定义阶段的合同谈判需要人类独立完成。Agent 可以替人类起草报价单与口径表草稿，但「在谈判桌上与客户方决策岗位对话」必须由人类本人完成。原因不是技术不能——是这种对话的结果会影响责任归属，法律责任不应由 Agent 单独承担。
第三，交付阶段的工程实现可以人机共做。Agent 在交付阶段承担绝大部分工程动作（写代码、跑测试、部署、监控），人类承担「决定要不要继续」「决定何时进入四周观察窗口」「决定何时宣告失败」三个动作。这一分工与多人团队里 FDE 主导工程、辅助工程师执行的结构不同——在 OPC 里 Agent 就是辅助工程师。
第四，回灌阶段的方法库条目可以由 Agent 协助抽象，但条目触发场景与边界条件必须由人类本人写。原因：触发场景与边界条件依赖人类对未来项目的判断，Agent 没有这一能力。
第五，撤离阶段的接班人交接在 OPC 里要重新定义——接班人是客户方指定的人类，不是另一名 Agent。这与多人团队里的撤离动作差别不大。
五处接口的共同点：人类不替 Agent 做需要承担法律责任的动作；Agent 不替人类做需要现场观察与未来判断的动作。这一分工边界是 OPC 形态下 FDE 工作流的承重边界。年轻读者在把卷四带进自己的 OPC 工作流时，应当先把这条边界刻在心里，再开始把五阶段方法论用进自己的项目。
本卷法条
FDE 第四法 · 五阶段不可越律
原文：侦察、定义、交付、回灌、撤离五阶段按序执行；每阶段有且只有一个退出条件，退出条件未达不得进入下一阶段。
推论：侦察不够进定义，沙地上盖楼；定义不收敛进交付，合同里埋雷；交付完不撤离，工作流长成赘生物；交付完不回灌，方法论做成一单生意。
失效条件：当客户业务面临人身安全或重大公共利益风险，本法的阶段顺序可被压缩，但五阶段不得跳过；压缩记录必须在六段解剖第四段写明。
每阶段的加速检查清单。
在时间紧迫场景下，五阶段必须保留的最低动作如下。任何一项被省略，对应阶段的承重论断失效。
侦察阶段加速清单（时间紧迫下保留六项）：
- 七问清单第一问——三个月后失败谁受伤最重——必须问出并锁定到岗位。
- 七问清单第三问——做成了谁会输——必须问出并写到三张图第三张。
- 三张图第一张——钱怎么流——必须问出预算科目来源与上限。
- 影子系统识别——必须现场看到至少一个影子系统的形态。
- 七问清单第四问——每天早上第一件事——必须由现场观察而非提问回答。
- 侦察工单当日落盘。
可以省略的：七问清单第二问（暗礁图）的完整追问、第四问到第七问的 follow-up 脚本、影子系统的清单完整度——这些可以延后到定义阶段补齐，但不能跳过侦察阶段。
定义阶段加速清单（保留五项）：
- 口径表五栏——指标定义、数据源、统计窗口、剔除规则、争议仲裁人——必须填齐。
- 最高优先级指标——必须锁定到一行可被数字判死刑的指标。
- 报价单四块——目标、交付物、报价与付款、不在范围——必须齐备。
- 防御条款——不承诺业绩、知识产权归属、数据所有权——必须出现在报价单中。
- 客户对口径表签字。
可以省略的：四类翻译的完整对照、报价反验的双向映射——这些可以延后到交付阶段补齐，但不能跳过定义阶段。
交付阶段加速清单（保留六项）：
- 原型第一周交付——且必须跑在客户真实数据上。
- 客户环境部署三项验证——数据流、权限、回退。
- 评估集——至少三个失败模式对应的固定输入与期望输出。
- 编排模式选择——subagent / handoff / router / skills 四选一，并记录选择理由。
- 业务端点证据 S1→S4——不能停在 HTTP 200。
- 四周观察窗口——四周内不允许重大变更。
可以省略的：完整的四种编排模式对照、评估集的全部设计步骤——这些可以延后到回灌阶段补齐，但不能跳过交付阶段。
回灌阶段加速清单（保留四项）：
- 六段解剖六段——必须填齐，第六段不允许写「无」。
- 死因分级——按六型之一或多型标注。
- 方法库条目——至少一条抽象条目。
- 脱敏三层——实体、数字、时间。
可以省略的：方法库条目的五条完整字段——可以先记录触发场景与失败模式两条，剩余三条在下一个项目里补齐，但不能跳过条目化。
撤离阶段加速清单（保留四项）：
- 交接——操作手册由客户方接班人写，FDE 校对。
- 断奶——按风险从低到高抽离，每两周一个动作。
- 四周法则——四周后停用率超过 30% 的功能列入「未活」。
- 日落条款——五项字段齐备，且写明响应时限承诺。
可以省略的：日落条款的完整五项字段模板——可以先写触发日期与评审输出两项，剩余三项在第一个日落评审前补齐，但不能跳过日落条款。
加速清单的本质：每一阶段都有一条不可省略的承重动作。在时间紧迫场景下，FDE 的纪律不是「全部动作做满」，而是「承重动作不漏、其余动作延后但不得跳过阶段」。加速清单的用法是把每一阶段的承重动作在阶段开始前读一遍，在阶段结束时核对一遍——任何承重动作未做，对应阶段的结论不可被宣告成立。
卷四与五条判据的逐条对应
卷一开篇把 FDE 的职业底线锚定在诚实，并把诚实拆成五条判据——对客户诚实、对数字诚实、对失败诚实、对认知诚实、对自己的诚实。这一节把卷四的方法论按这五条判据逐条对照，把方法论的承重墙与 FDE 的职业底线在同一章里锁死。
对客户诚实的对应。侦察阶段的七问清单是对客户诚实的承重动作——七问清单不允许用「提升效率」一类不可拆解的词回答客户问题，所有回答必须落到岗位、流程、数字上。定义阶段的防御条款与口径表五栏是对客户诚实的进一步兑现——不承诺业绩、不承诺绝对检测、不承诺百分百抓取，让客户在签字之前就清楚可控与不可控的边界。交付阶段的第一周原型交付是对客户诚实的工程表达——原型可以丑，但必须跑在客户真实数据上。撤离阶段的接班人手册是对客户诚实的最终兑现——手册由客户方接班人写，FDE 校对，让工作流真正在 FDE 不在场的环境下继续活。五阶段里任一阶段放弃对客户的诚实，对应阶段的结论立即失效。
对数字诚实的对应。定义阶段的统计窗口不少于四周、剔除规则具体到维度、争议仲裁人必须是客户方具体岗位——这三条是对数字诚实的口径锁。交付阶段的四周法则、四周内不允许重大变更、四项数据只用于稳定性观察——这是对数字诚实的时间锁。回灌阶段的脱敏三层检查（绝对经营数据模糊化、流程数据原样保留、时间模糊到季度）——这是对数字诚实的边界锁。三处锁对应三处诚实：数字怎么算、数字什么时候算、数字能不能被外部看到。
对失败诚实的对应。六段解剖第六段不允许写「无」是对失败诚实的最直接锁定。第六段的六型死因（需求不成立 / 找错人 / 工作流改动超过收益 / 数据源不稳定 / 唯一推动者掉了 / 我们没跟上）允许并列多选——并列多选本身就是对失败诚实的态度：失败往往不是单因，把多因并列写出来才是诚实。回灌阶段的第三个客户法则（同一补丁做到第三个客户才形成可迁移判断）是对失败诚实的工程兑现——把失败抽象为方法库条目，让下一个 FDE 不再重蹈覆辙。
对认知诚实的对应。定义阶段的报价反验——把报价单交给项目外但熟悉 FDE 工作方式的人读——是对认知诚实的双盲兑现。交付阶段的评估集设计——覆盖真实失败模式而非常规路径——是对认知诚实的工程兑现。撤离阶段的日落条款——X 个月后客户书面同意延续则延 X 个月，否则关闭——是对认知诚实的合同兑现。三处兑现的共同点是：把「我认为」与「可证伪」分开，把「我相信」与「客户书面确认」分开。
对自己诚实的对应。侦察阶段的判断日志格式（第一周判断 / 实际情况 / 第几周因为什么信号发现）是对自己诚实的最具体动作——第一周判断写完即锁死，只增不改，对应卷四 5.7 强调的「结论会过时，信号不会」。回灌阶段的方法库条目五条字段（触发场景 / 失败模式 / 识别信号 / 避免动作 / 边界条件）是对自己诚实的结构兑现——每一条都对应一个具体的可迁移判断，对应卷四 8.7 的写法。撤离阶段的断奶动作——按风险从低到高抽离——是对自己诚实的纪律兑现：FDE 必须在每一个抽离节点上诚实评估自己的存在感。
五条判据与五阶段的对应不是装饰。它让方法论的每一阶段都对应职业底线的某一面。当一个 FDE 在某个阶段感到「这样做好像太麻烦」时，回到五条判据里的对应那一条，问自己：如果我跳过了这一动作，我的诚实是否还在？这一问让「麻烦」从情绪变成判断题，从判断题变成可执行的纪律。
卷四小结 五阶段是一个闭合的工序
把五阶段连起来看，它们不是一个流水线，而是一个闭合的工序。链条从侦察开始，绕到撤离结束，但撤离的产出——方法库条目、四周法则判活记录、断奶后的工作流——又回到下一个项目的侦察端。
闭合的意义：方法库的厚度 = 侦察的精度。方法库里的条目越多，下一个项目的侦察越准，定义越稳，交付越快，回灌越准。每一个 FDE 在这个回路里走过的圈数，是这个 FDE 的真实资产。
一年四到六个项目，三年之后一个 FDE 走过约十五圈。十五圈里积累的方法库条目，足以让一个 FDE 在他熟悉的行业内，比任何新入场者更快地找到真问题。
一个 FDE 在第十五圈回头看自己的方法库，会发现条目里超过一半来自失败而非成功。失败被写下来、被脱敏、被条目化、被下一个项目引用——这是 FDE 这个岗位独有的财富机制。大多数职业把失败藏在抽屉里，FDE 把失败写进方法库。后者要求纪律，要求诚实，要求对客户、对数字、对失败、对认知、对自己的诚实同时在线。
这本书到这里，方法论的承重墙已经立完。卷五会讲人机分工——五阶段里哪些必须由人做、哪些可以由 AI 做、哪些必须人机共做。卷六会讲硬件与现场——五阶段在涉及物理设备、协议、边缘计算的项目里如何变形。卷七用案例验证——五个阶段在真实项目里跑出来的样子。卷八把五阶段写成组织制度——个人、小团队、知识库型团队怎么把五阶段装进自己的操作系统。
整本手册的下一卷，回到一个更日常的问题：人做什么，AI 做什么。
一个年轻人读完这一卷去做的第一件事，不会是写代码，而是坐在他下一个客户的现场椅子上，看九点钟的工位，看九点半的微信群，看十点钟的白板。然后他会站起来，找那个最不被欢迎的表的填表人，问他那张表哪里最难填。这个动作就是五阶段的入口。这一入口比任何工具、任何模型、任何平台都更值钱，因为它把人放到了真实业务流的源头。工具可以迭代，模型可以换代，平台可以迁移；现场观察、追问、识别、抽象的能力只在人那里。
一个中年的工程师读完这一卷去做的第一件事，会是回去翻自己最近一个项目的六段解剖第四段，看第一周判断与实际情况之间的差。差越大，回灌条目越值。他会从这一段差里抽出一行方法库条目，写进他自己的仓库。这一行就是他下一个项目的资产。资产不来自项目本身，资产来自项目与项目之间那条看不见的连线。
一个 FDE 的导师读完这一卷去做的第一件事，会是把这一卷教给下一个还没做过 FDE 工作的人。导师更看重纪律——五阶段的顺序、四周法则、第三方代签、四段付款、脱敏三层——方法本身可以由学生自行演化，纪律却只能由上一代亲手交付。这些纪律听起来繁琐，做起来更繁琐，但任何一条被跳过，下一个项目就可能死在被跳过的那一条上。导师把纪律传下去，FDE 这个岗位才有下一代。
开篇那位烘焙连锁的老板如果读完这一卷，他大概会翻到第六章，看到「口径表只有一行：指标定义=报废金额/同期营收；数据源=客户财务系统；统计窗口=季度；剔除规则=设备故障导致的报废剔除；争议仲裁人=客户 CFO」——他会想起来，这就是那一年他签字的那一行。这一行背后的全部动作——七问、三张图、影子系统、波次交付、四周法则、断奶、日落条款——他大多没看到，但他看到的那一行替他挣回了一年七位数的真金白银。方法论的承重墙在客户那一侧只露一行。这一行就是全部。其余的墙，由 FDE 自己扛。
那位老板在那一年后还做了别的决定：他不打算再买三十页方案了。他决定下一次采购，第一周必须看到原型跑在他的真实数据上，否则不签。这一决定另有其师——他被这一行口径表教会。方法论最值钱的地方不在方法本身，在它把客户变成了另一种客户——懂口径的客户会拒绝被忽悠，懂四周法则的客户会拒绝被假成功骗走预算。这种客户的扩展速度比 FDE 自身的扩展速度更快。FDE 走过的每一栋楼，方法论的墙都在那里替客户站岗。
五阶段加速检查清单
速查卡按阶段顺序给出承重动作清单，每条以一行写完：
- 侦察：七问第一问 + 七问第三问 + 三张图第一张 + 影子系统至少一个形态 + 第四问现场观察 + 侦察工单当日落盘。
- 定义：口径表五栏齐 + 最高优先级指标锁定一行 + 报价单四块齐 + 防御条款入报价单 + 客户签字。
- 交付：第一周原型 + 三项验证（数据流 / 权限 / 回退）+ 评估集三项以上 + 编排模式四选一并记录理由 + S1→S4 业务端点证据 + 四周观察窗口不动。
- 回灌：六段解剖六段齐 + 死因六型之一 + 方法库条目至少一条 + 脱敏三层过。
- 撤离：接班人手册由接班人写 + 断奶按风险从低到高 + 四周法则通过 + 日落条款五项字段齐。