防止智能体靠改测试数据蒙混过关

测试全绿、用例数量没变，Agent 的补丁就修对了吗？原文提醒了一种更隐蔽的情况：代码还没修好，它先重新生成了测试读取的数据，断言于是开始验证另一套结果。作者把这种做法称为 fixture laundering，可以理解为用测试样本的变化掩盖行为变化。

作者提出的办法是给 fixture 变更分类、要求提交者声明原因，再拿旧数据检查新代码。方向值得借鉴，但示例实现存在几处关键缺口，尤其是最后一步，并没有真正证明新代码的行为保持稳定。

测试没少，为什么验证力度却变弱了

Fixture 是测试依赖的固定数据，例如汇率记录、账户信息或接口响应样本。测试代码可能一行没动，但它读取的数据变了，实际验证的内容也会跟着变。

原文举出的风险是状态字符串：断言仍然比较 x == "premium"，fixture 里的分类却被改过了。检查形式还在，判断依据已经换了。

作者认为，这类修改容易混过审查，是因为大家对源码和样本采用了不同标准：源码逐行看，400 行的 fixture 差异往往只确认一句「重新生成了吗」。而追求测试通过的 Agent，恰好可以通过重新生成数据满足这个要求。

这是一种合理的风险分析，但原文没有统计数据，不能据此认定它就是 Agent 绕过测试最常见的方式。

也不能直接禁止修改 fixture。供应商格式更新、舍入规则变化、上游 schema 新增字段，都可能要求更新样本。真正需要区分的是：数据在合理演进，还是补丁把错误结果写成了新标准。

分类加声明，能让哪些变化露出来

作者先建立两个独立工作目录，分别对应分支与主干的共同祖先，以及补丁当前版本：

git worktree add --detach /tmp/base "$(git merge-base origin/main HEAD)"
git worktree add --detach /tmp/head HEAD

这里要看第一行的 git merge-base origin/main HEAD。它选的是共同祖先，后续比较应始终使用同一个基线。

脚本 fixture_gate.py 只依赖 Python 标准库，默认扫描 tests/fixtures，读取文件字节，计算 SHA-256，并保留十六进制结果的前 16 位。哈希不同，再分析内容，而不是依赖文本 diff 判断变化类型。

虽然正文称为四类风险，代码实际上输出五种类别：

• ADDED 表示新增文件，直接接受，不强制声明。
• REMOVED 表示删除文件，无论是否声明都阻断。
• SHAPE_CHANGE 表示结构变化，例如对象键或数组长度改变。
• TOLERANCE_DRIFT 表示没有发现超出容差的值变化。
• SEMANTIC_REWRITE 表示字符串、分类或超出容差的数字发生变化。

数字比较使用 math.isclose，同时设置 rel_tol=eps 和 abs_tol=eps，默认 eps=1e-6。因此，TOLERANCE_DRIFT 也会包含只调整 JSON 空白、缩进或键顺序的情况，不能把它直接理解为「确认发生了合理舍入」。

提交者需要写入 Fixture-Change: trailer，也就是提交说明末尾的结构化声明。原文示例用 TOLERANCE_DRIFT 声明汇率变化，理由是 vendor spec v3 rounds to 6dp；用 SHAPE_CHANGE 声明账户结构变化，理由是上游新增 region。

脚本通过 --base-tree、--head-tree、--fixtures、--message-file 和 --report 接收输入，默认生成 fixture-report.json。除新增文件外，分类与声明不一致、缺少非空理由，都会阻断，并以退出码 1 结束。

这道检查证明的是声明与数据变化一致，不能证明修改合理。

代码只检查理由是否非空，所以写一个 update 仍然能通过。二进制或无法解析的文件回退到 SEMANTIC_REWRITE，但声明匹配后也能通过；原文末尾所说的「每次变化都会阻断」，并不符合实际分支逻辑。

此外，trailer 示例路径带有 tests/fixtures/，脚本查找声明时却使用相对于 fixture 根目录的路径，例如 rates.json。原样照搬，声明无法匹配。/tmp/head/.git/COMMIT_EDITMSG 也不能直接假定有效，因为 worktree 中的 .git 通常是指向实际 Git 目录的文件。

用旧数据跑新代码，关键在于真的执行新代码

第二层检查试图拆开两个变量：保留补丁源码，把 fixture 换回基线版本，再执行固定的探针测试。作者给出的命令是：

BASE=$(git rev-parse origin/main)
git archive "$BASE" tests/fixtures | tar -x -C /tmp/head
python -m pytest probes/ -q -p no:cacheprovider --maxfail=1

要留意第一行：这里改用 origin/main，与前面选取的 merge base 不一定相同。第三行也没有切换到 /tmp/head，实际测试目录取决于当前 shell 所在位置。

-p no:cacheprovider 禁用 pytest 缓存插件，--maxfail=1 在首次失败后停止。这些参数能控制执行方式，却不能保证测试真的覆盖了补丁行为。

作者设计了三种 fixture 契约检查：

• 通过 len(pairs) == len(set(pairs)) 检查汇率交易对是否重复。
• 检查每条记录至少保留 pair、value、as_of 字段。
• 检查 value 是 int 或 float，并且大于 0。

问题在于，示例探针只是用 json.loads 读取固定文件，没有调用补丁里的汇率加载器，也没有执行其他业务代码。换回旧 fixture 后，它验证的仍然只是旧数据。

只读旧 fixture 的探针，无法证明新代码没有改变行为。

要实现作者描述的目标，探针必须让 head 版本的业务代码处理 base 版本的数据，再检查输出契约。否则，即使测试通过，也没有回答「补丁是否靠重写样本掩盖回归」。

还有一个文件覆盖问题：git archive 解包会覆盖已有路径，却不会自动删除 head 新增的 fixture。若要固定整棵数据目录，还需要处理新增文件残留。

作者建议探针失败后，为 PR 补充 Behavior-Change 说明，并交给理解业务的人审查。这个流程有价值，但失败只能提示需要调查，不能直接证明提交者有意掩盖问题。

我的判断

我赞同作者把 fixture 变更提升为正式审查对象。相比一律禁止更新数据，分类声明更能容纳正常演进；相比只看测试是否全绿，它又能把容易被略过的变化摆到审查者面前。

但原文没有提供真实项目的拦截率、误报率或对照实验。唯一展示的是合成补丁：一个 TOLERANCE_DRIFT 被接受，一个 SEMANTIC_REWRITE 被阻断。因此，这是一份值得修正后尝试的工程方案，还不是经过充分验证的通用门禁。

分类器也需要补边界。它在确认新值类型之前，就可能对字典调用 set(y)、对列表调用 len(y)，遇到容器被替换成标量时可能报错，未必能按预期归类。

适用范围同样有限。Golden-file 测试把 fixture 直接当作期望输出，修改它就是修改断言，应采用独立的人审流程。包含时间戳、生成 UUID 的数据要先归一化，否则报告会持续产生噪声。数万文件的目录存在哈希开销；只扫描补丁涉及目录可以减负，但必须接受覆盖范围缩小。

作者还建议把不稳定测试的隔离记录绑定到 (test_id, fixture_hash)。数据一变，旧隔离理由就自动失效；解除隔离则依赖固定数量的不同失败 seed，以及确定性重放通过。这个思路比只记日期更容易追溯证据，但原文没有给出 seed 数量或完整实现。

最后，文章明确披露了 MonkeyCode 产品推广关系。免费模型起草分类器、免费服务器运行临时探针，只是作者报告的使用方式，没有性能或效果对照，不能作为选择产品的依据。

能拿来做什么

• 对提交了 JSON fixture 的前端或 Node 项目，可以先在 PR 中输出变更分类报告，让审查者看到哪些字段、分类或数值契约发生了变化，再决定是否设为阻断条件。
• 对接口适配器、数据解析器和状态映射逻辑，应让新代码实际处理旧样本，并断言业务输出；只检查 JSON 字段齐全，覆盖不到这类回归。
• 给 AI 编程任务增加明确交付要求：修改 fixture 时说明分类和业务原因，涉及行为变化时补充 Behavior-Change，让解释随补丁一起进入审查。
• 接入作者脚本前，先修正基线、路径匹配、worktree 提交说明读取和类型检查问题。运行时生成且不入库的 fixture、单文件脚本、原型项目，以及无法确定稳定基线的仓库，可以跳过这套门禁。