PR Review 卡兩天的解：P5 三階驗證 + Claude Code Sub-Agents
更新於 2026年7月11日
PR Review 卡兩天的解：P5 三階驗證 + Claude Code Sub-Agents
Answer Capsule：PR review 卡兩天的根本原因不是 reviewer 慢，而是「一次塞太多東西」。把 review 拆成 Plan / Code / Verify 三階，每階一個 sub-agent 看，最後 verify 過了才能 merge。這就是 Alex 的 P5 原理。Claude Code 2.1.x 的 sub-agents tabbed UI +
/ultrareview命令把 P5 落地。Alex 在 his-shutien 醫療系統案例驗證：review 時間從 7 個工作天降到 1 天。
你有沒有遇過這種情況？
你開了一個 PR，commit 完已經晚上 10 點，發 Slack 通知 senior。
隔天早上看，沒人看。下午也沒人看。傍晚問了一下，senior 說「等等，我今天三個會」。
到了第二天晚上，你的 PR 還在那邊。同事的 PR 也卡在你這邊（因為你要先 merge）。team 整個 sprint 開始崩了。
老實講這不是你的 team 特別爛——這是大多數 5-30 人團隊的日常。
根本原因：不是 reviewer 太慢
90% 的人遇到 PR review 卡，第一反應是「換工具」、「催 senior」、「split PR 變小」。
這些都治標不治本。
我跑過 his-shutien（醫療系統）+ 好幾個 team 的陪跑後，整理出 PR review 卡的三個根本原因：
1. 一次塞太多東西進 review。
一個 PR 同時包含 design intent + implementation + test + style fix + 順手的 refactor。reviewer 要同時想 4 件事，自然慢，自然容易漏。
2. Reviewer 沒有分工。
不管 PR 是改 API 還是改 UI 還是加 test，都是同一個 senior 看。Senior 是 bottleneck 還在所難免。
3. Verify 沒有 gate。
Review 完 reviewer 寫個「LGTM」就 merge。但「Looks Good To Me」是什麼意思？code 跑得動嗎？test 涵蓋 edge case 嗎？production deploy 會不會炸？沒人保證。
P5 原理：Plan-Code-Verify 三階驗證
這是 Alex 6 個 cross-cutting principles 之一（Track B 模組包的核心 IP）。
簡單來說
把 review 拆成 plan / code / verify 三個獨立 stage，每階一個 sub-agent 看，最後 verify 過了才能 merge。這就是 P5。
P5 三階定義
第一階：Plan stage — 問「這個 PR 要做的事，design 對不對？」
- API surface 設計
- Data model（schema、constraint、migration）
- 跟既有架構的 alignment
- Scope 合理嗎
第二階：Code stage — 問「implementation 對齊 plan 嗎？」
- Code 有沒有按 plan 做
- 可讀性、命名、結構
- Test coverage（happy path + 1-2 個 edge case）
- 風格 (lint、format)
注意：只有 plan 已經過了，這一階才開始。否則白看。
第三階：Verify stage — 問「跑得動嗎？真的解決問題嗎？」
- 跑 test 真的過嗎（不是只看 CI 綠燈）
- Edge case 真的有測嗎（throw error / empty input / large input）
- Observability：log / metric / alert 設好了嗎
- 部署到 staging / production 之後 rollback plan 有嗎
這一階是 gate——沒過就不能 merge，不管 plan 跟 code 多漂亮。
為什麼 sub-agent 分工比一個人看完強
傳統 review：senior 一個人從頭看到尾，腦袋同時想 4 件事，然後寫個「LGTM」。
P5 + sub-agents：三個 sub-agent 各看一階，每個 agent 上下文獨立、回報只給結論、parent agent（你或 lead）整合三個結論決定要不要 merge。
差別：
| 維度 | 傳統 review | P5 三階 |
|---|---|---|
| 一次塞多少東西 | 全部混一起 | 一階一個 focus |
| Reviewer 切換成本 | 高（同時想 4 件事） | 低（一次一件） |
| 什麼算 reviewed | 模糊（LGTM） | 三階都過才算 |
| 能不能平行 | 否 | 是（sub-agents 同時跑） |
| 第一次 plan 錯成本 | 高（code 寫完才發現） | 低（plan-reviewer 直接 catch） |
| Junior 上手快不快 | 慢（要學會看一切） | 快（從 verify-reviewer 開始） |
最後一行特別重要：P5 讓 junior 也能 review——junior 從 verify-reviewer 角色開始（跑 test、check log、看 alert），慢慢往 code-reviewer、plan-reviewer 升。
Claude Code 怎麼落地 P5
P5 原理本身和 LLM 沒關係——你可以叫 3 個人類 reviewer 各看一階，一樣 work。
但要把它落地成可重複、可規模化的 pipeline，Claude Code 在 2026 Q1 之後特別適合：
1. Sub-agents tabbed UI — Claude Code 2.1.x 的 sub-agents tabbed UI 把每階 isolated context 視覺化，你可以同時看 plan/code/verify 三個 review session 進度。
2. /ultrareview 內建 multi-agent orchestration — 不需要自己寫 orchestration logic。一個命令編排三階。
3. Plan mode 讓你 review 前先看 plan — 寫 code 前先讓 Claude 給 plan，你 review plan。Review plan 比 review code 快很多（看 100 行 design 比看 500 行 code 快 5 倍）。
三個 sub-agent 怎麼寫 system prompt
放在 .claude/agents/：
plan-reviewer.md
---
name: plan-reviewer
description: Reviews PR design intent / API surface / data model alignment.
tools: Read, Grep, Glob, Bash(git:*)
---
You are an 8-year senior backend engineer reviewing the PLAN stage.
Focus on:
1. API surface (input/output/error case design)
2. Data model (schema, constraint, migration safety)
3. Architecture alignment (does this violate any invariant?)
4. Scope (right amount of work?)
Output: 3-5 bullet conclusions (PASS/WARN/FAIL) + 1-line summary
DO NOT comment on code style/naming/tests — that's later stages.code-reviewer.md
---
name: code-reviewer
description: Reviews PR implementation against approved plan.
tools: Read, Grep, Glob, Bash(npm test:*, ruff:*)
---
You are a paired-programming partner. Plan-reviewer already approved.
Your job: did the implementation match the plan?
Focus on: alignment / readability / test coverage / style.verify-reviewer.md
---
name: verify-reviewer
description: Final gate. Run tests, check edge cases, validate observability.
tools: Read, Bash(*)
---
You are the FINAL GATE before merge. Plan + Code already passed.
Focus on: actually run tests / edge cases / observability / rollback plan.完整版含 12 個 tactical tips 在 Track B B1 module。
Alex 真實案例：his-shutien 醫療系統
我在書田診所 HIS 陪跑時看過一個經典案例。
他們的 .NET 9 系統要接 VB6 legacy module。PR 開了一週 review 不過。
沒用 P5 之前
- Day 1：PR 開出來
- Day 2-3：senior 在開會，PR 等
- Day 4：senior 看了 30 分鐘，留 12 個 inline comments（混合 design + style + test）
- Day 5：作者改 + 回覆，又 push 一版
- Day 6：senior 又看，這次發現「這個查詢 N+1」（design 問題）
- Day 7：作者拆 PR
總計：7 個工作天
用 /ultrareview 後
- Plan-reviewer (3 min)：「WARN — 用 LINQ 看起來會 N+1，建議用 .Include() 預載」
- Plan REWORK：作者加 .Include()，重新提交 plan
- Plan-reviewer 二次 (2 min)：「PASS」
- Code-reviewer (4 min)：「PASS — 命名清楚，覆蓋 happy path 含 edge」
- Verify-reviewer (3 min)：「WARN — 缺空 result set 的 test」
- 作者補 test，verify 二次 PASS
總計：18 分鐘 + 作者改 30 分鐘 = 1 個工作天內結束
省下 6 天。
陪跑制 KPI 月報的 L2 Velocity 數據就是這樣抓出來的。
對照其他做法
| 做法 | 解的是什麼 | 限制 |
|---|---|---|
| P5 + Claude Code sub-agents | review 結構問題（一次塞太多 / 沒分工 / 沒 verify gate） | 需要 Claude Code Pro+ + team buy-in |
| 換更快的 reviewer 工具（GitHub Copilot Review） | 表面：reviewer bandwidth | 沒解結構問題 |
| Split PR into smaller chunks | 表面：PR size | 治標不治本，作者切碎反而 review thread 更難跨片看 |
| 找 senior 1-on-1 catch up | 表面：senior bandwidth | scale 不到 30+ team |
| 加更多 lint / pre-commit hooks | code 風格層 | 沒解 design / verify 層 |
Key Takeaways
- PR review 卡兩天的根本原因是「一次塞太多東西」，不是 reviewer 慢
- P5 三階驗證（Plan / Code / Verify）+ sub-agent 分工 = review 結構解
- Claude Code 2.1.x 的 sub-agents tabbed UI +
/ultrareview命令是 P5 的落地工具 - Junior 從 verify stage 開始學——不再是「我能不能看 senior 的 PR」哲學問題
- 真實案例：his-shutien VB6 case，7 天 → 1 天（省 6 天）
- 6 個原理（P1-P6）是思考框架不是工具，介面變動原理仍有效
FAQ
Q1：我 team 只有 3 個工程師，需要 P5 嗎？
3 人 team 通常你自己當 plan-reviewer + code-reviewer + verify-reviewer。P5 對你的 ROI 主要是「不一次性燒腦看完所有事」。即使 1-2 人 team 也適用——分階段 review 比一次看更不累。
Q2：sub-agent 一直給 false positive 怎辦？
90% 是 system prompt 沒夠嚴格。每個 agent 加 forbidden behavior block：「DO NOT comment on X」。Track B B1 module Tip 10 完整講這個。
Q3：跟 Cole Medin context-engineering-intro 差別？
Cole Medin 偏 SaaS feature ship 的 PRP loop（feature 級別）。P5 是 PR 級別。Track B B3 教兩者合體——feature 用 PRP 規劃 + 拆成多個 PR + 每個 PR 用 P5 三階。
Q4：team 不買單怎辦？
Senior 不買單最常見。解法：讓 senior 變 plan-reviewer 的 author（他寫 system prompt）。Senior 從反對者變 owner，自然推動。Track B B4 module 完整教 team adoption。
Next Steps
如果你卡在 PR review，下一步建議：
- 看 Track B B1 module 完整內容（5 lessons + 2 artifacts，含完整 sub-agent system prompt + 12 tactical tips + ai-coding-template fork）
- Fork ai-coding-template GitHub — 內建 11 agents + 21+ commands 的 reference codebase
- 如果你 team 5-30 人卡在 adoption：考慮陪跑制（NT$50-80K/月，限量 2 位/月）— 不只技術，含 team 文化 + KPI 設計
詳細 Track B 模組包 sales page（Founding 50 NT$6,800 lifetime）。
Related Resources
- Track B B1 PR Review Pipeline module
- ai-coding-template GitHub — Track B B2 reference + Track B 學員 fork
- Anthropic Claude Code docs — 官方文檔
- Cole Medin context-engineering-intro — PRP loop 互補
- Skool 工程師圈 — Track B 學員 lifetime member 入場
變更紀錄
| 版本 | 日期 | 變更 |
|---|---|---|
| 1.0 | 2026-04-29 | 初版（Plan 4 §Phase 7 Blog 1） |
