快速原型 vs 完整开发：FDE 的交付节奏

一、两种交付，两种死法

AI 项目常见的两种失败，对应两种交付方式：快速原型的死法是"演示很惊艳，上线不能用"——原型绕过了真实数据、权限、并发这些不性感的问题；完整开发的死法是"按图施工，竣工即过时"——八个月做完，客户说业务变了。

FDE 的交付节奏不是二选一，而是让两种模式各守其位：原型负责回答"值不值得做"，完整开发负责"做出来能活十年"。

二、原型的任务边界

一个合格的验证原型只需要证明三件事：

1. 真实数据能进得去。 用客户的一份真实数据（哪怕脱敏后的一小批）跑通，而不是用造的样例。
2. 输出能被业务判断对错。 让一线人员看结果，能说出"这条对、那条为什么错"。
3. 省下的时间可测量。 原来这个环节花多久，现在花多久，两个数字都要当场量。

三件事证明完，原型的历史使命就结束了。原型代码不配拥有未来，它应该被扔掉——保留原型代码继续长，是"演示惊艳、上线不能用"的起点。

三、完整开发从哪开始

原型验证通过后，正式工程的第一批交付物不是功能，是三样东西：数据接入的正式通道（带权限和审计）、输出的校验层、回归用例集。这三样是原型和产品的分界线——原型可以没有，产品一天都不能有。

四、节奏怎么排

我们的经验值：原型两周，验证汇报一次；通过后进完整开发，按里程碑分阶段交付，每个阶段结束都回到"真实数据、业务判断、可测量"这三问。

排期讨论里最该被问的一个问题："这个里程碑结束，业务方能在真实数据上看到什么？" 答不出来的里程碑，就是在往"竣工即过时"的方向滑。

撰稿：邓湘雷