AI 代码审查 Gate 本身是未经测试的代码

dev.to · AI#AI编程#代码审查#测试

Editor brief · 编辑速览

指出大多数团队的 AI Patch 审查流程从未用已知错误样本验证过，建议建立「已知坏 Patch 语料库」来测试 Gate 本身的有效性，并利用免费模型生成语料。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

你的 AI 生成补丁的审查关卡就是代码，但大多数团队从未对它运行过一次测试。一个无法捕获删除健康检查补丁的关卡不是关卡；它是附加了合并按钮的形式主义。发现这一点的最便宜方式是构建一个小型的已知错误补丁语料库，然后在可丢弃的服务器上用你的关卡对其运行测试。免费模型访问使语料库的生成几乎免费，免费服务器使观察失败几乎免费。

问题：验证的是补丁，从来不是流程

采用免费模型访问的团队通常会添加审查清单、冒烟测试或 CI 关卡，然后开始合并通过了审查的生成式补丁。但在实践中，没有人验证这个验证者，因为清单只写过一次，极少修改，而且从未针对故意构造的错误补丁执行过。这和发布一个没有测试的函数犯的是同样的错误：代码路径存在，但其行为未知。

一个典型的审查关卡会欣然放行移除启动配置验证的补丁、重命名数据库键的补丁、或反转速率限制条件的补丁，因为这些错误都不会触发标准构建。人工审查通常会在后续捕获这些错误，这意味着关卡什么都没做，只提供了虚假的覆盖感。关卡没有在保护流水线；是流水线在保护关卡。

立场：用免费基础设施换取失败，而非演示

免费服务器通常被视为预览环境，用来展示应用能够启动。这是可支配基础设施的最低价值用法。可支配服务器唯一能做事而生产环境做不到的，是廉价地失败，所以理性的用法是用对抗性输入运行审查流程，然后观察它崩溃。这不是向服务注入故障，而是向审查流程注入故障。

免费模型访问也在朝着同样的方向改变经济学：生成一个故意破损的补丁几乎不花一分钱，所以坏补丁语料库的边际成本趋近于零。

产物：坏补丁语料库和验证循环

循环有五个部分：干净检出、已知错误补丁的语料库、单一关卡命令和报告脚本。规则很简单：SLIPPED 行意味着关卡是 bug，而不是语料库。

# validate-gate.sh
# Usage: ./validate-gate.sh <repo> <gate-command> [corpus-dir]
set -euo pipefail

REPO="${1:?path to a clean checkout}"
GATE="${2:?gate command, e.g. './ci/gate.sh'}"
CORPUS_DIR="${3:-./bad-patch-corpus}"
RESULTS="gate-validation-$(date +%Y%m%d-%H%M%S).log"

for patch in "$CORPUS_DIR"/*.patch; do
  name=$(basename "$patch" .patch)
  git -C "$REPO" checkout -- . >/dev/null 2>&1 || true
  git -C "$REPO" apply "$patch" || { echo "$name: apply failed"; continue; }
  if $GATE >/tmp/gate-out.log 2>&1; then
    echo "SLIPPED: $name" | tee -a "$RESULTS"
  else
    echo "CAUGHT:  $name" | tee -a "$RESULTS"
  fi
done
echo "Results written to $RESULTS"

该脚本假设可以用 git checkout -- . 重置干净检出；如果你的仓库需要不同的恢复策略，请调整重置步骤。一个有用的初始语料库会将每个补丁映射到它所代表的故障类，以及应该捕获它的检查。

五步构建你自己的语料库

从最近三次生产事故中选择五个故障；这些是你的关卡必须首先捕获的故障类。

创建服务的干净检出，并确认关卡在未修改的代码上通过。

将每个故障写成一个最小补丁，一个故障一个补丁，名称要说明故障。

将关卡定义为一个单一命令，任何失败都返回非零退出码，包括冒烟探测。

运行验证循环，将每个 SLIPPED 行都视为关卡的 bug 报告，而不是语料库的 bug。

免费服务器在哪里适用

MonkeyCode 的免费模型访问和免费服务器选项适合这个循环，因为它们消除了通常阻止团队运行它的两个成本。用免费模型生成坏补丁几乎不花一分钱，而在可支配服务器上运行循环意味着关卡失败没有爆炸半径。披露：本文是 MonkeyCode 产品推广的一部分准备的。同样的循环也适用于本地虚拟机或临时容器；关键是环境必须是可支配的，而不是必须是特定产品。

局限性和谁应该跳过此方法

语料库只针对你已经知道的故障验证关卡；它无法创造新的故障类。能捕获所有五个补丁的关卡不是被证明正确，而是被证明对这五种情况足够，所以要把语料库当作底线。没有可重复关卡命令的团队应该先构建那个，因为运行 lint && test 的脚本还不是关卡。语料库也需要维护：当补丁停止应用时，服务已经演进，故障类值得有一个新的补丁。如果你的团队不会对 SLIPPED 结果采取行动，请完全跳过这种方法，因为没有后续的验证循环只是另一个未经测试的流程。

从未见过失败的审查关卡是一种信念，而不是控制。从最近三次事故背后的五个故障开始，在任何可支配的服务器上运行循环，并修复关卡直到它捕获你已经知道是危险的东西。交付物不是一个完美的关卡，而是一个真正在你面前失败过的关卡。