代码审查流水线

代码审查流水线

代码审查这件事，一个人干容易看漏，三个角度并行干才能稳。

但「三个人并行审」在现实里太奢侈——同事忙着改自己的 bug，谁有空把你的 PR 审三遍？Claude Code 让这件事变得便宜：开三个子代理，每个从不同角度审，并行跑，主代理整合。

这是 Eyad 在进阶系列里讲的核心思路之一，也是 9 步纪律化循环里「审查-修复-重测」闭环的关键一环。

为什么是三个子代理，不是一个主代理

一个主代理从头到尾审一遍，听起来更简单。但它有三个问题：

1. 上下文互相污染：审风格时读了一堆代码，到审安全时上下文已经塞满，注意力开始稀释
2. 视角单一：一个 prompt 只能问一个角度，多角度切换容易乱
3. 没有并行：三件事串行跑，慢

三个子代理并行解决全部问题——每个开干净上下文，专注一个角度，跑完只交回摘要。主代理拿到三份摘要做整合，决定哪些采纳、哪些忽略。

三个审查子代理

1. 风格检查 subagent

delegate to a subagent with this prompt:
"review the diff in this branch against the project's style rules. check:
- naming conventions (read .eslintrc, .prettierrc, or equivalent)
- file structure conventions (where do components/utils/tests live)
- consistent error handling patterns
- any dead code, unused imports, commented-out blocks
return a list of findings: file:line — issue — suggested fix. don't fix, just report"

只看风格，不评逻辑。它读 eslint 配置和现有代码风格，对照 diff 找不一致。

2. 安全扫描 subagent

delegate to a subagent with this prompt:
"security review the diff in this branch. check for:
- SQL injection (string-concatenated queries)
- command injection (unsanitized shell args)
- hardcoded secrets / tokens / API keys
- insecure deserialization (eval, pickle, JSON.parse of untrusted input)
- missing auth checks on new endpoints
- path traversal in file operations
return findings ranked by severity (high / medium / low). for each: file:line — risk — recommended fix. don't fix, just report"

只看安全，不评风格或测试。它有专属的检查清单，不会被其他角度干扰。

3. 测试覆盖率 subagent

delegate to a subagent with this prompt:
"review the test coverage of this diff. check:
- which new functions/branches have tests, which don't
- are the tests testing behavior or implementation? (behavior preferred)
- are edge cases covered? (null, empty, boundary values, error paths)
- are mocks overused? (flag any test that mocks >3 things)
- do the tests actually fail if the implementation is wrong? (mutation check)
return: covered areas, uncovered areas, weak tests (that would pass even if impl is wrong). don't write tests, just report"

只看测试质量，不评代码或安全。它甚至会做 mutation check——判断测试是不是真的「能挡住坏代码」。

主代理整合三份摘要

三个子代理跑完，主代理拿到三份报告。让它整合：

combine the three review reports (style, security, coverage) into a single PR review:
- deduplicate findings (same issue flagged twice = list once)
- rank by severity: security high > uncovered logic > style > nit
- for each finding: file:line — issue — recommended fix
- mark which are blocking (must fix before merge) vs nice-to-have
- output as a markdown table

don't fix anything — this is the review report

整合后的报告是「这个 PR 该不该合」的依据。blocking 项必须修，nice-to-have 可选。

修复-重测-重审闭环

这是 9 步循环里的「修-测-审」一环。光审不修等于没审。

fix all blocking findings from the review report:
- apply the recommended fix for each
- run the test suite after each fix
- if a fix breaks a test, /rewind and tell me — we'll reconsider the approach

after all blocking fixes:
- re-run the three subagents (style, security, coverage) on the new diff
- compare new findings vs old — did any fix introduce a new issue?
- iterate until no blocking findings remain

「did any fix introduce a new issue」是这步的精华——修 bug 引入新 bug 是 PR 审查最阴险的失败模式。每次修完都重跑三代理，确认没有 regression。

/review 斜杠命令：开箱即用的审查

如果你不想自己搭三个子代理，Claude Code 自带 /review 命令，一键启动审查：

/review

它会用一个内置审查子代理，从外部视角审你的 diff。比手搭三代理轻，但视角也单一。适合：

• 快速自查
• PR 提交前的第一道关
• 不想配置自定义子代理的场景

Ultrareview：深度审查

改动大、风险高的 PR，用更强力的版本：

/code-review ultra

或

claude ultrareview

Ultrareview 不只看 diff，还会看周边代码、调用方、潜在影响面——相当于请了一位资深 reviewer 全方位审一遍。适合：

• 改动公共 API
• 改动核心业务逻辑
• 涉及并发 / 安全 / 性能的改动
• 一次性大重构的最终把关

Ultrareview 比 /review 慢、token 消耗大，但能挡住 /review 漏掉的深层风险。

一份完整审查流水线模板

PR review pipeline for branch [feature/foo]:

Phase 1 — Parallel review (3 subagents):
  - style: against project's eslint/prettier rules
  - security: injection, secrets, auth, deserialization
  - coverage: untested branches, weak tests, mock overuse

Phase 2 — Aggregate:
  - combine reports, deduplicate, rank by severity
  - mark blocking vs nice-to-have

Phase 3 — Fix blocking:
  - apply recommended fix per finding
  - run tests after each fix
  - /rewind if any fix breaks tests

Phase 4 — Re-review:
  - re-run 3 subagents on new diff
  - flag any newly introduced issues
  - iterate until clean

Phase 5 — Final gate:
  - run /code-review ultra for deep pass
  - if clean, ready to merge

走完这套流程，你的 PR 审查质量会比单个人审高一个量级——因为它是多视角并行 + 闭环验证 + 深度兜底的组合拳。

几个审查纪律

• 每个子代理只看一个角度：别让一个子代理又看风格又看安全——视角一旦混合，深度就降。
• 审查子代理只读不改：让它们 report，不让它们 fix。修是主代理的活，避免多个代理同时改代码冲突。
• blocking 要严格定义：不是所有 nit 都 blocking。让主代理按「合并后会引发 bug / 安全问题 / 用户可见行为变更」来判断 blocking。
• 重审不能省：修完不重审等于没审——你不知道修没引入新问题。

下一站

• 子代理怎么定义——回顾 Subagents 深入。
• 9 步循环全貌——读 9 步纪律化循环。
• 大 PR 不好审？拆它——看 创建 Pull Request。