FDE原型阶段：验证方向而非Demo展示丨用真实数据验证方向，比用干净数据做出漂亮Demo更重要

上一篇说，发现阶段结束的标志是一句双方认可的问题定义。有了这句话，下一步是什么？

很多人的直觉是：开始开发。

FDE的做法不一样——先做原型，在客户的真实数据上跑，把方向确认下来，然后再进入生产级别的工程投入。

这篇讲原型阶段的核心逻辑：为什么要用真实数据，评测标准从哪里来、怎么建，以及原型阶段结束的标志是什么。

NotebookLM的音视频概览，解读的比较通俗易懂，对于时间比较紧张的读者朋友，可以听听，会有启发。

原型不是Demo，目的完全不同

先看一个真实发生的情况。

一家金融公司的数据科学团队花了几个月，在Jupyter Notebook里建了一套AI模型，准确率很高，首席数据官签字认可。然后项目进入部署阶段。

接下来发生的事：系统需要对接公司的本地Oracle数据仓库，需要通过SAML单点登录认证，需要通过内部安全审计才能接触生产环境，还需要在三个区域办公室的400个并发用户下稳定运行。

数据科学家做的东西，完全符合要求。但这些要求之外的事，没有人处理。项目卡在"预部署"状态七个月，没有上线。

这不是个例。这个场景在企业AI落地里反复出现，背后的原因只有一个：原型阶段验证的东西不对。

验证了模型在干净数据上的准确率，没有验证的是：这个方案在这个企业的真实系统里，能不能跑起来。

这就是原型和Demo的本质区别。

Demo是在受控环境里展示效果，目的是说服——说服客户、说服高管、说服投资人。Demo需要好看，需要流畅，需要让人印象深刻。

原型是在真实数据上验证方向，目的是发现问题——发现数据质量问题、发现系统接口障碍、发现评测标准和真实业务之间的落差。原型不需要好看，不需要完整，不需要生产级别的代码质量。

有一个比喻很准确：原型阶段是"企业防火墙内的黑客马拉松"。迭代以天计，不是以周计；不求完美，只求回答一个问题——发现阶段定义的那个问题，用这个方向，在这个环境里，真的能解决吗？

能，进下一阶段。不能，现在发现比进了生产再发现便宜得多。

为什么必须用真实数据

知道了原型的目的是验证方向，下一个问题是：为什么一定要用真实数据，用测试数据不行吗？

不行，原因是：

数据质量问题，只在真实数据里存在。

测试数据通常是整理过的、格式统一的、缺失值已经处理过的。真实的企业数据不是这样——它是几年甚至几十年积累下来的，格式各不相同，缺失值大量存在，不同系统之间的数据定义可能还有冲突。

模型在测试数据上准确率90%，接上真实数据之后可能直接掉到60%。这个落差在原型阶段发现，调整成本是天级别的；进了部署阶段再发现，调整成本是周级别的；上线之后才发现，代价是用户信任——而用户信任一旦失去，重建的成本比技术问题高得多。

边缘案例，只在真实业务里出现。

测试数据通常覆盖的是"正常"路径，是工程师预设的使用场景。真实用户不会按预设路径走。他们会输入奇怪的格式，会提出模糊的问题，会在系统没有预期到的地方触发边缘情况。

这些边缘案例，在测试阶段发现不了，在真实数据里跑一圈就会全部暴露出来。

系统接口障碍，只有真实接入才能发现。

原型阶段如果只是导出一份数据来跑，而不是真正接进客户的数据管道，那集成层面的问题就被推迟了。真正接进去的过程，会提前暴露后续部署阶段会遇到的那些障碍——权限问题、格式转换问题、接口响应速度问题。

这些问题早发现，就是原型阶段要处理的技术细节；晚发现，就是部署阶段的"集成墙"。

把这三类问题推迟到部署阶段，不是在节省时间，是在积累风险。

评测标准从哪里来，怎么建

原型阶段最容易被跳过的一步，是在开始写代码之前，先和客户一起建立评测标准。

工程师的直觉是"先做出来，再看效果"。但"效果"这件事，如果没有标准，就没有办法被客观评价。客户觉得好不等于真的好，工程师觉得准确率够了不等于业务能接受。

更重要的是：评测标准要和客户一起建，不能由FDE单方面决定。什么叫"对"，什么叫"可以接受"，什么叫"不行"——这些判断只有客户知道，因为它们来自真实的业务场景，不来自技术规范。

评测标准通常有三个层次，每一层单独看都不够，三层加在一起才完整：

技术指标是基础——准确率、召回率、响应时间、并发能力。这些可以用数字衡量，容易建立，也最容易被误认为是全部。技术指标达标，只代表系统在技术上是合格的，不代表业务上可以用。

业务指标是目的——这个系统对发现阶段定义的那个业务目标，贡献了什么？降低了多少处理时间，减少了多少错误，节省了多少人工成本。这些指标要在原型阶段就定义清楚，而不是上线之后再想。上线之后想，就没有基线数据可以对比，也就没有办法证明系统真的产生了价值。

用户接受度是关卡——用户愿不愿意用，信不信任系统的输出，在什么情况下会选择绕过系统自己处理。这一类指标最容易被忽略，也最终决定系统能否真正落地。技术达标、业务目标达成，但用户不用，落地就还是失败的。

John Deere项目的做法是个很好的参照：FDE团队没有自己决定什么叫"准确"，而是和农艺师一起，用几百个真实农业样本来建立评测标准。农艺师告诉FDE，在真实田间条件下，什么样的输出是可以指导操作决策的，什么样的输出会让他们不信任系统。这个标准建完，工程师才开始迭代。

这个过程有一个额外的效果：让领域专家参与建立评测标准，本身就是在建立他们对系统的信任。他们不是在等一个黑盒子做完，是在帮助定义这个系统应该是什么样的。这种参与感，是后续部署阶段用户采纳率的早期基础。

原型阶段的节奏

“企业防火墙内的黑客马拉松"这个比喻，说的是节奏，不只是速度。

具体操作上有几个原则：

以天为单位迭代，不是以周。 原型阶段每天都要有新的东西给客户看，每天都要有新的反馈进来。这个节奏不是为了赶进度，是为了保持反馈循环的密度。问题发现越早，调整成本越低；反馈循环越密，方向偏差越小。

以周为单位迭代的原型阶段，很容易出现一种情况：做了一周，给客户看，客户说方向不对，再做一周。两周才完成一次方向确认，时间和资源都在消耗。以天为单位，同样的时间可以完成十四次方向确认，找到正确方向的速度完全不同。

让客户的领域专家全程参与。 原型阶段不是FDE关门自己做，然后在某个节点展示结果。是让客户的领域专家参与每一次迭代——看输出，给反馈，告诉FDE哪里对、哪里不对、哪里和真实业务需求有出入。

这不只是效率问题。领域专家的参与，让原型阶段同时完成两件事：验证技术方向，和建立用户信任。后者在部署阶段会直接体现在采纳率上。

不求完美，只求回答那个问题。 原型的代码可以不整洁，界面可以简陋，流程可以不完整。这些都不是原型阶段要解决的问题。原型阶段只需要回答一个问题：这个方向，在这个数据上，能不能解决发现阶段定义的那个问题？

把原型做成了精美的产品演示，但没有在真实数据上验证核心假设，是用执行力掩盖了方向未经确认的风险。进入部署阶段之后，这个风险会以更高的代价暴露出来。

原型阶段结束的标志

不是FDE觉得做好了，不是演示看起来效果不错。

结束的标志是：客户的利益相关方确认，这个原型如果产品化，能解决我们在发现阶段定义的那个问题。

这个确认有三个层次，少了任何一层都不完整：

技术层——在真实数据上，系统表现达到了双方共同建立的评测标准。不是在测试数据上达标，是在真实数据上。

业务层——利益相关方能清楚地看到，这个原型和他们的业务目标之间的连接。不是"看起来挺好的”，是"这个东西如果做出来，我们的X指标会有Y变化"。

可行性层——FDE对从原型到生产的路径有足够的判断：主要的集成障碍在哪里，大概需要多少时间，有哪些风险点需要在部署阶段重点处理。

三层都确认，才是真正可以进部署阶段的信号。少了任何一层，进部署阶段都是在带着未解决的问题往前走。

写在最后

原型阶段是整个交付旅程里最容易被误解的阶段。误解不是来自不重视，而是来自对原型目的的判断——把它当成Demo来做，而不是当成验证工具来用。

Demo的成功标准是"看起来好"，原型的成功标准是"回答了那个问题"。这两件事方向不同，做法完全不一样。

用真实数据验证，和客户一起建立评测标准，以天为单位迭代，让领域专家全程参与——这四件事加在一起，是原型阶段真正的工作内容。

做对了，进入部署阶段的时候，方向是确认的，标准是清晰的，客户的信任是有基础的。做错了或者跳过了，部署阶段遇到的不只是技术问题，还有方向重新确认的成本，以及重建用户信任的成本。

下一篇进部署阶段——原型验证完之后，怎么把方案真正接进生产环境，以及那堵"集成墙"到底长什么样。

感谢你看到最后，如果你觉得有启发，随手点个赞、在看、转发吧，如果想第一时间收到推送，也可以给我加个星标⭐我们下期见。

我是「AioGeoLab」主理人塔迪Tardi，AioGeoLab是深度洞察AI第一性原理和应用实践的前瞻性研究实验室，目前有两个主要研究方向：
「塔迪GEO判断工程」在AI从“说”到“做”进化阶段，试图回答，如何让AI敢于行动、不因为责任问题而畏手畏脚，而做的一个前沿研究项目。
「塔迪硅基禅心」是传统东方智慧、未来AI前沿、当下应用实践，深层共鸣的探索。不是用AI解读经典，也不是用经典指导AI。 这是一场跨越2500年的对话，在算法与古老智慧之间，照见意识、智能与存在的本质。
塔迪的微信 - tardyai2025。