《FDE案例100》方法论特辑 · No.11｜交付与工程化：跨过"能跑"到"能用"

那些不”AI”的脏活，才是分水岭#

我们做 Demo 的时候，环境是干净的：一台自己的电脑、一条顺滑的网、一个配好的模型。

到了客户现场呢？

同样是这个案例，FDE 自己电脑上跑得好好的程序，到了客户电脑上就报错。原因很简单，每台电脑的环境都不一样。于是就有了那个特别经典的循环：你发一个安装包，对方说报错；他截图给你，你改一改再发一个；结果又冒出新的错误。

这些在标准软件工程里都是最基础的坑，但它就是会实实在在拖慢整个项目。

所以这位 FDE 后来把”环境”当成第一现场问题：进去先花时间把每台电脑的网络、权限、运行环境摸清楚，尽量提前统一。

他自己的原话是——“大量工作并不’AI’。” 你可能要修网络、要处理 Windows 环境、要梳理文件命名、要解决权限、要等老板开会回来、要催员工测试。这些看起来都不是 AI 技术，但它们决定了 AI 到底能不能进入真实业务。

我觉得这句话值得每个想做 FDE 的人贴在墙上。

能跑 ≠ 能生产#

第二道坎，是稳定性。

美国前三大的电信运营商那个案例，场景是分析网络数据、回答”现在到底哪个基站坏了、为什么坏、影响多大”。FDE 发现，客户自己其实早就搭过一个 Agent 了——给模型一个提示词：“你现在是一个数据分析师，我给你这些数据，请帮我分析。“看起来特别合理，跑起来也能出结果。

但一进生产环境就露馅了：同一个问题问两遍，答案可能不一样；SQL 写到上百行，中间就可能取错数据。

有人说，大模型本来就是不确定的，答案不一样很正常。这位 FDE 直接怼了回去：“如果我是一个企业老板，我问一个 Agent 两遍’公司哪个班成绩最好’，我希望它在数据没变化的情况下，告诉我同一个人。”

模型本身有随机性，不代表我们做出来的业务系统就应该不稳定。

他打了个很妙的比方：“就像汽油本身不稳定，但汽车工程的意义，就是让汽油可以安全、稳定地驱动车辆。”

做一个能跑的 Demo，是给汽油点了火；做一个能用的系统，是造一辆能上路的车。这是两回事。

成本也是这样：先别谈省油#

说到成本，还有一个更扎心的说法。

这位 FDE 说：“如果架构设计得不好，就像一辆漏油的车，你根本不用谈省油，因为油一直在往下掉。”

很多人一算成本，只算”调用模型多少钱”。但真实的成本包含好几层：调试成本、长期运行成本、规模化之后的成本。他举了个例子——不知道怎么做 Agent 的团队，可能为了调试一个东西花掉几千美元；而真正有经验的人，十几、二十美元级别的成本就能完成同样的调试。

差距不是模型给的，是工程能力给的。

兜底、可追溯、给反馈留位置#

那”能用”的标准到底是什么？

案例里给了几个朴素的答案。一个是回退机制：本地生活内容那个案例里，FDE 说如果某一个节点 AI 做得不好，就把这个节点重新交还给人。不追求百分之百自动化，AI 先跑，人负责最后的判断。

一个是校验与审计：把提示词、Skill、业务参数，还有校验、审计的 Loop 机制组合起来，让 AI 进的是一套完整流程，而不是一个孤零零的对话框。

还有一个是给人留下继续改的空间。那位 FDE 说得很清楚：“交付的不只是一个能跑的东西，还要让企业能够继续用、继续改。” 所以他在项目交付时就提前预留持续迭代的空间，让客户按照 SOP 自己继续优化。这样项目结束之后，事情就不会全部回到他这里。

你看，这些动作没有一个是炫技的，但每一个都在回答同一个问题：这个系统，客户敢不敢真的天天用？

规模化：从第一天就要想#

最后还有一个容易被忽略的角度——规模化。

电信运营商那个案例里，客户有几十甚至上百个分析师。如果每个分析师单独装一个 Agent、单独维护一套东西，这个方案很快就会失控。

所以他们的设计从一开始就考虑：把 Agent 放到云端，统一控制、监督和使用；让不同用户产生的数据和经验反过来提升系统，包括记忆、语义层这些能力。规模化不是上线之后才想的事，是从 Day One 就要规划的事。

一句话总结#

Demo 交的是可能性，工程交的是确定性；能跑只是及格线，能用才是交付线。

这是《FDE案例100》方法论特辑的第 11 篇。构建专辑写到这里，我们已经聊了怎么把能力做出来、怎么复用、怎么交付。下一篇开始换一个视角——从系统转向人。我们会聊一个几乎所有 FDE 都会得出的结论：AI 落地真正的瓶颈，排在最前面的不是技术，是人。