AI编码时代：用评估门禁取代人工代码审查

核心矛盾：代码写得比谁都读得快

当Claude Code、Codex这类编码智能体承担了大部分代码编写工作后，一个被长期忽视的问题浮出水面：如何在代码生成速度远超任何人阅读速度的情况下保证质量？

根据Zoroval团队的实践数据，智能体生成的PR中位数仅改动133行，看似不大，但大约每八个变更就有一个会改动超过1000行代码。更棘手的是，一个入职第一周的新工程师就能提交一个修改prompt或上下文构造器的PR——写出这个改动变得轻而易举，但判断它对产品的实际影响依然和过去一样困难。

面对这一矛盾，有两个显而易见却都会失败的答案。答案一：逐行审查每一处代码。 这是几十年来代码审查的黄金准则，但没有人能每天数次认真审查上千行智能体代码，于是人们开始"扫一眼"。扫读式审查看起来像审查，实际捕获的问题远比你以为的少，还让审查者成了整个系统最慢的环节。答案二：阻塞PR直到有人有空审查。 这很安全，却会慢慢拖垮团队——如果每个变更都要等上几天，你其实根本没在使用智能体编码，白白放弃了它带来的速度优势。

Zoroval选择了第三条路：针对那些会改变LLM行为的变更，建立一套"评估门禁"机制，因为这类变更恰恰是阅读代码无法检验的。

一次静默故障：上下文构造器如何悄悄搞垮了裁判模型

整套机制的起源是一次真实事故。Zoroval的产品使用"LLM-as-a-judge"（模型作为裁判）：一个模型读取对话日志（traces），判断某个已命名的"失败模式"是否存在，客户的监控完全依赖这个裁判。

7月13日，这个裁判漏掉了所有已经被人工确认的失败。监控任务运行了1138次裁判调用，而黄金数据集里有四个人工确认过的失败案例，裁判对这四个全部回答"否"，而整个运行过程没有报任何错误。

问题在于：模型没变，prompt模板也没变。团队的评估只在这两者之一发生变化时才触发，所以没人跑过黄金数据集。真正的根因是上下文构造器——那段负责组装模型所见内容的代码。它和模型、prompt一样是智能系统的组成部分，但修改它从不触发评估。

这暴露了LLM系统在CI中的核心问题：代码测试只检查输出的"形状"（比如是否是字段正确的合法JSON），却检查不了"判断"。一个围绕模型的代码改动可以通过所有测试，却彻底改变模型的结论。而有了编码智能体，这类改动随时在发生，往往出现在一个本不该碰模型的PR里。团队需要的，是一道知道"哪些文件会改变模型行为"、并拒绝仅凭绿灯测试就放行它们的评估门禁。

LLM-as-a-judge（模型作裁判）是一种用语言模型自动评估另一模型或系统输出质量的方法。由于人工标注成本高、速度慢，LLM-as-a-judge被广泛用于监控、测试和评估流水线：裁判模型接收对话记录或模型输出，按预设标准判断质量、检测失败模式或打分。其核心脆弱性在于裁判本身也是一个模型，受prompt、上下文、模型版本等因素影响，而这些影响往往不会以报错形式显现，只会悄悄改变判断结果——正如文中事故所示。

上下文构造器（context constructor）是指在将数据送入模型前负责组装、格式化、过滤输入内容的代码层。它决定了模型最终"看到"什么：哪些对话轮次被截断、检索到的文档如何排列、元数据以何种格式注入。上下文构造器的改动不影响模型权重、不改动prompt模板，却能从根本上改变模型的推理前提，是LLM系统中最容易被常规测试忽略的行为变更来源之一。

核心原则：审查证据，而非代码行

智能体让变更变得廉价。我们要求这些变更进入生产前必须有当下的证据。

这句话是整套LLMOps的核心。团队并不试图阻止LLM犯错——无论是编写代码的智能体还是产品内的模型都会犯错——而是构建一个让错误"廉价、可见、在触达用户前被捕获"的环境。贯穿始终的有四个理念：

• 审查证据，而非代码行。 人类依然做决策，但依据的是测试结果、评估分数、指纹和精确的commit SHA，而不是一个1000行的diff。安全、架构以及变更间的交互仍需人工把关。
• 规则归人所有。 定义门禁的策略文件很小，修改它需要所有者（资深工程师或ML工程师）审查，而门禁负责把这些规则应用到每一个变更。
• 门禁与智能体对话。 当门禁失败时，它的输出会说明改了什么、为何重要、如何修复，让编码智能体能自行解决。大多数CI输出是写给人看的，而这里的输出是写给下一轮智能体的。
• 审批绑定到精确内容。 每次审批都指向一个指纹或SHA，只要多改一行，审批就自动失效，无需任何人记着去重新检查。

评估门禁在CI中如何运作

这道被称为"Intelligence Change Gate"的检查，是整篇文章最关键的构想，它分五步运作。

第一步：声明受保护范围

一个策略文件列出所有可能改变模型行为的路径——prompt、上下文构造器、模型设置、检索代码等——并按它们影响的LLM组件（策略中称为stage，如monitoring）分组。值得关注的设计是line_patterns字段：设置文件改动频繁，门禁只在真正设置监控模型或推理强度的那一行发生变化时触发，而不会在有人添加数据库超时时误报。

第二步：对精确变更做指纹

每个PR上，门禁找出改动的受保护文件，仅取这些文件的diff，连同受影响的stage和规则一起用SHA-256哈希，生成变更指纹。如果有人改动了同一文件、你rebase之后指纹变了，就需要新的证据——这是刻意为之，因为你测量过的代码已经不再是即将合并的代码。

SHA-256是一种密码哈希函数，对任意输入生成固定长度（256位）的摘要字符串。其关键特性是确定性（相同输入永远产生相同哈希）和雪崩效应（输入哪怕只改变一个字节，输出哈希会完全不同）。在这里，将受保护文件的diff内容做SHA-256哈希，意味着只要任何一行受保护代码发生变化，指纹就会变化，旧的评估报告自动与新指纹不匹配。这使得"证据绑定到精确代码"成为一个可由机器自动强制执行的属性，而不依赖工程师的人工记忆或流程纪律。

第三步：要求匹配该指纹的评估报告

如果受保护文件发生变化，PR必须包含一份评估报告：一个小的JSON清单，列明指纹、黄金数据集、基线、候选版本以及每个受影响stage的结果。门禁不信任报告里的passed字段，而是从数字中重新计算是否通过。原始数据保持私密，报告只通过哈希指向它，不会有任何客户数据进入仓库。

第四步：让证据自动过期

这是团队最得意的设计。由于指纹覆盖的是精确的受保护diff，评估跑完后对受保护文件的任何编辑——无论来自人还是智能体——都会改变指纹，旧报告不再匹配，门禁再次失败。对文档和测试的改动不影响指纹，所以你仍可修正拼写错误。没人需要记住"这份证据是针对旧版本的"，门禁替你记住。

第五步：保留可见的破窗式越权

有时你会有意识地接受某种权衡。比如某个失败模式的目标从精确率转向召回率，评估会显示精确率下降。此时与其调阈值让它看起来像通过，不如将其记录为一个决策。门禁允许所有者越权，但这个越权是针对单个PR编号的独立文件，必须指明精确指纹、附带理由和风险说明、来自列表内的审批人、七天后过期，并且在CI中始终显示为owner_override而非pass。团队的staging分支上有43份评估报告，其中9个PR使用了所有者越权。

智能体看到什么？ 当门禁失败时，它打印的输出本质是一份"工单"：智能体知道该评估哪个stage、哪些文件导致失败、该把哪个指纹写进评估报告。有时智能体发现自己根本不该碰那个文件，于是回退那部分改动，门禁便无需评估直接通过——这也让门禁顺带捕获了意外的范围蔓延和被误解的需求。

通过评估门禁证明不了什么

门禁不仅拦截坏变更，也让好变更变得"敢于尝试"。

团队测试过一个便宜约六倍的裁判模型，它在第一轮检查中找到了黄金数据集里所有已知失败，顺利通过。但在更广泛的对比中，它在某个失败模式上说"是"的频率远高于现有裁判——因为它丢掉了定义的一部分，把本不在范围内的案例也标记了。

第一轮检查之所以漏掉这点，是因为黄金数据集只有正例。这样的数据集衡量的是召回率（模型能否找到失败），却从不衡量精确率（它说"是"是否可信）。一个过度说"是"的模型根本不可能在这种数据集上失败。

后来，这个便宜模型在一份同时包含正例和负例的评估通过后进入生产，将监控成本削减了约83%。它的评估报告自带局限说明：某个失败模式没有正例，因此召回率仍未经检验。门禁并不设计这个样本，它只确保"针对精确变更的证据存在，且局限写在旁边"，由人决定证据必须覆盖什么——因为LLM变更会以单个数字无法展现的方式失败。

这也划清了门禁能证明与不能证明的边界。它能验证受保护文件确实变化、报告匹配精确diff、每个stage有质量结果、样本达到策略规定的最小规模、运行足够新、各结果达到报告中的阈值；但它无法验证评估真的跑过、数字是否真实、阈值是否合理、黄金数据集是否覆盖了真正重要的失败模式。因此，每份评估报告仍必须有人工审查。

围绕门禁的四层LLMOps流水线

评估门禁之所以奏效，依赖于它周围的整套机制。团队的门禁分布在四层——本地、PR、staging、生产——一个变更必须全部通过。

本地层最便宜，智能体在提交PR前就能捕获错误。仓库根目录有一个AGENTS.md，Claude Code、Codex等智能体在开始工作前会加载它，内容描述的是边界而非代码风格，例如"develop是staging、main是生产""永远不要推送到main、永远不要绕过失败的守卫"。这些规则刻意写得简短而绝对，因为经验表明智能体对清晰规则的遵守远比对细腻段落可靠。每个智能体还在各自独立的git worktree中工作，避免并行智能体互相覆盖。

PR层运行Product CI。除了常规的后端测试、前端与数据库契约检查外，有两部分专属LLM系统：上述评估门禁，以及针对模型周边代码的回归评估。回归评估在每个PR上都跑，用冻结的合成案例和录制的LLM输入输出，不发任何真实模型调用就能快速、免费地验证模型周边代码行为是否一致。此外还需保护门禁本身——能编辑门禁的智能体就能关掉它，所以要给策略、脚本、工作流、评估报告和越权文件夹设置CODEOWNERS所有者，并在GitHub开启"要求代码所有者审查"和"必需状态检查"。一个小团队陷阱：GitHub不允许PR作者审批自己的PR，若智能体从你的账号开PR，就需要给它单独的账号。

Staging与生产层的铁律是：合并到staging永远不授权生产发布。 团队从不把develop合并进main，生产是唯一每次都需要人类决策的地方。发布采用选择性方式：所有者指定要发布的PR，发布分支从当前main起始，只带这些PR的squash提交；准备发布的智能体会贴出一页"证据包"，包含PR号、精确head SHA、迁移、评估报告、配置变更、LLM成本影响和测试结果。审批是一条绑定精确commit的PR评论，任何新提交都会使其失效。这里，LLM成本是正确性的一部分——一个让账单翻倍的变更即便每个答案都对，也是一种回归。

Git worktree是Git提供的一项功能，允许同一个仓库在文件系统的多个目录中同时检出不同分支，每个目录拥有独立的工作区和暂存区，但共享同一个.git对象库。在多智能体并行工作的场景中，若所有智能体共用同一个工作目录，它们的文件修改和暂存操作会互相干扰、覆盖。通过为每个智能体分配独立的worktree，可以让它们在逻辑上隔离的沙箱内并行操作，既避免冲突，又无需为每个任务完整克隆一份仓库，节省磁盘空间和初始化时间。

代价与盲区

团队坦诚列出了局限：它带来摩擦（改一行上下文构造器可能也要跑一次实时评估）；证据的质量取决于黄金数据集（50个案例可能漏掉罕见失败）；证据是自报的（CI从不接触私密数据，只检查哈希格式）；策略可能不完整（未列入的文件门禁完全看不见）；它不替代安全、架构的人工审查，也不替代生产监控。更重要的是，它只在小团队验证过，尚未在五十人规模的组织中跑过。

如果要上手，不必一次做全套：先从真实traces构建一个同时含正负例的小型黄金数据集，列出能改变模型行为的文件（务必包含上下文构造器），加一道当这些文件变化时就失败的必需CI检查，在PR模板里加一行LLM成本影响，再把一条CI失败信息改写成智能体能据以行动的工单。Zoroval已将这套门禁打包为开源的agent skill。