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 落地，還能控制 token 成本、讓 junior 從 verify 階段學起。Alex 在 his-shutien 醫療系統案例驗證：review 時間從 7 個工作天降到 1 天。

你有沒有遇過這種情況？

你以為 PR 卡住是因為 senior 太忙，實際上卡住的是「review 這件事本身沒有被拆成可以分工的步驟」。

你開了一個 PR，commit 完已經晚上 10 點，發 Slack 通知 senior。

隔天早上看，沒人看。下午也沒人看。傍晚問了一下，senior 說「等等，我今天三個會」。

到了第二天晚上，你的 PR 還在那邊。同事的 PR 也卡在你這邊（因為你要先 merge）。team 整個 sprint 開始崩了。

老實講這不是你的 team 特別爛——這是大多數 5-30 人團隊的日常。

根本原因：不是 reviewer 太慢

PR review 卡住的三個根因是一次塞太多東西、reviewer 沒分工、verify 沒有真正的 gate——換工具或催 senior 都治標不治本。

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 三階驗證

把整個 review 過程拆成 plan、code、verify 三個各自獨立的 stage，每一階都交給一個 sub-agent 專心看，最後只有 verify 這階通過才能 merge——這就是 P5 的核心概念。

這是 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 分工比一個人看完強

三個 sub-agent 各看一階、獨立回報，讓 reviewer 從「同時想 4 件事」變成「一次只想一件事」，junior 也能從最簡單的一階開始上手。

傳統 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

Sub-agents tabbed UI 讓你可以同時盯著三階的進度，/ultrareview 一個命令就編排完整條 review pipeline，plan mode 更讓你只需要看設計而不用先看一大堆程式碼。

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

每個 sub-agent 的 system prompt 都要有一句「DO NOT comment on X」，把它擋在自己那一階，不然三個 agent 又會混回同一鍋。

放在 .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。

Sub-agent 分工要花多少 token？成本怎麼抓

三個 sub-agent 平行跑等於三份 context 都要重新載入專案背景，PR 一多同時開，token 帳單跟排隊時間會一起變差，不是開越多越好。

/ultrareview 一次 spawn 3 個 sub-agent（plan / code / verify）。如果你的 team 同時有好幾個 PR 都在跑 review，等於同時有一堆 sub-agent 在燒 context——每個 sub-agent 重新讀一次 CLAUDE.md、architecture invariants、相關檔案，不是免費的。

我自己內部團隊分派 sub-agent 的時候，訂了一個很簡單的上限：預設一次最多 4 個平行 review session，真的要衝也不超過 8 個，超過就分批做。這跟前一篇談 SaaS ship loop 的 PRP loop 平行度上限 是同一個道理——不是為了省事，是因為超過這個數字之後，你自己要同時盯的 review 結論會先撐不住，反而漏看某一階的 WARN。

具體做法：每月跑一次 token 用量檢查，如果單一 PR 的三階 review 加起來超過某個門檻（例如 5 萬 tokens），代表這個 PR 本身可能就塞太多東西——回頭去對照前面「根本原因」那一段，先拆 PR，不要只怪 sub-agent 燒錢。

Alex 真實案例：his-shutien 醫療系統

這是我在書田診所 HIS 陪跑時看到的真實案例：同一個 PR，沒用 P5 卡了 7 個工作天，用了 /ultrareview 之後 1 天內結束。

我在書田診所 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 數據就是這樣抓出來的。

Junior 怎麼從 verify-reviewer 一路升到 plan-reviewer

P5 把 review 能力拆成三個難度遞增的角色，junior 先從跑 test、看 log 開始，累積夠了才碰 design 判斷，不用一入職就硬看 senior 那種全局 review。

前面表格最後一行寫「Junior 上手快」，展開講是這樣：

傳統 review 要求 junior 一次看懂「design 對不對 + code 品質好不好 + 能不能上線」，三種判斷力壓在一起，junior 自然不敢開口，只能跟著點頭。

P5 拆開之後，進場門檻完全不同：

第一階段：verify-reviewer。 跑 test、看 log、確認 edge case 真的被測到——這些是可以照 checklist 執行的機械性判斷，不需要對整個系統架構有經驗，新人入職第一週就能上手。

第二階段：code-reviewer。 累積幾個月「plan 已經對、我只看 code 有沒有照做」的經驗後，junior 開始培養「這段命名/結構好不好」的判斷力——這件事必須先看過夠多「plan 已核准」的例子才學得會。

第三階段：plan-reviewer。 到這階才需要「這個 design 對不對、跟既有架構衝不衝突」的全局判斷，通常是資深工程師才 hold 得住。

好處是每個階段的失敗成本都可控：verify-reviewer 判斷錯，頂多是漏抓一個 edge case，不會讓整個系統架構走歪；plan-reviewer 判斷錯，才是真正的高風險決策。這條路徑讓 team 可以把 junior 放進 review 流程，而不是把他們晾在旁邊「觀摩」。

對照其他做法

P5 解的是 review 結構問題本身，換工具、拆 PR、找 senior 加班都只是在同一個結構問題上打補丁。

做法	解的是什麼	限制
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 層

⚠️ 老實說：不是每個 PR 都要三階跑好跑滿

一行 typo 修正或版本號調整跑三階 sub-agent 是殺雞用牛刀，P5 該用在有真正 design 決策的 PR，不是所有變更都適用。

兩種情況我不建議硬套 P5：

1. 微小變更。 改一個錯字、調一個版本號、加一行 log，這種 PR 本身沒有 design 決策可言，spawn 三個 sub-agent 反而比人工掃一眼還慢，也白燒 token。plan-reviewer 這一階直接跳過，作者自己過一眼 code + verify 就夠。
2. 還在 spike / 探索階段的分支。 你自己都還不確定這個方向要不要走，PR 只是拿來驗證可行性，不是要合併的最終版本。這種分支先別跑正式 P5——先確認方向對了，要合併時才走完整三階。

P5 的價值在「有真正 design 判斷、又要進 production 的變更」上最大；越小越確定的變更，越應該用你原本的直覺判斷就好，不用每次都搬出完整 pipeline。

Key Takeaways

六句話濃縮全文：不是 reviewer 慢、P5 三階是解法、Claude Code 是落地工具、junior 有明確升級路徑、真實案例省 6 天、原理本身跟工具無關。

1. PR review 卡兩天的根本原因是「一次塞太多東西」，不是 reviewer 慢
2. P5 三階驗證（Plan / Code / Verify）+ sub-agent 分工 = review 結構解
3. Claude Code 2.1.x 的 sub-agents tabbed UI + /ultrareview 命令是 P5 的落地工具
4. Junior 從 verify stage 開始學，一路升到 code-reviewer、plan-reviewer——不再是「我能不能看 senior 的 PR」哲學問題
5. Token 成本要控：預設一次最多 4 個平行 review session，上限 8 個，超過分批做
6. 真實案例：his-shutien VB6 case，7 天 → 1 天（省 6 天）

FAQ

這裡收了六題最常被問到的問題，從「團隊人少要不要跑」一路排到「跟 Cole Medin 的 PRP 到底差在哪裡」。

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。

Q5：三個 sub-agent 一次跑，token 燒很兇嗎？

看 PR 大小。小改動三階加起來通常幾千 tokens；大改動（跨多檔案的 feature PR）可能到數萬。訂一個每月檢查的門檻，超過就代表 PR 本身該拆，不是 sub-agent 的問題。

Q6：小 PR（一行 typo）也要跑三階嗎？

不用。P5 用在有真正 design 決策的變更上，微小修正直接人工看一眼就好，硬跑三階是浪費 token 也拖時間。

Next Steps

先看 Track B B1 module 拿完整 system prompt，team 還沒建立 AI 協作習慣的話先從入門課打底再談三階分工。

如果你卡在 PR review，下一步建議：

1. 看 Track B B1 module 完整內容（5 lessons + 2 artifacts，含完整 sub-agent system prompt + 12 tactical tips + ai-coding-template fork）
2. Fork ai-coding-template GitHub — 內建 11 agents + 21+ commands 的 reference codebase
3. 如果你的團隊連基本 AI 協作習慣都還沒有（不只工程師，PM、QA 也要會跟 AI 講清楚需求）：可以先從 《AI 職場工作術》 這門課打底——P5 三階驗證是進階的工程紀律，前提是整個團隊已經習慣把工作講清楚給 AI 聽
4. 如果你 team 5-30 人卡在 adoption：考慮陪跑制（NT$50-80K/月，限量 2 位/月）— 不只技術，含 team 文化 + KPI 設計

詳細 Track B 模組包 sales page（Founding 50 NT$6,800 lifetime），或先加入 Skool 工程師圈 看免費內容。

Related Resources

延伸閱讀涵蓋同系列 PRP 文章、工具選型、零基礎入門，跨程度都能找到下一篇。

• 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 在地化 — 本系列 Blog 3，PRP loop + worktree 隔離完整拆解
• Vibe Coding 工具比較 2026 — 選 AI coding 工具的完整評測
• 什麼是 AI Coding？ — 零基礎入門定義
• Skool 工程師圈 — Track B 學員 lifetime member 入場

變更紀錄

這篇從初版到 D9 重定位重寫的版本異動記錄，方便追蹤內容什麼時候加了什麼。

版本	日期	變更
1.0	2026-04-29	初版（Plan 4 §Phase 7 Blog 1）
1.1	2026-07-22	D9 內容重定位重寫：擴充 token 成本控管 + junior 升級路徑 + 老實說邊界段 + 3 篇內鏈 + CTA 導 academy.cloud-f1.com