这篇解决的问题是：大模型交付的失败方式高度重复，但没有一份按「症状—成因—破解」整理的反模式清单。

最值得拿走的是七条反模式的判别特征，尤其是三条隐形致死率最高的：评测口径漂移、知识不沉淀的英雄式交付、资产不回流的外包滑坡——它们在项目进行中完全不像失败，到验收或续约时才发现没救。误用风险在于把反模式当帽子扣：判断靠证据链，不靠对号入座。

增量在于用了从严的入选标准：把海外方法论案例与国内私有化、银行规模化两类本土案例交叉，一个坑必须至少在两种语境独立出现过才收录，排除了环境特异的伪反模式；结论段还给出了按项目阶段分层的治理要害。

读完建议做一件事：拿七条清单逐条对照你手上最焦灼的那个项目，命中的条目写进下一次项目复盘。

—— FDEChina编辑部 · 犀利评审

复盘足够多的公开交付案例之后，会发现一个不太舒服的规律：大模型交付的失败方式不是随机分布的，而是围绕几个固定模式反复重演——换一个客户、换一个模型、换一批工程师，坑还是那几个坑。本文做一次交叉归纳：素材取自三组公开事实——Anthropic 工程团队发布的多智能体研究系统复盘与其对立面的技术论证、Palantir 从 bootcamp 到生产交付的 FDSE 方法链、以及国内私有化交付与大型银行规模化落地的公开报道口径（站内 Palantir FDE 模式拆解、国内私有化交付样本、银行规模化场景落地启示 有逐条溯源）。入选标准从严：一个坑必须在至少两种语境里独立出现过才收录，环境特异的问题不算反模式。先给结论：七个反模式里，致死率最高的三个都不是技术失败，而是治理失败——它们在项目进行中看起来完全不像失败。

反模式一：演示驱动交付

症状：项目的高光时刻全部发生在演示里。POC 阶段模型表现惊艳，客户高层拍板，然后进入漫长的工程化泥潭：真实数据一进来准确率就掉，真实用户的输入方式千奇百怪，边界情况层出不穷，上线时间一拖再拖，最后系统在「演示可用」与「生产可用」之间反复横跳，直到所有人失去耐心。为什么发生：演示使用的是精心挑选的样本、被反复调优的提示词和知道正确答案的操作者，它度量的是「模型在理想条件下能做什么」；而交付要回答的是「系统在真实分布下稳定做到什么」。两者的差距本来就该靠系统性的评测来弥合，但演示的政治回报远高于评测建设——给高层放一段流畅的演示，比解释一张评测基线表有效得多。怎么破：把评测基线建在演示之前。站内 评测基线 playbook 的核心做法是先从真实分布抽样建立基线，任何演示里展示的能力都要能对应到基线上的一组可复跑样本。给决策者的一句话翻译是：演示是能力上限，评测是交付下限，合同应该签在下限上。

反模式二：智能体拓扑先行

症状：需求还没定义清楚，架构图上已经画好了五六个智能体的协作拓扑——规划者、执行者、审查者、仲裁者，角色齐全，相互调用。结果是 token 成本失控、延迟叠加、错误在智能体之间传染，排查一个错误输出要在多轮上下文里追凶。为什么发生：Anthropic 在其多智能体研究系统的工程复盘中公开过一组代价数据：多智能体系统的 token 消耗约为普通对话的十几倍量级，其收益集中在调研类、可并行分解的任务上；同时 Cognition 团队发表了针锋相对的论证，指出多智能体拆分会割裂上下文、把隐含决策推给通信协议。两边共同的潜台词是：拓扑本身不产生价值，任务结构决定拓扑——先决定用多智能体再找任务，是把手段当地图的教科书式错误。怎么破：从单智能体加工具起步，让任务结构用真实工作量说话。只有当任务可清晰分解为独立子问题、子问题间的上下文依赖可控、且并行收益能覆盖 token 与延迟成本时，才升级拓扑。拆分的判断依据在站内 智能体上线检查清单 里有可逐项核对的条件。一句话版本：先证明单智能体不够，再增加智能体；而不是先建好舰队，再找海战。

反模式三：范围无边界

症状：从一个原型开始，客户每看一版就多「几个小需求」，三个月后 FDE 在同时维护七八个半成品功能，每个都接近可用、没有一个达到验收，团队疲于奔命，客户觉得进度缓慢，双边都不满意。为什么发生：原型驱动的交付方式自带这个风险。Palantir 的 bootcamp 文化——用客户真实数据在数天内冲出可运行原型——被广泛称道，但它的隐性前提常被忽略：原型是销售工具和需求探索工具，不是交付承诺；原型之后必须有一次显性的范围收缩，把「什么能做」收敛成「这次做什么」。国内的私有化项目里，这个环节经常缺失：原型带来期待，期待直接膨胀成需求清单，没有人负责说「不」。怎么破：把范围控制做成机制而不是美德。第一，原型演示时明确口头约定「原型中的所有内容未经排期」；第二，进入交付前用范围文档把需求切成三期，第一期小到可以两周内验收——站内 范围界定 playbook 给了完整的切法；第三，所有新需求进变更流程重新计价排期，不接受「顺手做了」——顺手是驻场交付里最贵的两个词。

反模式四：硬件到位等于交付完成

症状：项目里程碑以到货和部署为节点：服务器进机房、模型权重加载完成、推理服务返回正常响应，验收通过，项目组解散。三个月后客户发现业务部门不用，回头找供应商，得到的回答是「我们是按合同交付的」。为什么发生：国内大模型私有化热潮里，这个错位被公开报道反复验证——硬件到位与业务落地之间的缺口恰恰是最大瓶颈，缺口集中在业务逻辑梳理与数据治理，而这两件事既不出现在硬件合同里，也不在传统软件供应商的舒适区里。一体机的采购决策链（IT 部门、预算周期、招投标口径）与落地的责任链（业务部门、数据团队、持续运营）是断裂的，FDE 类角色本该是补上断点的桥，但如果合同按「设备加部署」计价，这座桥就没有预算。怎么破：把验收锚点从「服务跑通」改为「场景跑通」。签约时至少绑定一个明确场景的业务级验收标准，让到货部署只算开始不算交付；交付方内部则要防止另一面的滑坡——用「客户业务没准备好」来解释所有落地失败，把自身在需求翻译和数据治理上的能力缺口一并掩盖。站内 中国版 FDE 讨论过国内语境下这个角色的真实边界：它必须比海外同行更深入业务，因为国内客户的组织里没有现成的 bridging 角色可以配合。

反模式五：英雄式交付

症状：项目离了某个人就转不动。他脑子里装着所有客户口径、环境细节、历史决策和没写下来的 workaround，他休假项目就停摆，他离职客户就开始续约危机。为什么发生：驻场环境天然奖励个人英雄主义——现场只有你，客户直接找你，快速响应的捷径永远是「不用写文档直接改」。评测集、决策记录、交接文档这些沉淀动作的收益是延迟的、归属是组织的，成本却是即时的、由个人承担的，理性个体在项目压力下的选择不难预测。但组织的账不一样：关键人依赖是交付业务里最贵的隐性负债，它让人员流动直接变成客户风险，也让团队规模无法扩张——每个新项目都要重新培养一个「他」。怎么破：把沉淀做成流程的强制环节而不是个人美德。第一，评测集是第一优先级的资产——它是唯一不依赖人来回答「系统还能不能用」的资产，站内 评测回归模式 给了最小可行做法；第二，关键决策当天落三行记录：决策、理由、备选，成本极低；第三，交接按清单执行而不是按心情执行，站内 交接清单 的条目顺序就是资产优先级。判断一个项目是否英雄式交付，有个残酷的测试：让主力突然失联两周，看哪些东西还在转。

反模式六：验收口径漂移

症状：项目临近验收时，双方才发现对「完成」的理解完全不同。客户说「可用」指的是业务部门满意，交付方说的「可用」指的是功能全部实现；客户拿出的是开会时的某句口头承诺，交付方拿出的是需求文档第 4.2 节。类似的还有指标口径之争：准确率在谁的样本上算、以什么标注为金标准、跑多少次取什么值。为什么发生：大模型交付里「完成」天然模糊——生成式系统的输出没有唯一正确答案，质量判断带有主观成分，而合同文本又跟不上这种模糊性，于是口径在项目中途被一次次重估：客户高层换了、业务方换了、竞品演示看多了，标准就在无声处漂移。最危险的是，每次小幅漂移单独看都合理，加总起来可以让一个原本健康的项目在验收时变成废墟。怎么破：口径合同化，而且要在双方都没有压力的时候定。POC 之前就写清验收场景集、评测方法、金标准来源、通过阈值和争议裁决方式——站内 POC 验收清单 把这些列成了进场前必须逐项确认的条目。验收时如果发现口径需要变更，走正式变更而不是默认沿用新解释。北欧主权基金引入 Claude 的公开案例里，效果度量口径（关键工作流约两成时间节省、按年折算小时数）是在项目叙事中占据中心位置的——站内 Anthropic×NBIM 复盘 分析过这个细节的价值：口径清晰的项目，连成功都是可审计的。

反模式七：外包滑坡

症状：驻场团队做着做着变成了「高级外包」：按人头计费，客户指哪打哪，需求完全由客户定义，做的内容与自家产品越来越无关，团队既不了解客户的战略，也不反哺自己的产品，毛利越做越薄，人员越换越 junior。为什么发生：这个滑坡的商业机制在站内 FDE 商业模式分析 里有完整拆解，本质是定价与资产的错位：当收入只按人力时间计价、交付中产生的能力和数据不回流产品时，驻场就只剩成本没有复利，而成本型业务的天性就是不断被压价。它发生的门槛极低——只需在几个合同里默许「按客户要求做任何事」，滑坡就开始了，而且难以逆转：收入结构定型后，砍掉任何一个项目都伤营收。怎么破：四个早期信号要定期体检——收入结构里项目制与订阅制的占比、交付产出的资产回流率、团队人员结构的 senior 占比、对单个客户的定价权。两个恶化就停单修模式。FDE 模式的全部商业逻辑建立在「服务是产品的安装过程」上：驻场中发现的需求要变成产品路线，交付中沉淀的组件要回流平台，客户数据产生的洞察要在合规前提下改进模型能力。切断了回流，剩下的只是穿着科技公司 T 恤的人力外包。

结论

把七个反模式放回一起看，规律比清单更重要。前三个——演示驱动、拓扑先行、范围无边界——发生在项目早期，症状明显，纠正成本尚可；中间三个——验收错位、英雄式交付、口径漂移——发生在项目中期，症状隐蔽，因为「项目还在推进」，没有任何一方有动力停下来指出问题；最后一个——外包滑坡——发生在商业模式层，症状出现时已接近不可逆。这个时间分布决定了反模式治理的要害：早期靠工程纪律（评测先行、单智能体起步、范围文档化），中期靠治理机制（场景级验收、强制沉淀、口径合同化），晚期只能靠商业模式的定期体检。给从业者一个收束的判断标准：技术选型的坑，重跑一次的成本是几周；治理结构的坑，重跑一次的成本是一个客户、一个行业口碑，甚至一个团队的士气。七条反模式值得每个交付团队每季度对照一次——不是因为它们深奥，而是因为它们太普通了，普通到每个团队都相信「我们不会犯这种错」，然后按同样的顺序再犯一遍。