Qwen Code /review 增强：让 AI 审查可验证可信任

Qwen Code 0.21.3 让 /review 更加注重证据。这个稳定版本新增了 Test Plan 声明验证、对测试失败进行实测归因，以及更多验证视角。真正重要的变化并不是“增加了更多 review Agent”，而是更严格地区分：哪些声明只是读到过，哪些结果经过实际测量，以及哪些结论可以安全地据此采取行动。

在接受 AI review 之前，请先通过以下检查：

• 固定本次 review 所针对的 merge base 和 PR head。

• 将 PR Test Plan 转换为可证伪的声明。

• 验证引用的路径、package script 和报告的测试数量。

• 在 PR revision 上运行相关测试。

• 在 merge base 上重新执行失败的命令。

• 将失败分类为新增、共有或未测量。

• 通过 positive control 证明测试工具链确实能够检测到失败。

• 只有当 effective diff、证据和当前 head 仍然一致时，才能合并。

这份指南是对 Qwen Code 事件驱动型 CI finalizer 的补充。那份指南回答的是：CI 完成后，何时可以最终确认批准；而本文回答的是：review 证据是否值得信任。

本指南适用于使用 Qwen Code review pull request 的维护者，尤其是 PR 描述中包含 Test Plan，或者仓库中已经存在 flaky test 和历史遗留失败的情况。

如果你正在构建自己的 reviewer，这份指南同样有用。如果你首先需要证明某个 Agent 确实完成了工作，请从 Qwen Goal 证据检查清单入手。如果你还想参考另一种实现模式，可以对比 Claude Code 的显式验证工作流。

有哪些变化，为什么重要

官方 v0.21.3 release 表示，/review 现在会根据代码变更和 workspace 状态检查 Test Plan 中的断言。它还会在 base tree 上重新运行失败的命令，以实测方式完成失败归因，而不是根据发生失败的文件是否被修改过来猜测原因。

这弥补了三个常见的信任缺口：

Qwen 已合并的 review 工作还增加了 effective-diff guard。merge-base diff 为空时，应当停止 review。如果 diff 大幅缩减，则必须披露，因为 PR 描述中提到的工作可能已经不再存在于当前接受 review 的 revision 中。

六阶段证据工作流

1. 固定 review 身份

记录 repository、pull request、merge-base SHA、head SHA、Qwen Code 版本和 review effort。不要让后续 push 沿用之前的结论。如果 head 发生变化，review 就已经过期。

同时确认当前运行的 CLI 确实是预期的 build。Qwen 自己的 dogfooding 发现，subprocess 可能会解析到更旧的全局 binary，导致较新的 gate 被悄无声息地跳过。

2. 将 Test Plan 转换为声明

只提取可以验证的声明：

• 某个文件或 fixture 存在；

• 某个 package script 已定义；

• 某项结果报告了数量或状态。

将每项声明分类为 confirmed、contradicted、differs 或 unmeasured。测试数量发生变化并不必然意味着声明存在矛盾：不同 runner 或 flaky suite 都可能导致数量变化。它只是需要进一步解释的证据。

3. 先在 PR 侧运行

执行能够验证变更行为的最小命令集。保留准确的命令、exit code、失败文件集合以及相关 artifact。不要把“命令无法启动”归为“测试失败”。环境错误应归入 unmeasured。

4. 在 merge base 上重放失败

对于 PR 侧运行失败的每一条命令，都要在隔离的 base-tree checkout 中，使用等价的依赖和环境重新运行同一条命令。

应比较失败文件集合或稳定标识符，而不只是原始数量。flaky suite 在两次运行中失败的 case 数量可能不同，但这并不代表底层的失败归属发生了变化。

5. 验证测试工具链和 effective diff

在信任绿色通过结果之前，先加入一个隔离的、必然失败的测试或 mutation。如果命令仍然以零值退出，那么测试工具链并没有执行你以为它执行的内容。

然后重新计算 merge-base diff。如果 diff 为空，就停止 review。如果 effective diff 远小于平台声称的变更规模，应披露这种缩减，并且只 review 剩余的实际变更。

涉及 GitHub 渲染效果的声明，需要使用真正的 renderer，而不是在本地近似模拟 Markdown。Qwen 为这类裁决提供了一条可选择启用的临时仓库路径。这个仓库必须是一次性的，绝不能使用生产仓库来探测 renderer 行为。

6. 得出边界明确的结论

只有在当前 head 保持一致、所有重要 Test Plan 声明都已确认或得到解释、测试工具链的 positive control 有效，并且不存在新增的阻断性失败时，review 才能批准。否则应返回 request_changes、comment、stale 或 unmeasured。

可复制的 review 记录

review_evidence:
  tool: "qwen-code 0.21.3"
  base_sha: "full merge-base SHA"
  head_sha: "full PR head SHA"
  test_plan_claims:
    - claim: "npm test covers the changed parser"
      state: confirmed
      evidence: "script + command artifact"
  failure_attribution:
    command: "npm test -- parser"
    pr_side: ["parser.test.ts"]
    base_side: []
    classification: net_new
  harness_positive_control: passed
  effective_diff: confirmed
  terminal_state: request_changes

八项验收测试

根据路径推断失败归属。被修改的文件可能暴露一个旧失败，而未修改的文件也可能因为新变更而失败。必须对两个 revision 都进行实际测量。

将零发现视为证明。覆盖情况只能证明 Agent 检查过 diff，并不能证明 review 具备足够的判别能力。

在损坏的环境中不断重试。磁盘、进程或依赖故障应当让 review 立即短路终止，并以 unmeasured 状态披露。

Qwen Code 0.21.3 能让每一个 /review 结论都安全地用于自动合并吗？

不能。它改进了证据流水线，但 repository policy、环境完整性、flaky test、权限以及人工审批边界仍然适用。应当把最终证据视为更可靠的合并依据，而不是不受限制的授权。

Qwen Code v0.21.3 release

Test Plan 声明检查和 base-tree 测试工具链

实测失败归因

Renderer 裁决和验证视角

Effective-diff guard 和 positive control

召回、修复循环以及由变更规模决定的 review 预算

Qwen /review dogfooding 暴露的缺口

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。