Claude Fable 5 由 OneHop 提供
← 全部文章
UseCase

把 Claude Code Review 當成由 CLAUDE.md 與 REVIEW.md 驅動的 pull request 關卡

2026年6月16日 6 分鐘閱讀

A warm editorial vector scene of a GitHub-style pull request passing through two labeled markdown gates, CLAUDE.md and R

Anthropic 在 2026 年 3 月 9 日推出 Claude Code 的 Code Review，還附上一個足以讓每個工程主管皺眉的數字：在 Anthropic 內部，每位工程師的程式碼產出一年內成長了 200%，於是 review 變成瓶頸（Anthropic）。這才是真正的重點。AI coding 沒有消滅 review 工作。它只是把壓力點搬了位置。

有用的回應不是「讓 Claude 批改自己的作業」。那只會養出一間很有禮貌的 bug 工廠。有用的回應，是把 Claude Code Review 變成一個可重複執行的 PR 關卡，而且裡面的規則是你的團隊真的相信的。

Anthropic 現在的設定文件讓這件事變得實際可行。Reviewer 可以透過留言 @claude review 觸發 review，而 Code Review 會讀取 repository 裡的 CLAUDE.md 檔案，以及 root-level 的 REVIEW.md。違反 CLAUDE.md 的地方會被視為 nit 等級的發現，而且 Claude 甚至能標出某個 PR 讓 CLAUDE.md 變得過時（Claude Help Center）。REVIEW.md 則是放 review-only 規則的地方，包括 Anthropic 給的那個範例：「任何新的 API route 都必須有 integration test。」

這一句話就是關鍵。別再要求 AI reviewer「小心一點」。開始把 repo 法律交給它。

一張流程草圖，顯示 pull request diff 進入 Claude Code Review，分流到平行 review agents，並檢查 C

問題：AI 讓 PR Review 更吵了

社群裡的爭論很混亂，因為兩邊其實都對。

在 Claude Code Review 的 Hacker News 討論串裡，開發者質疑價格、價值，以及一個 AI vendor 把 reviewer 賣給 AI-generated code 這件事本身的尷尬。一位留言者指向 Anthropic 自己的大型 PR 數據，把它解讀成 agentic development 品質的警訊；其他人則認為，深入的第二雙眼睛正是這個工具發揮價值的地方（Hacker News）。

Reddit 上則是同一場辯論的務實版本。在一個討論串裡，有開發者問大家是否真的信任 Claude-generated code 到可以跳過 review，因為 Claude 有時會寫出他們自己也看不懂的程式碼。回答很直接：review 它、驗證它、保持變更小，不要假裝委派出去就代表責任消失了（Reddit）。另一個討論串裡，大家討論用不同的 AI agents 來 review Claude 的輸出，但仍然要把那份 review 本身拿回 codebase 裡檢查（Reddit）。

我的看法：用 Claude review Claude 寫的程式碼沒問題，前提是你不要把它當成獨立判斷。把它當成一個非常快、非常照字面、擁有巨大 context 但沒有 ownership 的 junior reviewer。它應該抓到無聊的遺漏、跨檔案不一致、缺少測試、安全地雷、過時文件，以及那些人類 reviewer 很可能掃過去的地方。

它不該是最後的 approver。

Anthropic 自己也直接這麼說。Code Review 不會 approve PR，也不會自己 block PR。既有 review workflow 會保持不變（Claude Help Center）。所以這裡的「gate」是團隊關卡：Claude 還沒跑過之前，不給 human approval；Important findings 必須解掉或明確 waiver；PR author 必須處理 repo-specific rules。

這很無聊。很好。無聊的關卡能防事故。

設定：兩個 Markdown 檔案，兩種工作

Claude Code Review 有兩個重要的記憶表面。

CLAUDE.md 是共享的專案 context。它一般適用於 Claude Code sessions，不只用在 review。Anthropic 建議把它用來放 commands、conventions、簡短 architecture notes、硬性限制，以及已知陷阱。他們也建議讓它保持高訊號密度，大約控制在 200 行以下，因為它會被載入 context，即使 prompt caching 能降低 Enterprise sessions 裡重複 token 成本（Claude Help Center）。

REVIEW.md 不一樣。它放在 repository root，而且只用於 review。Anthropic 的 Code Review 文件說，它的內容會作為高優先級指示注入每個 review agent，並且是控制 severity、nit 數量、skip rules、repo-specific checks、verification standards，以及 re-review behavior 的地方（Claude Code Docs）。

我會這樣切：

FilePurposeGood rulesBad rules
CLAUDE.md所有 Claude 工作的專案記憶Build commands、architecture、「用 Zod 做 request validation」冗長歷史、模糊偏好、重複的 API docs
REVIEW.mdPR review policy「新的 API routes 需要 integration tests」泛泛而談的「寫乾淨程式碼」建議
CI config確定性執行Typecheck、unit tests、lint、migration checks編譯器能證明的事卻交給 LLM-only checks

把穩定 context 放進 CLAUDE.md。把 review 壓力放進 REVIEW.md。任何確定性的東西都放進 CI。

一張精簡比較表視覺圖，有三欄標示 CLAUDE.md、REVIEW.md 和 CI，顯示 context rules、review

API Routes 的真正關卡

假設一個 backend team 一直送出只有 happy-path unit tests、卻沒有 integration coverage 的 routes。Human reviewers 有時會抓到。Claude-generated PRs 讓情況更糟，因為 agent 很擅長產出看起來合理的 handler code，卻很不擅長記住團隊特有的 review 傷疤。

先從 CLAUDE.md 開始：

# Project conventions

- API routes live in `src/routes`.
- Integration tests live in `tests/integration`.
- Use `requireAuth()` on non-public routes.
- Validate request bodies with Zod schemas from `src/schemas`.
- Run `pnpm test:integration` before marking API work complete.

接著加上 root-level 的 REVIEW.md：

# Code Review Rules

Treat these as Important unless stated otherwise.

## API routes

If a PR adds or changes a file under `src/routes/**`:
- Flag missing integration test coverage in `tests/integration/**`.
- Flag routes without explicit auth, unless the route is listed as public.
- Flag request bodies that are not validated with a Zod schema.

Do not accept unit tests as a substitute for route-level integration tests.

## Evidence bar

For every Important finding, cite the changed file and the missing or conflicting evidence.
If the claim depends on a convention, cite this REVIEW.md rule.

最後那段很重要。LLM reviewers 會產出很有自信的胡說八道。要求 evidence，會迫使 review 把一個 finding 綁到檔案、行號，或明確 policy。它不會消除 false positives，但會把 review 的形狀從「憑感覺」改成「拿證據來」。

現在某個 PR 加了：

// src/routes/billing.ts
router.post("/billing/plan", async (req, res) => {
  const result = await updatePlan(req.body.planId);
  res.json(result);
});

一則好的 Claude Code Review comment 應該會像這樣說：

  • Important：src/routes/billing.ts 新增了一個 POST route，但看不到 auth。
  • Important：request body 直接讀取 req.body.planId，沒有 schema validation。
  • Important：沒有在 tests/integration/** 底下新增對應的 integration test。

Human reviewer 仍然要做決定。也許 router 在更上層套了 auth middleware。也許 integration test 放在 generated contract suite 裡。可以。只要這個關卡在 merge 前迫使團隊進行那場討論，它就完成任務了。

觸發它，但不要燒錢

Anthropic 提供三種 repository trigger modes：PR 建立後跑一次、每次 push 後都跑，或手動。手動代表在有人留言 @claude review 之前不會產生成本；之後，該 PR 的額外 push 會自動觸發 review（Claude Help Center）。

對多數團隊來說，我不會一開始就用「每次 push 後」。Anthropic 說 Code Review 平均大約 20 分鐘，通常每次 review 成本約 15 到 25 美元，會隨 PR 大小與複雜度增加（Anthropic）。跟 production incident 比起來很便宜。跟跑 ESLint 比起來就很貴。

使用分層關卡：

  1. 每個 PR 都跑正常 CI。
  2. 有風險的 PR 才跑 @claude review。
  3. 大型 PR、auth 變更、payments 變更、migrations，以及 public API 變更，在 human approval 前必須經過 Claude review。
  4. 重大變更後再重跑 Claude review，不要每個 typo fix 都跑。
  5. Humans 擁有最後 approval。

一個輕量的 GitHub PR checklist 可以把關卡明確寫出來：

## AI Review Gate

- [ ] CI is green.
- [ ] `@claude review` has run, or this PR is exempt.
- [ ] Important findings are fixed or explained.
- [ ] If this PR changes conventions, `CLAUDE.md` is updated.
- [ ] If this PR changes review policy, `REVIEW.md` is updated.

如果你偏好在自己的 workflow 裡執行 Claude，Anthropic 的 GitHub Actions 文件展示了 anthropics/claude-code-action@v1 和 code-review plugin configuration，並附上常見提醒：API keys 要放在 GitHub Secrets（Claude Code Docs）。那條路給你更多 CI 控制。Managed Code Review 這條路則給你 Anthropic 描述的更深層 multi-agent reviewer。

不要把兩者混為一談。一個是可程式化 automation。另一個是付費的 depth-first reviewer。

一張 review triggers 決策樹圖，分支包含 small PR、risky PR、large PR 和 repeated pushes，最後結束於

訣竅：讓 Claude Review 合約，不是品味

糟糕的 REVIEW.md 讀起來像幸運餅乾：

Please ensure the code is clean, maintainable, secure, and well tested.

那只會產出一團糊。

好的 REVIEW.md 會把傷疤編碼進去：

## Database migrations

Flag as Important if:
- A migration adds a non-null column without a default on an existing table.
- A migration backfills data without batching.
- Application code starts reading a new column before the migration is deployed.

Skip:
- Formatting comments in generated Prisma client files.

這正是 AI review 變得有用的地方。它不是取代 senior engineer 的品味。它是在每個 PR 上重播團隊的 institutional memory。

幾條很好用的規則：

## Re-review behavior

On the first review, report Important and Nit findings.
On later reviews of the same PR, suppress new Nits unless they are directly caused by the latest push.

## Test policy

Flag missing tests only when the changed behavior is observable through a stable public interface.
Do not request snapshot tests for purely visual copy changes.

## Security policy

Flag any new endpoint that:
- Accepts user input without validation.
- Performs authorization by trusting a user-provided account ID.
- Logs tokens, session IDs, API keys, or full request bodies.

注意少了什麼：「讓程式碼更優雅」。Humans 可以在 review 裡爭論 elegance。Claude 應該檢查 contracts。

這些討論串漏掉了什麼

HN 和 Reddit 的辯論一直繞著同一個問題打轉：AI 該不該 review AI code？

問錯了。

真正的問題是：review 的哪些部分，你願意明確寫出來？

如果你的 review culture 都活在 senior engineers 的腦袋裡，Claude Code Review 會顯得吵雜又任意。如果你的 review culture 被寫成 repo rules，它就會變成 multiplier。CLAUDE.md 告訴 Claude 這個 project 怎麼運作。REVIEW.md 告訴 Claude 你的團隊拒絕 merge 什麼。

這也回答了「為 Claude 寫文件」的抱怨。是的，開發者現在正在為 agent 寫 docs。這聽起來很蠢，直到你意識到那些 docs 同時也是 onboarding material、review policy 和 incident prevention。一份好的 CLAUDE.md 對 humans 來說，也是一份更好的「這個 repo 如何運作」文件。

真正鋒利的邊緣是 accountability。如果 Claude 漏掉 bug，還是你 merge 的。如果 Claude 捏造 bug，你還是需要拒絕它。如果 Claude review 自己的輸出，你仍然需要獨立訊號：tests、type systems、static analysis、observability，以及一個理解這次變更的 human。

把 Claude Code Review 當成關卡，不要當成法官。讓它每次都問那些煩人的問題：

  • Integration test 在哪裡？
  • Auth 在哪裡 enforce？
  • 這個 PR 有沒有讓 CLAUDE.md 變成假的？
  • 這個 generated file 值得留言嗎？
  • 這個 finding 是由 code 支撐，還是只是直覺？

用在對的 PR 上，這就足以回本。

用同樣的設定試試 Claude Fable 5 on OneHop，drop-in，並且從 $10 免費額度開始。

延伸閱讀：Claude Fable 5 入門。