你公司最昂贵的评测集 (eval set) 并不在你的代码仓库里。它藏在销售工程师六个月前整理的一份幻灯片里，外加三个以你前五大客户命名的演示账号，以及一段半记不清的脚本，上面写着“点击这里，让智能体总结上个季度，见证奇迹的时刻”。它每周运行一两次，面向价值六位数或七位数的潜在客户。AI 团队里没有人曾为它完整跑过一次。
接着，你在某个周二发布了模型迁移。周四下午 4 点，销售工程师在值班频道发消息：摘要输出现在以“当然可以！这是摘要……”开头，而不是直接进入要点；数字被拼写成了单词而非阿拉伯数字；而潜在客户 —— 一位在四周前就预约了这次会议的财富 500 强 CFO —— 刚刚询问该产品是否一直这么啰嗦。发布说明称这是一次 1.2 个百分点的评测提升 (eval lift)。
评估集（eval set）是你的 AI 团队产出的阅读量最高的工件，而你几乎肯定不知道谁在阅读它。代码库是私有的，CI 任务是内部的，文件就在 prompts/ 目录的上一级——然而，上个季度一名销售工程师为了演示抓取了六个案例，一名市场分析师将三个失败案例放进了“看看我们的系统有多健壮”的幻灯片中，客户成功部门在续约电话中逐字引用了评估通过率，而产品部门则将该文件视为 AI 团队不愿分享的隐藏规范。阅读这些案例文件的人比阅读生成它们的代码的人还要多，而 AI 团队中却没人在意。
这不仅仅是权限管理的失效。评估集与代码库的其他部分位于同一个 Git 服务器上，拥有与其他工程产物相同的访问控制。问题在于，AI 团队是唯一将评估集视为代码的群体。其他所有人都会将其视为文档、营销材料、产品规范或客户投诉日志——而这些解读中的每一项都会从同一个文件中提取不同的片段，针对不同的受众进行包装，并将其发送到 AI 团队观察不到的地方。
新员工打开入职文档。文档指向了十一个月前的一个服务架构图、一个最后更新于十月的名为 “我们的 LLM 技术栈” 的 Confluence 页面，以及一个 “我们使用的模型供应商” Notion 表格。这些文档都没有告诉他们哪个提示词是针对哪种失败模式优化的，哪些评估案例是在哪次事故后添加的，当模型从 4.5 升级到 4.6 时哪个评判模型被重新校准了，或者为什么支持代理的系统提示词有一段谁都不敢动的奇怪的三行前导内容。入职两周后，他们提交了一个 “小的提示词清理” PR，删除了这段前导内容。评估套件通过了。不到一天，生产环境的准确率下降了四个百分点。
标准的新员工入职指南 —— 阅读架构文档、配置电脑、在第二周前完成第一个 PR —— 是为加入服务端的工程师设计的。AI 工程师加入的是一种不同的制品。他们要编辑的不是某个主任工程师写的 5000 行 Go 服务；而是一个经历了 11 次事故和 17 次评估驱动重写的 30 行提示词，而这 30 行代码的意义只存在于团队中两个人的脑子里。你的入职文档无法捕捉到这些，而尝试写一份更长的文档是错误的修复方案。
十四个月前，在你公司的某个角落，一位财务总监和一位平台负责人签署了一份为期数年的算力加速器资源承诺协议。他们根据前一个季度的遥测数据构建了一个峰值负载模型，谈到了比按需计费价格低 40% 到 70% 的折扣，并锁定了集群的规格——而你现在的产品路线图必须去适应这个规格。产品团队中没有人参与过那次会议。应用工程团队中也没有人见过那份电子表格。这份合同具有法律约束力，只有在履行承诺的前提下才能享受折扣，而它买下的容量边界，现在成了产品经理们正在规划的每一个第三季度功能的隐形天花板。
大多数团队直到第二年才会察觉到这个差距：容量合同本质上是路线图决策，但它们是由那些看不见路线图的人，使用不包含路线图信息的输入数据做出的。产品“三人组”认为他们正从一个清晰的优先级积压任务中挑选功能。财务部门认为他们正在优化一个固定的预算边界。在各自的语境下他们都是正确的，而冲突则会在规划会议上显现——当架构师提议为新的助手功能使用 700 亿参数模型时，平台负责人会平静地说，集群使用率已经达到 85%，如果不挤掉其他项目，这个模型根本放不下。
你的 AI 团队所谓的“评估集”（eval set），在大多数发布 LLM 功能的公司中，其实是从生产日志中提取的真实客户对话集合。团队中没有人认为这是一个隐私事件。数据从未离开过集群。没有配置新系统。没有增加供应商。一名工程师写了一个查询，将几千条追踪记录（traces）导出到标注工具中，然后团队就开始根据这些记录对模型输出进行评分。法律团队从未听说过这件事，因为从内部来看，什么都没有改变——原本就存在于同一个数据库中的对话，现在只是被几名工程师和一个裁判模型（judge model）读取了而已。
这就是那个无人审查的隐私边界。客户向你发送消息是为了让你回答他们。他们并不是为了让你拿这些消息去衡量模型才把消息给你的。这两种用途在存储层看起来完全一样，在推理层感觉也一样，但在每一种现代隐私监管制度下，它们属于不同的处理目的——而两者之间的鸿沟，正是下一轮合规阵痛将要降临的地方。
在最近一次 prompt 变更后，你的综合评估分数上升了 1.2 个点。但在同一周，法语查询的 CSAT（客户满意度）下降了 4 个点。这两个数字都是正确的。它们之所以不一致，是因为评估集（eval set）中 88% 是英语，6% 是西班牙语，其余的是长尾语言，其中任何一种语言的流量都不足以触动汇总数据的变化。法语的性能回归就在你的数据中 —— 它只是恰好位于顶级指标（top-line metric）噪声基底以下三个小数点位。
这是我在生产级 AI 系统中看到的最常见的区域漂移（locale drift）形式：不是突然的崩溃，也不是翻译字符串的 bug，而是一种被汇总数据掩盖、并最终在支持队列中浮现的持续性能差距。当巴黎办公室的人转发一张截图时，你已经在那个回归之上又发布了两个 prompt 变更，而二分查找（bisect）的成本需要耗费三个工程师工作日。
六周前，你将 get_user_email 重命名为 lookup_contact。新名称已发布，旧的处理程序已移除，变更日志记录了这一点，你的评估集也通过了。然而上周二，一位客户支持工程师联系了你：智能体在上周的大约 3% 的工具调用中返回了错误——tool_not_found: get_user_email。那个已被重命名的名称。那个在实时系统中已经不再对外公开的名称。
先验知识（Prior）具有粘性。你的智能体正在与之对话的模型是在一个语料库上训练的，在这个语料库中，get_user_email 是询问“这个人的电子邮件是什么”的绝大多数规范方式。即使你在推理时传递的 tools 数组中仅列出了 lookup_contact，模型偶尔——在特定的上下文条件下，特别是长追踪（long traces）或错误恢复状态下——仍会退回到它记忆中的名称。直接切换并不能消除长尾效应；它只是将软故障变成了硬故障。
一个 Prompt 回归在上午 9 点上线。在 Web 应用上，工程师在午饭前就回滚了系统 Prompt，追踪日志随之恢复平静。在 iOS 上，同样的回归存在于 App Store 三周前审核通过的二进制文件中——团队现在必须在两种方案中做出选择：要么在服务端替换 Prompt（这会使商店对用户实际行为的审核失效），要么申请加急审核（这需要花费 24-48 小时，还要消耗一点与平台团队积攒的人情值）。哪种方案都不在操作手册（runbook）里。
这就是部署节奏冲突（deploy cadence collision）：Web AI 功能按照团队的时钟迭代，而移动端 AI 功能则按照平台的时钟迭代。大多数发布流程（release trains）在有人想到“Prompt 是否应该与二进制文件绑在同一辆列车上”之前就已经确定了。结果是税收在悄然累积——审核延迟、不对称的回滚延迟、在重新提交时无法通过隐私审核的未披露 AI 界面，以及一整类移动端工程师修复速度仅为 Web 同行十分之一的 AI Bug。
传呼机在凌晨 3:02 响起。你眯起眼睛盯着手机，预料着那些常见故障：数据库故障转移、CDN 边缘节点失联，或者是某个八个月没人碰过的服务出现了 500 报错峰值。然而，警报显示的是：summarizer.eval-on-traffic.helpfulness rolling-1h: 4.21 → 4.05 (Δ -0.16)。没有 HTTP 错误。没有延迟峰值。没有服务宕机。系统在过去一小时内处理的每一个请求都返回了 200，并且响应体解析正常。然而，情况显然比午夜时分变糟了，而值班轮换要求你查明原因。
这种值班任务是标准的运维手册中从未提及的。出故障的东西并没有“坏掉”——它只是退化（regress）了。你多年来追踪的错误预算是以可用性和延迟来衡量的，而触发此次报警的故障模式在两者中都不可见。报警是真实的，客户受到的影响也是真实的，而你通常的诊断循环——检查部署日志、检查依赖图、查找错误的发布版本、执行回滚——在你意识到那个“错误的发布”可能只是昨天下午 4 点上线的一个 30 行系统提示词（system-prompt）的修改时，便碰了壁。在代码审查中，那次修改看起来完全无害。
一位产品经理在 Slack 上私聊你，询问当客户要求助手取消订阅时会发生什么。你开始凭记忆输入答案，然后又自我怀疑，于是打开系统提示词读了 30 秒。你粘贴回一份摘要。他们向你道谢后继续忙别的了。三小时后，支持团队问了同样的问题。到了周四，合作伙伴负责人把提示词的截图贴进了交易审查中。
这就是“提示词即文档”（prompt-as-documentation）反模式。当你第一次意识到这种情况发生时，感觉会很棒。你花了六个星期调优的制品，现在成了产品功能的权威真理来源。产品经理在读它，支持团队在读它，销售团队在读它，甚至某个角落的设计师也在读它。你的工作成了支柱，这在以前的服务层代码中从未有过。你可以通过计算有多少不相干的人能凭记忆调出这个文件来证明这一点。
翻开任何一个运行了一年的生产系统提示词（system prompt）的 git blame，你都会发现一些工程团队不愿承认的事实：这个文件有三个作者，而他们对“变更”的定义各不相同。上个月重构指令块的工程师将提交记录标为“无功能变更，仅为了清晰起见重新排序”。每季度读一次该文件的产品经理会这样描述同样的差异：“你改写了语气——客户会察觉到的”。运行回归测试套件的 ML 工程师会说：“你搞坏了第三个少样本示例（few-shot example），从那以后评估结果（eval）就一直变红了”。
这三者都是正确的。提示词同时具备代码、规范和超参数的属性。任何长期交付 AI 功能的团队都会发现，该文件的提交历史是一场缓慢进行的三方署名权争议，CODEOWNERS 无法捕捉到这一点，diff 查看器也无法体现出来。
弃用通知邮件在一个周二的下午寄达。你的计费流水线赖以生存了 14 个月的模型现在进入了 60 天的倒计时。提示词是由一名在 3 月离职的工程师调优的。评估套件自发布以来从未重新设定基准。客户成功团队正在询问为什么两个企业账户的“AI 感觉不一样了”。没有人把这件事列入路线图，也没有人能清爽地接手，因为在你组织的心理模型中，这是一个一次性项目 —— 尽管这已经是今年的第四次了。
每个在生产环境中运行 AI 功能的团队在 18 个月内都会得出同样的感悟：基础模型提供商正以团队未曾预料的频率弃用模型，而团队的迁移应对措施始终是由于收到通知邮件而触发的被动仓促应对。解决方法不是为下一次迁移准备一个更好的操作手册 —— 这类手册已经很多了，你的团队可能也写过一个。解决方法是停止将迁移视为一个项目，而是将其视为一个经常性的运营原语。把它排进日历。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
