Skip to content
FunCoding

Search

Search docs, Skills and MCP

代码审查入口与强度

选择本地、文件或 PR 审查,理解 effort、验证和结论边界。

This page has not been translated into English yet. The original Chinese version is shown below.

/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 评论、增量与恢复。