代码审查入口与强度
选择本地、文件或 PR 审查，理解 effort、验证和结论边界。
/review 检查改动的正确性、安全、性能、测试与具体代码质量问题。它默认报告发现；发布到 PR 或修改工作树另有显式入口。
选择范围
/review
/review src/utils/auth.ts
/review 123
/review https://github.com/org/repo/pull/123无目标时检查本地未提交变更。没有变更就停止，不启动审查 agents。PR 编号用于当前仓库，完整 URL 也能指向另一仓库，但跨仓库只读 diff，无法获得完整本地代码与构建验证。
三种 effort
| 强度 | 工作范围 | 结论边界 |
|---|---|---|
| low | 按差异规模做 3–6 个内联角度、适用的 gap sweep 和补查；无 subagent、构建测试或项目规则 | 最多 10 条未验证发现，无 verdict，不发 PR 评论 |
| medium | 精简 finder 集合，保留安全、测试覆盖、构建测试及一次验证 | 发现已验证，但原可 Approve 的结论降为 Comment，不发布 |
| high | 完整发现、分片验证与迭代反向审计 | 可形成 Approve、Request changes、Comment；显式发布时才写 PR |
/review --effort low
/review 123 --effort high官方概述还有一句把 medium 与 low 一并称为单次内联替代，与详细 effort 表矛盾；这里按详细定义区分 medium 的验证和构建路径，不承诺固定调用数量。安全敏感或发版前需要完整二次查漏时应选 high。
强度如何决定
依次使用显式 --effort、该项目上次明确输入的等级、运维 review.effort 设置，最后是内置目标默认：PR 为 high，本地和文件为 medium。使用记住的等级时会先提示，再输入新的 --effort 可替换。
PR 上有效的 --comment 强制 high；非 PR 的 --comment 被警告忽略，不改变强度。本地/文件上的 --fix 至少升到 medium，但不强制 high；PR 上 --fix 无效。
high 可能使用增量缓存，只审查新提交；low/medium 不使用该缓存，始终看完整 PR diff。不同强度不改变正确选取比较基准的要求。
发现怎样呈现
Critical 表示合并前应修复的问题，Suggestion 是有实际成本或风险的改进，Nice to have 是可选优化。低置信度单独放 Needs Human Review，不能当成已经证明的缺陷。
每条发现需写出触发输入、状态或时序，以及错误结果；质量问题需说明具体维护成本。单纯风格偏好、可由格式化器规范化的差异、无实际风险的小重构通常排除；类型错误、死代码等实质问题仍在范围内。
报告和后续动作
同仓库报告保存在 .qwen/reviews/。medium/high 同时写相同文件名主体的 JSON，Web Shell 可呈现可筛选结果；跨仓库轻量审查不保存这套报告。
每次运行以 Review complete: <target> — <disposition> 结束，脚本更适合使用无头审查的退出码。修复、发布与恢复分别见应用发现、PR 评论、增量与恢复。