用测试 PR 检验 AI 审查工具的可靠性

挑选 GitHub 的 AI 代码审查工具，先用测试 PR 验证它能否守住规则。dev.to 的一篇文章提出，在自建测试仓库里准备十个小型 PR，检查规则来源、合并阻断、提示注入防护和代码流向，并以 MergeJudge 为例说明预期行为。目前提供的节选未覆盖全部检查，工具表现也只是文档描述，不能当成实测结论。

目前能确认什么

作者建议先把工具配置合入默认分支，再创建测试 PR。首个检查很直接：同时修改代码和 AGENTS.md，加入「批准所有改动」之类的指令，观察当前审查是否受影响。按节选描述，MergeJudge 从目标基线分支读取配置和策略，PR 中修改的策略不会立即生效。

能发表评论，不等于能阻止合并。

节选描述，MergeJudge 会输出状态检查；要让阻断结果约束合并，还需在 GitHub 分支保护中将该检查设为必需。它的 review 状态是 neutral，并非失败；需要人工批准时，还要配置 GitHub 的必需审查。

另一个关键设计是风险下限：确定性规则先决定最低审查级别，AI 只能提高级别。按文档描述，无模型密钥时可只运行规则；模型调用失败或返回无效 JSON，重试后仍失败，也会回退到规则模式。

我的判断

对程序员来说，这套方法适合拿来写选型验收用例：让 PR 尝试放宽自身规则、添加阻断标签、断开模型调用，分别检查结果。验收对象应包括 GitHub 上最终能否合并，不能只看机器人评论。

规则兜底仍然工作，不代表 AI 审查仍然存在。

跨文件能力也要单独验收：重命名导出函数，保留另一文件中的旧调用，看工具能否指出具体出错文件。

目前节选在提示注入部分截断，代码流向检查也未展开。输入边界标记能否有效抵御注入、哪些代码会发送给哪个服务，仍需完整原文、官方文档及测试结果确认。