你的智能体通过了每一项测试。CI 流水线显示绿色。你发布了它。
一周后，一位用户报告说他们的批量导出任务悄无声息地只返回了 200 条记录，而不是 14,000 条。智能体访问了分页 API 的第一页，得到了一个干净的响应，以为没有更多内容了，然后就继续下一步了。你的模拟（Mock）一次性返回了全部 200 个条目。而真实的 API 从未告诉智能体还有另外 70 页。
这不是模型的失败。模型的推理是正确的。这是测试基础设施的失败 —— 这种现象在团队构建和测试智能体系统（agentic systems）时非常普遍。
大多数 AI 产品复盘都聚焦于同一个故事：模型错了，用户发现了，信任瓦解了。修复方法显而易见——提高准确率。但有一种更隐蔽的失败模式，复盘很少能捕捉到，因为标准的准确率指标无法反映它：模型是正确的，但原因却是错误的，而那些检查了推理逻辑的高级用户再也没有回来。
称之为“过度声明陷阱”（overclaiming trap）。在这种失败模式下，正确的最终答案是由捏造的、事后修补的或结构不合理的推理链支撑的。它比普通的错误更危险，因为它看起来像是成功，直到你最专业的用户开始悄悄离开。
一个团队上线了一条 JSON 提取流水线。在开发环境中运行完美：98% 的准确率、干净的结构化输出、可预测的 token 数量。他们推送到生产环境后，模型开始产生多余的空白字符，JSON 解析器开始报错，API 账单是原型阶段估算的 2.3 倍。模型没变。提示词没变。
是 tokenizer 变了——更准确地说，他们对它的假设从一开始就是错的。
分词（Tokenization）是你的输入经历的第一次转换，却是工程师在调试时最后才想到要检查的地方。大多数团队把它当作已解决的问题：文本进去，token 出来，模型完成其工作。但字节对编码（BPE，Byte Pair Encoding）——大多数生产级 LLM 背后的分词算法——在结构化输出生成、前缀缓存、成本估算和多语言部署中做出的决策，会产生连锁影响。一旦你知道该往哪里看，这些影响完全是可以预测的。
你上线了一个 AI 功能。模型表现良好——你量化过它。精确率达 91%，召回率扎实，P99 延迟低于 400ms。三个月后，产品分析给出了一个令人沮丧的数字：高级用户已将其完全关闭，而另一批用户则不加修改地接受每一条建议，包括那些明显错误的。
这就是信任校准差距。它不是模型问题，而是设计问题——而且比大多数 AI 产品团队愿意承认的更为普遍。
2025 年 4 月，OpenAI 为 GPT-4o 发布了一次系统提示词更新。几小时内，1.8 亿用户发现 ChatGPT 变得谄媚奉承。这一故障并未被监控系统发现，而是由 Twitter 曝光的。回滚过程耗时三天。
这次事件揭示了 AI 行业一直在默默回避的一个事实：提示词更改就是生产部署。然而，大多数团队却将其视为普通的配置文件修改。
AI 部署的核心问题在于，你部署的不是单一内容，而是四个要素：模型权重、提示词文本、工具 Schema 以及它们共同依赖的上下文结构。每一个要素都可能独立发生偏移，每一个都可以部分发布。与导致崩溃的 API 接口不同，AI 的故障通常是概率性的、渐进的，并且在影响到大部分流量之前往往是不可见的。
这本质上是披着 AI 外衣的分布式系统一致性问题。
每个生产环境的智能体团队最终都会构建同一个东西：一个无限增长的记忆存储、悄然退化的检索性能，以及在用户报告智能体引用了他们的旧工作、已弃用的 API 或三个月前取消的项目后，一场疯狂的冲刺来添加遗忘功能。业界已经在赋予智能体记忆上投入了巨大的努力。更困难的工程问题——对记忆进行垃圾回收——才是真正的生产可靠性所在。
与软件垃圾回收的类比不仅仅是隐喻。智能体记忆系统面临着同样的根本张力：你需要回收资源（上下文预算、检索相关性），同时不能销毁仍然可达（语义上与未来查询相关）的数据。解决这个问题的算法与你的运行时已经使用的算法惊人地相似。
你的代码审查清单是为一个以分号放错位置或忘记空值检查为主要缺陷的世界而设计的。那个世界已经不存在了。AI 生成的代码很少有拼写错误，几乎总能编译通过。但它正在以你的审查流程从未设计来捕获的方式，悄悄地侵蚀你的代码库。
对数十万个 GitHub Pull Request 的分析表明，AI 生成的代码产生的问题是人类编写代码的 1.7 倍——每个 PR 大约 10.8 个问题，而人类为 6.5 个。但缺陷的分布发生了根本性转变：逻辑错误增加了 75%，性能问题出现的频率几乎是之前的 8 倍，安全漏洞多了 1.5 到 2 倍。最重要的缺陷恰恰是你传统审查机制最容易遗漏的。
生产环境中的 LLM 给出了一个错误的答案。一张支持工单到来。你翻查日志，只看到提示词、补全内容和延迟指标——却没有任何信息说明检索系统到底拉取了哪些文档、哪些块进入了上下文窗口，或者模型在综合答案时最依赖的是哪段内容。你只能像做考古一样：重新对一个已经更新过的语料库跑一次查询，祈祷结果还和之前一样，同时不知道问题究竟出在检索、分块、文档本身还是模型推理上。
这就是数据溯源的缺口，而大多数 AI 团队直到掉进去才意识到它的存在。
Andrej Karpathy 直言不讳：AI 实验室正在"过拟合"Arena 排行榜。某头部实验室在公开发布前私下评估了 27 个模型变体，只发布了表现最佳的那个。研究人员估计，仅凭选择性提交就可以将排行榜分数人为提高多达 112%。所有人都视为基准真相的众包评估系统已经成为博弈目标——一旦成为目标，它就不再是有效的衡量标准了。
这就是古德哈特定律在发挥作用：当一个指标成为目标时，它就不再是好的指标。这一规律在经济学和政策领域已被充分理解了数十年。在 LLM 工程中，它正在实时摧毁评估套件，而构建这些套件的团队往往浑然不知。
大多数采用 AI 编程智能体的团队，都会把第一周花在争论使用哪个模型上。他们用人为设计的例子对 Opus、Sonnet 和 GPT-4o 进行基准测试，痴迷于排行榜，最终选出一个。然后他们花接下来三个月纳闷，为什么智能体一直在重建错误的抽象、忽视他们的测试策略，以及反复询问该用哪个包管理器。
问题不在模型。问题在上下文文件。
每款 AI 编程工具——Claude Code、Cursor、GitHub Copilot、Windsurf——都会在每次会话开始时读取一个项目专属的 Markdown 文件。这些文件有不同的名字：CLAUDE.md、.cursor/rules/、.github/copilot-instructions.md、AGENTS.md。但它们的目的相同：告诉智能体那些无法通过阅读代码推断出来的信息。这个文件的质量如今比背后的模型更可靠地预测输出质量。然而大多数团队只写一次、写得很糟，然后再也不碰。
大多数采用 AI 编程工具的团队都会遇到同样的瓶颈。第一个月看起来像是成功案例：PR 吞吐量上升，Sprint 速率在攀升，工程经理正在制作幻灯片准备向领导层汇报。到了第三个月，事情悄然发生了变化。事故率开始回升。资深工程师在代码审查上花费了更多时间。一个简单的 Bug 修复现在需要理解一段团队中根本没人写过的代码。生产力的提升已经消失殆尽 —— 但衡量体系从未捕捉到这一点。
问题在于，大多数团队最先关注的指标 —— 生成的代码行数、合并的 PR 数量、消耗的故事点数 —— 对于 AI 辅助开发来说是错误的衡量单位。它们衡量的是产出代码的成本，而不是持有代码的成本。AI 让产出几乎变得免费，却让持有成本保持不变。
每个部署 LLM 路由的团队都是同样的起步方式：按价格排列模型，将简单查询发送给便宜的模型，复杂查询发送给昂贵的模型，然后庆祝成本降低了 60%。六周后，有人发现合同分析准确率从 94% 降到了 79%，编码助手开始虚构不存在的 API 端点，复杂支持工单的客户满意度直线下滑——而路由仪表盘上仍然显示"质量保持 95%"。
问题不在于路由本身。问题在于，仅优化成本的路由将所有质量下降视为等同，而实际上你降级的那些查询恰恰是质量最重要的那些。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
