你的 AI 项目为什么死在生产环境：3 个真实团队的工程教训

接个大模型做个 Demo，4 个方框就够了——用户、WebSocket、LLM、再回到用户。架构图看着很 AI。

上线第一天面对真实用户，你需要的是 12 个以上——而且其中没有一个是 AI。

2026 年 7 月，三个团队——一家银行的 AI 聊天机器人、一个 YC S26 的初创公司、一家做 COBOL 智能体的工程团队——同时撞上这个问题：真正决定 AI 项目能不能上线的，从来不是模型有多强，而是工程基础设施够不够厚。

今天把三家的工程教训摆在一起，看看到底是哪里出了问题。

01 三个教训：3 家团队撞上的同一堵墙

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

故事来自一家银行的 AI 聊天机器人团队。一位 Node.js 开发者接手时，自己都觉得活儿简单到尴尬："用户连接时打开 WebSocket；消息发给 AI；回复流式传回去。架构 v1 只有四个方框。"

撑了不到一周。他凭直觉问："如果有人问机器人昨天的 IPL 板球赛谁赢了，会怎样？" 没人答。当场试——机器人把这个问题塞进装满定存利率和贷款条款的知识库搜索，什么都没找到，却自信地胡答了一通："板球相关问题请联系您的支行"。

好笑十秒。然后就不好笑了。这个机器人没有"这不归我回答"的概念。

他们需要一个"守门人"——意图识别（Intent Detection）。但把意图识别也用大模型实现时，灾难来了：

外请的资深工程师看了架构图笑着说："你们在用剑切菜。剑看着唬人，刀才是干这活的对的工具。"

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

银行团队解决意图问题后，又问："能缓存吗？" 答案是"能，Redis"。然后他们花了一周才搞清楚——缓存什么是个远比想象中难的问题。

第一次：存查询、存回复，键值对搞定。结果下一个测试就崩——"今天定存利率多少"命中，"能告诉我今天的固定存款利息吗"就没命中。同一个问题、同一个意图、不同的字符串。

第二次：按意图缓存，不按原文。撑了一天。有人连问两个都被归为 FD_RATE："定存利率是多少"和"定存有什么好处"——同一个意图桶，完全不同的答案。

架构师递过来一张纸巾，写着两个词：语义缓存（Semantic Cache）。原理：把查询转成嵌入向量（embedding）——捕捉"含义"——再和缓存向量比对，足够接近就直接返回缓存答案。

周一早晨开发者打开 Grafana，看到的却是——缓存命中率 8%。原因：他把相似度阈值设成 0.90，只是因为某篇 Medium 文章用了 0.90。团队拿两天的真实流量重新校准，命中率从 8% 推到 60%——同样的模型、同样的缓存，只动了一个数。

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

第三个故事来自 Coasty——YC S26 的一家初创公司，做"计算机操作智能体"的 API：能在没有可用 API 的遗留桌面软件和 Web 应用里完成医疗预授权、财务录入、系统间搬运。

传统替代方案是 RPA（录制一串点击再回放）。界面可预测时能用，但按钮一移位、弹窗一出现、页面加载一变慢，就会崩。

Coasty 创始人在 HN 讨论里透露真正的差异化：

这就是"AI 只能兜底，不能负责"的精髓：确定性工作流 + AI 兜底。

对照答案来自 Hypercubic 的 Hopper——面向大型机和 COBOL 的智能体开发环境。COBOL 系统承载着银行、保险、政府、航空的核心业务，但懂 COBOL 的开发者正在快速退休。

Hopper 的设计哲学：每步决策打检查点（checkpoint）；定义不变量（invariant）——什么不能变；关键操作前设审批关卡（approval gates）；每步留可回放事件日志（replayable event log）。

这四样不是"AI 功能"，是审计与合规的工程基础设施。

02 老板该问的 3 个问题

卡在这个问题上的，不是个例。3 个绕不开的问题：

• 分类器还是大模型
  ：95% 的请求是显而易见的，规则引擎或小分类器就够了——你的架构图里有没有这一刀？
• 阈值从哪来
  ：缓存、相似度、置信度——拿两天的真实流量跑出来的，还是抄的某篇 Medium 文章？
• 失败模式有几种
  ：屏幕显示"完成" ≠ 真的完成——只有下游信号兜得住隐性失败。

03 算账时间：Demo 与生产的真实比率是 1:10

多出来的每一个方框都不是 AI——是意图分类器、语义缓存、下游信号校验、审批关卡、事件日志。1:10 的成本差距，几乎全部花在工程基础设施上。

银行开发者原话最戳人："每一个方框的存在，都是因为某天有东西崩了、有人笑了一个烂问题、或者一个仪表盘在周一早晨羞辱了他们。我实际做的，是眼看着一个系统在我面前自己把自己设计出来。"

04 Mixlab Launchpad 的方法论

帮传统行业做 AI 改造这几年，我们沉淀出一套标准流程——分类器和规则处理 95% 显而易见的请求；LLM 只服务 5% 真正模糊的；缓存阈值拿两天的真实流量跑出来；审计与合规的工程基础设施当头号投资。

3 个场景具体走法：

场景 1：客服 / FAQ 类智能体——小型分类器先把 95% 显而易见的请求拦下来；剩余 5% 才进 LLM；置信度低于阈值转人工；闭环对齐下游反馈。

场景 2：流程自动化类——把流程拆成确定性步骤 + 模糊判断步骤；确定性步骤用代码跑，模糊步骤才用 AI 兜底；每个动作打 checkpoint，关键操作加 approval gate；操作完成后必须等下游信号。

场景 3：遗留系统对接类——明确"什么不能变"的不变量；AI 只能在不变量边界内做判断；每步决策打点，关键操作人工审批；留可回放事件日志。

这套流程下来，Demo 与生产的成本比从 1:10 收回到 1:3。

所谓"工程基础设施"，就是意图分类器、语义缓存、下游信号校验、审批关卡、事件日志——这些才是 AI 落地的真正护城河。

05 回到本质

AI 落地的真问题，从来不在模型那一层。它在分类器选错的那一刻、在缓存阈值抄博客的那一刻、在用纯视觉代替下游信号的那一刻。

模型不是壁垒，工程基础设施才是。

给企业决策者的 4 句话：

1. 别问"接哪个模型"，先问"分类器够不够"。95% 的请求应该走规则引擎或小分类器，LLM 只服务那 5% 真正模糊的。
2. 别问"准确率多少"，先问"失败模式有几种"。"提交了却没真正提交"这种隐性失败，只有下游信号兜得住。
3. 别问"AI 能做什么"，先问"流程能不能拆"。把确定性流程用代码跑完，AI 只在偏离时介入。
4. 别问"上不上线"，先问"出了错谁来兜底"。检查点、不变量、审批关卡、可回放日志——这些是审计基础设施，不是 AI 功能。