Claude 多角度代码审查

要解决什么问题

PR 或本地分支上的代码变更，往往靠人工扫一遍 diff：逻辑、安全、错误处理各看各的，容易漏点，也容易把「风格意见」和「真 bug」混在一起。这个技能把审查拆成可重复的流水线：先定范围与项目约定，再多角度并行找候选，最后用独立验证者按文件 + 行号裁决，再合成一份有上限、按严重度排序的报告。

工作方式

前置：必须在 Git 仓库中运行；默认用 git diff @{upstream}...HEAD，必要时回退到 main...HEAD 或 HEAD~1；若有未提交改动，会额外并入 git diff HEAD。

整体分五个阶段：

1. Scope：构建正确的 diff 命令、确认有非空变更、列出文件、概括变更，并收集各级 CLAUDE.md / CLAUDE.local.md 中的审查约定。
2. Find：按 effort 启动多个发现者——正确性分 A/B/C（high）或 A～E（xhigh/max），清理合并为一个发现者（可读性、性能、可测试性、架构、兼容性等，且仍优先抓正确性问题）。发现者被要求：凡有可命名失败场景的候选都要上报，由后续验证者裁决。
3. Verify：同一 (file, line) 上的多条候选合并为一个验证者处理，裁决为 REFUTED / PLAUSIBLE / CONFIRMED，以减少重复调用。
4. Sweep（仅 xhigh/max）：在确认数未达上限时，补查测试、配置、文档、构建脚本、迁移等缺口区域。
5. Synthesize：合并语义重复、按影响排序、裁剪到级别上限（high 最多 10 条，xhigh/max 最多 15 条），并写一段摘要。

努力级别由「正确性角度数 × 每角度候选数 × 是否扫查」决定；max 与 xhigh 结构相同，差异主要在 API 推理 effort。

边界与注意

• 无变更或所有发现者为空时，会返回明确的空结果摘要，而不是伪造问题。
• 路径经 suffix-matching 规范化，避免绝对/相对路径不一致导致重复条目。
• 最终报告只保留 CONFIRMED 与 PLAUSIBLE；验证者若因基础设施错误全部失败，应视为故障而非「审查通过」。
• 每条发现应描述用户可见后果（错误行为、错误输出、数据丢失等），而不是停留在中间实现状态。