FDE的职责与工作流程

第2章　FDE的职责与工作流程

第1章说明了企业AI项目为何难以落地，并把FDE定位为在客户现场补上这一差距的角色。本章回答三个问题：FDE 具体做什么，工作按什么顺序推进，责任如何划分。全章先给出FDE的工作定义，并将其与相近岗位（adjacent roles）区分开来；随后引入贯穿全书的四组概念：两种工作模式，即发现与构建；三个交付阶段，即界定、验证与交付，以及阶段之间的门；四类责任归属，即结果、实现、决策与访问边界，它们被写进一页纸的交付章程；最后说明两类交付产出，即当前客户的系统与可复用的经验。读完本章，读者应能判断一项工作处于哪个阶段和哪种模式，说明每项决策由谁拍板，并为一个项目起草交付章程。本章不涉及编码，结尾要求读者为合众通信起草一份交付章程草案。

2.1　FDE的定义与由来

FDE这个名称在AI领域流行得较晚，它所指的工作方式却出现得更早。本节先交代这个岗位的来历，再给出本书使用的定义，最后说明同名岗位在不同公司里为什么并不相同。

2.1.1　岗位名称的来历

“前线部署”借自军事用语，原指把部队部署在靠近前沿的位置。软件行业借用这一说法，强调工程师靠近问题发生的现场，并拥有根据现场情况作出取舍的空间，不必把每个决定都提交总部。

这种做法并不是软件行业自然形成的，而是被一类特殊的客户环境逼出来的。Palantir早期的客户是情报机构，使用者是领域专家而不是软件人员，数据散落在难以替换的遗留系统里，判断出错的代价又很高。厂商无法在远处拿到准确的需求，只好先做出原型，拿给使用者看，再按反馈修改，如此反复，直到产品与使用者的真实工作逐渐对上。把工程师放在使用者身边，就是把这个循环缩到最短。

通常认为，Palantir 在 2010 年代初将这种工作方式固定为一个岗位，内部曾以 Delta 作为代号。这个代号来自早期业务拓展团队按北约音标字母命名的习惯。公司同时设有负责平台的产品研发工程师，两类岗位的区别可以概括为：产品研发工程师把一种能力做给许多客户，前线部署工程师则为一个客户组合和调用多种能力；前者关注平台的质量与复用，后者关注客户的业务目标是否达成。据称，在 2016 年之前，前线部署工程师的人数一度超过平台工程师。也有观点认为，工程师嵌入客户现场的做法在 IT 服务业中出现得更早，因此其起源仍有争议。本书不讨论谁最早采用这一做法，只说明这一岗位名称，以及“现场—产品”之间的反馈机制，是在 Palantir 逐渐成形的。

这样分工的意义不止于组织架构，还在于它形成了从现场回到产品的反馈。据一位前员工的回忆，早期的前线部署工程师在客户处做了大量手工的重复性工作，产品团队再把其中反复出现的部分做成工具，平台的许多组成部分由此成形。

大模型进入企业之后，这种工作方式重新被需要。模型是通用的，从模型能力到企业里一个能用的系统，中间隔着数据、流程、权限与组织这几类问题，这一层不会因为模型变强而自动消失。据报道，OpenAI在ChatGPT发布之后，因为早期企业客户难以从模型中获得价值，设立了专门的前线部署工程团队。

2.1.2　本书对FDE的工作定义

各公司的岗位说明措辞不一，本书不照搬其中任何一份。它们大多围绕同一个现实：产品或模型能够提供的能力，与客户真正需要的能力之间总有差距，FDE的工作就是在现场补上这段差距。本书把这一工作展开为三个条件；三者同时成立，才属于本书所说的FDE。这样做是把FDE的定位拆成可以逐项检查的条件。

（1）位置，在客户的真实环境中工作，使用客户的真实数据与系统，直接面对使用结果的人。

（2）责任，对客户的业务结果负责，验收标准是系统在生产环境中运行并达到约定的指标，而不是交出文档、演示或功能清单。

（3）沉淀，把现场所得整理成可复用的组件、评估脚本和做法，使下一次部署更快、更稳。

有两点需要澄清。第一，在现场工作不等于接受客户提出的每一项要求。判断需求本身是否正确，也是FDE的责任；对结果负责，包含判断哪些要求不应当做。第二，对结果负责不等于多写代码。衡量工作的是客户实际获得的价值，而不是代码数量，因此最好的做法有时是少做。项目结束时，客户应当比项目开始时更有能力独立运行这套系统，而不是更加依赖FDE小组。

第三个条件还需要说明一处取舍。在产品厂商内部，沉淀的去向通常是公司的核心产品。但本书的读者不一定受雇于产品厂商，也可能在系统集成商、企业自己的技术部门或科研团队里做同样的工作。对他们来说，沉淀的去向是团队自己的组件库、评估脚本和文档模板，而不是某个产品。因此本书把第三个条件表述为“沉淀”，不要求“回流到产品”。

三个条件缺一不可：不在现场，工作容易退化为远程实施；不对结果负责，工作容易退化为交出分析和建议；没有沉淀，每个项目都从头开始，人员离开后系统也可能停摆，最终成为一次性的定制开发，也就是国内读者熟悉的驻场外包。

以合众通信为例。Tom提出“用AI预测基站故障”之后，FDE小组进入东部区域的网络运维中心，使用中心真实的告警和工单数据，在值班主管和外场工程师能够亲手使用的环境里把系统做出来。评价这个系统的，是网络可用率一类业务指标，而不是代码量或演示效果；项目结束时，数据接入和评估脚本这些部分，应当能留给下一个项目复用。

2.1.3　岗位名称相同，工作内容不同

同样称为FDE，实际工作内容并不相同。从公开的岗位说明看，各公司通常把这一岗位的重心放在三类工作之一：协助成交、推动客户成功，或为核心产品积累能力。同类工作还可能被称为应用AI工程师、部署工程师或智能体工程师。本书讨论的是以客户成功为主要目标、同时重视经验沉淀的一类工作，也就是同时满足位置、责任、沉淀三个条件的工作。

差异也有历史原因。一位曾在Palantir任职的工程师对这个岗位的历史作过分期：早期做平台部署与稳定，之后依次是数据集成、客户定制应用、平台与赋能，近来是大模型部署。这些工作不是后者取代前者，而是逐层叠加，所以今天的岗位说明常常像是几类职业的合并。国内也可能出现把驻场外包改称FDE的岗位。招聘启事里写着“FDE”的岗位，与本书所讲的相符到什么程度，需要逐条对照三个条件来判断。

招聘市场的数字也要这样读。Lightcast的2026年招聘数据（经媒体转述）显示，2026年1至8月，FDE岗位的发布量比上年同期增长了十倍以上。这个数字统计的是发布的岗位数，而不是录用的人数，转述的报道没有给出起始基数，而基数很小时增幅会显得很大；岗位名称的含义又不统一。所以它只能说明这个名称正在被大量使用，不能由此推出有多少人在做本书所讲的工作，这与阅读失败率数字的方法是同一个思路，先问度量对象和口径。招聘、薪酬与职业路径不是本书的主题，下文不再讨论。

2.2　相近岗位与FDE小组

本书用三个条件界定FDE：在客户的真实环境中工作，对客户的业务结果负责，并把现场经验沉淀下来。本节把这三个条件作为比较尺度，用来考察企业中与FDE共享部分客户、技术或目标、但容易混淆的岗位，说明它们分别在哪一项上与FDE不同；随后再说明，为完成一个项目，FDE 需要与哪些人组成小组。这样做有两个目的：一是帮助读者在招聘启事、项目分工或团队介绍中判断某项工作是否属于本书讨论的范围；二是帮助读者进入项目后明确哪些事情应交给其他岗位，哪些事情必须由自己承担。

2.2.1　用三个条件比较岗位

比较岗位时，容易落入两种做法。一种是罗列职责清单，清单很长、彼此交叉，读完仍然分不清差别；另一种是给岗位排高低，仿佛FDE是其他岗位的升级版。本书不采用这两种做法。每个相近岗位，都是组织针对某个具体问题作出的安排：售前工程师以较低成本回答大量客户的技术问题，顾问在不承担实施责任的前提下提供相对独立的判断，产品经理在多个客户的需求之间作出取舍。FDE 的安排不同，它要求工程师较长时间深入一个客户。这种安排成本较高，也无法覆盖大量客户，因此企业通常只在差距最大、风险最高的地方使用 FDE。

比较时对每个岗位问三个问题，分别对应位置、责任、沉淀三个条件。

（1）位置：这个岗位在成交之前还是之后接触客户，接触多长时间，是否使用客户的真实数据与系统。

（2）责任：系统出了问题，由谁在生产环境中承担后果；代码写在谁的环境里，由谁维护。

（3）沉淀：一次项目所得的经验，有没有固定的渠道进入下一次项目。

表2-1按这三个问题比较了七种相近岗位，另加两列说明各岗位通常对什么负责、产出什么。表中写的是各岗位在多数公司里的典型情形，具体公司会有出入，各条的依据在下文逐项说明。

表2-1　FDE与七种相近岗位的比较

使用这张表时，重点不是统计一个岗位具备几项特征，而是看它缺少哪一项。缺少现场位置的岗位，与客户之间隔着转述，信息容易在转述中失真；缺少结果责任的岗位，即使产出被客户接受，也未必经受过生产环境的检验；缺少沉淀机制的岗位，每个项目都像第一次开始。FDE 的特点是三项同时具备，这既是它的价值，也是它成本较高的原因。下面按这些缺口展开讨论：成交之前的岗位通常缺少生产结果责任；成交之后的岗位分别可能缺少结果责任、沉淀机制，或缺少修改系统的权限；产品一侧的岗位则通常缺少客户现场的位置。

名称不能代替这把尺子。同类工作在不同公司里被叫作FDE、应用AI工程师、部署工程师，甚至解决方案架构师，而同名岗位的重心又各不相同。读岗位说明时，不必先看名称，逐条核对三个条件即可：工作地点和数据是否真实，验收是否以生产环境中的结果为准，经验有没有去处。

2.2.2　成交之前的岗位

售前工程师和解决方案架构师在成交之前就与客户的技术人员接触，用到的技术能力也与FDE相近，所以最容易与FDE混淆。区别在于责任在哪里终止。售前工程师的工作服务于促成交易：做演示，回答技术问题，搭建用来说服客户的概念验证环境，目标是签下合同，而不是交付合同所承诺的结果。解决方案架构师多出一层，要与客户一起设计整体方案，产出是架构图和建议，落地由客户自己或第三方实施方完成，所以他的责任通常在方案交给实施方时就结束了。

责任终点不同，产出的证明力也不同。演示提供的是存在性证据，只说明存在一批输入，系统在这批输入上表现良好。售前与方案阶段的概念验证常使用脱敏或离线的数据，在这个意义上与演示同类：它们适合回答“这条路有没有可能走通”，回答不了“在这家客户的生产环境里能不能持续运行”。FDE的工作从后一个问题开始，所以必须使用真实数据，也必须把权限、失败处理这些售前阶段可以暂时略去的事情做完。

这些岗位与FDE并不对立。一个项目的前半段通常由它们完成，FDE 接手的是它们留下的承诺和假设。FDE 也可能参与成交，帮助客户判断产品能否在其环境中运行，但多数FDE岗位不设置销售指标，评价仍以交付结果为准。

2.2.3　成交之后的岗位

成交之后，企业里还有三种岗位同样与客户长期接触，分别是咨询顾问、系统实施方和客户成功经理。它们各缺一项，缺的东西不同。

咨询顾问的产品是建议，价值在于独立：不牵涉实施利益，才能对客户说出不中听的实话。管理咨询的交付物是报告和路线图，报告交出，项目即告结束，建议是否有效要很久以后才有人检验，也未必归到顾问身上。所以FDE与顾问的差别不在谁更聪明，而在建议被检验的速度。FDE的判断一旦落到系统里，几周之内就会在生产数据和用户反馈面前接受检验，错了要自己返工；这种被快速纠正的处境，是FDE判断力的来源之一。代价是FDE的独立性弱于顾问：他对自己构建的系统有利害关系，评价这套系统时需要有人旁证，这也是评估设计中要把评估与构建分开的原因。

系统实施方包括系统集成商和驻场外包，他们同样写生产代码，也同样驻留现场，与FDE最为相像。差别在两处。一是责任的边界：实施方按合同范围交付，范围之外不是他的事，需求清单上没有的问题，即使发现了也缺少动力去解决；FDE对结果负责，所以要判断清单本身对不对。二是经验的归属：实施方的代码和经验常常止于这一个项目，下一个项目的团队从头再来；不为产品厂商工作的实施顾问，写出的代码再好，也进不了其他客户共用的产品。这两处差别来自合同安排和组织安排，而不是个人能力。同一位工程师，在按人天计费、需求清单固定的合同下，做的是实施；在以业务指标验收、并留出沉淀时间的安排下，做的才是FDE的工作。这也是“驻场外包改称FDE”的风险所在：名称改了，合同没有改，工作也就没有改。

客户成功经理对客户的续约和使用采纳负责，是最了解客户日常使用情况的人。他发现问题之后，需要把问题提给产品和工程团队排期，从发现到修复常以季度计，他自己通常不修改系统。因此客户成功经理与FDE更像接力而不是替代：FDE项目的终点，是把运行中的系统连同监控、回退办法和已知问题清单交给客户成功经理或客户自己的运维团队，使系统在FDE撤出之后仍有人负责。也有公司设置“客户工程师”一类的岗位，写脚本、排查接口问题来保持客户的系统运行，但不承担新系统的构建。这可以看作客户成功经理向工程一侧的延伸。

2.2.4　产品一侧的岗位

产品经理与FDE的分歧最为微妙，因为二者的目标相同，都是让产品对客户有用。差别在取舍的单位。产品经理为产品在全部客户上的整体价值负责，面对一个具体客户的要求，他要问这是不是许多客户共有的需求；FDE为眼前这位客户的结果负责，他要问怎样才能让系统在这里运行起来。两边的判断各有道理，所以冲突是结构性的，不是谁对谁错。有的公司在客户一侧设置“前线部署产品经理”，专门对一个客户账户的成果负责，再把所见带回核心产品团队，说明这种冲突已经有专门的岗位去消化。

FDE有就地取舍的权力，可以在现场改变范围、调整方案，不必每件事都等总部批准。但这种权力有边界。本书的做法是按影响范围划线：只影响这一位客户、事后可以撤回的决定，由FDE小组在现场作出；会改变产品对所有客户的行为、或者难以撤回的决定，提交产品一侧裁决。这条线不是行业公认的标准，而是本书为避免现场的权宜之计悄悄变成产品的永久特性而采用的规则。

产品研发工程师，也称平台工程师，是沉淀的接收方。FDE在现场写出的东西往往带着这个客户的特殊假设，要改写成能被许多客户使用的组件，需要懂得抽象和兼容性的人来做。FDE与平台工程师之间的关系，决定了现场所得是变成产品，还是留在某个客户的代码仓库里。有的公司专门设置服务FDE的平台团队，派人嵌入各个客户小组，帮助解决架构与重构问题，使FDE的成果更容易放大。

2.2.5　岗位之间的交接缝

分工越细，交接处的风险越大。一个FDE项目里有三个交接缝，每一处都有常见的失败方式，也都有可以事先做的防范。

第一处在成交与进场之间。售前阶段的承诺、演示中看到的效果，以及客户由此形成的期望，会被FDE小组原样继承，而这些承诺通常是在没有接触真实数据的情况下作出的。典型的失败是小组进场后发现，承诺的指标在真实数据上做不到，却已经写进了合同。防范的办法是进场之初把承诺拆开重新核对：哪些已有证据，哪些只是假设，哪些要等看到数据之后才知道。这也是本章后面要引入阶段之间的门和交付章程的原因。

第二处在现场与产品之间。现场所得要变成沉淀，需要有人整理，也需要有人接收。常见的失败有两种：所得停留在个人笔记和聊天记录里，没有人整理；或者产品团队收到的是客户的原话，而不是归纳之后的问题，无从判断是个别现象还是共性。防范的办法是把沉淀当作交付物的一部分，在项目计划里为它留出时间和责任人，而不是等项目结束后有空再做。

第三处在交付与运行之间。FDE撤出之后，系统由客户的运维团队或客户成功经理接手。常见的失败是系统能够运行，但接手的人不知道它为什么这样设计、出了问题如何回退，几个月之后没有人敢动它。防范的办法是把移交当作一项要验收的工作：接手方应当不依赖原来的工程师，独立完成日常运行，并完成一次故障恢复。

这三处合起来说明，FDE的工作不是从进场开始、到撤出为止的一段，而是向前接着售前的承诺，向后连着运行的责任。后面各章要求读者留下的交付物，很大一部分就是为了让这三处交接可以被检查。

2.2.6　FDE小组的组成

一个人要同时具备足够的技术深度、对产品的判断、与业务人员打交道的能力和对不确定性的耐受力，并不容易。所以规模较大的FDE项目通常由小组而不是个人承担。本书所说的FDE小组，指为同一个客户目标共同承担界定、构建和交付的人，不论他们隶属于产品厂商、系统集成商，还是企业内部的技术部门。小组之外还有客户一侧的对接人，他们不是小组成员，却决定小组能做什么。

Palantir的做法是把小组内部分成两种取向。一种称为Delta，即前线部署工程师，偏重构建：全栈开发、接口集成、数据管道、调试线上系统。另一种称为Echo，即部署战略师（Deployment Strategist），偏重界定：弄清客户业务在哪些环节最值得改进，定义可度量的成果，管理干系人与变更。通俗地说，Echo更接近为客户的问题负责的产品经理，Delta更接近能把东西做出来的工程师。

这两种取向与后文要讨论的发现、构建两种工作模式有对应关系，但不能等同。发现与构建是同一个人在一个项目里反复交替的模式，Echo和Delta则是小组内部的分工。小项目里一位FDE两种模式都要做；规模变大之后，权重才分到两个人身上，一人以发现为主，另一人以构建为主。

有两点容易被误解。第一，分工不是交接。由Echo先把问题界定清楚、再交给Delta去做，是一种常见的失败方式：能否构建本身决定了问题该怎样界定，数据拿不拿得到、权限批不批得下来，只有动过手的人才清楚。所以两个人应当同时参与发现，也同时对结果负责，Palantir内部也承认两种岗位的界线在实践中常常模糊。第二，搭配没有固定的比例。每个客户项目都需要有一个人对“做什么”负责，有一个人对“做出来”负责，至于小组里各有几位，要看项目当前的瓶颈；规模小时，两个责任可以落在同一个人身上。

在此基础上，本书设想了小组内部的五种职能。这不是任何一家公司的固定组织架构；一个人可以承担多项职能，一项职能也可以由多人分担，如表 2-2 所示。

表2-2　FDE小组内的五种职能

近来公开的岗位说明显示，这种分工在大公司里仍在细化。OpenAI为其FDE组织设置了技术部署负责人，职责包括与客户发起人确定试点范围和验收标准，制定整体的交付计划，并在计划的早期核查安全、权限、审计和基础设施是否满足企业要求。这些职责落在表2-2的现场牵头和评估与验收两项上，可以看作这两项职能在项目变大后从开发者身上分离出来的一个实例。

对读者而言，本书的练习要求一个人，或者一个学习小组，在合众通信的案例上依次承担表2-2中的全部职能。这样安排是出于教学：读者需要体会每一项职能的难处，并不意味着现实中一个人应当包办。

2.2.7　小组的规模与汇报关系

小组的形态随规模变化。创业公司和小项目里，一位FDE常常同时承担界定与构建；规模上升之后，两种取向会重新分开，分开的时机取决于一个人能否同时照顾好客户关系和构建。因此不存在唯一正确的编制，要看项目当前的瓶颈在界定还是在构建：界定不清时增加牵头的力量，构建积压时增加工程的力量。

汇报关系同样影响小组的行为。FDE小组可以挂在销售、产品或工程三条线下，每条线的考核不同，所偏向的条件也不同。下面是本书的推论，不是统计结论。挂在销售线下，评价容易向成交和续约倾斜，责任条件会收缩成促成交易；挂在产品线下，沉淀有渠道，却容易被客户现场的紧急事务挤掉；挂在工程线下，构建质量有保障，但与客户业务的距离容易拉长。没有哪一条线能同时保护三个条件，所以无论挂在哪里，都需要用交付章程把三个条件写成小组自己的考核项。

回到合众通信。Tom提出需求之后，FDE小组进入东部区域的网络运维中心。对小组而言，Tom是结果的责任人，Alice和Bob是最了解真实流程的使用者，David掌握系统权限与安全审查，Emma和Frank分别对接备件采购与效益核算。这几个人不是小组成员，却是小组每天打交道的对接人，小组能做到什么程度，很大程度上取决于与他们之间的责任划分是否清楚。这些划分怎样写成一页纸，是后面的交付章程和本章交付物要回答的问题。

2.3　发现与构建两种工作模式

前一节说明了FDE小组由哪些职能构成。本节讨论小组成员在工作时处于什么模式。一位FDE的一周可能看起来很杂乱：上午坐在值班席旁观察操作，下午修改数据接入代码，晚上为负责人写一页说明。若按这些活动要回答的问题进行归类，可以得到两种工作模式（working mode）：一种是弄清问题究竟是什么，称为发现模式（discovery mode）；另一种是做出能够被检验的东西，称为构建模式（build mode）。本节先说明模式、岗位和阶段是三个不同的维度，再分别描述两种模式的目标、做法、产出和纪律，然后讨论两种模式如何转换，以及两种典型的失败方式。

2.3.1　模式、岗位与阶段是三个维度

本章反复用到三个词：岗位、阶段和模式。它们回答的是不同的问题，混用会得出错误的安排。岗位说明一个人在组织里负责什么，表2-1把FDE与相近岗位区分开，用的就是这个维度。阶段说明一个项目推进到了哪里，以及下一步投入凭什么证据，本章用三个阶段和阶段之间的门来规定。模式则说明一个人在某一段时间里主要想回答什么问题，由他当前缺少的信息决定。三个维度互相独立。同一个岗位的人在一天之内可以经历两种模式，同一个阶段之内两种模式都会出现，表2-3把三者并列。

表2-3　岗位、阶段与模式的区别

分清三个维度，可以避免三种常见的误用。第一种是把模式当成岗位，在小组里指定一些人专门负责发现，另一些人专门负责构建。这样安排之后，构建的人看不到客户，发现的人拿不到数据，两边靠文档交接，而发现与构建本来就不是两道可以交接的工序，小组里的搭配也没有固定的比例。第二种是把模式当成阶段，规定前三周做发现，之后都是构建。发现于是变成一个日期，而不是一份证据，客户在第四周才说出口的约束没有地方安放。第三种是把阶段当成模式，以为通过了阶段门，发现就可以停止。阶段门检验的是证据是否足以支持下一步投入，并不保证问题从此不再变化。

本书还要处理一个用词上的麻烦。在业内的资料里，“发现”有时是项目某个阶段的名称，有时是指一类活动，两种用法会在同一篇文章里同时出现。本书把它固定为模式的名称。项目阶段另用界定、验证和交付三个词。

模式与小组内Echo、Delta两种取向也不是一回事。Echo和Delta是小组分工的重心，一位成员在一段时间内主要承担哪一种，取决于小组的搭配；模式则是同一个人在同一个项目里的交替。小项目里只有一位FDE时，他自己在两种模式之间往返，两个概念重合；小组变大之后，两个概念分开，但每位成员仍然需要知道自己此刻处于哪种模式。

2.3.2　发现模式

发现模式的目标，是把客户陈述的问题转化为可以检验的问题。客户最初提出的往往是方案名称，如“需要一个聊天机器人”“要使用检索增强”“想要一个能够自主行动的智能体”。这些是方案设想，不是需求，因为它们没有说明谁在什么环节遭遇了什么损失，也没有说明达到什么程度才算有用。发现模式要做的，就是把模糊请求转化为清楚的工程问题。

发现的对象有三类。第一类是工作本身，也就是任务实际上是怎样完成的：谁在做，用哪些系统，在哪些环节绕开了官方流程。第二类是约束，包括数据能否取得、权限由谁批准、合规与集成有什么限制。约束必须在发现模式里就摸清，因为在做出一个系统之后才发现一条无法绕开的安全、合规或集成限制，是企业AI项目中常见的失败原因。第三类是人，即谁会因这个系统受益，谁会受到影响，谁有权否决。

获取这些信息的主要办法是看，而不是问。情境访查（contextual inquiry）的做法是到用户自己的环境里，观察他完成真实的任务，一边看一边问，并把自己对观察的理解说给当事人核对。影子工作法（shadowing）更进一步，要求跟着用户过完他真实的一天，看他打开哪些系统，在哪些表格之间复制粘贴，在哪些环节皱眉，绕过了哪些流程。之所以要看，是因为用户对自己的工作有大量没有说出口的经验，访谈里给出的往往是整理过的版本；而官方流程文件与实际做法常常在多年前就已经分开了。观察的重点因此是变通，也就是那些偏离流程的地方，以及人们实际信任的数据来源，而不是流程图本身。创业方法里“走出办公楼”的主张与此相通：商业设想只是假说，必须拿到客户那里检验。

一个来自制造业质检环节的综合性叙述，可以说明陈述的问题与真实的问题可以相差多远。管理层的说法是要把检测自动化；一线观察的结果却是，检测本身每件约十五分钟，而事后的记录、转录和归档每件约四十五分钟，积压的文档才是客户投诉的源头。两种理解对应的第一个切片完全不同：前者需要计算机视觉和监管审批，周期以季度计，通过的把握很小；后者只需要把口述转成结构化记录，再导入既有系统，三周就可以做出第一版。这一叙述是综合性的，数字属于叙述者的设定，本书用它说明发现的价值，不把它当作统计事实。

发现模式有四种典型产出，下面逐一说明。它们不需要写成长篇文档，几页纸足够，要紧的是每一条都能追溯到一次具体的观察或一次具体的谈话。

（1）现场笔记（field notes）。按时间顺序记录看到的和听到的，并且把观察到的事实与自己的解释分开写。以后别人要复核一个判断，要能从笔记中找回当时的原始情形。

（2）问题陈述（problem statement）。用客户自己的语言写一两句话，说明谁在哪个环节遇到了什么损失，现在怎样应付，以及怎样才算好转。问题陈述需要得到负责结果的人认可，不能只由小组自己认定。

（3）利益相关方线索。至少回答四个问题：谁最终使用这个系统，谁负责它的运行，谁批准它上线，出了问题谁来救场。这四个问题通常足以暴露塑造设计的主要约束。

（4）假设台账（assumption ledger）。把范围、排除项、当前的假设、已知的风险、各项事务的责任人和成功标准列出来，并且随着发现的深入不断更新。台账的作用是让不确定性可见，而不是假装它不存在。

发现模式的纪律可以概括为先听问题，再提出方案。过早提出方案有两个代价：客户会围绕这个方案重新组织自己的描述，之后说出的需求变成对既定方案的修补；小组也会过早绑定在某条技术路线，等发现路线不合适时更难回头。这并不意味着发现模式中不能写代码。为看清数据形态而编写的一次性脚本，可以作为发现工具使用，只要不把其结果误认为系统的一部分。判断是否越界的方法很简单：在提出方案前，先让客户用自己的话复述问题，并确认复述准确。

发现的结论也可以是不做。如果这个问题不在客户最重要的几项优先事项之内，生产部署所需要的、持续数月的高层关注和跨部门配合就得不到保证；如果没有业务负责人认领结果，或者拿不到真实数据，项目同样不应该继续投入。把这样的结论及早写下，并附上“什么条件满足后可以重新开始”，是发现模式的正当产出。具体的访谈提纲、观察记录方法和利益相关方地图，留到第3章。

2.3.3　构建模式

构建模式的目标，是做出能够被检验的东西。“能够被检验”有三层含义：客户可以在真实数据上亲手使用，评估集可以对其进行量化评分，另一个人可以复核构建过程和结果。目标不是立即做出完整系统，也不是做出外观漂亮的演示。

构建模式的基本单位是切片（vertical slice）。切片沿着完整工作流，从真实输入一直到可核对的结果，只实现最窄的一条通路；通路中的每一层都保持最小实现，但整条路径必须打通。软件工程中所说的走通骨架（walking skeleton）与此相近。之所以做切片而不是单独演示某个组件，是因为单个组件无法暴露组件之间的接口假设：数据格式、权限传递和人工复核如何衔接，只有整条路径走通后才会显现。

以合众通信为例。在发现完成之前，还不能确定该做什么，但可以说明切片是什么形态：取一类工单，让工单系统导出的真实记录进入，经过分类，结果出现在值班席的界面上，由值班人员确认或更正，确认或更正的结果再回写到评估记录里。这条路上每一层都很薄，没有复杂的界面，没有多余的功能，却已经能回答数据是否可用、结果是否有人愿意核对、更正能否回流这几个问题。这个例子只用来说明切片的形态，不代表合众通信项目最终要做的事情。

切片与演示、概念验证的区别，可以用四个条件检查：数据必须是真实数据，而不是专门为演示准备的数据；流程必须是客户实际使用的流程，而不是简化版本；结果必须按照事先写明的判据评分；失败必须被记录并能够追溯。四个条件缺少任何一个，所构建的东西就仍然更接近演示。

构建模式有六条纪律。

第一，从最简单的办法开始。先用最直接的做法走通，例如一次模型调用、一组规则或一次检索，只有评估显示不够用时才增加复杂度。复杂度一旦加上去，每一层都要付出调试、评估和维护的代价。

第二，预期第一版会被推翻。第一版的作用是尽快得到真实的反馈，被推翻是它的正常结局，不被使用才是它的失败。因此第一版不值得为了完美而多花时间。

第三，让客户操作。键盘应当在客户手里，由客户输入他们平时会输入的内容，尝试设计者没想到的用法，甚至把它弄坏。由开发者操作、客户旁观的讲解式演示，换来的多半是礼貌的掌声而不是信息。

第四，公开面对失败。第一个切片在真实数据上出错是常见的事。演示出错时，恰当的反应是当着客户的面追查输入的哪一部分超出了设计的预期，并把它登记成评估集里的一条新样例。客户由此看到系统是可以在他们面前被调试的，信心来自失败被修复的过程，而不是一场没有失误的演示。

第五，先拿一个小而真实的成果，再谈大而完整的方案。一个能在短时间内产生真实价值的小成果，比长篇的路线图更能赢得信任，坏消息也应当尽早说出。

第六，按会长期运行来写。一个为了应急而写的“临时”脚本，一旦帮到了别人，就进入了别人的工作，拆掉它的代价由别人承担，它因此会一直运行下去。所以哪怕是切片，也要在交付之前想过：谁在半夜被它叫醒，出了问题交给谁，为了快做出了哪些取舍。

构建模式的产出是四样东西：可运行的切片，在评估集上的结果，失败记录，以及客户操作时的观察笔记。最后一样常被忽略，它却是连接两种模式的桥梁，下一小节回到这一点。表2-4把两种模式并列比较，两列的内容是各自模式的典型情形，同一个项目的不同时点会有出入。

表2-4　发现模式与构建模式的比较

2.3.4　两种模式之间的转换

两种模式在时间上的分布随项目的推进而变化。一个常见的描述是：第一周几乎全是发现，尽量少做构建；中间几周两者混合，但偏重构建；最后几周以构建为主，发现活动用来检验所建的东西能否真正落地。图2-1的下半部分用界定、验证、交付三个阶段表示了这种变化。图中各段的长度只表示相对比重，不是实测数据，具体比例随项目而不同。

图2-1　发现与构建两种工作模式及其转换

为什么不先把发现做完，再开始构建？有三个理由。其一，客户说不清的东西，往往要看到东西才说得清。一个能运行的切片摆在使用者面前，引出的反应比任何访谈提纲都多。其二，数据与权限的真实状况，多半要等到真正接入时才暴露：样本里干净的数据，到了生产环境里常常不再干净，各业务线的字段含义也未必一致。其三，两种模式的关系不是先后，而是相互供给。

设计领域的双钻模型（Double Diamond）有助于看清这一点。它把设计过程画成两个依次出现的钻石，每个钻石都先发散、再收敛：第一个钻石用来确定问题，第二个钻石用来确定方案。对FDE而言，发现大体对应第一个钻石，构建大体对应第二个。不同之处在于现场：客户的真实数据和真实的使用者，让第二个钻石里做出的东西反过来修正第一个钻石里的结论，所以两个钻石在这里不是依次出现，而是交替出现，一对小的往返在一周之内就会发生几次。这也是FDE需要在客户现场工作、而不是在远处遥控的理由之一。

既然模式要交替，就需要一些信号来提示何时转换。下面的信号是本书归纳的经验，不是统计规律。从发现转入构建，有三个信号。

1）问题陈述已经得到负责结果的人认可。

2）第一个切片需要的真实数据，入口已经打通，或者已经有明确的开通路径与日期。

3）成功判据可以检验，即写得出“达到什么就算通过、没达到什么就算不通过”的句子。

从构建回到发现，也有四个信号。

1）客户在操作中做了设计者没有预料的动作，说明小组对工作的理解有缺口。

2）评估中的失败集中在某一类输入上，而原因不在模型或代码，在于对这类输入的业务含义理解不够。

3）出现了新的责任人、审批环节或权限障碍，这些在发现时没有被看到。

4）指标在改善，但使用者并不使用，说明被改善的可能不是使用者真正的难处。

信号只能提示，不能替小组做判断，而判断常常发生在忙乱之中。为了让“此刻处于哪种模式”变成可以检查的事，本书建议小组每周写一份模式声明（mode declaration），由五项组成。这是本书为教学设计的做法，不是行业的通行规范。

1）本周的主要模式，是发现还是构建。

2）本周要回答的一个问题，只写一个。

3）预期看到什么证据。

4）由谁判断证据是否充分，应当包括客户一侧的一位对接人。

5）证据与预期不符时，下一周怎么办。

声明的价值在周末对照。如果问题连续两周写不出来，或者连续几周声明的都是构建，而要回答的问题却没有变化，往往说明小组已经滑向下一小节所说的某种失败。

最后要提到切换的成本。发现需要在使用者身边，构建需要开发环境，两处离得太远，转换就会被拖延，小组也就长期停留在较舒服的那一种模式里。可行的缓解办法是把一部分开发放到现场，让评估和调试在使用者看得到的地方进行，这是本书的推论。现场的开发环境需要符合客户的安全要求。

2.3.5　两种典型的失败

模式用错的方式，基本上有两种，每一种又各有一个容易被忽略的变体。

第一种是只发现、不构建。表现为访谈、调研和报告不断增加，却始终没有可以运行的东西，项目停留在“概念验证坟墓”的状态，即概念验证既不通过也不终止，长期搁置：没有期限、没有指标，也没有裁判。这种失败之所以常见，是因为不构建看起来更稳妥；没有东西做出来，也就没有东西会被证明不可行。它的一种变体是在会议室里发现，只访谈管理者和信息部门，不观察一线人员的实际操作，最后得到的只是管理者眼中的问题。

第二种是只构建、不发现。表现为技术推进很快，演示也很漂亮，却没有人能够回答系统给谁使用、在哪个环节使用、怎样才算有用。系统可以运行，但部署仍然失败，原因往往是选错了问题。例如一场只用历史导出文件做成的故障预测演示，就是这种失败的一个侧面：演示在技术上可以是真实的，但演示之后没有人能够回答权限、处置成本、依据和度量四个问题。它的另一种变体是在合成数据上构建。访问权限尚未批准时，合成数据可以暂时帮助项目保持进度，但必须明确标注其性质并记录这项依赖，不能把基于合成数据得到的结论推广到真实使用场景。

只构建不发现，在实践中比只发现不构建更难被自己察觉。一个可能的原因是反馈的速度不同：代码跑通、指标上升，是即时的、令人满意的反馈；发现的反馈则迟缓而含糊，要过几天才知道一次访谈是否有价值。人倾向于停留在反馈快的模式里。这是本书的推论，不是已有研究的结论。

两种失败各有一个简单的自检问题，可以每周问一次。上一次由使用者本人在真实数据上操作业务系统，是哪一天？上一次有一个判断因为发现而被改变，是哪一天？前一个问题回答不出，说明发现停在会议室里，或者构建停在合成数据上；后一个问题回答不出，说明小组可能只在执行，而没有在学习。

案例　三周没有离开工位

以下情境为虚构，用于说明只构建不发现的一种形态。Tom提出“用AI预测基站故障”之后，FDE小组拿到一份历史告警和工单的导出文件，立即开工。三周里，小组每天在自己的工位上整理数据、设计特征、比较模型，每周的模式声明都写着“构建”，要回答的问题一栏也都是同一句：把预测做准。

第三周末的内部复盘上，一位成员翻出日历：十五个工作日里，小组在网络运维中心现场的时间只有开工会的半天；与值班主管Alice、外场工程师Bob没有说过一句话。小组能报出模型的离线指标，却说不出一次基站故障从告警到修复要经过哪几个环节，也说不出预测结果会在哪个班次、通过哪个界面送到谁的手里。

复盘没有讨论要不要换模型，而是改了三条做法：没有写进模式声明的问题不开工；每周至少有一个半天待在使用者的工位旁，只观察；发现模式的产出，即现场笔记和问题陈述，必须先于下一个切片提交。第四周，小组进入了中心。这次观察看到了什么，留到第3章再讲。

本节区分的两种模式，是理解后面各节的基础。后面把项目的推进拆成三个阶段，并规定阶段之间的门；模式则在每一个阶段内部反复出现，两者交叉，构成小组每周需要回答的一个问题：现在处于哪个阶段，这一周又处于哪种模式。

2.4　交付的三个阶段

前一节讨论的是一个人在一段时间内主要想回答什么问题。本节换到项目的尺度，讨论一个项目推进到了哪里，以及凭什么证据决定下一步投入。客户最先想要的往往是一个能演示的东西，小组最容易给出的也是能演示的东西，而能演示与可交付之间隔着许多还没有回答的问题。把这些问题按试错代价由低到高排开，每一组问题的末尾都要作一次决定：证据够不够，值不值得把更多的人和时间投进下一组问题。一组问题，加上末尾的那次决定，就是本书所说的一个阶段。

2.4.1　三个阶段总览

本书把FDE项目分为三个阶段（phase）。界定（scoping）回答该不该做、做什么；验证（validation）回答能不能做到、能做到什么程度；交付（delivery）回答能否在客户生产环境中长期运行，并交给客户自己的团队。三个问题的排列遵循同一逻辑：每个问题的试错成本都高于前一个。界定主要投入人员时间；验证需要接入真实数据的代表性样本并建立评估，投入数周的高级工程师时间；交付则需要完成集成、权限、上线、监控和移交，投入最大。把成本最低的问题放在前面，只有在前一个问题获得答案后才进入更昂贵的阶段，这就是三个阶段的排列依据。

阶段的名称与划分是本书的教学设计，业内的资料并不统一。OpenAI的一份岗位说明把工作列为发现、技术界定、系统设计、构建和生产推广五个环节。另有几份行业资料转述其前线部署团队的做法，分为早期界定、验证和交付三段，其中验证一段要先与客户商定验证标准，再借助评估反复改进，最后对照目标出具报告。还有资料把上线过程拆成若干步，每一步都有负责人和退出条件。划分的粗细各不相同，共同点是每一段结束时都要拿出证据，说明可以继续。本书取三段，是因为它们正好对应三类不同的证据：问题是真实的，方案行得通，系统撑得住。再细分出来的环节，多半仍然服务于这三类证据之一，不会多出新的决定。

阶段与模式是两个独立的维度（表2-3）。每个阶段里发现与构建都会出现，只是比重不同：界定以发现为主；验证以构建为主，用发现去解释失败；交付以构建为主，用发现去跟踪真实的使用。三个阶段之间设两道阶段门。本书把界定与验证之间的门称为界定门，把验证与交付之间的门称为验证门，这是本书的叫法，不是业内通行的术语。图2-2把三个阶段、两道阶段门以及它们在全书中的位置放在一起，中间一行给出与概念验证、试点、生产、规模化四个阶段的对应关系。

图2-2　交付的三个阶段、阶段门与全书章节

这里的“验证”要与“概念验证”区分开。概念验证是企业AI项目常用的概念验证、试点、生产、规模化四个阶段中的第一个，原指以较小成本回答技术上是否可行。本书的验证阶段所做的事，大体就是这个意义上的概念验证，但附加了三个要求：使用真实数据的代表样本；判据在开始之前写明并获得认可；结束时必须在阶段门上作出决定。这三条恰好是概念验证坟墓所缺少的。两套阶段的对应关系是：界定阶段的通过条件，就是概念验证的进入条件，即业务问题与成功指标已写明、现状基线已测得；验证阶段的通过条件，覆盖概念验证的通过条件和试点的进入条件；交付阶段包含试点与生产，规模化所需的价值证据与复现留待后面的章节，它既可以是交付阶段的收尾，也可以是下一个用例新一轮三阶段的起点。

还要说明阶段的单位。阶段针对的是一个用例（use case），而不是一个客户。一家企业往往陆续提出多个用例，每个用例各自经历三个阶段，前一个用例留下的数据接入、权限安排和评估方法，可以缩短后一个用例的界定与验证。据一家科技媒体2026年9月对OpenAI一位负责人发言的报道，某半导体客户在大约18个月里陆续上线了约35个用例。这只是一个单方说法，数字不能推广，但它提示了一点：与客户的关系是长的，三个阶段会被反复经过。

2.4.2　界定阶段

界定阶段回答该不该做、做什么。工作主要处于发现模式：观察真实工作，摸清约束，找到结果负责人，并把客户陈述的问题转化为可以检验的问题。构建只限于两类：一类是为看清数据而编写的一次性脚本，另一类是对最窄切片的设想。这个阶段通常以数天到数周计，不应拖延数月，因为它几乎不需要生产资源；如果持续过久，往往说明小组正在用调研代替决定。

界定阶段结束时，小组需要拿出五件交付物。

1）问题陈述及其认可记录，由负责结果的人签认。

2）范围说明书，写明这一轮做什么，同样重要的是写明不做什么，以及满足什么条件后可以重新讨论被排除的部分（第3章）。

3）指标的定义和现状基线，即要改善的数字按什么口径计算、现在是多少（第4章）。

4）评估集方案和验收门槛。方案写明样本从哪里来、多少条、由谁标注；门槛写明达到什么数字、按什么口径算通过、由谁认可（第5章）。评估集的初版也在这一阶段做出，扩充与校准在验证阶段继续。

5）方案选型和架构决策记录，写明备选方案、取舍理由和已知风险（第6章）。

有的资料把验收门槛的认可看作验证阶段的任务。本书把它提前到界定阶段的末尾，原因是验证阶段一开始就要拿门槛当判据，门槛若在结果出来之后才定，标准就会迁就结果，所以退出条件必须在阶段开始之前写明。

界定门要检查三件事。第一，五件交付物齐备。第二，问题陈述、指标和门槛都已由结果责任人认可，也就是客户一侧有一个具体的人对结果负责，并且这件事在客户最重要的几项事务之内，否则此后持续数月的高层关注与跨部门配合无从保证。第三，真实数据的入口已经打通，或者有明确的开通路径和日期，并且有人对访问边界负责。此外，客户一侧最好有一位能在信息技术、安全和采购流程上批准例外的发起人；没有这样的人，即便对方态度友好，所做的也只是一次商务洽谈，还不是一个项目。

界定阶段的终止条件，是发现模式中“不做”这一结论的正式形式，也对应三个预警信号：没有业务方的负责人，只有信息部门在对接；只许看不给碰，要求先证明能力却不提供真实数据；需求没有边界，第一次会议就要覆盖全公司的场景。出现其中两个以上，并且在约定日期前仍无改变，界定门的结论就应当是停止。停止不是失败。一份写明因为什么停止、满足什么条件后可以重启的记录，是小组交给客户的有价值的产出，比一个勉强开工、半年后无疾而终的项目便宜得多。

以合众通信为例。Tom目前给出的是一个方案设想，即“用AI预测基站故障”，加上一个目标，即减少网络中断，对象是东部区域网络运维中心。要通过界定门，这五件交付物目前都还是空白：真实的问题、指标口径和验收门槛，要到第3至6章才逐项填写。在那之前，这个项目只是一个设想，还没有到可以开始验证的时候。

2.4.3　验证阶段

验证阶段回答的问题是：在这家企业的真实数据上，按照事先写明的判据，这项工作能够做到什么程度。工作以构建模式为主：完成界定阶段选定的第一个切片，接入真实数据的代表性样本，用评估集评分，让客户使用者亲手操作，记录失败并分析原因；发现模式则用来解释失败，例如失败集中在哪类输入，背后对应什么业务规则。

真实数据在哪个阶段进入，资料的说法不一。有的把早期原型建立在合成数据上，真实数据到交付阶段才取得；有的则要求在验证阶段就让系统在真实数据的代表样本上运行。本书取后一种，要求真实数据不晚于验证阶段进入。合成数据可以回答一个想法在原理上行不行，却回答不了它在这家企业自己的数据上行不行，而验证阶段要回答的恰恰是后一个问题。界定阶段里用合成数据做出的演示可以帮助沟通，但不构成验证门所需要的证据，这与只构建不发现时“在合成数据上构建”是同一类错误。

验证阶段结束时的交付物有五件。

1）可运行的第一个切片，能在真实数据上从输入走到可核对的结果。

2）首次评测结果，与门槛并列呈现，而不是只给出一个平均数；它既是基线，也是后续改进的起点。

3）失败案例清单及原因归类，分清是数据问题、规则问题、模型问题还是权限问题。

4）使用者亲手操作的观察记录和人工验收记录。

5）对验证门的建议，附证据包，说明建议继续、缩小、补证还是停止，以及理由。

验证阶段有一条容易被忽略的纪律：先建评估，再谈改进。有资料建议，验证阶段的第一周只做评估集并跑出基线，不写生产代码，不做集成，也不部署，把基线与客户要求的门槛并排摆给客户看。差距小，项目就短；差距大，双方对工作量就有了共同的认识，范围与日程可以据此调整。这样做是把后期才会爆发的分歧提前到便宜的时候。有从业者估计，验证占用一到三周的高级工程师时间，而跳过它，可能使数月的交付工作指向错误的目标；这是经验估计，不是统计结果，不同项目的差异很大。

一个行业文章中的综合性叙述，可以说明验证阶段的价值。叙述中的项目，是为一家拥有400家门店的零售商做店员助手，界定阶段约定的门槛是在100条评估案例上达到70%。首次评测只得到41%：系统分不清会员顾客和散客，因而答错退货规则；也应付不了每周五调整的清仓降价规则。小组用两周补做修正，分数升到73%，随后在12家门店试点，第10周扩大到48家。这是一个综合性叙述，其中的数字不是实测。值得注意的有三点。第一，41%出现在验证阶段，代价是几天的时间，而不是上线之后的投诉。第二，验证门上的决定既不是继续，也不是停止，而是带着日期的补证。第三，“每周五变化的规则”不是模型能解决的问题，需要有人负责把规则的更新送进系统，这是责任归属问题；这一点是本书的解读。

验证门要检查四件事。其一，评估集上的结果达到事先认可的门槛，并且必须项（任何一项不满足都不得继续的判据）全部满足。其二，失败路径可以恢复：系统出错时有人工兜底，错误可以被发现，操作可以回退。其三，使用者愿意继续使用，这要看客户在亲手操作中的行为，而不是演示会上的礼貌反应。其四，数据与权限的范围已由数据和安全的责任人确认，交付阶段的人力与成本估算已用验证的结果更新；其中数据与权限的确认，对应试点的进入条件。

验证阶段的终止条件沿用概念验证的规定：到达周期上限仍未达标，且拿不出具体的改进路径。再加两种情形：失败的原因指向数据质量或权限，而这两样在约定期限内无法补救；必须项反复不达标。这三种情形下，继续把人力投入交付阶段，只会把已知的问题带进更昂贵的环境。

验证阶段最常见的偏差有三种：事后调整门槛，使结果看起来通过；只展示通过的样本，把失败的样本留在抽屉里；把验证做成演示，用选定的数据和客户旁观的方式，换来的是掌声而不是证据。构建模式中切片与演示的四个区别条件，可以用来检查验证有没有滑向演示。

2.4.4　交付阶段

交付阶段回答的问题是：这个系统能不能在客户的生产环境里长期运行，并且交给客户自己的人。它包含的工作最多，第9至25章展开的绝大部分内容都属于这一阶段：企业数据与知识的接入，工具调用与工作流等系统能力，集成、身份与权限，安全与合规，容量与发布门禁，监控与成本，效益量化，用户采纳，以及运维移交与组件沉淀。工作仍以构建模式为主，发现模式用来跟踪真实使用中出现的新情况，例如使用者绕开系统的地方，往往指出了系统与真实流程之间尚未对齐的部分。

交付阶段内部还包括发布门禁，不能把它与阶段门混为一谈。阶段门决定是否把更多人员和时间投入下一阶段，是对投入的决定；发布门禁检查某个具体版本是否具备上线条件，例如运行、安全和恢复方面的证据是否齐全，是对版本的检查，在交付阶段内可能经过多次。验证阶段通过，并不等于可以绕过发布门禁。试点即使成功，如果从未演练过恢复，发布仍然可能被否决。反过来，即使通过了每一道发布门禁，系统也可能因为业务指标没有变化，在交付阶段结束时被判定为未达成目标。

交付阶段的上线不是一次动作，而是逐步放宽的过程。常见的做法是先在受限的范围内上线，由人逐条监看，随着生产流量上的评估结果持续干净，再逐步放宽约束。灰度发布（canary release）是同一思路在技术上的实现。本书把这个过程看作一连串小型的门：每一次放宽，都是把系统暴露给此前没有检验过的条件，而已有的证据只对被检验过的条件有效，所以放宽需要新的证据，不能沿用小范围试验中积累的信心。每一步都应当有负责人和退出条件，并且在放量之前就准备好可用的回退方案。

交付阶段以移交收尾。移交不是把文档交出去，而是责任的转移。责任只应在门通过之后转移：接手运行的一方，在验收通过之前不承担持续支持的责任，这样就不会有人在无意之中承担了责任。移交包通常包括运行手册、告警、评估集、仪表盘和升级路径，以及经过培训的客户一侧负责人。本书建议用一个具体的判据检验移交是否完成，这是本书的设计：在FDE不在场的情况下，客户一侧的运行负责人能够独立完成三件事，即处理一次告警，用评估集复核一次质量，执行一次回退。三件事做不到，移交就没有完成。

交付阶段结束时，通过的标志不是系统已经上线，而是约定的业务指标按事先的口径移动了，并且移交验收完成。系统在生产环境里运行而指标不动，是交付阶段最典型的停滞，采纳而不是部署才是终点。终止的条件沿用试点和生产的规定：质量或使用持续不达标，运行成本或风险超出事先写明的上限且无法降级处理，或者出现不可接受的安全事件。

表2-5把三个阶段并列比较。它只是总览。

表2-5　三个阶段的比较

2.4.5　阶段之间的门

阶段门（phase gate）是两个阶段之间的一次正式决定：在投入下一阶段之前，根据现有证据决定继续、缩小、补证或停止。既有 资料对这一概念的称呼并不统一，本书统一使用“阶段门”。图 2-2 中的界定门位于界定与验证之间，验证门位于验证与交付之间。交付阶段的终点另有移交验收，其作用与阶段门相近，但检验的是责任是否具备转移条件。

在阶段之后设门，并非FDE的发明。一篇1990年发表的新产品管理论文提出的阶段门方法，把新产品开发分成若干阶段，每个阶段之后设一道门；每道门由三部分组成，即项目团队要提交的交付物、用来评判的判据，以及据此作出的决定，决定有继续、终止、暂缓和退回四种。项目管理方法PRINCE2在阶段交界处也有类似安排：阶段结束时，项目经理向项目委员会汇报，重新核对业务论证是否仍然成立，更新计划与风险，再由委员会决定继续、调整或终止。两者共同的思想是，投入不应当沿着惯性自动延伸，每一步都要有一次明确的、有人负责的决定。

本书借用这个结构，作三处改动。第一，判据不在门上才讨论，而是在阶段开始之前写入交付章程。“门检验证据而不是时间”，前提就是证据的标准在看到证据之前已经定下。第二，不设无期限的暂缓。无期限的暂缓正是概念验证坟墓的入口，本书把它改为补证：限一次，写明日期，写明补什么。第三，增设缩小，即缩小范围后继续。资料中遇到未达标的情形，常见的处理是调整范围，或者结束项目；问题局限且可以回退时，也可以收窄范围后继续试点。把缩小写成一种正式的决定，可以避免小组在继续与停止之间摇摆。表2-6列出四种决定。

表2-6　阶段门的四种决定

一道门由三部分组成。

1）证据包（evidence pack）。小组交给决定者的材料，应当短，能在一次会议里读完，内容包括阶段交付物、与判据逐项对照的结果，以及小组自己的建议。结果不好的部分不得省略。

2）判据（criteria）。事先写入章程的通过条件与终止条件，每一条都有口径和数字，或者是可以核对的事实。判据分为必须项和期望项，下面说明。

3）决定记录。写明决定、理由、决定者和日期，以及决定带出的条件，例如补证的截止日期。记录保存在章程的变更记录里。

判据分为两类。必须项（must-meet criteria）是任何一项不满足都不得继续的条件；期望项（should-meet criteria）则需要综合权衡〔Cooper·1990〕。区分两者，是为了避免平均数掩盖致命缺陷：一个整体正确率很高的系统，如果越过了批准的数据访问范围，或漏掉客户最重视的一类案例，平均成绩再好也不能放行。有资料中的合同审阅案例把门槛定为审阅时间减少 60%，同时要求在客户最关心的案例上不得漏掉需要修改的条款；前一项是期望项，后一项是必须项。凡涉及安全、权限和不可逆操作的要求，都应优先考虑列为必须项。

谁来作决定，与谁来提供证据，必须是两方。证据由小组提供，决定由客户一侧负责结果的人作出，他的权限来自业务发起人，而不来自提供系统的一方，否则就成了既做又判。这项权限要在章程里写明。小组可以提出建议，但建议不是决定。

门看的是证据，不是日历。证据齐备，门可以提前召开；到了周期上限，门必须召开，但到期不等于通过，结论完全可以是停止。门上还要注意证据的适用范围。评估集如果在调试过程中被反复看过，系统就可能是照着它调出来的，用它在门上打出的分数会偏乐观。较稳妥的做法，是在门上加入一部分调试时没有看过的样本，具体办法见第5章。

阶段门容易退化成三种形式。其一是走过场，会议照开，结论永远是继续。一道从不说“不”的门不提供任何信息；回顾小组过去经过的几道门，数一数有几次的结论是缩小、补证或停止，是检验门是否有效的一项简单自检，这是本书的建议。其二是事后补门，系统已经上线，才回头补写判据和决定，这时的判据只是对已经发生的事情的追认。其三是按平均数放行，忽略必须项。

三个阶段不是瀑布。学到了新东西，可以重新打开较早的决定：验证中发现界定时的假设有误，就退回修订范围说明书，修订经过章程的变更程序并留下记录。设门的目的，是防止在小实验里得到的信心，在不知不觉中被用到更大、条件不同的情形上。

最后给出一项按阶段定位项目停滞的自检。读者可以用它判断一个迟迟没有进展的项目卡在哪里。

1）卡在界定：客户一侧说不出这件事在他们重要事项中的位置，或者没有人认领结果，或者问题陈述迟迟得不到认可。

2）卡在验证：评测反复重做而门槛不变，或者门槛一再被修改，或者首次评测结果迟迟没有与门槛并列呈现给客户。

3）卡在交付：系统已经在生产环境运行，约定的业务指标却不动，或者移交一再推迟。

这项自检的思路来自资料中按阶段诊断项目的做法，具体条目为本书重写。

三个阶段和两道门说明了项目按什么顺序推进，却没有说明谁有权在门上作出决定，也没有说明变更怎样处理。这两件事由下一节的交付章程回答。

2.5　交付章程

前几节留下了几件没有落实的事。现场决定与产品决定要按影响范围划线，这条线要并入决策归属的规定；阶段门的判据要在阶段开始之前写下来，并且要有一个具体的人在门上拍板；业务结果归谁、系统运行归谁、数据归谁、出了事归谁这四个问题，也还没有落到一份可以签字的文件上。本节把这些事收进同一份文件，即交付章程（delivery charter）。

交付章程是客户与FDE小组在项目开始时共同签署的一份短文件，写明项目要达到什么、不做什么，四类事项分别由谁负责，阶段门凭什么证据通过，以及变更如何提出和批准。它既不是合同，也不是方案文档。合同约束商务条款，方案文档说明系统如何实现，章程回答的是另一类问题：出现分歧或意外时，应当找谁，由谁作出决定。下面先说明为什么需要这份文件，再讨论四类归属、决策归属与决策清单、访问边界与访问清单、章程的写法和变更，最后说明章程与现场诊断表的关系。

2.5.1　为什么需要一份章程

企业AI项目里的责任不清，多数时候不是因为没有人，而是因为没有人把它写下来。口头约定在平静时够用，在三种时刻会失效。一是人员变动，说好负责的人调走了，接任者并不认这个约定。二是压力出现，进度落后或者指标不动，各方都倾向于把原因归到相邻的部门。三是出现意外，例如发现系统读到了不该读的数据，需要立刻决定怎么办，却没有人知道该找谁。书面文件的作用，是把这三种时刻要用到的答案提前写好。

与此相应，常见缺口有三个，分别对应下面四类归属中的结果、决策和访问边界。第一，结果无人认领。系统上线后业务指标没有变化，业务一方认为这是技术问题，技术一方认为是业务流程没有配合，两种说法都可能成立，根源在于没有指定对业务指标负责的人。第二，决策无主或越位。需要拍板时，每个人都掌握一部分权限，却没有人拥有完整的决定权，于是议而不决；或者有人认为自己可以决定，替他人作出了超出权限的决定。第三，访问边界依赖默认设置。为了尽快做出可演示的原型，系统使用权限很大的共享账号，没有人正式批准，也没有人认真核对它能够读取什么，直到安全评审时才暴露。对AI项目而言，这一缺口尤其严重，因为系统读取的数据和调用的工具通常多于一般业务应用；一旦出错，事后也很难查清它读取过什么、依据了什么。

项目管理里早有相近的做法。项目章程（project charter）是由发起方批准的文件，授权项目开始，并允许项目负责人调动资源，通常写明项目的目的、目标、范围、主要相关方，以及假设与约束。责任分配的方法如RACI、DACI和RAPID，则要求把一项工作或决策中谁建议、谁执行、谁拍板、谁只需知情区分开来。在AI风险管理的框架里，治理被作为贯穿全过程的职能，强调组织要对与AI相关的角色、责任和决策权限作出明确安排。

本书的交付章程沿用这个形式，但作了三处调整，它们是本书的设计，不是通行规范。其一，更短。FDE项目周期短、变化快，几十页的章程在第一次变更时就已过时，也没有人愿意通读，所以正文力求一页纸，访问清单、变更记录、证据包等放在附件里，其他文件已有的内容只引用，不复制。其二，访问边界单独成项。一般的项目章程把权限放在约束或风险里一笔带过，而AI系统读取客户数据的方式，直接决定项目能否获准上线，值得单列，并且写成可核对的清单。其三，加入阶段门与退出条件，承接前面对阶段门的约定。

章程与合同的关系是引用而不是取代。凡涉及价款、期限、知识产权和违约责任的内容，以合同为准，章程只写工作层面的安排，并在开头写明所依据的合同。这样分工的好处是，修改工作安排不必走商务流程，章程可以随项目进展及时更新；章程与合同出现冲突时，以合同为准，并通过章程的变更程序修正章程。这是本书的建议。

2.5.2　四类归属

归属（ownership）指对某一类事项负最终责任、并有权作出决定的人。本书把FDE项目中需要事先指定归属的事项分为四类：结果、实现、决策和访问边界，各指定一位负责人。四类归属的含义、通常的承担方和在合众通信中的对应人物见图2-3。

图2-3　交付章程中的四类归属

结果归属回答“业务指标改善了没有，谁对此负责”。结果责任人必须在客户一侧，并且有权调配与结果相关的流程、人员和预算。理由在于，系统达标并不等于业务指标改善。预测再准，如果值班排班和告警处置流程没有改变，网络中断也不会减少，而这些都不在FDE小组的权限之内。所以要把两种责任分开：小组对系统在约定条件下达到约定质量负责，结果责任人对业务指标负责。分开之后，指标不动时才能分清，是系统没有达标，还是系统达标而业务没有跟进。移交验收和效益量化，都要用到这一区分。在合众通信，网络运维中心主任Tom有预算和拍板权，是结果责任人。

实现归属回答“系统怎样做，做得好不好，谁说了算”。实现责任人在小组一侧，通常是小组的技术负责人，对技术方案、代码质量、评估方法和系统在约定条件下的表现负责。这一类的边界由另外三类划定：不能越过结果责任人认可的目标和门槛，不能越过访问边界批准人的批准，也不能把会影响所有客户的产品决定当作本客户的现场决定。把它写下来，不是为了限制小组。客户需要技术答复时知道找谁，小组的技术判断（例如拒绝一个会使系统无法评估的方案）也因此有人承担。

决策归属和访问边界各有一些需要展开的内容，分别放在下面两小节。这里先说明四类之间的关系：结果和实现是一个项目的两端，一端在客户的业务里，一端在小组的工程里；决策归属规定两端之间的分歧由谁裁断；访问边界则是一道独立的闸门，不论结果多么紧迫，实现多么合理，都要先过这道闸门。

2.5.3　决策归属与决策清单

决策归属回答“遇到分歧，谁说了算”。其核心要求只有一条：每项决策必须有且只能有一位拍板人。拍板人必须是具体的人，而不是部门、委员会或“双方协商”。人们常以为共同决定更稳妥，实际上共同决定往往意味着没有人单独负责，出问题时责任无处安放。DACI 区分推动者、批准者、贡献者和知情者，RAPID 区分建议、同意、执行、提供意见和决定；这些方法细节不同，但共同的最低要求都是一项决策只能有一位决定者。本书采用这一最低要求，不要求完整采用某一种框架。

项目开始时无法列出将来要作的每一项决定，可行的做法是按类别列出决策清单（decision list）：每个类别写明拍板人、事先要咨询的人和事后要通知的人，以及拍板人的答复期限。表2-7给出一份起点。表中的拍板人是通常的安排，不是固定的规定，客户组织不同，对应的人也不同。

表2-7　决策类别与通常的拍板人

表2-7中有两点需要说明。第一，它把现场决定与产品决定的划线规则并入了决策归属：只影响这一位客户、事后可以撤回的决定，由小组在现场作出；会改变产品对所有客户的行为、或者难以撤回的决定，提交产品一侧裁断。第二，本节在这条规则上增加了一条：涉及客户数据和权限的决定，无论大小，都不由小组自己作出。可撤回性对访问并不成立。授权可以收回，但授权期间已经发生的读取无法收回，所以“先放开，出了问题再关”并不是可撤回的决定。这一条是本书的设计，依据是访问一旦发生就无法撤销这一事实。

一个人可以承担多类归属，规模较小的客户尤其如此，Tom就同时是发起人、结果责任人和多数决策的拍板人。兼任本身不是错误，但有两种兼任需要警惕。其一，提供证据的人同时决定门的结果，等于自己评审自己，所以阶段门的证据由小组提供，决定由客户一侧作出，不能反过来。其二，对业务指标负责的人同时批准访问边界，指标压力会推着他放宽权限，所以访问边界的批准人宜独立于结果责任人，通常由信息技术或安全部门的负责人担任。这是本书的建议，依据是两者的激励方向不同：前者希望尽快见效，后者承担权限被滥用的后果。必须兼任时，要在章程里写明兼任，并指定一位复核人。

2.5.4　访问边界与访问清单

访问边界回答五个问题：“系统能读什么、写什么，以谁的身份，在什么期限内，谁批准、谁撤销？”批准人通常是客户信息技术或安全部门的负责人，在合众通信中是信息技术部负责人 David。章程不应写“按公司安全规定执行”这类无法核对的表述，而应附一份访问清单（access list）。清单中每项权限占一行，写明对象（库、表、字段或接口）、权限类型（读或写）、身份（个人账号或服务账号，并写明具体账号）、批准人、有效期和撤销方式。

清单背后的原则是最小权限（principle of least privilege）：每个主体只获得完成任务所必需的权限，且只在必要的期间内持有。对AI系统，这条原则有两处需要特别注意。第一是身份。如果所有调用共用一个服务账号，审计记录就无法追到发起提问的人。有资料给出一个综合案例：某资产管理机构原计划让投资研究摘要智能体使用单一服务账号，安全负责人认为，涉及未公开重大信息的读取必须能追到具体的人，这个架构因此被否决。第二是期限。临时开放的权限如果没有期限，就会变成永久权限，因为没有人记得去关。所以清单中每一项都要有有效期，到期自动失效，续期是一次新的批准，而不是对旧批准的默认延长。

访问边界还有一个容易忽略的特点：批准人往往不止一位。大型客户里，业务、信息技术和合规常常各有一位负责人，各握一把钥匙，缺哪一把项目都走不下去。有资料给出医疗行业的综合案例，临床信息、信息技术和财务三位负责人各自关心不同的事，项目只有同时取得三方信任才能推进。因此进场之初就要问清楚，一共有几把钥匙，各在谁手里，并把持钥匙的人写进章程。在资料的同一个综合案例里，隐私负责人从第二周起就参与设计，几条不可协商的要求被直接写进了架构，原本预计要半年的内部审查在十一周内通过。这只是一个综合案例，不能当作统计规律，但它说明了一点：把审批方尽早拉进设计，比在上线前补审批省时间。

小组有时确实需要超出常规的权限，信息技术部门的拒绝也未必总是对的。这时较稳妥的请求方式，是提出一次有边界的例外：范围明确，有期限，有责任人，有回退办法，到期时要么转为正式安排，要么关闭。这样的请求比“请开放访问”小得多，也给批准人留出了一个不影响他处理下一个同类请求的说“是”的理由。后面的案例框给出了一个具体的例子。

2.5.5　章程怎么写

表2-8是章程的模板，共七个条款。每个条款写什么、由谁认可，以及对应前文哪一节，都在表中列出。条款的取舍是本书的设计，其中目标、范围、相关方、假设与约束取自项目管理中章程的通行内容。

表2-8　交付章程模板

写章程时有四条规则。第一，有名有姓。每一项归属都写具体的人及其备份，部门名和岗位名不算，因为部门不会签字，也不会接电话。第二，可检验。读完一个条款，应当能判断它是做到了还是没做到。“提升运维效率”不可检验；“东部区域网络运维中心因基站故障造成的中断时长，按指标定义文件的口径，较基线下降到约定的水平”才可检验。目标值要等现场发现和指标定义的工作完成后才能填入，起草时可以留空，但留空处必须写明由谁、在何日前填入。第三，写明不做什么。范围若只写做什么，没写的事就由各方心里的默认来填，争议多半从这里开始。第四，引用而不复制。指标定义、评估集方案等已有专门文件的内容，章程只写文件名和版本，避免两处记载不一致。

起草的顺序也有讲究。章程不必一次写完，建议先写归属、访问边界、变更与升级路径和签署这几项，它们不依赖对问题的诊断，可以在进场第一周形成骨架；访问审批往往是项目中最长的一段等待，越早提出越好。目标与范围要等现场发现和指标定义的工作完成才能填满。阶段门的判据则按阶段分次写入：界定门的判据写在骨架里；验证门的判据在界定门召开之前写入，随全部条款齐备后签署的1.0版一同生效，此前的骨架版记作0.9版；移交验收的判据在验证门召开之前写入，作为补充条款由全体签署人确认。这样做，每个阶段的判据都是在该阶段开始之前定下的，与阶段门的要求一致。这里的分次写入是事先安排好的填写计划，不属于变更。

章程写好之后，可以做一次检验：随便挑一个事项，问“这件事现在找谁”，如果半分钟之内不能在章程里找到一个名字，就说明它还没有写好。这个检验的目的，是把章程当作随时查阅的工具而不是存档的文件。下面列出七类常见缺陷，读者可以对照自查。

1）只有部门，没有人。归属栏写“信息技术部”“业务部门”，出事时没有人知道该找谁。

2）目标写成方向，没有口径和基线。“提升效率”“减少中断”无法判定是否达到。

3）没有“不做什么”。范围靠各方心里的默认，变更请求在每次例会上都会冒出来。

4）一人兼任所有归属，也没有说明兼任的风险如何处理，证据与决定、指标与权限落在同一个人手里。

5）访问边界写成“按公司安全规定”，没有清单、期限和撤销方式。

6）阶段门的判据在门上才讨论，或者门没有周期上限，到期不开。

7）签完不再更新。人员调动了，范围变了，章程仍是第一版，与实际脱节，最后没有人再翻开它。

2.5.6　章程怎么变更

章程签署后一定会发生变化。人员会调动，假设会被证伪，验证阶段也可能发现界定阶段的判断有误。变更本身不是失败，没有变更程序才是问题；没有记录的变更，几个月后就会变成“我记得当时不是这么说的”。因此，章程必须规定变更如何提出、如何批准和如何记录。下面从五个方面说明。

第一，什么情况触发变更。以下六种情况出现时，都应当提出变更请求。

1）目标、指标口径或验收门槛要改。

2）范围增减，包括增加用例、扩大对象或缩小对象。

3）归属人变动，包括离职、调岗和较长时间的休假。

4）访问边界要放宽或者延期。

5）假设被证伪或者约束改变，例如约定的数据迟迟拿不到，或者合规要求更新。

6）阶段门作出缩小、补证或停止的决定。这类决定本身要写入章程，并相应更新后续的判据和周期。

第二，变更请求写什么。变更请求（change request）是触发变更的书面申请，应当让拍板人只看这一页就能作决定。至少包括下列内容。

1）编号、提出日期和提出人。

2）涉及的章程条款，以及改动前后的文字。

3）变更的原因和证据，不能只写“需要”。

4）对目标、范围、周期、成本、风险和访问边界的影响。

5）拍板人，以及要求的答复日期。

第三，变更分级。并非每一处改动都要全体重新签署，否则变更会因为太麻烦而被绕过。表2-9把变更分为三级，分级依据是改动会不会触及目标、指标、门槛、访问边界和阶段安排这几项核心内容。

表2-9　变更的三个级别

表2-9背后有一条不对称的原则：收紧可以先做，放宽必须先批。收紧的代价是暂时损失一部分功能，随时可以恢复；放宽的后果一旦发生，例如一次不该发生的读取，就无法撤回。这与涉及访问的决定不由小组自己作出的规定出于同一个理由，也与按可撤回性划线区分现场决定和产品决定的思路一致。

第四，变更记录。每次变更在变更记录（change log）里占一行，列明编号、日期、条款、变更内容、原因和证据、提出人、拍板人、决定和新版本号。阶段门的决定也记在这里：证据包和判据另存为附件，变更记录只登记决定、日期、拍板人和附件位置。每个版本都要留存，每周的模式声明附上当前的章程版本号，使阅读模式声明的人知道它所依据的是哪一版约定。

第五，逾期无人答复怎么办。章程为每类决策写明答复期限和升级对象，升级对象通常是拍板人的上一级主管或项目发起人。期限届满而没有答复，先升级，不视为批准。升级之后仍然没有结论，适用保守默认（conservative default）：现状不变，任何放宽访问、扩大范围、进入下一阶段并新增投入的请求，都视为未获批准，已经在运行的工作保持原状。选择这样的默认，是因为在这些请求里，放宽的后果难以撤回，而维持现状的代价是延误，延误可以被计量，也可以被追究。保守默认同时给拍板人施加了反向的约束：延误要记入变更记录，累积的延误是向发起人报告的理由，拍板人也无法用沉默代替一次明确的“不”。这是本书的设计。

案例　谁来决定能不能读生产库

以下情境为虚构。合众通信的FDE小组进场第二周起草了交付章程的骨架版（0.9版），访问边界一栏只写了“信息技术部负责”，没有写人。第三周，小组想用真实的工单记录检验一个想法，信息技术部给的是一份导出文件，小组技术负责人觉得直接读生产库更方便，便告诉了Tom。Tom说：“可以，你们直接读。”

小组随即向信息技术部提交申请。数据库管理员回复说，生产库的读取要由David批准。David次日答复，涉及运维生产系统的账号要经过安全评审，他需要先知道小组用什么身份读取、读哪些表、读多久。小组答不上来：章程里没有访问清单，Tom的“可以”也不是David的批准。工作因此停了两天。

第三天，小组、Tom和David坐在一起，把“能不能读生产库”拆成两个问题：业务上有没有必要，由Tom认；读哪些对象、以什么身份、读多久，由David批。当天形成的申请有五项：对象是工单表和备件表中事先列出的字段；只读；使用个人账号，经统一认证，不用共享账号；有效期到界定门召开之日，是否延期由David届时决定；到期或越界时，信息技术部直接关闭账号。David当天签了字。

章程随之补全并签署，定为1.0版：访问边界一栏写上David的名字，后附这份访问清单；决策清单写明数据访问由David拍板，三个工作日内答复，逾期升级到信息技术部的上一级主管。小组事后的复盘只有一句话：Tom有权决定这件事值不值得做，无权决定生产库向谁开放，两件事本该是两个人。

这个情境说明了几件事。第一，缺口出在章程而不在人。Tom没有越权的意图，David也没有故意拖延，两个人各按自己对权限的理解行事，只是这两种理解从来没有被放在一起过。第二，补救没有走“说服信息技术部放宽”的路，而是把请求改写成一次有边界的例外，范围、身份、期限、回退和到期处理都已写明，批准人批准它的成本因此很小。第三，这个缺口在起草阶段就可以发现。骨架版可以留空内容，但不应当留空责任人，按半分钟能否找到名字的检验，访问边界一栏找不到名字，就说明这一栏还没有写好。第四，如果1.0版签署之后，David因为岗位调动由别人接任，这就属于归属人变动，按表2-9是大变更，需要原签署人重新签署，版本升为2.0。

2.5.7　章程与现场诊断表

第1章的现场诊断表（表1-4）已经问过一遍相近的问题，章程与它是前后相接的两个步骤。诊断表是进场时的调查，目的是弄清现状；章程是调查之后的承诺，目的是规定今后怎样做。诊断表的权限栏问的是以谁的身份读取、读到什么粒度、访问能否追溯到人，答案是访问清单的输入；组织栏问的是业务结果、系统运行、数据、事故各归谁，成功标准由谁确认，答案是结果、决策和访问边界归属的输入。

责任缺位的四个检查问题与四类归属并不是一一对应的关系。“业务结果归谁”对应结果归属；“数据归谁”对应访问边界归属；“出了事归谁”，即谁承担后果并有权决定回退，对应决策归属中的回滚与升级；“系统运行归谁”在项目中分成两段，交付期间由实现归属承担，移交验收之后转给客户自己的运行团队，由移交验收和运维移交处理。也要注意区分两组概念：诊断表按“项目为什么落不了地”把障碍分成数据、流程、权限与组织四类，那是对问题的归类；本章的四类归属是对责任的归类，只是碰巧都有四项，彼此并不对应。

诊断表的证据强度规则也可以带进章程。表1-4把证据分为无、自述、文档和实测四级。诊断时，有人说“这件事归我负责”，只是自述；章程签署之后，它成为文档；这个安排真正起作用，例如批准真的生效、账号到期真的被关闭，则是实测。章程里的每个名字，都应当能在诊断表中找到对应的证据强度，凡只有自述的，应在界定门之前升级为文档。

有了章程，项目各方就有了共同依据，下一节转到项目结束时留下的东西。FDE项目有两个产出，一个是当前客户的系统，另一个是可以复用的经验，二者之间怎样取舍，下一节说明。

2.6　当前客户的系统与可复用的经验

交付阶段以移交收尾，交付章程把责任写在了纸上。本节回过头来讨论一个更具体的问题：一个FDE项目结束时，究竟留下了什么。本书的回答是两样东西。第一样是在客户环境中运行、由客户人员使用的系统；第二样是离开这个客户之后，其他人仍然能够使用的经验。两样东西来自同一段工作，但接收方、时间尺度和认可者不同。把它们混为一谈，是两类常见失败的共同根源：只顾第一样，项目结束时没有留下可复用的东西，每个项目都从头开始，变成一次性定制开发；只顾第二样，把客户现场当作产品试验田，客户得不到约定结果，信任也会随之消耗。

下面先分别说明两个产出各是什么，再讨论哪些经验值得沉淀，两个产出发生冲突时怎样取舍，以及哪些东西可以带出客户环境、哪些必须留下。图2-4把两个产出的去向画在一起，表2-10逐项比较二者。

图2-4　一个项目的两个产出及其去向

2.6.1　第一个产出，当前客户的系统

第一个产出是客户为之付费、结果责任人为之签字的东西：在客户的生产环境里运行，被客户的使用者用于真实的工作，并且按照约定的指标产生业务结果的系统。这里的“系统”不等于代码。能跑与可交付之间隔着质量、边界、运行和价值等一系列没有回答的问题，只交出代码，这些问题仍然留在原处。

本书把第一个产出分为四个部分。系统本体，包括代码、配置、数据接入，以及提示和模型调用的设置。证据，包括评估集、评估脚本、验收时的评估结果和上线之后的监控数据，它们说明系统在什么条件下达到了什么水平。运行能力，包括运行手册、告警、权限安排，以及有能力也有权限接手的人。使用，指使用者在日常工作中实际使用这个系统，业务指标按约定的口径发生了变化。四个部分缺任何一个，系统都只是被部署了，还谈不上被交付。四个部分与章程的四类归属大致对应：使用与指标由结果责任人负责，本体与证据由实现责任人负责，运行所需的权限由访问边界批准人负责，而它们此后的变化由决策归属管辖。

第一个产出有一个容易被忽略的特点：它由若干各自会变化的部分组成。一个已部署的AI系统，至少包含应用代码、提示、模型、检索配置、源数据、策略和评估集，其中任何一部分变化，都可能改变系统的行为，即使应用的版本号没有变。例如模型供应商在同一个别名之下换了模型版本，系统的输出就可能不同。所以移交之前要建立一份组件版本清单（component inventory），逐项写明当前版本、变更的方式、变更之后需要重跑哪些评估、由谁负责。对于外部依赖，如模型供应商宣布停用某个模型，也要事先指定谁来跟踪、谁来迁移，不能等到停用之后才发现没有人负责。这些安排合在一起，才构成运行所有权：所有权不只是一个名字，还包括采取行动所需的权限和能力。

责任转移应当以证据为条件。大型工程组织在接手一项服务之前，通常有正式的评审。Google的SRE团队用生产就绪评审（Production Readiness Review）作为接手服务的前提，评审覆盖系统架构与依赖、监控、应急响应、容量规划、变更管理和性能；发现的差距先排成优先级逐项改进，达到要求之后责任才逐步转移，转移期间开发团队仍然作为后备，不值得由SRE团队接管的服务则留在开发团队手里。这套做法对FDE项目有三点启示。其一，责任转移与移交验收一样，是以证据为条件的，而不是到了日期就转移。其二，转移可以分步进行，先培训，再共同值守，最后完全接手。其三，转移之后的支持期要写明时长、范围和联系途径，避免任何一方默认原来的工程师会无限期地提供非正式的帮助。

回到合众通信。对这个项目而言，第一个产出是东部区域网络运维中心的值班人员和外场工程师能够日常使用的系统，以及支撑它的评估集、运行手册和权限安排。它是否合格，由Tom依据章程中写明的指标来判断，而不是由小组自己判断。

2.6.2　第二个产出，可复用的经验

第二个产出是离开这个客户之后，别的人仍然能够使用的东西。这句话里有两个关键词。一个是“别的人”，沉淀必须有接收方，写下来却没有人会读的东西不算沉淀。另一个是“使用”，而不是“阅读”，一段难忘的经历、一份个人笔记或者聊天记录里的几句话，都依附于个人，人走了就没有了，也不算。

经验可以沉淀为三种形态。第一种是组件，如数据接入的适配器、评估脚本的骨架、提示的模板，它们可以直接被下一个项目调用。第二种是模板与方法，如本章的交付章程、评估集的构建办法、访谈提纲、验收门槛的写法，它们不涉及代码的耦合，换一个客户只需重新填写。第三种是记录，即项目复盘。一份有用的复盘记录要写清楚：客户的底层问题是什么，工作流程改造前后各是什么样子，用了哪些数据结构，触及了哪些集成点，出现过哪些边界情形，评估集是什么样子，客户真正在意什么、出乎意料地不在意什么，以及哪里最难。这样的记录很枯燥，价值在于累积：积累到十个项目，它就成了一本可以查阅的手册，不再是十段互不相干的经历。

沉淀的接收方，在产品厂商是产品团队，在企业内部是平台团队，在没有这两者的小团队里，是下一个项目的小组。本书把第三个条件写作“沉淀”而不是“回流到产品”，原因就在这里。无论接收方是谁，都应当在项目开始时就指定。小组里的沉淀负责人在小组一侧负责整理，接收方的负责人在另一侧负责接收，两个名字都应当写进章程条款3的附件，并与表2-7中“沉淀与复用”一行的拍板人对应起来。

沉淀不是一座仓库，而是一条回路：在现场观察到的东西被记录下来，被提炼成通用的形式，再回到下一个现场去检验。回路常在三处断开。第一处是失真，现场的信息经销售、实施等几手转述，到达产品一侧时已成了缺少细节的轶事，无法判断是个别现象还是共性。第二处是过时，文档跟不上系统和客户的变化，接收方学到的是一个已经不存在的系统的描述。第三处是记录负担，写复盘与交付争夺同一批人的时间，而交付通常会赢。针对这三处，本书的办法是：让记录嵌入交付物本身，例如评估集就是错误类型的记录，每周模式声明就是现场判断的记录；让每条记录带上来源，说明出自哪次访谈、哪批样本；在项目计划里为沉淀留出时间和责任人；复盘采用固定的短格式，不写长文。

表2-10把两个产出放在一起比较。两者最大的差别不在内容，而在接收方：第一个产出的接收方是客户，由结果责任人认可；第二个产出的接收方是下一个使用者，认可的人也随之不同。

表2-10　两个产出的比较

2.6.3　什么值得沉淀

不是现场做出的一切都值得沉淀。沉淀有成本，进入共享库的每一项能力，都意味着有人要长期维护它。流传较广的一个比喻是碎石路与铺装公路：现场做出来的，是针对一个客户的、快速的、有时粗糙的路；产品或平台一侧的工作，是看过几条这样的路，辨认出共同的走向，把它修成通用的路。现场代码往往追求快，泛化它的成本常常高于写第一版。所以第一个问题永远是哪一条路值得铺装。

本书把资料中的产品化问题归纳为四项判断，见表2-11，用来决定一个候选是进入共享库，还是留在这个项目里。

表2-11　沉淀候选的四项判断

表中的几项需要作进一步的说明。关于复现，软件工程里有一条三次法则：两处相似的代码不必急于重构，第三次出现时再提取成通用的过程；过早的抽象会得到错误的抽象，后来的需求会使它越改越糟。本书借用这条规则，但作两处调整。一是把“三个客户”放宽为“三个用例或项目”，因为读者未必有三个客户，同一个客户内部的不同用例也可以算数。二是区分对象：三次法则主要约束代码类的组件，而模板与记录因为不涉及代码耦合，一次就可以沉淀，不必等到第三次。

关于使用者与边界，有一对相关的取舍，即配置与代码。不同客户之间常见的差异，如字段、审批、路由和连接器的选择，适合做成声明式的配置，因为配置可见、可版本化、可支持；一旦差异改变了业务语义，就应当走代码，并经过评审和隔离，不要把配置语言扩张成一门难读的编程语言。谁来编写配置同样重要：如果是内部工程师，可以容忍表达力更强的工具；如果是客户的管理员，就需要校验、预览和更窄的原语。这也回答了边界的问题：通用部分保持稳定，差异留在配置层或适配层，现场仍有余地，通用部分也不会被客户的特殊要求撕开。

以合众通信为例，评估脚本的骨架，即读入样本、调用系统、逐条打分、汇总、出具报告，与具体的评分标准是两种东西。前者换一个客户几乎不用改，适合沉淀；后者来自网络运维中心专家的判断，属于客户专属。把二者放在不同的文件里，是日后能够沉淀的前提。

2.6.4　两个产出之间的取舍

两个产出之间的冲突是真实的。小组的时间有限，把当前系统做成可以复用的样子要多花工夫，而对客户的约定在先。本书的立场是客户成功优先，不为复用牺牲当前交付。理由有两点。第一个产出是小组的责任所在，也是客户信任的来源。一个把客户当作试验田的小组，很快就没有下一个可以沉淀的客户。资料中也有类似的判断：如果要求FDE为自己交付的每个功能都做一个通用版本，既拖慢项目，又令各方沮丧；比较合理的结构，是FDE专注于交付针对这个客户的方案，另由产品一侧负责一个节奏较慢的流程，把现场成果拉进平台，FDE对平台的贡献，就是把自己做的这条碎石路记录下来。

据此，本书提出一条分摊规则：当前项目承担留痕的成本，不承担泛化的成本。留痕的成本由当前项目承担，因为只有在现场的人才能记录；泛化的成本，包括抽象、兼容、文档和测试，由接收方立项承担。如果接收方就是读者自己所在的团队，泛化应当安排在项目与项目之间，而不是项目之中。留痕的要求不多，本书只提三条。

1）客户专属的东西与通用的东西分开存放。数据、业务规则、阈值和客户名称放在配置和适配层，通用的逻辑放在核心代码里。这几乎不增加工作量，却决定了日后能不能把通用部分取出来。

2）记录随手做，不留到最后。每周模式声明、评估中发现的错误类型、客户在意的事情，都记在固定的位置，并带上来源。

3）在项目结束前一周完成复盘记录，用固定的短格式，由沉淀负责人收口，在移交验收之前交出。

回路还需要固定的会议和固定的输入，不能依赖个人的热情。有团队的做法是每月开一次半天的综合评审：各FDE汇报各自交付了什么，哪些部分可以泛化，哪些属于客户专属；产品一侧从中辨认共性的需求，每月挑出两三项进入泛化。节奏慢到不打断交付，又快到产品确实在向现场学习。同时，这个会议也让现场与产品两边保持联系，避免两边各自形成互不相容的看法。

怎样知道第二个产出真的产生了？资料中有一个简单的检验：每做完五个项目，回头看产品，最近五个项目里现场做的工作有多少已经进入平台，进入得多，回路是通的，几乎没有，则回路已断。对于没有产品平台的读者，本书建议用更粗略的办法：比较相邻两个项目，从拿到真实数据到第一个可评估版本所用的时间，以及可以直接沿用的接入和评估材料所占的比例。如果后一个项目的起点没有高于前一个，就说明经验并没有真正留下来。这个办法受项目差异的影响，只能作为提醒，不能当作结论。

还有一种冲突来自客户。客户未必愿意为他人的复用而等待；如果沉淀需要客户出人力，例如请客户专家复核一份去标识后的评估集，这就属于范围的增加，应当按章程的变更程序提出变更请求，而不是悄悄占用客户的时间。

2.6.5　带出什么，留下什么

并非现场所得的一切都可以带出客户环境。客户的数据、业务规则和专有配置属于客户；通用的组件、评估框架、方法与教训，通常可以归FDE所在的机构，前提是有明确的约定。有一份服务合同的大纲就写了类似的条款：客户专属的代码归客户；通用化的组件、评估框架和基础设施方面的贡献归供应商；供应商保留用本次项目的教训改进产品的权利；客户数据未经另行书面同意，不用于本项目之外的任何目的。这只是一份起点性的大纲，不是法律意见，具体条款须由法务审定。本书不讨论合同，只要求两件事：章程里要有这一条，决策清单中“沉淀与复用”一行要有拍板人，并且按内容分开，涉及客户数据与规则的部分由结果责任人决定，通用组件是否进入产品由产品一侧负责人决定（表2-7）。

为了在带出之前把关，本书建议对每一件准备带出的东西做一次带出审查（asset exit review），回答四个问题，四项都通过，才可以带出。其中第三项，即分享之前去除隐含的假设或者把假设写明，来自对可复用资产的通行要求，其余三项是本书的补充。

1）里面有没有客户的数据，包括样本、截图、日志和字段的取值。

2）里面有没有客户可识别的业务规则、系统名称、阈值或人员信息。

3）里面隐含的假设是否已经去除，或者已经写明。例如脚本里写死的路径、编号格式和组织结构。

4）结果责任人或其指定的人，是否已经书面确认可以带出。

如果客户不同意带出某一项，沉淀的形式可以改为带出方法，不带出内容：保留做法，去掉内容。例如记录评估集是怎样构建的、怎样抽样、怎样请专家标注，而不带出评估集本身；记录一类错误的特征和处理办法，而不带出具体的工单。这样，经验仍然留下了，客户的数据没有离开。

客户专属与通用化的更细致的边界，以及运维移交的具体做法，留到第25章。至此，本章的框架已经完整：FDE按三个条件界定，在发现与构建两种模式之间转换，沿界定、验证、交付三个阶段推进，每一道门凭证据放行，责任由章程写明，结束时留下两个产出。下一章从界定阶段的第一项工作开始，也就是弄清客户真正的问题。

习题

（1）概念辨析

以下三则岗位描述均为虚构。A：常驻客户现场，按客户提供的需求清单实施系统，以清单逐项验收，项目结束时交付源码并离场，不负责上线后的运行。B：在成交之前的三周内，使用客户提供的脱敏样本搭建演示，成交后转交实施团队，不再参与。C：在客户现场使用真实数据交付系统，以合同约定的业务指标是否达到作为验收依据，项目结束后把其中通用的部分整理进公司的组件库。请按位置、责任、沉淀三个条件，逐则判断它是否属于本书所说的FDE。对不属于的，对照表2-1指出它最接近哪一种岗位，并说明缺少哪一个条件。

（2）模式判断

某小组一周的模式声明如下。本周的主要模式：构建。本周要回答的问题：把预测做准。预期看到的证据：准确率提高。谁判断证据是否充分：小组技术负责人。证据与预期不符时：继续调参。这一周小组比较了三种分类方法，调整了特征，没有去过现场。请回答：（a）这份声明五项中，哪几项不符合对模式声明的要求，为什么；（b）对照从发现转入构建的三个信号，判断小组是否已经具备转入构建的条件，并说明依据；（c）改写这份声明，使它成为一份合格的发现模式声明。

（3）阶段判断

判断下列四种情形各处于哪个阶段，卡在哪里，在相应的门上应当作出继续、缩小、补证、停止中的哪一种决定，并写明表2-6要求同时写明的内容。（a）系统已在生产环境运行三周，使用者很少打开，约定的业务指标没有变化。（b）评估集在调试中被反复查看，验证门上用它的得分作为通过依据，得分达到了门槛。（c）问题陈述已经写好，但客户一侧只有信息部门对接，没有人认领结果。（d）验证中发现，范围说明书对一类输入的假设与实际不符，修正这个假设会使范围缩小。

（4）章程找错

以下是一份虚构章程的摘录。目标：提升运维效率。范围：覆盖客户的全部运维系统。归属：结果由业务部门负责，实现由项目组负责，访问边界按公司安全规定执行。决策：重要事项由双方协商决定。阶段门：验证结束时评审，评审通过则进入交付。变更：如有变更，双方沟通后调整。签署：已由双方负责人签署，没有版本号。请对照章程常见的七类缺陷，逐条标出这份章程犯了哪几类。再重写其中的目标和访问边界两条，使它们符合章程的四条写作规则，可以假设必要的细节，但须标明哪些是假设。

（5）决策归属

在合众通信的项目中出现下列五种情形。对每一种，按表2-7、现场决定与产品决定的划线规则和“收紧可先做、放宽必须先批”的原则回答：谁拍板，是否可以先执行、事后补记，应当记入哪份文件。（a）小组在一次测试中发现，原型读取了访问清单之外的一张表。（b）验证门上，必须项中有一项未达标，Tom表示希望先进入交付。（c）模型供应商宣布三个月后停用小组正在使用的模型版本。（d）小组希望把为合众通信写成的数据接入适配器并入公司的通用组件库。（e）值班主管Alice提出，希望系统同时回答备件库存方面的问题。

（6）区分两个产出

某项目结束时有下列八份材料：运行手册；写死了客户内部目录路径和系统名称的接入脚本；通用的评估脚本骨架；附有客户工单原文截图的复盘记录；客户专家标注的评分标准文件；去除客户信息之后的错误类型统计与处理办法；访问清单；组件版本清单。请把它们分入三类，即属于第一个产出、属于第二个产出且可以带出、不能带出或须经审查才能带出，并按带出审查的四个问题说明每一份的理由。对须经审查才能带出的，写出让它可以带出所需要的处理。

（7）数字阅读

某报道称“FDE岗位的发布量一年内增长了十倍以上”。请按阅读数字的五个追问，写出你要向报道提出的问题。再回答：这个数字能否说明按本书三个条件界定的FDE这种工作方式正在普及，为什么。

（8）综合作业

为合众通信起草一份《交付章程》的0.9版草案，以表2-8为模板，以本章交付物中的表2-12为起点。草案只能填写Tom已经陈述的内容和已经出场的人物，其余各处留空，但每个留空处都要写明由谁、在何日之前填入。决策清单至少列出表2-7中的五类，并写明每一类的答复期限；访问清单至少列出三个拟申请的访问项，对象只能引用前言已经公开的系统名称，状态一律写作待批准。另附不超过800字的说明，回答三个问题：草案中哪些条款因为信息不足而留空，各在哪一章之后可以填入；Tom兼任多项归属带来的风险，你在章程里准备怎样处理；你预计第3章工作之后最可能需要变更的条款是哪一条，那次变更属于表2-9中的哪一级。

本章交付物

本章交付物是《交付章程》模板和合众通信的交付章程草案（0.9版）。模板即表2-8，共七个条款，附决策清单、访问清单和变更记录三份附件，可用于任何FDE项目的开始阶段。草案以表2-12为起点，由读者补全，它是后续各章逐步填满的第一份文件。

填写规则有四条。第一，草案只填Tom已经陈述的内容和已经出场的人物：目标是减少网络中断，对象是东部区域网络运维中心；四类归属中，Tom对应结果与最终决策，David对应访问边界，实现由小组技术负责人承担，姓名由读者按小组分工填写。“用AI预测基站故障”是Tom提出的方案设想，不是目标，只作记录，不作为范围的依据。第二，范围、指标口径、现状基线和真实的问题，一律不填，留待第3章和第4章补全。第三，每个留空处必须写明责任人和截止日期。第四，条款中凡是写明了的内容，状态一栏标“已填”，其余标“待填”，使任何人一眼就能看出这份章程还差什么。与前面案例框中的骨架版不同，这份草案的访问边界一栏写的是David本人，而不是部门。

表2-12　合众通信交付章程（0.9版草案）

说明：“已填”仅表示该处内容取自Tom已陈述的内容或已出场人物的职责；其余各处均须待后续章节补全。

检查草案时，可以用半分钟检验：随便挑一个事项，问“这件事现在找谁”，如果半分钟之内不能在草案里找到一个名字，就说明这一处还没有写好。草案中凡是“待填”的地方，也必须能回答“谁来