第 9 章 · 真正改变的是交付契约

软件项目有一个很有仪式感的时刻：上线。

群里发喜报，项目组拍合照，领导感谢双方团队。忙了几个月的人终于松一口气。

上线当然重要。没进生产，前面全是准备。

但从客户价值看，上线只是系统第一次有资格接受检验。

用户会不会用，流程会不会改，模型遇到真实数据还能不能工作，出了异常谁来接。每一项都在上线以后才露出真面目。

传统项目把上线当终点，有它的合同和组织原因。FDE 若只是把终点往后拖几周，却不改变衡量方式，也只是延长了交付。

新的契约得回答：到底什么发生了，项目才算完成？

从“能跑”到“有人用”

原型最容易证明的是能跑。

给一组样例数据，模型识别出字段；输入一个问题，系统生成答案；点一下按钮，流程走完。客户看到以后会兴奋，因为原来抽象的能力终于有了画面。

问题是，演示里的每一步都有人照看。

数据提前清理过，异常不会同时出现，权限已经开好，模型答偏了可以重来。到了生产环境，用户不会按照演示脚本生活。

第一道门不是准确率，而是采用。

操作人员是否愿意把工作交给系统？他需要同时维护旧流程吗？系统慢十秒会不会让他放弃？出现错误时，他知道找谁吗？

OpenAI 的 FDE 职位说明把“生产采用”和“可衡量的工作流影响”直接写进成功标准。比起部署了多少模型，它更关心工作流有没有变化。

一个系统如果每天被打开一百次，却只是让用户复制结果回 Excel，采用仍然可能是假的。使用量只能说明有人点击，不能单独证明价值。

最小可行部署，不是更漂亮的 POC

概念验证回答“技术有没有可能”。

最小可行部署要回答“在真实环境里，这件事值不值得继续”。

两者看上去都可以很小，差别在约束。

最小可行部署至少要碰到真实或足够接近真实的数据，进入实际工作流，有明确用户，也要事先约定一个结果指标。它不必承担全部生产流量，却不能只在会议室里表演。

Palantir 曾把 AIP Bootcamp 概括为五天以内从零走到用例。速度很吸引人，但“五天”不是魔法。短周期的价值，是逼双方只选一个足够具体的问题，当场用数据和工作流检验，不给宏大平台项目留下无限延长的空间。

快不是为了少写代码，而是为了早点得到反对意见。

用户说这个步骤根本不会这样做，安全团队说这个权限不能开，数据一接才发现三套系统互相矛盾。这些“坏消息”越早出现，项目越省钱。

先约定裁判，再开始比赛

企业 AI 项目最容易使用模糊目标：

提高效率、改善体验、赋能决策、增强智能化水平。

这些话适合写在立项材料里，不适合验收价值。

一个具体项目至少要把三类指标分开。

第一类是系统指标：准确率、延迟、稳定性、调用成本。

第二类是工作指标：处理时间、人工复核比例、积压数量、一次通过率。

第三类才是业务结果：少亏多少、多赚多少、风险降低多少、客户是否续约。

三类不能互相替代。

模型准确率提高，不保证工作时间下降；工作时间下降，也不保证企业省下成本。一个岗位每天省两小时，如果人仍然必须全程待命，财务上未必马上出现节省。

所以项目开始前要先约定裁判：看哪几项数字，基线是什么，多长时间判断，谁确认结果。

没有裁判的试点，最容易永远处于“再优化一下就有价值”的状态。

敢说“不值得做”

传统供应商很难拒绝有预算的需求。

客户愿意付钱，项目就有收入。至于收益是否超过成本，通常被归到客户自己的商业判断。

FDE 若声称对结果负责，就不能完全躲在这条边界后面。

有些流程一年只发生几十次，自动化开发成本永远收不回来；有些任务虽然耗时，却需要人承担关系和判断，硬换成 AI 只会增加复核；有些问题根源是错误制度，模型只能让它执行得更快。

这时候，最有价值的交付可能是一句“不值得做”。

说这句话不浪漫。它可能让合同缩小，甚至让项目停止。但如果 FDE 只负责证明 AI 什么都能做，最后还是回到了卖功能。

判断值不值得，需要把技术账和生意账放在一起：

做出来要多少钱，运行要多少钱，错误成本多大，节省能不能真的进入财务报表，增长是不是由系统带来。

技术是入场券，算账才决定这件事有没有下一场。

对结果负责，不等于承诺所有结果

“按效果付费”听起来最符合 FDE 精神。

系统多追回一百万元，服务方分成；每解决一次客户会话，按次收费。价格直接挂在价值上，双方目标似乎完全一致。

现实里，结果往往由很多因素共同决定。

销售增长可能来自市场行情，坏账下降可能因为客户结构变了，客服满意度还受物流和产品质量影响。服务方若无法控制关键变量，却承诺最终结果，合同会变成一场归因争论。

所以对结果负责，不等于把企业全部经营风险接过来。

更可行的方式，是分层承诺。

对自己能控制的系统和工作流指标承担明确责任；对业务结果共同设目标、跟踪归因；条件成熟时，再把一部分费用与结果挂钩。

中国企业采购习惯、预算科目和验收流程也决定了，不是所有客户都能一步跳到纯结果定价。阶段验收与价值指标可以同时存在，不必为了显得先进而否定项目管理。

交付结束时，应该多出三样东西

一项 FDE 项目结束，至少应该留下三类结果。

客户侧，工作发生了可观察的变化。用户真的采用，风险边界清楚，业务指标有前后对照。

产品侧，现场经验沉淀成了可复用能力。连接器、评估集、业务对象、控制规则或交付手册，下一次能用。

关系侧，双方知道接下来该扩大、维持还是停止。不是靠“客户感觉不错”，而是有数据和共同经历支撑。

如果只留下代码，项目仍然很脆。

如果只留下客户关系，服务会依赖个人。

如果只有一组漂亮指标，却没有可复用能力，团队会在下一家客户重新开始。

FDE 的交付契约之所以比传统项目更重，是因为它同时碰到了这三边。

第三部到这里，可以把答案说得更清楚一些。

AI 的新，不只在它能生成内容，而在它开始参与行动；FDE 的新，不只在能力混合，而在责任不再轻易停在上线；交付的新，不只是周期更短，而是必须用生产采用、工作影响和可复用反馈来证明价值。

可一旦准备这样做，过去的数据建模与治理经验还能帮上多少忙？

下一部，我们把旧工具重新拿出来，看哪些还锋利，哪些已经不够用了。

本章资料

场景说明：本章上线、采用与指标设计场景为企业软件交付中的复合情境。