为AI提交的PR建立不可自降的审核门槛

AI 编程代理提交 PR 的速度，已经超过人逐行阅读的速度。作者给出的办法是：先由仓库规则把 PR 分成低风险、人工审查和阻断三档，再让模型检查差异。模型只能提高审查等级，不能降低门槛。

这套方案最值得看的，是如何防止代理修改自己接受审查的规则。作者用自建的 MergeJudge 演示了具体配置，但其中「规则来自基准分支、模型不能放宽规则」的思路，也适用于其他 AI 代码审查工具。

为什么规则要排在模型前面

把「能不能合并」全部交给模型，容易遇到两个问题：评论很多，却没有稳定的准入标准；代理还可能在同一个 PR 中修改审查说明，让自己更容易过关。

作者把审查拆成两层。确定性规则先给出最低审查等级：

• auto：低风险信号。
• review：必须由人检查。
• block：阻断。

模型随后读取 diff，补充行内评论，并且只能把等级调严。例如，规则判为 auto，模型可以提升到 review 或 block；规则已经要求人工审查，模型就不能把它降回 auto。

模型负责补充判断，仓库规则负责守住底线。

作者展示了三个公开 PR：文档小拼写错误进入 auto，工作流文件变更进入 review，硬编码 API key 进入 block。这些例子说明输出形式和预期分流，没有证明工具在复杂项目中的准确率。

代理为什么不能顺手改掉审查规则

关键在于配置从哪里读取。

MergeJudge 从基准分支的最新提交读取 .mergejudge.yml 和 AGENTS.md，不使用当前 PR 分支里的对应文件。因此，代理即使提交了放宽规则的修改，也不能拿这份新规则审查自己的 PR。

对于明确需要人看的目录，作者建议直接配置保护路径：

lanes:
  protected:
    - ".github/**"
    - "deploy/**"
    - "**/auth/**"
    - "**/migrations/**"

这段配置解决的是「有些变更无论模型怎么判断，都必须有人看」。要注意 protected 下的路径：命中后至少进入 review，即使没有启用 AI provider 也一样。

需要理解业务语义的要求，则放进 AGENTS.md 的 ## Code review 小节。例如，src/api/ 下新增的每个 HTTP handler，都必须检查资源授权。这里检查的是当前用户能否操作目标资源，不能只看是否登录。

原文也提到已有 CLAUDE.md 的团队可以补充审查要求，但明确描述的基准分支读取对象是 .mergejudge.yml 和 AGENTS.md，没有展开 CLAUDE.md 的具体读取方式。

规则变更最终仍要靠人工合并和分支保护把关。读取基准分支配置，解决的是「当前 PR 不能给自己降低标准」，不能单独替代 GitHub 权限管理。

接入不难，但审查信号需要接上合并权限

作者提供两条路径。GitHub App 面向公开仓库，每月最多提供 10 次免费 AI 审查，无需 API key 或配置文件。私有仓库或更高用量可以自带 key，也可以运行 npx mergejudge-runner setup，复用已有的 Claude Code 或 Codex 登录。

另一条是自托管 GitHub Action，无需 MergeJudge 账号。先执行 gh secret set AI_API_KEY 保存 provider key，再添加 .github/workflows/mergejudge.yml。下面是原文的完整工作流：

name: MergeJudge
on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review, labeled, unlabeled]
permissions:
  contents: read
  pull-requests: write
  checks: write
jobs:
  lane:
    if: github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    steps:
      - uses: gauravsharmaGG/mergejudge-runner@v1
        env:
          AI_API_KEY: ${{ secrets.AI_API_KEY }}
        with:
          provider: anthropic        # or openai, zai, openai-compatible, none
          model: claude-sonnet-4-5   # any model your provider supports

要看清 if 那一行：这个示例只运行同仓库分支发起的 PR，来自 fork 的 PR 不在覆盖范围内。

provider 支持 Anthropic、OpenAI、z.ai 和 OpenAI-compatible endpoint；设置 provider: none 时，只运行确定性规则，不需要 key。启用 AI 后，diff 和上下文片段会发送给对应 provider，自托管 runner 并不代表模型推理也在本地。

执行后会产生一条持续更新的汇总评论、diff 行内评论，以及 mergejudge/lane 检查：success 对应 auto，neutral 对应 review，failure 对应 block。

但检查结果不等于合并权限。原文没有详细说明，如何把 review 的人工确认要求配置成 GitHub 上不可绕过的约束。接入时需要补齐这一步。

我的判断

我赞同把稳定规则放在模型前面。部署文件、认证逻辑、数据库迁移是否需要人看，通常可以直接约定，不必每次重新问模型。相较于只写一段审查提示词，这套分层方式更容易解释每个 PR 为什么被拦下。

但 MergeJudge 是作者自己的项目，核心引擎采用 MIT 开源许可。原文属于接入演示，没有给出误报率、漏报率、审查耗时或人工工作量的对照数据。「能节省多少审查时间」目前仍是待验证的判断。

路径规则也有边界：授权逻辑可能散落在约定目录之外，模型能否发现问题仍需观察。作者也明确说，新增行上的密钥检查只是快速筛查，不能替代完整 secret scanner。

auto 只是低风险信号，不是自动合并许可。

能拿来做什么

• 先梳理团队必须人工审查的路径，把工作流、部署、认证和迁移目录写成明确规则；可以用 provider: none 先验证分流是否符合预期。
• 给 Node API 项目补充具体的资源授权检查要求，并核对审查工具实际读取的文件和分支，避免规范写了却没有生效。
• 用包含文档修改、敏感路径变更和业务逻辑变更的一组 PR 试跑，记录误报与漏报，再决定模型评论能承担多少审查工作。
• 接入后检查 review、block 与分支保护的实际配合，并确认 fork PR 的处理方式，避免把已有检查结果误当成完整的合并门禁。