确定性软件的 PRD 模板已经演变成了一种肌肉记忆。问题陈述、用户故事、验收标准、边缘情况、成功指标、范围削减。工程师知道如何阅读它，产品经理（PM）知道如何填写它，设计师知道该从哪些章节提取原型图。这是一个被磨损得恰到好处的产物，它交付了一代又一代的 CRUD 应用、仪表盘和 SaaS 工作流。
它也没有“模型在 5% 的情况下会出错”的字段，没有“我们接受的评估（Eval）合格分”的字段，没有“当模型拒绝回答时用户会看到什么”的字段，也没有“该 PRD 锁定了哪个提示词（Prompt）版本，以及发布后允许谁进行更改”的字段。每一个按照这种模板交付的 AI 功能，都带有一份谁也没写下来的隐性契约。复盘总是让人们在遭遇挫折后才痛苦地意识到这一点。
Agent 事故发生后的第一个小时总是相似的。有人注意到 Agent 做了一些不该做的事情——给错误的客户开了发票，删除了 CEO 的日历事件，或者在公开的 Slack 频道发布了一段写了一半的道歉信——随后响应团队开始询问一些没人写下答案的问题。哪个下游系统持有审计日志？哪个值班轮换组负责该系统？该调用是否可逆，窗口期是多久？Agent 使用的凭证归谁所有，该凭证是否还允许它触及我们尚未检查的其他系统？编写 Agent 的团队很少掌握这些答案，因为答案存在于 Agent 调用的系统中，而且在发布时没人把它们统一记录在一个地方。
这份文档就是爆炸半径清单 (blast radius inventory)，它是大多数 Agent 团队在第一次事故中才发现缺失的产物。它不是安全检查表，不是工具 schema，也不是操作手册 (runbook)。它是 Agent 可以触及的每个外部系统的详尽列表，以及在该系统遭遇最糟糕状况时你所需的每一项事实。那些在没有这份清单的情况下发布 Agent 的团队，是在赌事故响应的上下文重构速度能超过爆炸蔓延的速度。随着 Agent 拥有的工具越来越多且功能越来越强大，这场赌局的胜算正变得越来越低。
拥有面孔的语音智能体并非简单的“带脸的语音助手”。它是一个同步视频 AI 系统，当人类第一次看到口型落后于音频三帧，并下意识地（即使无法准确说出原因）判定屏幕上的东西是假的时候，这种差异就显现出来了。那些构建了 300 毫秒语音流水线，然后又在末尾强行塞入一个渲染模型的纯语音团队，刚刚继承了一个他们在路线图中未曾预料到的实时多模态问题。
这个门槛并不宽松。在音视频偏移低于约 45 毫秒时，观众会认为是完美同步。一旦音频领先超过 125 毫秒或音频滞后超过 45 毫秒，大脑就会将这种不匹配标记为错误，即使观众无法指出具体原因。在一个数字人必须同时倾听、思考、说话和渲染的对话循环中——且在你和用户之间还隔着网络——音频输出和渲染面孔之间没有任何余地来容纳拙劣的衔接。
你从工具目录中注销了 lookup_account_v1，换上了 lookup_account_v2，并修改了系统提示词中的一个段落来指向新名称。测试通过了。三天后，支持工单开始提到助手“一直尝试调用不存在的东西”，或者——更令人不安的是——它用自信、看似合理的数字回答客户问题，却根本没有查询数据库。弃用并没有在通信层失败，它在规划器（planner）中失败了。
这是将工具弃用视为语法变更与将其视为行为迁移之间的差距。智能体不仅是在注册表中拥有你的函数；它还拥有数月的计划、多步配方（recipes）以及通过该函数作为检查点的 few-shot 示例。撤掉它更像是停用下游服务非正式硬编码的内部 API——只不过下游服务是一个你无法通过 grep 搜索其习惯的模型，而且当它偏好的工具消失时，它的兜底方案是编造一个。
90% 的公司员工都在使用个人 AI 账号——ChatGPT、Claude、Gemini——来完成工作，而其中 73.8% 的账号是非企业性质的。与此同时，57% 使用未经批准的 AI 工具的员工正在与其共享敏感信息：客户数据、内部文档、代码、法律草案。大多数高管认为他们的政策可以防止这种情况发生。但数据表明，实际上只有 14.4% 的团队部署的 AI 获得了全面的安全批准。
领导层认为正在发生的事情与实际发生的事情之间的差距，就是影子 AI 治理问题。
大多数公司的本能反应是下达禁令。在网络层面封禁个人聊天机器人账号、发布政策备忘录、进行年度培训，并称之为治理。这是最糟糕的应对方式——不是因为担忧是错误的，而是因为这种干预措施在没有缩小问题的同时，反而让问题变得不可见。
发布前的成本模型通常是一张精美的电子表格。它假设通过代表性的提示词（Prompt）运行模拟流量，并在测试过的缓存命中率和干净的工具调用路径下运行。但发布后的现实是，一旦功能真正开始运作，这些假设都将不复存在。模拟流量未涵盖的意图恰恰是用户最常使用的。工程团队没收到会议通知的营销活动所带来的流量，最终落在了路由树中成本最高的分支上。在第三周，使用量超过中位数 40 倍的重度用户群体才会开始出现。
这类问题在全行业内已屡见不鲜：调查显示，约 80% 的企业对 AI 成本的预测偏差超过 25%，并报告在成功发布后的几个月内，成本通常会增加 5 到 10 倍。这些数字中关键的细节是“成功”二字。失败的 AI 功能才能维持在预算内。成本偏差是由功能的成功运行驱动的，而不是因为团队做错了什么。这使得它成为一个规划产物（planning artifact）问题，而不是工程问题 —— 而大多数团队依赖的规划产物，即每月账单，其实是最糟糕的检测器。
在你的 AI 团队中，被低估最严重的资产是每周一小时，由三个人坐在房间里阅读你的产品实际对用户说了什么。不是综合评分。不是移动平均值。不是仪表盘。而是实际的对话记录。逐字逐句的输出。模型悄然形成的懒散措辞。你的分类体系中未涵盖的意图。用户尝试了三次，用三种不同的方式表达需求，而你的评估准则（eval rubric）却将这三次对话都评为“满意”。
将这一小时制度化的团队，能够建立起仪表盘永远无法呈现的 AI 功能心理模型。跳过这一步的团队，会根据看起来不错的指标发布六个月的产品，然后在下一次季度业务回顾（QBR）中发现，在无人察觉时，中位数体验已经漂移到了令人遗憾的境地。
我上个季度合作的一个团队花了六周时间构建了一个“智能文档分类器”——微调模型、评估框架、自定义 UI，以及整个生产流水线。它在周二上线。接下来的周一，一个全新的通用模型发布了，在同样的评估中，它以零样本 (zero-shot) 的方式击败了他们的微调模型，且无需任何基础设施投入。他们整个第二季度的 OKR 变成了一个仅包含一行 API 调用的包装器。路线图在 12 个月前承诺要“掌控分类技术栈”。而这项承诺在墨迹未干之前就已经错了。
这并非孤例。行业追踪器记录显示，仅在 2026 年第一季度，各大实验室就发布了 255 个模型，到 3 月份为止，平均每周约有三次意义重大的前沿模型发布。成本已经崩溃：API 定价自 GPT-3 以来下降了 97%，顶级供应商之间的差距在大多数基准测试中已缩小到统计噪声范围内。当底层技术变化如此之快时，一份为期 12 个月的特性路线图就不再是计划——而是一份你无法重新审视的赌注清单，这些赌注是根据在你交付第二个项目之前就会过时的信息做出的。
云端 AI 的策略通常建立在一个没有人明确写下来的前提之上：出站 HTTPS (outbound HTTPS)。厂商 API、托管评测器、遥测流水线、模型注册表、向量存储、仪表板 SaaS、密钥管理器——其中的每一个都静默地解析到公网上的一个域名。一旦拔掉这根电缆，整个技术栈并不会优雅降级，而是会直接崩溃。
大多数团队直到那一刻才会发现，他们的架构中存在从未考虑过的出站依赖。一个“微小”的提示词更新可能需要调用托管分类器；评估套件需要通过网络访问 LLM 评测器；可观测性代理会向后端发送数据；模型注册表从 CDN 拉取权重。这些都不是恶意的，也并不罕见。当你忽视了那根电缆时，云原生技术栈本就是这个样子的。
我建议的一个团队花了两个月时间在其 RAG 流水中不断更换 LLM。从 Claude 到 GPT，再到 Gemini，最后又换了回来。每一次更换都能让幻觉率降低几个百分点，但从未在关键指标上有所进展：他们的支持代理找到正确知识库文章的概率仍然不到 60%。他们调优的层级错了。检索器返回的是无关的文本块，而无论 LLM 多聪明，都无法根据检索器从未呈现过的文档来回答问题。
嵌入模型是 RAG 系统中决定 LLM 甚至“被允许”看到什么的部分。它描绘了语料库的几何结构——即在向量空间中，哪些文档会落在哪些查询附近。一旦这种几何结构出错，LLM 就只是一个对错误上下文侃侃而谈的自信叙述者。换一个更聪明的 LLM 通常只会让回答更显“文采”，而不会让回答更准确。
许多自称“有评估（evals）”的团队，其实际情况是：有一个仪表板，某人每周运行一次测试套件，然后将数据粘贴到没人看的 Slack 频道。评审人员批准提示词（prompt）更改时，甚至根本没看过它是否影响了测试套件，而回归问题（regression）两周后才在客户反馈单中显现。评估确实存在，但评估并未进入开发循环。
解决办法在于结构，而非意愿。只有当评估存在于变更发生的地方——即 Pull Request（PR）评论中，紧挨着代码差异（diff），并带有单个 PR 的增量变化和评审员无法忽视的回归提醒时，评估才能真正起到质量把关的作用。在其他任何地方，它们都只是表演性的产物：投入了大量精力构建，却什么也拦截不到。
评估分数连续两个季度呈上升趋势。仪表盘是一片绿色，回归测试套件自三月以来从未标记过真实的失败，团队交付 prompt 更改的速度也变快了，因为评估（eval）给出了清晰的通过/失败答案。与此同时，用户反馈的质量正在下滑。NPS 下降了 4 分，支持队列里堆满了没人标记过的失败模式，产品负责人开始质疑：如果客户这么生气，为什么评估结果看起来却这么好？
评估集没有撒谎。它正在回答六个月前它被构建时要回答的问题，针对的是发布周存在的流量分布。产品已经发生了偏移。用户群体已经发生了偏移。发布时团队未预见到的长尾用例现在占了流量的三分之一。评估集仍在衡量第一周的世界，而团队正在用昨天的产品对今天的模型求平均值。
这就是评估集腐化（eval set rot）。它是现代 AI 工程中最隐蔽的失败模式之一，而且随着评估集的变大而变得更糟，因为维护它的人将“更多用例”误认为是“更好的覆盖”。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
