第 4 章 激活部署

「模型通常是最干净的部分。难的是找到那个没人写进文档的工作流。」 —— 一位一线 FDE

「无论技术如何进化，组织内部的人性和权责博弈，始终是比技术更复杂的难题。」 —— 申悦，FDE 一线从业者

4.1 上线不等于激活：企业部署的「首日魔咒」

「激活」在消费互联网，指新用户完成关键行为、体会到产品的「啊哈时刻」（aha moment，用户第一次体会到产品价值的瞬间）。而在企业部署里，激活指目标用户群体在日常工作中，形成对系统的稳定使用习惯——不是演示会上鼓掌，是三个月后没人催、系统依然被高频使用。

换句话说：企业软件的「上线」，走完的只是采购和验收的行政流程；「激活」发生在用户的行为里。上线那天固然值得庆祝，但项目最终是否成功，还得看三个月后还有没有人继续使用。

麻省理工学院 NANDA 实验室那份《生成式人工智能的鸿沟》报告里有一组数字：只有约四成企业为员工提供官方的人工智能工具订阅，而多达九成员工，日常在用个人消费级的人工智能工具干活。这意味着大量企业的真实状态是「双轨制」：官方系统空转，影子人工智能（shadow AI，员工绕开公司官方系统、用个人工具干活的现象）横行。系统上线了，激活却从未发生。

为什么企业部署普遍死在激活环节？因为它要过的是三道关，和消费互联网产品（面向个人用户的 to C 产品）完全不是一种关。消费互联网产品死于「不好玩」，而企业部署死在用户手里——用户嫌它不顺手：比旧习惯多一步，就没人用；用户觉得它不可信：一旦错一次，信任就清零；用户觉得它与自己无关：那就更没人碰。

这三关，没有一关能在总部解决，你只能到客户的会议室、车间和工位上去过。所以激活是 FDE 的主场，也是它跟「交付即走」的传统实施最大的不同：传统实施把验收单当终点，FDE 把客户行为的改变当终点。

4.2 快速迭代：部署期的「热修复」文化

互联网产品迭代靠 A/B 测试（分组对比实验），用小步快跑逼近最优。但企业部署场景里做不了严格的 A/B 测试，样本太小、干扰太多。可它的精神内核——快速、小步、基于证据的迭代——在部署期变成了一种工作方式：像抢修线上事故一样，快速响应用户的每一个小抱怨。我称之为「热修复」。

消费互联网产品的迭代节奏以「版本」计，周更、双周更。而 FDE 部署期的迭代节奏以「天」甚至「小时」计：上午业务用户说「这个输出少了供应商编码字段」，下午字段就加上了；今天车间主任说「这个界面戴着手套点不准」，明天按钮就放大一倍。这种响应速度对用户的意义，远超功能本身——上午提的问题下午就改好，比任何承诺都更能攒下用户的信任。用户在第一个月就会形成判断：「这个团队是来真的」，还是「又一个交完就走的」。

这种节奏不是口号。

品牌效果营销公司 Skai 就接过这么一个紧急需求：数千个商品要在多个电商平台之间统一分类。放在过去，这事得拉上数据科学团队排期——「他们有工具，但产能有限，排进路线图要等很久。」这回，一支面向客户做定制功能的小分队直接在数据平台上调用模型：第一天写好提示词、在客户商品库上跑通，第二天就发布到生产——同样的活按传统做法至少要一个月。带队的副总裁事后总结：「我不需要变成提示词工程师，也不需要变成大模型专家。」热修复的底气，是工具链已经铺到了问题旁边。（出处见附录 C）

热修复文化有三个执行要点。

第一，反馈必须直达写代码的人，中间不能隔着传话筒。以前，用户的反馈要经过客户成功、产品经理、排期，最后才到工程师——每传一手丢一半上下文，等排上期，一周过去了，用户的心也凉了。而在 FDE 模式下，反馈直达写代码的人，最好写代码的人就坐在用户旁边——这不是修辞：第一美国主管数据与人工智能的副总裁普鲁布·纳辛纳（Prabhu Narsina）回忆与平台方工程师的合作，原话是「他们几乎每天和我们一起开会，一起写代码，一起 debug」。Palantir 缩短的正是这个回路：前线部署工程师现场就能构建、测试、学习、回传，不必等一个正式的产品需求走完流程。

第二，迭代优先级由「使用阻塞度」排序，而不是「功能重要度」。部署期的取舍逻辑与产品期相反。产品期按战略价值排需求，而部署期要问的是「什么在阻碍明天的使用」——一个配色问题如果让车间工人觉得「这是给办公室白领做的」，它就是最高优先级；一个强大的预测功能如果用户当前用不上，它就排到激活完成之后。部署期先把使用率做出来，功能深度往后排。

第三，每天收工时问一个问题：今天的改动，让用户明天的哪一刻更顺了？这样修下去，就不只是「有求必应」——每一次修复，都是一次有意识的激活设计：你在逐个拆除用户与系统之间的摩擦点。摩擦点的清单，就藏在进场尽调的流程地图和日常观察里。

OpenAI 的 FDE 工作法里有一个对应的节奏划分：前期共创（驻场白板对齐）、验证（建评估体系，即 evals）、交付（多日驻场构建）。注意交付阶段仍以「多日驻场」为单元——能修得这么快，靠的就是人守在问题旁边。

4.3 在客户的环境里迭代：评估体系驱动的质量提升

速度解决了，还剩方向问题：往哪儿改、改成什么样算好？在人工智能部署里，回答这个问题的载体是一个 2024 年后才成为主流的实践：评估体系——用一批标准案例，给系统的输出持续打分。

传统软件的质量只有两种状态：功能对或错，测试过或不过。而人工智能系统的质量是连续的、概率的、场景相关的——同一个回答在演示里惊艳，在某个具体业务语境里却可能是灾难。更要命的是，「好」的定义权在业务方，不在工程方：模型觉得完美的回答，业务专家可能一眼看出外行。如果没有这把评估标尺，人工智能部署的迭代就是蒙眼狂奔：调了半个月，质量是升是降，没人说得清。

评估体系的工程实践，在领先团队里已经固定成三步。

第一步：从真实案例里长出来。评估集不能靠工程师编，必须来自客户的真实业务素材。这一步的本质，是把业务专家的隐性判断力，显性化为可执行的标尺。

第二步：让业务方成为评委。评估体系不是工程师的自嗨工具，评审者必须包含业务方。最好的做法是把评估做成业务专家能参与的形态：并排的输出对比、简单的优劣标注、定期的评审会。

这个过程有双重收益：评估集越来越准，业务方对系统的理解越来越深——他们看着系统在自家案例上一次比一次答得好，信任的积累是亲眼所见，而非汇报所得。第 2 章写的摩根士丹利就是这么干的：给系统打分的不是工程师，是天天用它的理财顾问。

第三步：把评估体系接到生产回路上。上线不是评估的终点。生产环境里持续采集真实输入输出，定期抽样评估，分数一旦下滑立即告警——这把「质量」从上线前的一次性验收，变成贯穿生命周期的持续看护。毕竟，用户最敏感的不是平均质量，而是质量的稳定性：系统错一次造成的信任塌方，需要十次正确才能填回来。

评估驱动的质量提升，在曲线上长什么样？客服软件公司 Intercom 的公开案例给出了一条罕见的完整上升曲线：它的人工智能客服产品，第一代平均只能解决 23% 的会话，更换底层模型后升到 51%，再针对具体客户深度定制，最高到 86%；Anthropic 自己拿它做客服，自 2024 年上线起持续调优，解决率（会话无需人工介入就解决的比例，口径纪律见附录 A）升到 79%，每月解决约 56 万次会话。同样的爬坡，Salesforce 也走过：把自家客服智能体调了整整一年，「答不上来」的比例才从三成压到一成以下（第 2 章展开过它自用踩坑的另一面）。

上线那天的分数只是曲线的起点，而激活期的质量迭代以季度计。（出处见附录 C）

约翰迪尔的合作，是「评估体系先行」最完整的公开样本。这家公司要解决的是除草剂浪费：传统喷药机整田覆盖，而它的「看见即喷」（See & Spray）技术用 36 个摄像头加机器视觉，在时速 12 到 15 英里的行进中只喷杂草——一分钟覆盖三个足球场的面积。精准农业的理想很大：美国每年种 12 万亿株玉米和大豆，最好的农田每英亩产 200 蒲式耳，顶尖种植者能做到 600——「如果每一株都能被单独照料，产量可以翻天覆地。」这是约翰迪尔技术高管贾斯汀·罗斯的原话。

但农民要的不是技术，是可信的建议。OpenAI 的前线部署工程师飞到爱荷华，跟着农艺师下地，先和专家一起评审数百个真实作业案例、建起定制评估体系，再快速迭代模型——并且必须赶上农时，错过播种季就是错过一年。

最终结果：化学品使用量减少最高 70%，农户的互动频率提升了 6 倍。先有评估体系定下的「好」，才有这两个数字。（出处见附录 C）

评估体系的深层意义在于，把老师傅脑子里那句「什么叫好」，变成系统天天自动执行的打分标准。这正是 FDE 模式的微观缩影——客户的知识不再只是需求文档里的文字，而是活在系统里的标尺。

4.4 另辟蹊径，降低使用门槛

让用户用最少的动作到达价值，是产品设计的常识。但企业系统的使用门槛，往往是系统之外的障碍。部署实践里被反复验证的「降门槛」手法，有四种。

手法一：寄生在用户已有的界面里。用户的主战场在哪，你的系统就该出现在哪：他在电子表格里工作，你就做表格插件；他在邮件里审批，你就让审批在邮件里完成；他在工单系统里干活，你就把人工智能建议嵌进工单卡片。而如果要求他登录新系统，就等于在你和他之间加了一道每天都要翻的墙。

OpenAI 在西班牙对外银行从 12 万员工已有的 ChatGPT 界面切入，Anthropic 则通过模型上下文协议（MCP）让模型进入客户已有的工作流工具，都是同一逻辑。

家居零售商 Lowe's 把同一逻辑做到了卖场地板上：店员的人工智能助手不做成新系统，直接装进他们手里已有的手持终端，语音就能问商品、问库存。这个助手铺到了 1,700 多家门店，累计回答了逾 500 万次店员提问。项目负责人的原话：「不在卖场地板上待过，就没法为门店团队做设计。」（出处见附录 C）

西班牙对外银行是「顺着旧习惯进入组织」的最佳样本。它 2024 年 5 月开始与 OpenAI 合作，第一步只发出去 3300 个 ChatGPT 企业版账号——不做全员运动，先让种子用户自己玩。员工很快自发创建了 2 万多个定制助手（GPTs，员工可自建的专属人工智能应用），其中约 4000 个被高频使用；管理层没有禁止「影子人工智能」，而是反其道行之：「我们给大家一个安全的平台，让他们放心去试。」同时配套结构化培训：250 名高管（含董事长本人）先上课，全行建起「人工智能先锋网络」，培养了一批被内部称为「人工智能极客」的高级用户。一年多后的数据：员工平均每周节省约 3 小时，83% 的人每周活跃使用，账号也扩到了 1.1 万个。2025 年 12 月，双方顺势官宣全行推广：25 个国家、12 万名员工，并启动一个叫「八件事」的端到端转型路线图。从 3300 到 1.1 万再到 12 万，每一步扩张都发生在上一步的使用数据被公布之后——这就是「让习惯自己走路」的激活。（出处见附录 C）

这套打法的在地版本有个关键差别：中国企业少有「员工自主选工具」的土壤，所以种子不是「发账号让员工自己玩」，而是先争取一个事业部或一个条线的专项预算——组织配发的第一批账号，本身就是合法性。

手法二：默认值里藏着激活率。新用户面对空白系统的第一反应是「然后呢」，多数流失就发生在这三秒。FDE 的解法是把「第一次使用」预装好：预置的模板、预填的示例（基于客户自己的数据）、预设的引导（第一次打开时，已经有一个属于他自己的待办）。系统在第一天，就应该比用户更懂他可能要做什么——前几天蹲点观察到的东西，这时候就派上用场了。

手法三：把「问人工智能」翻译成「点按钮」。企业用户对「和人工智能对话」这件事的熟练度，远比想象参差。所以让用户自己组织提问，就等于把工程负担转嫁给最不该负担它的人。

成熟的做法是把高频场景封装成一键动作：「生成上周异常报告」「核对这批发票」「草拟这封客户函」——按钮背后，是经过评估调优的完整提问与流程。对话式交互留给探索，按钮式交互留给日常。

手法三做得最狠的，是供应商先拿自己练手。Salesforce 的自家帮助站沉淀了 74 万多篇知识文章，过去客户遇到问题得自己搜索；他们把问答智能体直接封装进帮助站，用低代码（low-code，拖拽式免编程开发）工具两个月就完成上线——如今 76% 的咨询无需人工介入就解决（2026 年 8 月访问口径）。ServiceNow 同样先拿自己开刀：据其自家披露，自家助手上线 120 天，就跑出约 1,000 万美元的年化收益。

自己先激活，既是最好的测试场，也是最有说服力的销售材料。（出处见附录 C）

手法四：先做「副驾驶」，再谈「自动驾驶」。面对高风险、高抵触的流程，不要一步到位推自动化。让系统先以「建议者」身份存在——人工智能起草、人来确认；人工智能标注、人来裁决。用户在一次次确认中，建立对系统判断力的信任校准；等确认通过率高到一定程度，自动化才提上议程。

约翰迪尔的方案至今保留着农艺师的最终决策权；金融合规场景的智能体设计，普遍保留人工把关；医疗场景更是如此——坦帕综合医院的脓毒症（一种可致命的全身感染反应）预警至今是系统提示、医生裁决（第 8 章会展开这个挽回数百条生命的案例）。先副驾驶后自动，是拿一点激活率换风险可控的稳妥走法。

但「人来确认」有一个反直觉的失效模式：确认一多，人就不看了。Anthropic 的工程团队公布过一组遥测数据（系统自动上报的使用数据）：用户会批准约 93% 的权限请求——看得越多越不细看，审批疲劳让监督形同虚设；一次内部演习里，一封「帮我跑一下这个」的钓鱼邮件，25 次尝试成功了 24 次。

他们的解法是把边界从「指望人每次都认真点允许」挪到系统底层：默认拒绝，出事也翻不了墙。高风险的内容场景，则把这道边界前置到上线之前：TIME 为年度人物做交互式人工智能体验，先让红队（red team，模拟攻击者做安全测试的团队）模拟了数千种攻击手法才放行。副驾驶要配的从来不只是一个「确认按钮」，还有一道不依赖人的注意力的边界。（出处见附录 C）

4.5 旷日持久的集成大战

每个 FDE 老兵都有一身伤疤，它们来自同一场战争：与客户「遗留系统」的集成大战——那些在企业里运行多年、没人敢动的老系统。

战争的残酷程度，超出所有没在一线待过的人的想象。a16z 在《Trading Margin for Moat》里的描述一针见血：人工智能应用需要的上下文——历史记录、业务逻辑、权限体系——全部锁在企业内部的数据库、接口和工作流里，而连接它们的工作「从来都不是选择题，而是必修课」。金融业的老式大型机、医疗业数百家诊所的异构系统、制造业几十套各自为政的车间系统——这些环境的共同点是：文档过时、接口残缺、懂它们的人已经退休了一半。

这场战争的战略要点有四。

• 第一，把集成当战役打，不当杂务办。 集成工作在多数项目计划里被写成一行「系统对接：2 周」，然后在执行中膨胀为四个月。错误的根源，是把集成当技术杂务——其实它既是技术考古，又是组织政治，还得管数据治理，是不折不扣的硬仗。正确的姿势：进场尽调时就画出系统地图，把集成风险分级排期，最硬的骨头最早啃——集成的不确定性最大，每推迟启动一天，整个项目的时间表就裸奔一天。

• 第二，数据问题先于模型问题解决。 那份报告里有个被广泛转引的洞察：大量人工智能项目失败的底层原因是「垃圾进垃圾出」——人工智能接入了未治理的数据源，同一个文档十个版本随机命中，输出自然不可信。Palantir 的解法是本体（ontology）：先把企业的数据资产建模成带业务语义的层，厘清「哪个字段权威、哪个版本有效、谁有权看什么」，人工智能在这层地基上运行。这条路径的普适启示是：数据治理没法在开工前一次性做完，而会贯穿项目始终——很多人工智能项目干到最后，主体工作其实就是治理。连 Palantir 自己都在这事上栽过：内部一个系统被 230 万个数据条目撑爆内存，复盘的第一句话是「我们从未见过这个系统真正要处理的数据」。

美国海军的「造船操作系统」，是这个启示最壮观的注脚。2025 年 12 月，海军部长与 Palantir 首席执行官共同宣布了一笔 4.48 亿美元的合同：先覆盖两家大型造船厂、三个海军船坞和一百家供应商。造船业的数据环境是教科书级的灾难：企业资源计划系统、几十年前的数据库、纸质图纸并存。而试点阶段的两个数字让所有人闭嘴：在核潜艇制造商通用动力电船公司，潜艇排产计划从 160 个人工小时压缩到 10 分钟以内；在朴茨茅斯海军船厂，物料审核时间从几周压缩到一小时以内。

海军部长特意强调：「这不是概念，不是试点，不是研究——这事已经在干了。」（出处见附录 C）

先花大力气把数据接进统一的语义层，效率奇迹才可能发生——而不是反过来。

同样的逻辑在三个完全不同的行业复现。快餐连锁 Wendy's：全北美 6450 家门店的糖浆缺货调度，过去要 15 名员工查上一整天，接入数据平台后五分钟出方案。房贷巨头房利美：用人工智能识别抵押贷款欺诈，检出率超过 99%，远超原来的规则系统。花旗银行：客户信用审批从几小时压到几分钟——人工智能一口气读完信用史、交易习惯、行业风险与关联企业。

三个行业，一个共同前提：先把散乱的数据归置成机器能理解的语义层，智能才有地方落脚。（出处见附录 C）

• 第三，用人工智能打人工智能的集成战争。 一个 2025 年后的重要变量：集成工作本身开始被人工智能自动化。a16z 预想的场景已经部分成为现实——没有接口的老系统，用浏览器智能体模拟人去取数；字段映射、格式转换、接口文档解读，大量交给模型处理。领先团队的自我要求是：「尽最大可能自动化集成流程——流程挖掘、数据管道、系统对接、接口文档梳理——这种速度优势会复利。」用人工智能来干人工智能部署的活，这可能是这个岗位最妙的地方。

• 第四，知道什么时候绕开，而不是攻克。 不是所有遗留系统都值得正面集成：有些系统的正确解法是「影子读取」：只读快照、夜间同步；有些是「人工摆渡」：过渡期保留人工环节；有些干脆「宣告隔离」：明确告知客户该流程的数据不在本项目范围内。工程师的自尊心总想攻克每一座堡垒，而 FDE 的判断力，恰恰体现在选择战场——项目要的是客户结果，不是技术全胜。

4.6 变革管理：让客户组织为你站台

激活最大的软阻力不在技术，在组织。报告的五大路障里，「员工抵触」与「变革管理」合计占了近半壁江山。让系统跑起来，工程师就够了；但要让人的行为改变，就得动员整个组织。

变革管理在 FDE 语境下，核心是三组人物的经营。

• 支持者：你的内部盟友。 每个成功部署的背后，都站着一个客户内部的支持者：他真心相信这件事，愿意押上自己的信誉为你开路。年利达律师事务所的大卫·韦克林就是典型——作为律所市场创新负责人，他是 Harvey 在所内的对应方、倡导者和保护伞。支持者的经营要点：给他能讲的材料（能讲出去的故事）、给他战功（把他的远见变成他职业生涯的亮点）、给他安全感（失败时你顶在前面）。一个被善待的支持者，胜过十场产品宣讲会。Lowe's 干脆把这条做成了制度：每个人工智能项目必须落入「顾客怎么买、门店怎么卖、员工怎么干活」三类之一，且必须有高级副总裁级的业务负责人背书——「他们不入局，我们就不做。」

• 影响者：非正式的意见领袖。 每个组织里都有一批无冕之王：资深分析师、车间老师傅、部门里「问他就行」的人。他们不掌权力，但掌握信任。他们的一句「这玩意儿还真行」，抵过管理层三封全员邮件；他们一句「不好使」，第二天车间里就没人点开。所以激活期要刻意经营这批人：请他们第一批试用、认真对待他们的每一条吐槽、把采纳他们的建议显性化——「这个字段是按王师傅的意见加的」。让影响者成为共同作者，是破解「不是我做的东西我不用」心态的最短路径。设备管理公司 Jamf 是个极端样本：全公司 16 个部门推广之后，最大的意外是「推动最广泛采用的不是工程师」——绩效考核的对话工具是业务同事花不到 45 分钟搭出来的，而过去同类项目要一个团队做三个月。当搭建的门槛降到这个程度，影响者就不再只是口碑节点，而是直接的建设者。

• 受损者：方案触动的利益群体。 自动化必然重新分配工作，而重新分配工作必然制造受损者：被压缩了存在感的审批岗、被穿透了信息壁垒的部门、被替代了「独门手艺」的老员工。如果忽视他们，他们就会成为系统最顽强的地下抵抗者——消极不配合、传播事故案例、在验收时投反对票。成熟的变革管理，会提前设计「受损者的出路」：把被释放的人力导向更高价值的工作（并公开承诺不裁员），把「守门人」转型为「教练」（老师傅的经验用来训练系统），让受损者看到自己在未来里的位置。这既是人道，也是纯粹的功利——抵抗的成本，远高于安抚的成本。

票务平台 Vivid Seats 与 Sierra 的合作，展示了激活期「客户侧全员动员」的样子。决定引入智能体后，这家公司的产品、客户体验、工程三个团队全部压上——「一旦做了决定，我们就百分之百投入，全员重测试。」结果：从启动到上线不到四周，上线后问题解决率提升了 40%，客户满意度（CSAT）提升了 35%。

但更有价值的是后续变化：常规问题被智能体接走后，客户体验团队从「排队灭火」转向根治流程问题，甚至有余力做一些超出客户预期的服务；而智能体对话数据开始反哺产品——「如果一个月有一万人问同一个功能，我们就能立刻把它排上优先级。最好的时刻是：一个规律带来的产品改进，让用户根本不需要再求助。」（出处见附录 C）激活做到头，用户反而越来越少需要求助——这个案例同时预告了第 7 章的「现场反哺产品」。

动员的结构也可以反过来设计：不只是客户在动员，供应商同样把资源嵌进客户组织。Lyft 与 Anthropic 的合作是个三件套：双方共建产品、Lyft 优先获得新能力的早期测试资格、Anthropic 为 Lyft 的工程师提供培训——结果是客服平均解决时长降了 87%，每天有数千个请求由智能体直接解决。三件套里最便宜、也最容易被省掉的是第三件，而往往正是它决定了动员能不能在客户组织里扎下根。（出处见附录 C）

中国公司里的对应样本也在出现。电商公司得物的效率工程负责人任喜亮，把万人规模公司的人工智能转型拆成三步：第一步跟全员达成共识，降低工具门槛，让所有人先用起来；第二步把企业场景按容错空间分成四象限，容错空间大的场景（比如经营分析）优先交给人工智能；第三步设专门的知识运营小组，钻进业务团队里，把专家的隐性经验从个人脑子里搬到人工智能可见的空间。共识、场景、知识——顺序不能反：先有人愿意用，再挑对的地方用，最后让人工智能有米下锅。（出处见附录 C）

变革管理的终极检验标准只有一个：当你的团队撤场后，系统是否依然被使用。如果你在场时热火朝天、撤场后迅速冷却，那不是激活，是伴舞。真正被激活的组织，会自己往前走。

4.7 我，机器人——交付工作本身的自动化

给客户交付自动化，是产品本身；让自己的交付工作自动化，是效率。后者是 FDE 团队摆脱「收入随人头线性增长」的第一杠杆。

FDE 的日常工作中，有惊人比例的动作是可模板化的重复劳动：新客户的部署环境初始化、数据接入的标准管道、安全审查的问卷应答、上线前的检查清单、周期性向客户汇报的格式。每一个第二次做的动作，都应该触发一个提问：「这能变成脚本、模板或清单吗？」

领先团队的做法，已经沉淀成四类资产。

• 部署模板： 把环境搭建、权限配置、监控接入，打包成一键式的基础设施即代码（IaC）。新客户进场，第一天就能在客户的云环境里拉起标准化环境，而不是从零配置一周。Decagon 能把简单场景的部署压到 15 天，背后是高度模板化的接入层。（出处见附录 C）

• 集成组件库： 主流企业系统的连接器（预置的系统对接件），写一次、处处复用。Palantir 的本体模型，本质上把这个逻辑做到了极致：数据接入的产物不是一次性管道，而是可复用的、带业务含义的数据资产。

• 检查清单文化： 安全审查清单、上线准入清单、撤场交接清单。这套清单最见价值的时刻，是撤场前一天：驻场工程师和客户的接手人坐下来，对着交接清单逐项打钩，钩打完，人才撤场。清单把「依赖个人经验」变成「依赖组织记忆」。

• 自动化汇报： 向客户的周报、向公司的现场情报，都应该半自动生成。FDE 的时间单价太高，不该花在复制粘贴上——更不该让「忘了汇报」切断第 7 章要讲的现场与产品之间的回路。

自动化还有一层容易被忽略的用法：把质量检查也交给机器。DoorDash 是典型：其智能客服系统每天处理数十万通来电，背后是自动化测试容量提升了 50 倍——如果没有这样的测试产能，以天为单位的迭代根本不敢在这么大的流量上跑。这也是 DoorDash 能和外部专家团队一起，用八周完成从方案设计到部署的底气之一。（出处见附录 C）

自动化的复利有多可观，可以从一个侧面印证：a16z 把「构建或采购工具来自动化服务交付」列为组建前线部署团队的关键建议，并判断这是这一代人工智能公司能比上一代企业软件公司跑得更快、客单价门槛更低的关键变量。Sierra 公开的一组客户数据也印证了这一点：从启动到上线最快的不到两周、最慢的六周，有客户上线首日就解决了过半咨询；Palantir 把销售周期从九个月压到几周——这些都不是靠工程师加班，是靠把昨天的交付变成今天的脚手架。

前 Palantir 工程师 Barry 把这个逻辑说得更直白：公司在客户试点上烧掉过数百万美元，很多试点的利润率「字面是负无穷」，但管理层把它记在研发的账上，而不是成本的账上——每一次实施，首先是构建与学习的机会，其次才是生意。「百分之九十九的创始人和投资人咽不下这口气。」先承认交付是投资，才轮得到它产生复利。（出处见附录 C）

「FDE 不就是人海战术吗」——这个最常见的质疑，到这里也有了答案。人海的问题不在人多，而在每个人都在做不可复用的一次性劳动。每一次交付都在为下一次交付修路——这样一来，同样的一支队伍，速度也会一轮快过一轮。

系统跑起来了，人也用起来了。但企业生意的残酷在于：激活只能让项目活过第一年；能不能长期活下去，还得看续约。下一章，守住续约。