第 3 章 · 从交付代码到交付结果

两种问法

先看两种项目复盘会。

第一种，问的是：「功能都做完了吗？接口都通了吗？bug 都修了吗？」——都做完了，项目就算成功。

第二种，问的是：「这东西上线两个月，客服的平均处理时长降了没有？降了多少？差评率有没有变化？运营愿不愿意继续用它？」——只有这些数字有了正向变化，项目才算成功。

传统软件交付是第一种问法，FDE 的交付是第二种。从「功能做没做完」到「业务变没变好」，这一步思维切换，是做好 FDE 的地基。 这一章讲两个必须完成的切换。

工程师有个本能：拿到需求就想开始写，而且想写得漂亮、想从头造一套自己的东西。这个本能在 AI 交付里往往是有害的。

价值优先意味着，动手之前先问三个问题：

一句话：FDE 的第一交付物不是代码，是「这件事确实有用」的证据。 代码只是拿到证据的手段之一，而且往往不是最快的那个。

这不是让你不写代码，而是让你把「写代码」放到「已经确认值得做」之后。第 13 章会给你一条具体的「先快验、再定制、后工程化」的三层路径。

传统软件是确定的：同样的输入，永远同样的输出。大模型不是——它是概率性的，同一个问题问两次，措辞可能不同；它会有幻觉，会一本正经地编，会在你没防备的地方出错。

很多工程师第一次做 AI 交付时，会本能地想「把它调到 100% 准」。这是个陷阱：你调不到 100%，而且追求 100% 会让你在错误的地方耗尽预算。 FDE 要做的不是消灭不确定性，而是管理它。管理有四个动作：

这四个动作，本质上是把「AI 会出错」从一个风险，变成一个被设计过的、可控的系统特性。业务方真正怕的从来不是 AI 会错，而是错了之后无人知晓、无法挽回。你把这四条做扎实，业务方就敢让 AI 上线。

价值优先不能只停在口号上。FDE 至少要把价值落到一种可观察数字里：

粗算 ROI 时，不需要一开始就精确到小数点。能先算出一版「能不能成立」就够：

月度价值 = 节省人时 × 人时成本
        + 风险减少价值
        + 增收贡献
        - AI 运行成本
        - 人审成本
        - 维护成本

这条公式会逼你把隐藏成本也算进去。很多 PoC 看起来效果不错，但一加上人工复核、模型调用、数据维护和异常处理，真实 ROI 就变薄了。FDE 要早一点把账摊开，免得上线后才发现「越用越贵」。

这两个切换背后，其实是一种心态的转变——Ownership，对最终结果负责到底。

传统分工里，每个人只对自己那一段负责：我把代码写完就交给你，你的模型不准不关我事。FDE 不能这样。因为前两章讲过，AI 项目死就死在那些「不关任何人事」的缝隙里。FDE 的定位，恰恰是那个说「这件事的最终效果，我兜」的人。

这不是要你揽下所有活自己干，而是要你盯住那个业务结果，谁掉链子就去补谁的位、去协调、去推动——直到那个数字真的变好。

往交付包里放一句「价值假设」，格式固定：

如果我们把 ___（哪个环节）交给 AI，业务上的 ___（哪个指标）应该会从 ___ 变到 ___。

写不出这句话，说明你还没想清楚要交付什么结果。这句话会成为后面场景卡和验收指标的种子。