工程级代码审查

要解决的评审问题

很多代码评审一上来就逐行挑毛病，结果实现了错误功能的代码也能收到一堆风格建议；没有明确评审范围的会话，则常常对着 lockfile 和构建产物浪费篇幅。这个技能把评审拆成两阶段，强制先验证实现是否符合需求，再谈代码质量。

核心能力与关键步骤

• 两阶段流程：Stage 1 对照 PR 描述、issue 或任务规格逐项核对，发现实现偏离立即停止；Stage 2 才检查正确性、可维护性、安全性和性能。
• 范围解析：先确认处于 git 仓库（git rev-parse --git-dir），按「用户指定文件 → 会话改动 → 未提交改动 → 未跟踪文件」的回退链确定范围，排除 lockfile、压缩产物和 vendored 代码；零文件时停下来询问。
• 基线解析：分支评审使用 merge-base 而非工作区差异；对堆叠在未合并分支上的改动，优先采用托管平台的 base SHA，并用 --name-only 集合过滤越界结论。
• 模式选择：读 diff 之前先用 git diff --stat 等元数据统计信号（改动行数、文件数、跨模块数、安全敏感文件、迁移、API 面变更，均排除测试文件）。3 个以上信号触发深度审查并派出并行专家 agent；2 个信号询问用户；0–1 个走标准流程。
• 结论表达：finding 按 CR-001 式编号，必须携带 [file:line] 和引用代码作为证据，按四级严重性与五档置信度归档；行内评论用 (无前缀)、Nit:、Consider:、FYI: 区分是否阻塞合入。
• 反模式清单：对着 linter 挑风格、借评审扩大改动范围、基于未验证的「不存在」下结论、无基线就把行为变更判为回归，均被明确禁止。

适用边界与注意点

超大 PR 会得到按模块评审和拆分建议（stack、按文件组、横向、纵向四种策略）；缺失 linter 或测试工具时标记缺口而非猜测。当修复需要超出 PR 范围的 API 重新设计，或变更意图不明时，技能要求停下来询问而不是假设。