企业AI为什么难以落地

第1章 企业AI为什么难以落地

大模型让制作一个令人信服的演示变得容易，但把同样的能力接入企业的数据、权限、流程和责任体系，难度并没有同步下降。本章围绕这一落差展开。读完本章，读者应能区分“演示成功”和“可交付”，识别企业 AI 项目停滞的主要障碍，审慎解读常被引用的失败率数字，并说明为什么模型能力提升后，部署工程反而更为重要。这些判断构成后续各章的共同前提：第 3 章收窄项目范围，第 5 章建立验收标准，第 20 章设置发布门禁，都是对本章所述落差的具体回应。本章不展开编码，结尾要求读者完成一份结构化的落地诊断。

从演示到生产的鸿沟

一场成功的演示证明了什么

几乎每个企业AI项目都有一个相似的开头：团队拿出一个原型，对着一批预先选好的文件提问，系统给出流畅而准确的回答，在场的人由此相信这件事可以做成。这一刻通常被称为演示（demo）。此后数月里，项目能否走进真实业务，在很大程度上取决于人们怎样理解这次演示所证明的东西。

演示往往是企业AI项目中最先产出、也最先被用作决策依据的交付物：团队在选定的数据、选定的输入和受控的环境中，展示系统能够完成某项任务。大模型降低了构造这类演示的工程门槛，一个能够读取若干文档并流畅作答的原型，如今只需很少的开发投入。演示的说服力因此上升，但它所能证明的命题范围并没有随之扩大。

从逻辑形式上看，演示提供的是存在性证据：它表明存在一批输入，系统在这批输入上表现良好。生产环境要求的则是另一种东西，即一项承诺：面对持续到来、分布事先未知、含有噪声甚至带有对抗性的真实输入，系统的表现仍处于约定范围内；表现越界时，有预先安排的处置路径和负责人。由于大模型的输出具有不确定性，这项承诺不能写成绝对保证，而应通过评估集、通过阈值和适用边界来表达。从“存在”到“承诺”，所需证据的性质已经改变：前者可以由一次成功运行提供，后者依赖对输入分布的度量、对系统边界的强制和对失败的预案。把前一种证据当作后一种证据来使用，是企业 AI 项目中一类常见的推理错误。

这种落差在企业采购中十分常见。典型情形是：供应商的演示令管理层满意，合同金额也已确定；九个月后系统仍在运行，却没有业务部门真正使用。合同中的功能逐项交付，业务价值却没有兑现。业界常把这种距离称为从试点到生产的鸿沟（pilot-to-production gap）。一种常见的解释是，问题主要出在模型与企业的数据、工作流、权限、系统集成、监管要求和组织安排之间的连接，而不是模型本身。

MIT NANDA在2025年发布的一项企业生成式AI落地调研提供了一组与此相关的数字：对嵌入式或任务专用的生成式AI工具，受访组织中约60%曾做过评估，约20%进入试点，约5%成功实施。比例逐级下降，试点之后降幅最大。但这组数字不能当作企业AI项目的总体失败率：它以组织而非项目为单位，来自个别访谈，各类别样本量不同，各组织对“成功”的界定也未必一致。如何阅读这类数字，见1.3.2。

演示与生产之间隔着什么

演示环境与生产环境的差异，不是同一组要求的简单加码，而是约束集合发生了变化。演示只需让观看者相信输出正确；生产系统则必须同时满足一组相互制约的要求。表 1-1 从八个维度对二者进行对照，并列出相应要求缺失时的典型后果。

表1-1　演示环境与生产环境的对照

表中各行并非彼此独立。输入是否具有代表性，决定质量度量是否可信；权限的颗粒度，决定哪些数据可以开放给系统；失败策略和责任归属，则决定一次故障是停留在技术层面，还是扩大为组织协同失败。下面讨论其中三个在大模型应用中尤其容易被低估的方面。

第一是演示输入是否具有代表性。演示用例通常由项目团队事先挑选，内容比真实业务输入更完整、更规范，也更少出现歧义、缺失和异常情况。因而，上线评审不能只重复演示，而应纳入边界用例、对抗用例，以及经过脱敏和授权处理、但未经项目团队专门整理的真实样本，并将其中一部分保留到最终评估阶段。其核心要求是：用于质量度量的样本，应由独立于演示准备的流程产生，并能够覆盖预期的输入范围；否则，得到的结果只能说明系统适用于那些被精心挑选的演示用例。业界通常将这类样本集合称为评估集（eval set），本书沿用这一称呼，并在第5章详细讨论其构造方法和验收标准。

第二是模型之外的系统。机器学习系统往往可以较快开发出来，长期维护却成本高昂，原因包括边界侵蚀、组件纠缠、隐藏的反馈回路、未声明的数据消费者、数据依赖和配置问题。这些问题最初是在预测式机器学习系统中总结的，其中许多同样存在于大模型应用，只是表现形式有所变化：提示和调用参数承担了部分配置职责，检索所依赖的文档库构成数据依赖，外部供应商对模型的更新则可能在本方代码未变的情况下改变系统行为。图1-1用示意图说明，模型调用只是生产系统的一部分，围绕它还必须建设使系统可用、可控、可恢复的其他组件。

图1-1　生产系统中模型调用与周边组成部分

第三是失败策略。生产系统依赖模型接口、检索服务、身份服务和业务系统等外部组件，其中任何一个都可能变慢、报错或返回格式异常。工程实践可以归结为一条原则：每个外部依赖和每个不可逆动作，都必须有明确的失败处理和恢复策略；否则，系统在不确定条件下的反应本身就可能造成事故。还要区分软件状态和业务状态：回滚可以恢复软件状态，但已经发出的通知、已经写入下游系统的记录属于业务状态，回滚最多只能阻止后续影响扩大。因此，不可逆动作应置于人工确认之后，或在设计时配套补偿动作。具体的失败策略将在第16章和第20章讨论。

案例　一场演示之后没有人回答的问题

以下情境为虚构，用于说明演示与生产之间的距离。合众通信网络运维中心主任Tom在第一次会议上提出，希望用AI预测基站故障，减少网络中断。设想某供应商随即用一份历史告警导出文件做了演示：大屏上列出未来24小时内风险最高的若干基站，排名清晰，会议室里反应积极。

这场演示在技术上可能是真实的证据，但它对下列问题完全沉默。信息技术部负责人David管理系统权限与安全审查，需要弄清预测程序以什么身份读取网管系统，能读到哪些对象、到什么粒度。值班主管Alice面对排名第三的高风险基站，必须决定要不要派外场维护班组上站；凌晨出现误报时，处置成本由谁承担，没有人说得清。外场维护工程师Bob想知道，系统给出的依据能否与他在现场看到的情况相互对照。Tom本人则要回答，“减少网络中断”究竟用哪一个指标来度量，改善到什么程度才算数。

本书并不在此判断该需求是否应当按原样实施，那是第3章的任务。这个情境要说明的是：同一场演示可以既是真实的技术证据，又无法回答任何一个关系到系统能否被运行、被信任的问题。

什么才算可交付

要判断一个系统是否越过了这道鸿沟，需要一套可以逐项检验的标准。“生产就绪”在行业文献中常被当作不言自明的共识，实际上不同角色对它的理解并不相同。不妨设想这样一次会议：团队被要求在八周内把一个两周做成的原型变成面向一万名员工的生产系统，而在场各方对“生产”的含义各有侧重——业务发起人关心业务连续性，终端用户关心工具是否有用，工程团队关心能否运维，安全团队关心数据和访问是否受控，支持团队关心推广后的工作量能否承受。缺少共同定义时，分歧往往要到上线前才暴露。

本书据此区分“能跑”与“可交付”。能跑，指系统在选定的输入上产生了可接受的输出，演示即属此类。可交付则要求同时满足以下四项条件。

（1）质量可度量。在能够代表真实输入分布的评估集上，系统的质量水平已被测得，并有事先约定的合格线。

（2）边界可控。系统可访问的数据与可执行的动作有明确界限，且界限由系统中模型以外的部分强制执行，而不依赖模型自行遵守。

（3）失败可恢复。每个外部依赖和每个不可逆动作，都有事先约定的失败策略与回退路径。

（4）责任可追溯。有被指定的运行负责人；对任一已产生的输出，事后可以还原其输入、所用的系统版本、所依据的来源和经过的决策环节。

对这一定义，需要说明三点。其一，四项条件是必要条件，不是充分条件。满足四项条件的系统仍可能无人使用：采购和验收可以完成，但系统是否真正被激活，取决于用户的日常工作。使用与采纳问题在第24章处理；本章所说的“可交付”，只讨论系统自身应具备的性质。

其二，上线前通常要回答三个审计问题：谁能访问什么，谁负责事故，如何证明发生了什么。四项条件与这三问大体对应：条件（2）对应谁能访问什么，条件（4）对应谁负责事故和如何证明发生了什么。审计三问没有涉及质量，而质量恰恰是大模型系统区别于确定性软件之处，因此本书增列条件（1）。

其三，这一定义是工程性的，目的是让验收争议落到具体交付物上，而不再停留在“还不够成熟”之类的笼统判断。条件（1）对应第5章的评估集与验收标准；条件（2）对应第9章的数据权限定义、第18章的运行时身份与授权，以及第19章的威胁建模；条件（3）对应第16章和第20章的失败处理与发布门禁；条件（4）对应第21章的监控与审计。按此定义，演示与可交付之间的差距可以逐项检查。第1.2节将进一步回答：在真实企业中，这些差距具体由哪些障碍造成。

失败出在数据、流程、权限与组织

上一节说明，演示与生产之间的差距来自约束集合的扩大。本节回答这些约束在真实企业中来自哪里，以及项目通常在哪些环节停下来。不同研究对企业 AI 项目失败原因的分类并不一致。本书采用数据、流程、权限和组织四类，是因为它们对应 FDE 小组在现场可以逐项取证的对象：查看数据、观察流程、核对权限配置，并确认谁对结果负责。

这一归纳的出发点是，在已有的多项研究中，受访者列为主要原因的因素大多不在模型本身。RAND在2024年发布的一项以资深机器学习从业者为对象的访谈研究（下称RAND访谈研究），归纳出五类反复出现的根因，包括业务方对问题的误解、缺少可用的数据、追逐新技术而忽视用户的真实问题、基础设施不足，以及把技术用于对它而言过于困难的问题。这类研究的证据性质与适用范围，留待1.2.5讨论。下面依次考察四类障碍。

数据有，却不一定可用

企业AI项目启动时，常听到的一句话是“我们有很多数据”。这句话多半属实，但它说的是数据的存在，不是数据的可用。从存在到可用，至少隔着四个层次：能不能拿到，读不读得懂，信不信得过，能不能持续更新。

能不能拿到，是权属与技术两个问题的叠加。数据可能分散在多个系统中，归不同部门管理，导出需要审批，或只能以夜间批量文件的形式提供。读不读得懂，取决于字段含义、取值口径和业务规则是否有人记录。同一个“客户”或“订单”，在不同部门的系统里常有不同的定义。建模者若不了解这些定义背后的业务含义，就无法判断哪些字段重要，哪些并不可靠。信不信得过，关乎数据是怎样产生的：由用户手工录入、又与录入者的考核无关的字段，质量往往参差，而这在表面上看不出来。

能否持续更新，是生产环境特有的要求。演示可以使用一次性导出的快照；生产系统则必须应对数据源格式变化、数据延迟和传输中断。缺少自动清洗与监控管道的组织，往往无法及时发现模型上线后的数据故障。

大模型应用使数据问题更隐蔽。与要求固定输入格式的传统程序不同，大模型面对残缺、过期或相互矛盾的输入，通常不会直接报错，而可能生成一段流畅的回答，数据缺陷就这样被语言的流畅性掩盖，很难在演示阶段暴露。企业数据治理是一项长期工程，项目不必等治理体系全部完善后才开始，但必须在立项时确认：完成当前任务所需的那部分数据是否可获得、可理解、可信且能够持续更新。数据质量、语义和数据契约将在第9章展开；项目初期的数据可用性判断见第3章和第4章。

流程里没有AI的位置

系统输出要产生业务价值，必须进入某个人的决策，或触发某个流程动作。模型即使足够准确，如果用户还要另开页面、重新登录或手工复制粘贴才能看到结果，它仍然只是流程旁的一件工具，而不是流程的一部分。流程障碍的核心因此不是“模型能否完成任务”，而是“任务在流程中处于什么位置”：谁在什么时点需要这个输出，输出应写入哪个系统、触发什么动作，以及输出缺失或不可信时流程如何继续。

这三个问题在演示阶段常常没有答案，因为演示本身就是脱离流程的场景。RAND访谈研究中最常被提到的根因，正是业务方对需要解决的问题存在误解或沟通偏差，其结果是模型针对错误的指标优化，或与实际的工作流程不匹配。不妨设想一个费用报销审核的场景：团队开发了一个能逐项核对票据的助手，演示时它准确指出了异常项。但审核员的实际工作是在时限内批量处理，并对少数申请人发起追问；助手的输出既不进入审核系统，也没有触发追问的入口，审核员只能在两个界面之间来回复制。每张票据多出的这几步操作，足以让审核员回到原来的做法。

流程的真实形态也往往与文档不同。流程图描述应当怎样做，而一线人员为完成工作形成的变通，如私人表格、口头约定和绕开系统的沟通，不在任何文档里，却承载着流程中最关键的判断。只依据流程图设计的系统，会在最需要判断的地方缺位。第3章因此强调现场观察。

流程障碍还有一种相反的表现：员工并非不用 AI，而是不使用企业提供的 AI。MIT NANDA 的采购方调研发现，许多员工已经在个人事务中使用通用 AI 工具，因此会更敏感地感受到企业内部工具在上下文记忆、工作习惯适配等方面的不足。判断一个 AI 项目能否融入流程，首先要了解用户现有的工作方式，而不能只比较模型能力。

权限边界要先于能力画定

企业数据的访问由身份与权限管理：不同岗位的人能看到不同的客户、合同和内部文件。传统应用通过界面和接口限定用户的访问范围；大模型应用则用自然语言跨越多个数据源回答问题，它能把分散的信息聚合起来，也就能把用户本无权看到的内容聚合出来。若系统以一个权限很大的账号读取全部数据，再由模型决定向谁说什么，权限控制实际上就交给了模型的判断。

权限在这里包含三个层面。数据权限回答谁能读什么，动作权限回答系统能写入或触发什么，合规边界回答数据能否出境、能否留存、能否用于训练。三者通常由不同的部门把关，也由不同的人回答。

原型阶段最省事的做法，往往是使用一个共享服务账号，让原型读取全部文档，以取得最好的演示效果。问题会在生产评审时出现：安全团队需要知道谁通过系统访问了什么，以及访问记录能否追溯到具体人员。共享账号无法回答后一个问题，因为所有读取行为在审计中都归属于同一主体。对于要求将读取行为关联到责任人的受监管场景，这种设计无法通过评审。大型企业的安全评审通常还会追问：数据是否离开企业环境，是否被用于训练模型，如何防止提示注入导致数据外泄，智能体能够执行哪些动作，以及如何让它停止。这些问题在立项时就已经存在，只是常常到评审阶段才集中暴露。把它们当作后期审批手续，而不是早期设计约束，是权限障碍最常见的来源。

所以权限边界应当先于能力画定，含义有二。其一，在确定系统要做什么之前，先确定它能碰什么，包括可读取的数据范围、可执行的动作和数据可以到达的位置。其二，当时间或资源不足、不得不缩减范围时，先缩减功能的广度，而不是放松控制。权限的定义、运行时的身份与授权、威胁建模，分别在第9章、第18章和第19章展开。

案例　一个共享账号引出的三个问题

以下情境为虚构。合众通信的FDE小组为网络运维中心做了一个原型，可以用自然语言回答关于工单和备件的问题。为了让演示顺利，原型使用了一个只读的共享服务账号，可以读取信息技术部开放的全部数据。

信息技术部负责人David在评审中没有评价回答是否准确，而是问了三个问题。第一，不同岗位的人向原型提同一个问题，看到的内容是否应当相同。第二，一次提问读取了哪些记录，事后能否看出是谁问的。第三，如果提问者设法诱导原型去读取它不该读的内容，由什么来保证它做不到。

FDE小组当时只能回答第一个问题的一部分。David没有否决项目，他提出的是一个顺序：先由信息技术部和业务部门共同确认哪些角色可以看哪些数据，再决定原型可以回答哪一类问题。这个顺序，就是本节所说的权限先于能力。

组织里没有人对结果负责

前三类障碍都有技术上的对应物：数据管道、集成接口和权限配置。第四类障碍出现在技术之外，涉及项目结果由谁负责。演示阶段通常看不出这个问题，因为演示由项目团队完成，团队自然会对演示负责；上线后，责任边界才会暴露：系统出错由谁处置，业务指标未达预期由谁调整，数据源发生变化由谁修复。如果这些问题没有明确答案，系统上线后就会成为无人认领的资产。

责任缺位可以用四个问题检查。业务结果归谁，即谁对系统要达到的业务目标签字；系统运行归谁，即谁在告警响起时负责处置；数据归谁，即谁有权决定数据如何使用与修改；出了事归谁，即谁承担后果并有权决定回退。这四个答案若落在不同部门而无人协调，系统便停在各方的边界上。典型的形态是信息技术部门牵头立项而业务部门无人署名，或业务部门提出需求却无人负责运行。

RAND访谈研究提供了相关的证据：受访的业界从业者中，有84%把至少一项由业务领导层的决策与预期造成的原因，列为项目失败的主要原因。这一数字的口径需要说明：受访者多为不担任管理职务的工程师，结果可能偏向于指出领导层的问题。

责任缺位也发生在一线。熟悉业务的专家是项目成败的关键，只有他们能说明数据的含义与可靠程度；但当他们认为项目的目的是取代自己的岗位时，会出现消极抵制。MIT NANDA 另一项覆盖 52 家组织的调研，请受访的项目发起人和一线用户按出现频率给常见的规模化障碍打分；所列五类障碍中，不愿采用新工具、缺乏高层支持和变革管理困难都与人和组织有关。该调研说明，这些分数反映的是出现频率，而不是影响大小。

因此，项目在立项时就应当能写出这四个问题的答案，并由具名的人确认。第2章的交付章程与第3章对责任人和决策权限的梳理为此而设；上线之后如何让系统真正被使用，由第24章讨论。

障碍出在连接处

把四类障碍放在一起，可以看到一个共同结构：问题往往不在模型内部，而在模型与企业要素之间的连接（connection）。数据问题涉及模型与数据的连接，核心是数据是否可用；流程问题涉及模型输出与业务流程的连接，核心是输出是否真正嵌入工作；权限问题涉及模型与权限体系的连接，核心是访问是否受控；组织问题涉及模型与人的连接，核心是结果是否有人负责。图1-2概括了这四类连接。

图1-2　模型与企业之间的四个连接

这也解释了演示为什么能绕过全部四类障碍：演示使用选定的数据，不经过真实的权限，处在流程之外，也不需要有人对它负责。演示展示的只是模型本身，而生产环境的难点恰在模型之外的连接上。表1-1中演示与生产的差异，有相当一部分可以归入这四类连接，其余属于生产工程本身，如并发、变更管理与监控，留待第20章和第21章。

表1-2按连接整理了典型表现、现场可取的证据和后续章节。

表1-2　四类障碍的对照

四类障碍并不相互独立。权限限定了数据可以开放到什么程度；无人负责的数据，质量问题无人修复；流程若不在设计时说清，权限评审时就无从判断一次访问是否必要。诊断时应当把四类放在一起看，同一个现象常常同时出现在不止一栏。

应用这一归纳时，需要注意三点。第一是证据性质。本节引用的研究主要来自从业者和采购方的自述，样本有限、口径各异，因此得到的只是障碍类别和出现频率的方向性判断，不能直接当作因果估计。例如，RAND 访谈研究主要考察机器学习模型，单纯调用预训练大模型的项目不在其范围内。软件开发领域一项约有五千名受访者参与的调查，也得到相近的结论，即 AI 会放大组织原有的优势和缺陷；但该调查限于软件开发，不能直接推广到其他行业。

第二，“障碍在模型之外”不是对所有项目都成立的命题。RAND访谈研究的五类根因中，就包括把技术用于对它而言过于困难的问题。若任务本身超出模型当前的能力，改善数据、流程、权限与组织并不能使它成功。因此，在归咎于环境之前，先要用评估集检验任务本身是否可行，这是第5章的内容。第三，四分法是便于现场取证的工作分类，并不穷尽全部原因。追逐新技术而忽视真实问题，归入第3章的问题界定；基础设施投入不足，在第20章和第21章的生产工程中处理。

本节的结论是：在多数企业AI项目中，决定成败的主要因素位于模型之外的连接层；但这一判断必须在具体项目中逐项取证，不能预先假定。

概念验证为什么停在概念验证

前两节说明了演示与生产之间的差距，以及造成差距的四类障碍。本节进一步讨论这些障碍如何表现为项目组织问题：为什么大量企业AI项目完成概念验证后，既没有进入规模化阶段，也没有明确终止。

概念验证在验证什么

概念验证（Proof of Concept，PoC）原指用较小的成本回答一个具体问题，即某个设想在技术上是否行得通，验证对象是单一的可行性假设。企业AI项目却对它寄予更多期待：决策者想借它判断是否值得继续投入，一线想看系统能否好用，采购部门想借它比较供应商。这些期待对应三类不同的问题，即技术上是否可行、业务上是否有价值、在企业的数据、权限、流程和责任体系中能否运行。概念验证通常只回答第一类，因为它与演示相似：使用选定的数据，不经过真实的权限，处在业务流程之外，也无人对它负责，1.2节所述的四类障碍都被绕开了。

由此产生一种错位：概念验证能够回答的问题很窄，却容易引发范围很大的组织反应。“概念验证成功”在汇报中很容易被理解为“项目已经得到证明”，预算、预期和对外承诺随之增加；而业务价值和生产条件往往要到试点阶段才会暴露，此时已经投入了更多资源，停止项目的代价也更高。

另一种结局是概念验证既未明确成功，也未明确失败。业界把这种状态称为概念验证坟墓（PoC purgatory）：项目没有达到可以放大的证据，也没有触发终止的条件，在例会汇报中年复一年地“持续推进”。它通常同时具备三个“无”：无期限，没有人规定验证何时结束；无指标，事先没有写明达到什么水平算通过；无裁判，没有人被授权依据证据宣布通过或终止。

这种状态能够持续，并不只因为疏忽。继续的成本分散在预算和工时里，无人单独负责；宣布终止则要有具名的人承认判断有误。对各方而言，维持现状往往风险最小：供应商保住合同，发起人保住“正在推进AI”的叙事，项目团队保住可见度。局部合理的选择叠加起来，就把项目留在了概念验证阶段。概念验证本身并无过错，它是廉价排除不可行方案的有效手段；问题在于事先没有规定它回答哪个问题，以及答案出来之后做什么。

失败率数字该怎么读

流传较广的失败率数字常被并排引用，容易让人得到“大多数项目失败”的印象，但它们的度量对象、成败标准和性质往往并不相同。第一，度量单位不同，有的以组织为单位，有的以项目为单位，同样说“多数”，分母并不一致。第二，成败标准不同，“没有可测回报”“被放弃”“被主观认定为失败”是三种不同的事件，一个已经上线但回报尚未显现的项目，在第一种口径下算失败，在第二种口径下不算。第三，性质不同，实测、转述的估计与对未来的预测应当分开。

例如，MIT NANDA在2025年的调研称约95%的企业生成式AI项目没有回报，这是以组织为单位的判断，成功指试点之后部署并有可测的业务指标，回报在试点后6个月内衡量，数字来自访谈，样本有选择偏差。Gartner在2024年预测至少30%的生成式AI项目会在概念验证之后被放弃，这是以项目为单位的预测，不是已经发生的统计。两者都说“大量项目没有走到生产”，但不能放在同一个分母上比较。

读这类数字时，可以依次追问五件事。

1）度量单位是什么，是组织、项目还是工具。

2）成败如何定义，是没有可测回报、被放弃，还是被主观认定为失败。

3）时间窗口多长，窗口过短会低估晚到的回报。

4）样本从哪里来，偏向哪一类受访者或企业。

5）数字是实测、转述还是预测。

按这五问重读，能够支持的结论是有限的：在来源各异、口径不同的多项研究中，相当一部分企业AI项目没有达到预期，转化在试点之后明显收窄。一个精确的总体失败率，对所有企业和技术路线的推广，以及对失败原因的因果判断，都不能由此得出。本书此后引用这类数字时，一律写明口径和性质。

从概念验证到规模化的阶段与退出条件

避免概念验证长期停滞的办法，是把项目拆分为若干阶段，并为每个阶段事先写明要回答的问题、通过依据和终止依据。本书使用概念验证、试点、生产和规模化四个阶段，如图 1-3 所示。不同组织对阶段的称呼可能不同，关键在于每个阶段回答的问题不同，通过条件和终止条件也不同。

图1-3　四个阶段与退出条件

表1-3给出各阶段的进入条件、通过条件和终止条件。它只是总览，合格线怎样确定见第5章，发布门禁见第20章，停止条件的案例见第26章。

表1-3　各阶段的进入、通过与终止条件

三条纪律适用于每个阶段。第一，退出条件必须在阶段开始前写明，并同时包含通过和终止两类条件；如果通过条件事后才确定，标准就可能迁就已经得到的结果。第二，每个阶段都要设置周期上限，到期必须作出决定，不能自动延期。第三，必须指定有权依据证据作出决定的人；这一权限应来自项目业务发起人，而不能来自系统提供方，否则项目团队既是执行者又是裁判者。

立项时已能观察到三个预警信号，出现两个以上就应当先停下来。一是无主之地：项目在企业内没有业务方的负责人，只有信息部门对接，结果没有人署名负责，上线后出了问题也无人处置。二是只许看不给碰，要求先证明能力，却不提供真实数据，所得的验证不能外推到真实输入。三是需求无边界，第一次会议就要求覆盖全公司所有场景。这些信号与表1-2的四类障碍相互印证，用本章交付物的诊断表可以在立项时逐项取证。

模型越强，部署越值钱

前三节讨论了落地为什么难。本节讨论一个相关的判断：随着模型变强，这种难度会不会自行消失。本书的回答是不会，而且部署工程的价值会相对上升，但这个判断有适用条件。

模型能力趋同，调用成本下降

对多数企业任务而言，可用的前沿模型已经不止一家，不同模型在公开基准上的成绩逐渐接近，同等能力水平的调用成本也总体呈下降趋势。这一趋势有多方面原因：多家厂商争夺相同客户，开放权重模型持续追赶，蒸馏和小模型也使较低成本获得接近的能力成为可能。具体降幅取决于所选基准、模型规格和比较时间窗口，本书不作统一的定量断言。

趋同带来两个后果。其一，模型的选择不再单独决定项目之间的差异，能获得同一个模型的企业，成败更多取决于能否把模型接入自己的数据、流程和权限。其二，模型由外部厂商持有并不断更新，今天选定的模型明天可能被替换，系统在设计上需要容忍这种替换，这是第7章讨论模型无关设计的出发点。

另有两种推论需要提防。一种是“成本下降，所以部署的价值上升”。成本下降使更多任务越过了经济上可行的门槛，这只说明可做的任务变多了；价值是否转移到部署这一端，还取决于模型之外的连接是否稀缺，不能仅凭价格走势断定。另一种是“能力趋同，所以能力足够”：趋同说的是厂商之间的差距，不是模型与任务要求之间的差距。一家研究机构2025年的预测认为，现有模型尚不具备自主完成复杂业务目标的成熟度，到2027年底将有四成以上的智能体项目被取消。这是预测而非统计，但它提示，模型足够好这一前提不能默认成立。

价值更多落在模型之外的连接层

如果模型能力可以从市场上以相近条件获得，企业之间的差异就更多来自模型之外的部分，即图 1-2 所示的四类连接。这些连接具有两个特点。其一，它们依赖企业自身的情境：数据口径、权限结构、流程中的隐性做法和责任安排，都无法直接从市场购买。其二，它们必须在现场建设，因为相关信息需要通过观察和与一线人员沟通获得。因此，模型越容易获得，把模型接入具体企业的那一层就越稀缺，部署工程的边际价值也越可能集中在这里。

软件开发领域有一项相关的经验证据。2025年一项约五千名技术从业者参与的调查发现，AI更像一个放大器，既放大高绩效组织的优势，也放大低绩效组织的失调。该调查限于软件开发，能否推及其他业务领域尚需分领域验证，但它与本章的论点方向一致，即同一个模型在不同组织里的结果，取决于组织已有的条件。

这一判断有三个适用条件。第一，任务落在模型当前能力范围之内。若任务本身超出模型的能力，改善数据、流程、权限与组织也不能使它成功，部署工程就无从放大价值；因此在判断部署的价值之前，要先用评估集检验任务是否可行。第二，价值确实取决于企业特有的情境；对通用的写作润色、翻译之类任务，现成产品往往已经够用，部署工程的增量价值有限。第三，连接层的建设成本并非固定。2026年一项覆盖97个国家、1,719 位受访者的调查中，约三分之一的受访者称曾因内部可用的智能体编码工具而放弃购买软件。这说明自建的门槛在下降；而 MIT NANDA 在2025年的调研显示，与外部厂商合作的部署成功比例约为内部自建的两倍（约67% 对33%）。该调研也指出，这一差异可能反映组织能力的不同，不能据此证明因果。两项证据方向不同，由谁来建设连接层，现有证据并不一致，第6章将专门讨论自建与采购。

FDE的位置与本书的路线

在这一背景下，可以这样界定FDE的位置：FDE在客户现场把模型接入数据、流程、权限和组织这四类连接，并对系统在生产环境中的结果负责。FDE 的职责、工作方式和交付流程见第2章；本书将 FDE 视为一种交付能力，招聘、薪酬、定价和职业路径不在讨论范围之内。

FDE并非解药。一家研究机构在2026年9月发布的预测认为，到2028年将有七成企业放弃由供应商FDE构建的智能体，原因涉及范围、激励、治理、所有权和退出安排等问题。该预测没有披露调查样本，属于分析判断，不宜当作统计；但它所指的结构性问题与本章一致：责任、边界和退出条件若没有事先写明，派驻再多的工程师，项目仍会停在概念验证阶段。

本书按项目推进顺序展开：先发现真实问题并建立证据（第二篇），做出第一个可用版本（第三篇），接入企业数据与知识（第四篇），补充工具调用、工作流和智能体等系统能力（第五篇），通过发布门禁上线（第六篇），最后量化价值并完成交接（第七篇）。每章以一项交付物收尾，这些交付物在合众通信的网络运维案例中逐章叠加，最终构成一个可运行、可验收、可交接的系统。本章的交付物不依赖该案例，是一份可用于不同企业 AI 项目的障碍诊断表，见本章末。

习题

（1）概念辨析

用自己的话说明，为什么一场成功的演示不能推出系统在生产中的表现。结合存在性证据与承诺的区别，各举一个输入分布上的差异。

（2）场景判断

某团队用自己挑选的30个样例测得回答准确率为94%，系统以一个共享服务账号读取全部文档，上线后由项目组轮流查看。按1.1.3节的四项条件逐项判断它是否可交付，并指出每一项缺少的具体交付物。

（3）层次辨析

某企业称“我们有十年的客户服务记录”。按1.2.1节所述的四个层次，即能否拿到、读不读得懂、信不信得过、能否持续更新，各写出一个应当向数据负责人提出的问题。

（4）数字阅读

某报道称“调查显示七成企业的AI项目未能投产”。按1.3.2节的五个追问，写出你要向报告作者提出的问题，并说明哪些问题的答案会改变你对这个数字的解读。

（5）追溯出处

选取1.3.2节所举的一个数字，找到它的原始报告，核对原文口径与本书所述是否一致，并说明二者的差异会怎样改变对该数字的解读。

（6）设计题

为一个“用AI辅助客服质检”的概念验证写一份退出条件，包括周期上限、通过指标与合格线、终止条件、有权作出决定的人，以及通过后进入试点的前提。

（7）论证题

1.4节提出“模型越强，部署越值钱”，并给出三个适用条件。针对每个条件，设想一个使它不成立的企业情境，并说明应当收集什么证据来判断该情境是否成立。

（8）综合作业

选一个有公开报道的企业AI项目，成功、停滞或被终止均可，仅使用公开资料填写本章的《企业AI项目落地障碍诊断表》，并按表1-3判断其所处阶段。每个格子写明证据来源与强度，缺乏公开证据的格子如实标出，不得推测填写。另附不超过800字的说明，论述该项目的主要障碍出在哪个连接。

本章交付物

本章交付物是《企业AI项目落地障碍诊断表》，由表1-4和表1-5两张表组成，可在任何企业AI项目的立项、评审或复盘时使用。表1-4按数据、流程、权限、组织四栏取证，表1-5判断项目所处的阶段。

填写规则如下。证据强度分四级：无，没有任何依据；自述，来自当事人的口头说法；文档，来自可核对的文件、配置或日志；实测，来自抽样检查、现场观察或评估集结果。判断分三档：无障碍、待查、存在障碍。证据只有“无”或“自述”级时，只能判为待查；判为存在障碍或无障碍，都至少需要“文档”级的证据。“需补取的证据”一栏必须写出具体的取证动作和负责人，不得留空。

表1-4　企业AI项目落地障碍诊断表（障碍部分）

表1-5　企业AI项目落地障碍诊断表（阶段判断部分）