PR 审查仪表盘连续六周显示绿色。机器人捕获率、评论量、开发者的“点赞”反应——一切都很稳定。然后生产环境发生了一起安全事故，事后分析指向一个缺失的空值检查（null-check），而这个检查机器人以前是能捕获到的，大约在两个月前悄然停止了。没有人更改机器人。没有人降级模型。仪表盘从未变动。但标准变了。
这是自动化代码审查在任何产品演示中都不会出现的失效模式。团队采用 LLM 审查器是为了获得一致性——每个 PR 都遵循相同的检查清单，没有资深工程师因“心情不好”而产生的波动，初级贡献者的周转速度也很快——这种一致性在最初的一个季度确实存在。然后系统提示词（system prompt）演变了，模型升级了，few-shot 库积累了，机器人开始使用不同于团队验证时的模型，根据不同的准则来审查不同的代码库。团队对“机器人能捕获什么”的心理模型衰退成了“机器人上周捕获了什么”。
审查器并非单一制品
人们很容易将 LLM 代码审查器视为一个单一的整体：即机器人。但在实践中，它是一系列独立漂移的组件栈，其中任何一个组件都可能在没有发布说明的情况下改变标准。
系统提示词是第一个层面。大多数团队每周都会对其进行迭代。在一位开发者抱怨评论内容太长后，有人添加了“更简洁一些”。在一次险些酿成大祸的事件后，有人添加了“标记缺失的测试”。有人删除了关于代码风格的条款，因为 linter 现在可以处理它了。每次修改都是一个局部合理的微小变化。其总和就是一个两个月内没有人完整读过的准则。
模型是第二个层面。提供商的权重更新现在已成常规——OpenAI、Anthropic 和 Google 都在同一个模型 ID 下发布影响行为的更新，而无需更改版本字符串。即使是固定的快照（pinned snapshots）也不是真正固定的：安全过滤器会更新，解码参数会改变，像 claude-sonnet 或 gpt-5 这样的别名会在提供商滚动新快照时自动升级。别名的订阅者所经历的每一次微小变化，都是一次既没有公告也没有分阶段发布的生产部署。
Few-shot 示例是第三个层面。在权限事故之后，有人添加了一个完美的“抓得好”示例。在一位开发者对琐碎建议（nit）表示反对后，有人添加了一个“不要标记这种风格”的示例。示例对行为的影响比指令更具侵略性，而且它们通常被检入到与系统提示词不同的文件中——或者更糟，被录入到不会在代码审查中产生 diff 的配置 UI 中。
检索增强上下文（RAG）是第四个层面。现代审查机器人会拉取仓库惯例、过去的 PR 决策和代码所有者的偏好。检索索引每晚重建。惯例文档上周二被编辑过。机器人的行为在周三发生了变化。
团队用来验证机器人的评估集（eval set）是第五个层面。评估集本身也在漂移，因为维护它的团队正是标准在发生变化的那个团队。你不能用一把正在变动的尺子来检测这把尺子是否在变动。
捕获率是错误的北极星指标
大多数 AI 代码审查工具的公开基准测试只报告一个核心数字：捕获到的预埋 Bug 百分比。最近的独立评估显示，领先者处于 50–80% 的范围内，其中 Greptile 约为 82%，Bugbot 和 Copilot 在 50% 左右，CodeRabbit 为 44%，而 Graphite 的捕获率较低，但信噪比较高。这些数字每隔几个月就会变动。
那个没有出现在基准测试页面上的数字是二阶导数：自上次机器人更新以来，捕获率变化了多少，以及变化集中在哪些类别？一个平均能捕获 80% Bug 的机器人，可能在空指针问题上捕获率达 95%，而在授权问题上仅为 40%，而一次模型升级可能会翻转这些数字，却不改变总体的捕获率。仅监控核心数字的团队看到的是一条平线。而监控每个类别捕获率的团队，会在事故发生前两周看到授权问题的捕获率崩溃。
误报率（False-positive rate）是谎言的另一半。行业标准范围在 5–15% 之间，对于一个每周审查 50 个 PR、每个 PR 有 5 条评论的团队来说，10% 的误报率意味着每周有 25 条错误标记——每月要花费超过 20 小时的调查时间来处理机器人的噪音。捕获率与误报率之间存在权衡，而一次推高其中一个指标的机器人更新，通常也会推高另一个指标。如果不在稳定的语料库上同时测量这两者，团队就无法知道机器人的校准向哪个方向移动了。
资深工程师的“撤退”问题
最具破坏性的漂移不是技术性的，而是行为上的。当 LLM 审查器上线时，团队的资深工程师开始不那么仔细地阅读 PR——并不是因为有人要求他们这样做，而是因为机器人已经审查过了，显而易见的问题已经被捕获了。一名初级工程师的 PR 以前会得到首席工程师（staff engineer）提供的 15 条评论，现在只得到一句三行的“看起来不错，已处理机器人的反馈”然后合并。
在演示中，这是一个功能，而不是 Bug。整个目的就是为了腾出资深人员的时间。问题在于，机器人的捕获率在悄然变化，而资深工程师的注意力是在“机器人是一个稳定的安全网”这一假设下被重新分配的。当机器人的标准下降时，安全网就会变薄，团队交付的代码中的资深人员监管就比组织架构图所暗示的要少。仪表盘显示绿色是因为机器人仍在评论；只是机器人评论重要事情的频率不再像以前那么高了。
就像配备了 ABS（防抱死制动系统）的驾驶员与没有 ABS 的驾驶员发生事故的方式不同一样——安全系统改变了操作者的风险预算，而新的总风险取决于系统是否真的提供了操作者当前所假设的保护。校准 LLM 审查器就是在校准团队的风险预算。一个不测量机器人捕获率的团队，就是在不测量安全网的厚度。
版本化评审准则是基础准入门槛
必须落地的原则是：将评审器视为具有版本化接口的软件。三个组件是不可协商的。
首先是针对精选语料库的回归评估。一个包含 150–300 个历史 Bug 修复 PR 的语料库——团队清楚其中的 Bug、修复方案以及应当触发的评审评论——在每次机器人更新时都会重新运行一遍。按类别划分的通过率才是真正的质量 SLI（服务水平指标）。模型升级如果导致鉴权 Bug 捕获率从 90% 降至 60%，那就是 P1 级回归，也是触发回滚的条件，无论总体得分显示如何。没有这个语料库，团队甚至没有语言来描述发生了什么变化。
其次是跟踪机器人与人类评审员随时间推移产生的分歧的校准日志。每当人类评审员在机器人未标记的 PR 上添加评论，或者将机器人的评论标记为错误并删除时，这种分歧都会记录在产生该结论的机器人版本下。净新增分歧的滚动比率就是漂移信号——与回归评估不同，它捕捉的是相对于代码库不断演进的规范的漂移，而不仅仅是一个冻结的语料库。
第三是回滚原语。机器人的完整状态——系统提示词、模型快照 ID、few-shot 库、检索索引提交——必须是一个单一的可寻址制品，当下次模型升级导致捕获率波动时，可以将其固定回已知的良好版本。“回滚到上周五的机器人”应该是一条指令。在大多数团队中，这目前需要半天的 Git 考古和半天的等待供应商支持工单。这种不对称性——漂移是自动的，回滚是手动的——正是漂移最终胜出的原因。
将评审器视为偏好每周都在漂移的初级工程师
经得起生产环境考验的心智模型是：LLM 评审员不是一个代码评审工具，而是一个偏好每周都在漂移、校准责任在团队手中的初级评审员。团队中的新入职初级工程师会得到定期的 1:1 面谈、一份书面的注意事项清单、与资深工程师进行结对评审，以及在漏掉某些问题时的复盘。默认情况下，机器人什么都得不到，但不知为何，我们却期待更稳定的输出。
评估集、校准日志和回归语料库就是机器人的 1:1 面谈。版本化评审准则是其书面检查清单。针对新机器人版本的影子运行（Shadow runs）就是结对评审。追溯到机器人漏检的事故复盘就是回顾。一个在没有这些仪式的情况下上线 LLM 评审员的团队，相当于让一个没有经理的初级评审员直接上岗，结果正如你所预料的那样：标准会随着模型和提示词在当周的变化而随意摆动。
架构上的启示是：自动化代码评审是一个校准值会衰减的测量系统。除非测量是基于稳定的外部语料库和经过跟踪的人类分歧信号，否则仪表板就在撒谎。将机器人视为静态门禁的团队会发现，尽管仪表板显示稳定，但其质量标准已经发生了偏移——而那些以对待生产数据库一样的运营严谨性来对待机器人的团队，在下周四模型更新时，其安全网依然稳固。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
