先说个场面。（合成场景，但"上线达标、第二年消失"这件事我见过两次。）
一家连锁零售，做门店巡检评分。店长每天拍货架照片，模型判陈列合不合规。上线三个月，指标达标：漏检项从三成掉到不到一成，区域经理在例会上表扬过一次。
第四个月区域经理换人。新经理问了一句"这套东西谁在管、结论怎么算出来的"，会议室没人答得上。运维组翻了两天邮箱，翻出当初那份 demo PPT。两个月后评分停了，大家回到把照片发群里。
采购后来跟我说了一句话，难听但准确："你们给的交付文档在哪儿？"
那一刻我才承认，我交出去的是一台能跑的机器，不是一个能运转的系统。这两句话的差别，就是这一篇要讲的尾巴。
尾巴为什么决定第二单，三个漏点怎么补
第一单靠 demo，第二单靠"没有你它还能跑"。
客户决定续不续，问的从来不是"这套技术先不先进"，而是"我这边离了你们的人，还出不出得来结果"。这一问的答案写在尾巴里，不写在模型里。
还有一层不太体面的现实：按人月结算的项目里，文档、培训、交接被双方默认成"售后"，等于白送。白送的活没人排期，最后一定偷工；偷工的结果是第二单没了。
三个漏点，我一个一个说怎么补。
漏点一：知识只在你脑子里。
我见过最浪费的一次交付，是同事写了 42 页接口说明，客户运维组长拿着它问我："这个系统每天早上该有人看哪个数？"我答不上来------那份文档从头到尾没打算让任何人看它。
后来我只要求一份东西，叫《这个系统替谁做了什么判断》，一页 A4，三段话：它替哪个岗位做哪个判断；哪些参数不能自己动，动了会出什么事；出问题了按什么顺序查，先查谁。
再加一个很便宜的补充：在仓库根目录放一份决策记录，只记"为什么没用另一种做法"。客户三个月后想改版，最怕的不是没文档，是把你当初踩过的坑再踩一遍。这份东西写十行就够，三年后救过我的项目。
还有个排期上的经验：文档不是最后一天补的，是长出来的。我现在进场第二周就在客户那边建一个文件夹，名字很朴素，叫"给客户看的"。以后每周一页往里丢：这周我动了哪个判断口径、为什么动、这改动影响谁。到交接那天，那个文件夹本身就是交付包的一半。
最后一天补文档的下场我见过太多次：写的人不耐烦，看的人看不懂，一周之后没人再打开它。
漏点二：培训只做给经理看。
给领导做的培训叫汇报，不叫培训。真正的判据是：一线会不会报错。
我现在固定拆成两场，都很短。
一场给一线，三十分钟，只教三件事：怎么看出这条结果是错的；错了以后点哪个按钮；报给谁、多久要有回音。这三件事写在一张卡片上，打印出来贴在工位，我管它叫上岗卡。
卡片只有五行，样例长这样（内容按常见处境拟写）：
- 这套评分只帮你提前发现明显不合格，不直接作为处罚依据；
- 看到"无法判断"四个字，就是它请你亲自看一眼，不是它没说话；
- 你觉得这条判错了，点"标记不对"------你不点，也没人知道；
- 系统异常找张三（运维），判断口径找李四（区域）；
- 每天开工先看板上那条红色提醒，昨天有几条没处理。
五行是我能接受的上限。超过五行的一线不会看，这张卡就变成了又一份没人读的文档。
一场给运维，也不讲架构，只做一件事：当着他们的面演一次回滚，然后让他们自己演一遍。演砸了当场再来一遍。培训结束时运维手里应该有：登得进去的地址、看板的链接、回滚步骤、我的联系方式和响应时限。
培训完怎么算成功？我看一个数：接下来一周，一线自己发现并拦下的错误条数。是零，就说明根本没培训成------不是他们不认真，是他们没看懂这系统在干什么。
漏点三：运维接不住一套没监控的系统。
这个漏点最贵，补法也最省事：交接之前做一次"断奶演练"，我管这叫把系统还给客户。
具体做法是整整一周，我不动任何东西。不出错我不动，出了错我也不动，只写观察记录，让运维操作，我在旁边记他们卡在第几步。
这一周会把你没写下来的所有东西逼出来。我第一次做的时候，发现三件我以为讲清楚了的事：看板地址在某个人的浏览器书签里；重启服务要先停一个定时任务，这个顺序我从没写在任何地方；出了问题运维找不到客户侧拍板的人是谁。
断奶演练要占整整一周，客户不一定批。这块我没找到一套能说服采购的标准话术，现在我用的办法是把它写成验收条款，而不是请求------"上线验收包含一次运维独立演练"，写进合同，就不用现场求人。
交付包清单：没有我也能跑
这份清单我按"给谁看"排，不按重要程度排。
| 交付物 | 给谁看 | 什么时候证明它有用 |
|---|---|---|
| 《这个系统替谁做了什么判断》一页 | 客户侧新来的任何人 | 换岗那一周 |
| 参数与提示词白名单，改了会怎样 | 运维 | 第一次有人手痒改版 |
| 排错顺序表：症状到先查什么 | 一线、运维 | 第一次报错 |
| 回滚步骤，运维演练过并签字 | 运维 | 出事那天 |
| 联系人矩阵：哪类问题找哪个岗位 | 全体 | 每一次异常 |
| 错误样本集（第 07 篇那个） | 模型侧 | 每次改版回归 |
| 变更窗口与升级流程 | 运维、客户管理 | 第二次改版 |
| 数据留存与删除说明 | 法务、安全 | 内部审计 |
八项里我最看重两项：排错顺序表和错误样本集。前者决定出事当天有没有人能在三十分钟内把系统带回可用；后者决定你半年后改版时敢不敢按发布按钮。
至于 PPT 和架构图，给管理层看确实有用，但挡不住任何一次事故。
这段工时怎么算进报价
先说一句我踩过的坑：早期我把尾巴当成"顺便做掉"的东西，不报价、不排期，结果每次都是项目最后一周熬夜补，补出来的东西自己都不想看。
现在的做法有三条。
尾巴单列一行。 报价里"交接与培训"和开发、部署并列，按我的经验通常占 2 到 4 周工作量（这是经验区间，不是统计）。写进报价它才是交付物；不写，它就变成你的免费加班和客户的"你们不维护"。
用里程碑收，不按工时收。 三个点：上线验收、断奶演练通过、上线后三个月回访。第二单最容易谈的时机就在第三个点上------那时候客户已经知道没有你会怎样。
把长期服务写清边界。 第 02 篇引过阿里云那边给的两类商业化方向：按结果付费，和面向重点客户的长期服务合同。落到一线，长期服务合同能不能签，就看一件事：客户有没有一个人能独立看着这套系统跑起来。有，他敢签；没有，他签了也不安心。
回访那天只问三个数
三个月回访不是客套，它是我判断第二单能不能谈的时刻。我只问三个人，不问领导。
问一线：现在还走这套流程的单子，一天有多少条？掉到个位数，说明系统已经被绕过去了，绕路的原因第 06 篇讲过。
问运维：这三个月你自己处理过几次异常，最麻烦的是哪一次？答不出次数，说明断奶没做成------那这次回访得变成第二次培训，别嫌难看。
问客户侧的业务负责人：这套东西今年让你在哪个数字上省了时间？他答不上来，就先别谈续约，回去把验收数字重新对一遍。第 07 篇第一关那个老问题，一定会在这个时刻现形。
三个数都拿到了，第二单的话术是现成的；拿不到，这一趟就是一次免费诊断，记得别把它写成售后。
一句收尾
尾巴做到什么程度算够，我到现在没一个准数。多做一周像浪费，少做一周客户就散了。
我目前只留一条粗糙的判据，但它每次都管用：从运维组里随便拉一个人，在他没得到我任何帮助的情况下，能不能把系统从"出问题了"带回"能用"。能，就叫交完了；不能，就还没交完。
这一条也顺手替我回答了另一个问题------为什么我宁愿少接一单，也要把断奶演练留在排期里。
下一篇回到技术，把 FDE 的栈地图摊开：模型选型、检索、工作流、工具调用、评测、部署、权限。