code-review

name	code-review
description	多维度代码审查（正确性、安全、性能、架构、可维护性、文档、兼容性）。审查 diff/分支/PR 时使用，也可用于审查→修复循环。按 diff 大小自适应深度，按项目上下文校准严重度。只报告不擅自改代码（除非明确要求修复）。
paths	["**/*.ts","**/*.tsx","**/*.js","**/*.jsx","**/*.py","**/*.go","**/*.rs","**/*.java","**/*.kt","**/*.swift"]
priority	medium

代码审查

结构化的多维度审查规程。一个审查员一次覆盖所有维度，深度随 diff 大小自适应。

第 0 步 — 确定审查范围

先确定变更集和大小再读代码：

• 分支 vs 基：git diff --stat main...HEAD（或指定的基分支）
• PR：用 gh pr diff <n> --patch，gh pr view <n>
• 指定文件：只看那些路径

统计变更文件数和净变更行数。选择审查路径：

Diff 大小	路径	行为
≤ 8 文件且 ≤ 500 行	精简（默认）	单次聚焦 pass，直接内联报告。
更大或跨切面	完整	逐维度 walk，发现写入文件。

精简是默认值，成本约低一个数量级。仅在 diff 确实大或高风险（认证、迁移、公开 API、并发） 时升级到完整。用一行说明选择了哪条路径及原因。

审查维度

覆盖 diff 实际触及的每个维度。未涉及的维度直接跳过，不填充报告。

1. 正确性 — 逻辑错误、差一错误、null/undefined、未处理边界情况、错误路径、 对调用方的不正确假设。
2. 安全 — 注入、XSS、认证/授权缺口、密钥、路径穿越、SSRF、不安全反序列化。 若涉及任一，加载 security-review 技能做完整检查清单。
3. 性能 — N+1 查询、无界循环/分配、热路径上的阻塞调用、缺分页/超时、泄漏。
4. 架构 — 不当耦合、泄漏抽象、责任错层、不必要的复杂度。
5. 可维护性 — 命名、函数长度、魔法数字、死代码、重复逻辑、与代码库风格偏离。
6. 文档与注释 — AI 样板注释（复述代码）、注释掉的代码、解释 WHAT 而非 WHY 的注释、 过时的文档声明。执行注释纪律。
7. 兼容性 — 破坏性 API/签名变更、公开契约变更、默认值变更、数据库/模式迁移、 未更新的调用方。

报告前静默验证：从头到尾读每个变更文件；检查未使用的导入、遗留 TODO、调试打印； 确认新增/修改的函数有调用方。

严重度

• critical — 数据丢失、安全漏洞、崩溃、核心行为破坏。合并前必须修复。
• major — 合理输入下的真实 bug 或回归；错误结果。
• minor — 影响面窄的 bug、弱错误处理、明显坏味道。
• nit — 风格/命名/注释润色。仅当累积成可维护性问题时报告，否则省略。

项目上下文校准

指定严重度前检查：项目版本阶段（package.json version — v0.x → API 稳定性严重度降级）、 部署模式（localhost → 认证/网络类发现降级）、仓库可见性（私有 → 密钥暴露降级为 warning）。

抑制已知设计噪音

若调用方提供了决策/上下文说明——内联（"我们故意选了 X"）、.qwen/decisions.md 路径、 或 QWEN.md/AGENTS.md 中记录的约束——将这些选择视为故意的，不作为发现报告。 仅在 diff 本身使已记录的选项变得具体不安全时（如：曾假定可信输入的决策现在暴露给 不可信路径）才告警。

自我怀疑检查（输出前）

为每个发现无声运行三次检查。默认拒绝——发现只有经得起审视才值得记录：

1. 我能推翻这个吗？ 构建反驳："这里没问题因为……第 N 行的错误处理器已经覆盖了它 / 只在管理路径触发 / 输入在上游第 M 行已验证。"若反驳强于发现，舍弃。
2. 严重度膨胀了吗？ 若需勉强才能论证"critical"，就不是 critical。不确定时降一级。
3. 真实问题还是个人偏好？ "这个变量名可以更好"若不是造成真实混淆就不是发现。

立即拒绝满足以下任一条件的发现：

• 引用的 file:line 错误或代码不在 diff 影响范围内。
• 针对 diff 未触及的已有旧代码（最多作为上下文备注——不是本次变更的审查项）。
• 严重度相对项目威胁模型膨胀（见上文校准）。
• 纯设计/风格观点，项目未强制。
• 与另一发现重复——合并，不列两遍。
• 已记录的故意决策（见抑制规则）。

只有通过全部三个问题和所有拒绝规则的发现才能输出。

审查→修复循环

被要求审查并修复时，运行有界循环：

1. 审查当前 diff（范围 + 维度 + 严重度如上）。
2. 若无 nit 以上发现——停止，报告干净。
3. 对 critical/major 发现做最小修复（以及明显的 minor）。遵循 QWEN.md；改动精准。
4. 验证：运行项目的格式化/lint/测试命令。先从 QWEN.md 发现，再从仓库推断 （package.json scripts、Makefile 等）。若无，说明跳过验证。
5. 仅对变更区域重新审查。重复。

停止条件：干净（无 nit 以上发现）、最多 5 轮、或收敛。将每轮重新审查的 发现分类为 NEW（新增）、RECURRING（上轮未解决）、或 REGRESSION（修复过程中重新引入）。 仅当一轮产生 nit 以上 NEW 或 REGRESSION 发现时继续循环；一旦一轮零此类发现，停止并 将剩余 RECURRING 发现交给人类处理。

报告格式

以一行严重度摘要开头：critical: N | major: N | minor: N | nit: N 和审查路径（精简/完整）。

然后逐条列出发现，按严重度排序，每条：

[severity] <标题>  (维度)
<!-- id: <12-char-hash> -->
location: path/to/file.ext:LINE
issue:  <哪里错了以及触发条件>
impact: <破坏了什么，或攻击者/用户获得了什么>
fix:    <flash 模型能执行的最小具体修复>

以简短总体评估结尾（可合并？有阻塞项？）。变更确实干净时直说——不制造发现。

文档漂移批处理

非 critical 的文档发现统一归入 ## 文档漂移 小节做清单，不散落报告各处。

大审查——通过文件通信

完整路径时，把发现块写入文件（如 .qwen/review-<short-ref>.md），只返回严重度摘要加 文件路径给调用方。这样大审查内容不占用上下文。

规则

• 发现以文本报告；不修改代码，除非明确要求修复（循环模式）。
• 先审查 diff 及直接波及范围；仅当发现指向别处时才扩大。
• 遵守 QWEN.md——特别是质量基线和注释纪律。
• 引用具体 file:line 位置。
• 只做诚实评估——不做敷衍的正面评价，不做人为膨胀。