AI 应用为什么总在演示时完美、上线后崩溃

     大多数团队把 AI 项目失败归咎于模型不够好。但真正杀死项目的，往往不是模型，而是第一行代码之外的那些事：谁有权限调用、账单为什么失控、出了问题能不能回溯。这些问题不解决，再聪明的模型也只是一个昂贵的演示道具。   

     有一个现象在 AI 团队里极其普遍：demo 阶段一切顺滑，上线第一周就开始出问题。调用量突然翻倍，账单数字让人看不懂，某个用户触发了一个没人预料到的输入，结果被下游系统放大成一个真正的事故。团队开始加班，然后发现根本不知道从哪里查日志。   

     这不是模型的问题。模型从头到尾都在正常工作。真正出问题的，是围绕模型搭起来的那套系统——或者更准确地说，根本没有搭起来那套系统。   

     Demo 能跑通，是一种危险的错觉   

     很多团队犯的第一个错误，是把「能跑通 demo」当成「具备工程化能力」。这两件事之间的距离，比大多数人想象的要远得多。一个 demo 可以在理想输入下稳定运行，但它不需要处理脏数据、不需要限制谁能调用、不需要在凌晨三点服务超时时自动降级、也不需要在一个月后解释「为什么上周二成本突然涨了三倍」。   

「

     AI 工程的门槛没有因为工具变多而变低，只是从「会不会搭系统」变成了「能不能在不稳定里维护稳定」   

」

     传统软件系统有一个基本假设：相同的输入，给出相同的输出。AI 系统打破了这个假设。输出天然带波动，同一个问题问两遍可能得到两个不同的答案，同一套逻辑在不同上下文下表现迥异。这不是缺陷，这是这类系统的本质特征。但正因为如此，围绕它搭起来的工程体系，必须从一开始就把「失败」当成常态来设计，而不是等出了事再补救。   

     成本失控，通常有迹可查——但没人在查   

     AI 应用的账单为什么会失控？表面原因是 token 用量超出预期，但背后几乎总有一个共同的根因：没有人知道谁在调用、调用了什么、为什么调用。   

1某个功能上线后被用户以远超预期的频率触发，没有任何调用量的上限设置

2提示词里混入了大量冗余上下文，每次调用都在烧不必要的 token，没人注意到

3一个后台任务出现了死循环，在被发现之前已经跑了几千次调用

4不同团队各自接了同一个模型的 API，没有统一的计量和分配机制

     这四种情况有一个共同特征：如果有完整的调用日志和预算告警，每一种都可以在造成大损失之前被发现。但大多数团队在早期根本不会把「可观测性」排进优先级，因为那个阶段还没出过事。等出了事，才发现补日志比搭日志难得多。   

     4   

     AI 系统的工程层：模型层、编排层、数据层、治理层——大多数团队只认真对待第一层   

     真正的复杂度，藏在模型之外   

     如果把一个生产级 AI 系统拆开来看，它大概分成四层：模型层决定能力边界，编排层决定任务如何拆解和调用，数据层决定系统能看到什么，治理层决定出了错如何追踪、回滚、限权。大多数团队会在模型层投入大量精力，在编排层花一些时间，然后几乎跳过数据层和治理层，直到被现实逼回来。   

     治理层看起来不性感。它不产生新功能，不提升模型效果，不能在演示里展示。但它是整个系统能否上线的底线。没有治理层，你不知道系统今天可用是因为它真的可靠，还是因为还没遇到足够极端的输入。   

     生产环境里最容易出事的地方，几乎从不是「模型给出了错误答案」。更常见的是：上游数据格式悄悄变了，模型的输出开始漂移，但没有任何监控捕捉到这件事，直到某个下游系统把错误结果放大成可见的业务故障。或者某个权限设置过于宽松，某类用户触发了不该触发的能力，造成的后果比预期严重得多。   

●失败时还能守住边界，才说明系统真的具备上线资格——而不是永远假设一切顺利   

     所以判断一个 AI 应用是否成熟，我不会先看它用了什么模型，而会先看它的工程护栏。能不能观测调用链路，能不能回放历史请求，能不能在两个版本之间做对比评测，能不能在出问题时快速定位到具体的那次调用。这些能力不耀眼，但它们的存在与否，决定了一个系统是「在生产环境里运行」还是「在生产环境里碰运气」。   

     预算不是财务问题，是工程问题   

     很多团队把 AI 成本治理理解成「控制花费」，这个理解太窄了。预算设置本质上是一种工程约束，它迫使团队在设计阶段就想清楚：这个功能的合理调用频率是多少，单次调用的 token 上限应该设在哪里，哪些场景可以用轻量模型替代，哪些场景必须用重型模型。这些问题如果不在设计阶段回答，就会在账单里以更贵的方式被回答。   

     更重要的是，预算告警是一种早期预警系统。当某个功能的调用成本突然偏离基线，背后几乎总有一个值得调查的原因：是用量真的增长了，是有什么东西在异常调用，还是提示词被改了但没人意识到影响。成本曲线是系统健康状况的一面镜子，只是大多数团队没有养成定期看它的习惯。   

     ✦ 小结   

     AI 工程真正比拼的，不是接了多少模型，而是系统在不稳定里是否依然可控。模型决定能力上限，但让模型能力变成生产能力的，是日志、权限、评测、回滚、预算告警这些看上去不性感却决定生死的工程细节。谁先把治理层做扎实，谁的系统才更像基础设施，而不是一个精心维护的演示。