AI项目落地为什么总是死在生产环境？三个真实案例揭示的工程真相

很多团队都有过这样的经历：花几天时间接上大模型，画一个四个方框的架构图，Demo演示效果惊艳。上线后面对真实用户时，却发现这个「Demo」根本不堪一击。实际上，一个真正能跑在生产环境的AI系统，需要的方框数量是Demo的3倍以上——而且这些方框里，几乎没有一个是AI。

教训一：意图识别不该用大模型

本文基于三个真实团队的实践案例，深入分析AI项目从Demo到生产环境过程中最容易踩的坑，以及如何通过扎实的工程基础设施让AI真正发挥价值。

教训二：缓存不是键值对，是语义对

某银行AI聊天机器人团队的遭遇很有代表性。最初架构只有四个方框：用户、WebSocket、大模型、返回用户。运行不到一周就暴露了问题——当用户问「昨天的IPL板球赛谁赢了」时，机器人在定存利率和贷款条款的知识库里搜索一番后，自信满满地回答：「板球相关问题请联系您的支行」。 问题出在缺乏意图识别机制。当把意图识别也交给大模型来做时，成本和延迟都成了问题：一轮LLM意图识别的延迟在200-300毫秒，成本约0.01元/次；而一个小型transformer分类器的延迟仅10-15毫秒，成本约0.0001元/次，准确率却相当。资深工程师看了他们的架构后评价：「你们在用剑切菜。剑看着唬人，刀才是干这活儿的工具。」 正确的做法是用规则引擎或小型分类器处理95%的明确请求，只把真正模糊的5%交给大模型。这不是技术妥协，而是工程上的最优解。

教训三：AI只能兜底，不能负责

基于上述教训，企业决策者在评估AI项目时，应该关注的是： 1. 分类器够不够：95%的请求应该走规则引擎或小分类器，LLM只服务那5%真正模糊的。别问「接哪个模型」，先问「分类器选对没有」。 2. 阈值从哪来：缓存、相似度、置信度……这些阈值应该用真实流量跑出来，而不是照搬技术博客。 3. 失败模式有几种：屏幕显示「完成」不等于真的完成。「提交了却没真正提交」这种隐性失败，只有下游信号才能兜住。 4. 出了错谁来兜底：检查点、不变量、审批关卡、可回放日志——这些是审计基础设施，不是AI功能，却是AI落地的真正护城河。

决策者应该问的四个问题

YC S26的一家初创公司Coasty做的是「计算机操作智能体」——在没有可用API的遗留系统和Web应用中完成医疗预授权、财务录入等任务。传统的RPA方案在界面可预测时能用，但按钮移位、弹窗出现、页面加载变化时就会崩溃。Coasty的差异化在于「确定性工作流加AI兜底」：可预测的步骤用规则执行，不可预测的部分由AI处理。 另一个案例是面向大型机和COBOL系统的智能体开发环境Hopper。它的设计哲学是：每步决策打检查点；定义不变量——明确什么不能变；关键操作前设审批关卡；每步留可回放事件日志。这四样东西不是「AI功能」，而是审计与合规的工程基础设施。 核心洞见是：AI擅长处理模糊性和不确定性，但企业级应用需要的是确定性和可追溯性。两者并不矛盾——让确定性流程自动化，让AI只在偏离时介入。

如有侵权，请联系删除。