AI代码评审的隐患：模型故障切换为何会误批补丁

当AI代理在CI流程中负责代码评审时，一个看似无害的工程细节可能让系统批准一个从未真正被评审过的补丁。这篇实验室复盘记录了一个具体的失败场景：模型发生故障切换（failover）后，旧的评估收据（eval receipt）被复用，导致门禁放行了一个新模型从未打分的改动。

问题的本质：收据与评审身份脱钩

核心结论可以一句话概括：一张评估收据必须绑定它所对应的 diff、prompt、模型以及工作区代次（workspace generation）。仅凭 diff 哈希匹配，并不等于完成了一次有效评审。

问题的触发链条非常典型。实验在一个被回收复用的工作区里跑了两个代号模型（lab-model-a 与 lab-model-b）。流程大致是：先把一张旧收据复制进被回收的任务目录，模型 A 写下一张针对该 diff 的 pass 收据；随后模型 A 掉线，重试阶段选中了模型 B；而模型 B 发现磁盘上 receipt.json 已经存在，便直接跳过了打分环节。

这里的关键在于：故障切换把“文件存在”当成了“评审已完成”。磁盘上残留的收据是上一次尝试（attempt）的产物，但新模型并没有重新评估。这不是缓存键失效，也不是锁文件重试的问题——那张收据对另一次尝试而言是完全合法的，它只是不属于当前这次合并。

工作区代次（workspace generation） 是本文方案的核心概念之一，值得单独说明。在 CI 系统中，同一台服务器或同一个目录路径可能被多个任务先后复用——前一个任务失败后，系统会清理（或不清理）现场，再把同样的目录分配给下一个任务。"工作区代次"就是为了区分这些"前世今生"而引入的单调递增或随机生成的标识符：每当一块工作区被重新分配给新任务，就铸造一个新的代次值，任何遗留文件因为携带旧代次而在校验时失效。这一机制与数据库中的乐观锁版本号（optimistic lock version）在原理上高度相似——它不阻止旧数据写入磁盘，但保证旧数据在读取时会被识别并拒绝。没有工作区代次，diff 哈希相同的两次任务就无法在文件系统层面被区分，从而为收据复用创造了条件。

为什么“朴素门禁”会被骗过

原文给出的朴素检查逻辑极其简单，也正因如此而危险：

def naive_accept(receipt, diff_sha256):
    return receipt.get('diff_sha256') == diff_sha256 and receipt.get('verdict') == 'pass'

这个函数只比较了一个存储哈希就停止查找。diff 字节匹配，于是返回成功。它完全忽略了模型 id、工作区代次，也没有检查是否存储了任何评审理由（reasons）。在一台被回收复用的服务器上，这种单字段检查太容易被欺骗。

原文梳理了几个促成该失败的叠加因素，值得工程团队对照自查：收据使用了所有尝试共享的固定文件名；工作区复用保留了故障切换前的旧评分文件；门禁信任 diff 哈希却不校验打分者身份；代理和门禁共用同一个可写服务器目录；没有 attempt id 把任务日志与被批准的收据关联起来；清理逻辑只在成功时运行，于是崩溃会留下旧文件。

持久化修复：绑定身份而非延长超时

修复思路不是让模型“更努力”，而是拒绝为来自另一次尝试的收据背书。原文提供了一个名为 bind_receipt.py 的程序（目标环境为 Python 3.9 及以上的常规 CI 镜像），它把收据与 diff、prompt、model、workspace generation 四个字段严格绑定。

其核心机制是：引导阶段（bootstrap）在任何代理启动之前就铸造出工作区代次；尝试开始时捕获预期的模型 id；门禁重新计算哈希并逐一比对每个绑定字段。任何字段缺失都视为任务失败，而不是软性警告（soft warning）。

程序提供三个子命令：write（写收据）、verify（校验）和 selftest（自检）。原文特别强调，在接入 CI 之前必须先跑自检：

python3 bind_receipt.py selftest

自检失败意味着绑定器本身就不可信。校验命令会打印不匹配的字段名并以退出码 1 返回，一旦出现字段不匹配就直接让任务失败、不做重试。

决策表：朴素门禁 vs 绑定门禁

原文用一张决策表清晰对比了两种门禁在各种状态下的行为：

观察到的状态	朴素门禁	绑定门禁
相同 diff，新模型 id	接受	拒绝
相同 diff，新工作区代次	接受	拒绝
相同身份，verdict 为 fail	拒绝	拒绝
相同身份，reasons 为空	接受	拒绝
打分后 diff 字节被改动	拒绝	拒绝
收据缺失	取决于脚本	拒绝
全新匹配收据且含 reasons	接受	接受

只有最后一行才是有效的合并路径，其余所有观察状态都保持关闭并阻止合并。可以看到，朴素门禁在“新模型 id”“新工作区代次”“空 reasons”这几种本应拦截的场景下全部误放行——这正是本次事故的根源。

引导规则与自由服务器的作业契约

原文反复强调一个原则：这些规则要落在任务镜像（job image）里，而不是写进 prompt。因为处于被评审状态的代理有能力编辑 prompt 文本。

具体引导规则包括：在 bootstrap 中铸造 WORKSPACE_GEN 且先于代理进程启动；模型选定后导出 MODEL_ID 并冻结该值；每张收据按 attempt id 命名目录存放；忽略上一代次遗留的任何收据路径；verify 返回非零即让任务失败且不重试；合并前比对任务日志中的模型 id 与收据；把收据缺失视为失败而非跳过检查。

在所谓“自由服务器”（可复用、可切换打分者的环境）上，bootstrap 还应当擦除代理可写的评分路径——即便绑定器已经存在，擦除依然必要，因为脏目录会藏匿代理可能误信的其他文件。四个绑定值应作为命令行参数传入，而非 prompt 文本。

为什么规则必须在任务镜像（job image）而非 prompt 中 这一点在安全工程中有对应的经典原则：策略执行点（policy enforcement point）必须位于被策略约束的主体无法修改的位置。Prompt 本质上是代理在运行时可以读取、引用甚至在某些工具调用场景下间接影响的文本；而任务镜像是在代理进程启动之前由 CI 平台固化的环境，代理无法在运行时修改镜像内已编译或已安装的二进制文件。这与操作系统安全中"不能让用户态进程修改内核"的道理一脉相承。将门禁逻辑写进镜像，实质上是把信任锚（trust anchor）上移到了代理控制范围之外，从而使"代理通过改写评审规则来为自己放行"这一攻击路径在结构上不可行，而非仅靠约定或提示词来规范行为。

必须认清的局限性

这篇复盘难得地坦诚列出了方法边界，这比方案本身更值得工程团队重视。

哈希不衡量评审质量。一张匹配的收据仍可能描述的是对 diff 的一次草率阅读——门禁只检查身份和理由的存在性。一个敌意的运行器（hostile runner）可以伪造文件里的每一个绑定字段，所以绑定器不是面向模型厂商的证明服务（attestation service），必须搭配团队已经信任的运行器使用。

工作区代次必须来自 bootstrap 而非代理。如果让代理自己铸造该值，它就能改写尝试历史，门禁随后会为代理自编的“故事”背书。此外，自检根本不调用远程模型，绿色自检并不等于补丁已被评审。

原文也明确给出了不适合采用此方案的场景：当团队需要厂商签名的模型运行证明时（本脚本无法提供）；当缺乏独立发布策略时（绑定器是 CI 检查，不是发布审批）；当工作区在任务后总是被销毁、且模型 id 在尝试间不会变化时（更简单的 diff 哈希可能就够了）；以及用于配额规划、成本预测或硬件选型时（这些运营数字应查厂商文档）。

工程启示

随着 AI 代理越来越多地嵌入 CI 流程并承担评审职责，“文件存在即任务完成”这类隐性假设会成为真实的安全漏洞。这篇复盘的价值不在于那段 Python 代码本身，而在于它点明了一个被普遍忽视的失败类别：评审产物与评审身份的脱钩。

需要说明的是，原文披露该文章是 MonkeyCode 产品外联内容的一部分，文中的“免费模型访问”和“免费服务器”均为运营方提供的前提假设，且作者明确表示未验证任何可用性细节。但即便抛开这些商业背景，其核心工程教训依然成立：任何会回收工作区的宿主都存在同样的漏洞。把绑定器放进任务镜像、在字段不匹配时阻止合并，是一个成本极低、收益明确的防御措施。

一句话总结其方法论：在故障切换能够重放旧评分之前就绑定收据，在代理进程之外铸造工作区代次，当模型、prompt 或 diff 不匹配时一律失败关闭。