# 审查流程与证据

> 理解发现分工、分片覆盖、验证、反向审计和隔离运行。

- 网址：https://funcoding.ai/agents/qwen-code/usage/review-pipeline/
- 核实日期：2026-10-08（命令、配置和价格以官方文档为准）
- 官方来源：[Qwen Code 官方文档：Code Review](https://github.com/QwenLM/qwen-code/blob/main/docs/users/features/code-review.md)

---
high 审查先确定范围并把 diff 保存、分块，再加载规则、并行发现、去重验证、反向查漏，最后形成规范化结果。具体 agent 数量取决于目标、规模和触发的专门检查，不能用概述中的固定数字估算所有运行费用。

## 小改动按检查角度分工

正确性检查分别逐 hunk 读取、追踪被删除的行为、沿调用方和新增字段读点追踪，再按语言陷阱或包装/代理类型增加专门检查。质量检查区分重复实现、修复层次与抽象、同类代码一致性。

其他检查涵盖安全、性能、测试覆盖、构建测试，以及攻击者、值班维护和长期维护视角。PR 还会核对关联 issue 的原始复现和问题归属，不能只信作者对修复的描述。

跨文件追踪不仅检查改动后的函数能否被旧调用方使用，也查新增字段是否在真实路径被填充和读取。超过十个修改符号时，调用方方向优先签名变化，新增字段的生产者方向不按该阈值缩减。

## 大 diff 按区域覆盖

源码改动超过 500 行，或总 diff 超过 3200 行时，改为约 400 行的区域 agent，每个对负责区域执行各维度检查。边界尽量落在 hunk，超大 hunk 只在顶层声明处分开，不在函数中间切。

每块需返回 Covered 收据，缺收据会补审；测试、文档和锁文件计入总差异，但源码阈值单独计算。改动集中在现有 300 行以上、至少 40% 为新内容的源码文件，或源码文件有 800 行以上变更时，还会针对全文件不变量做额外检查；测试和生成文件不符合该专门检查条件。

## 验证与反向查漏

每个 verifier 最多处理八条发现，回到真实代码追踪失败场景。否定 Critical 要提供反证；证据不足时降置信度，而不是只写“太推测”就删除。

反向审计携带累计发现清单继续找遗漏，连续两轮没有新发现才算收敛。小 diff 默认最多十轮，分块 diff 五轮；至少 3000 effective lines 的巨大 diff 在有显式 deadline 时降到三轮，只有默认时间墙时仍是五轮。

review.reverseAuditRounds 只能降低上限，不能提高。达到轮数或时间限制要披露截断，不能声称已收敛；后面找到的新发现也需验证。

## PR worktree 与探测

同仓库 PR 使用 `.qwen/tmp/review-pr-<number>`，避免切换当前分支；可在其中安装依赖和运行构建测试。这是会执行项目命令的审查，不应理解为纯文本读取。

改变代码来验证的 mutant 或 probe 使用旁边的独立临时 worktree，避免污染其他读者的视图。review 会话有 lease，第二个会话不能拆掉正在审查的目录；结束后清理临时树，报告留在主项目目录。

审查指令类文件时，具备代码树的流程还可在一次性副本执行变化后的指令，比较执行结果与文案承诺。该检查有真实执行成本，不能从“只修改 Markdown”推断审查不会运行操作。

## 可复核的发现数据

规范化结果放 `.qwen/tmp/qwen-review-<target>-findings.json`，终端、Markdown 和发布内容都从同一文件生成。每条有唯一 id、severity、confidence、source、summary、最多六十字符的 shortSummary、failureScenario 和非空 locations。重复 ID、未知严重度、缺场景或缺位置会在写入时拒绝。

同一模式跨文件可合并为一条发现，但保留每处 location。若测试在基线已失败，test-delta 可把引用该失败文件的 Critical 降为 Suggestion 并保留测量证据；若这次确实引入不同失败原因，应同时列出两边证据重新判定。

终端渲染证据可通过独立 tmux server 捕获 .ans，装有 freeze 时再生成 PNG。报告需区分像素、终端字节或仅文本推断，不能把未生成图片的检查描述为截图验证。