AI项目为何折戟生产环境：三个真实团队的工程教训

接个大模型做个Demo，四个方框就够了——用户、WebSocket、LLM、再回到用户。架构图看着很AI。上线第一天面对真实用户，你需要的是十二个以上，而且其中没有一个是AI。2026年夏天，三个团队同时撞上同一个问题：真正决定AI项目能不能上线的，从来不是模型有多强，而是工程基础设施够不够厚。

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

故事来自一家银行的AI聊天机器人团队。一位开发者凭直觉问了一个问题：「如果有人问机器人昨天的IPL板球赛谁赢了，会怎样？」没人答。当场一试——机器人把这个问题塞进装满定存利率和贷款条款的知识库搜索，什么都没找到，却自信地胡答了一通：「板球相关问题请联系您的支行」。这个机器人没有「这不归我回答」的概念。他们需要的是意图识别——一个「守门人」。但把意图识别也用大模型实现时，灾难来了：单次延迟200-300毫秒，每次成本约0.01元。而一个小型Transformer分类器，延迟仅10-15毫秒，成本约0.0001元。「你们在用剑切菜。剑看着唬人，刀才是干这活儿的工具。」

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

银行团队解决意图问题后，又问：「能缓存吗？」答案是「能，Redis」。然后他们花了一周才搞清楚——缓存什么是个远比想象中难的问题。第一次尝试：存查询、存回复，键值对搞定。结果下一个测试就崩——「今天定存利率多少」命中，「能告诉我今天的固定存款利息吗」就没命中。同一个问题、同一个意图、不同的字符串表达。第二次尝试：按意图缓存，不按原文。撑了一天。有人连问两个都被归为同一意图桶，却是完全不同的答案。解决方案是语义缓存：把查询转成嵌入向量，捕捉「含义」，再和缓存向量比对，足够接近就直接返回缓存答案。但这里有个关键陷阱——相似度阈值。开发者把阈值设成0.90，只是因为某篇博客文章用了0.90。结果缓存命中率只有8%。团队拿两天的真实流量重新校准后，命中率从8%推到60%——同样的模型、同样的缓存，只动了一个数字。阈值从哪来？拿两天的真实流量跑出来，还是抄的某篇博客文章？这是本质区别。

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

第三个故事来自YC S26的一家初创公司，做「计算机操作智能体」的API——能在没有可用API的遗留桌面软件和Web应用里完成医疗预授权、财务录入、系统间搬运。传统替代方案是RPA（录制一串点击再回放），界面可预测时能用，但按钮一移位、弹窗一出现、页面加载一变慢，就会崩。这家公司的真正差异化在于：「确定性工作流 + AI兜底」。对照答案来自面向大型机和COBOL系统的智能体开发环境Hopper。它的设计哲学是：每步决策打检查点；定义不变量——什么不能变；关键操作前设审批关卡；每步留可回放事件日志。这四样不是「AI功能」，是审计与合规的工程基础设施。「AI只能兜底，不能负责」——这句话的真正含义是：确定性工作流必须用代码写死，AI只在偏离时介入。

给企业决策者的四句话

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

如有侵权，请联系删除。