Anthropic 讓 AI 程式變可審

Anthropic 的 review 工具把 AI 寫的程式拉回可審查、可控管的流程，重點是先抓 bug 與風險，再談速度。

我用 AI coding 工具一陣子了，老實說，一開始真的會上癮。你丟需求，它吐程式；你改一點，它再補一點。看起來像是自己變快了，團隊也像是少了一個瓶頸。但我越用越覺得不對勁：diff 很漂亮，測試卻常常只寫一半；功能看起來能跑，細節卻像是有人把風險藏在註解後面。最煩的是，這種 code 不是那種一眼看出來很爛的東西，它是「很像對」的東西。也就是這種東西最會害人。

我會注意到 Anthropic 這個 code review 工具，是因為 SaaS Ultra 的文章 Anthropic Launched a Code Review Tool to Check the Flood of AI-Generated Code — The Problem It Solves Is Real。這篇不是在吹產品多神，反而很務實：AI 生成的 code 變多了，review 的人沒變多，最後卡住的不是寫 code，而是把 code 審乾淨。文章沒有提供工具的實際使用數字，所以我不會亂編；但它把問題講得很準，準到我看完只想說，對，這就是現在很多團隊卡住的地方。

AI 把寫 code 變便宜，review 卻沒有跟著變便宜

“The faster developers use AI to write code, the more code that exists in production that nobody has fully reviewed.”

翻譯一下就是：產 code 的成本掉下來了，但建立信任的成本沒有。這件事很殘酷，因為很多團隊現在還在用舊思維看 AI coding，覺得只要生成速度夠快，整體就會更有效率。問題是，真正拖慢你的從來不是「寫不出來」，而是「不敢合」。你可以叫模型十分鐘吐出一個 feature，但你還是得知道它怎麼處理 auth、錯誤、邊界值、資料外洩，還有那些看起來小、其實會炸的副作用。

我之前看過一個 permissions layer 的例子，AI 幫同事把功能骨架搭得很漂亮，命名也乾淨，結構也順。結果 review 的時候差點直接過掉，因為整體太像正確答案了。後來我們才發現其中一個分支在條件失敗時會默默放行。這種 bug 很陰，因為它不是「明顯錯」，而是「太像對」。AI 很會把錯誤包裝成可讀的程式，讓人以為自己省了時間，其實只是把風險延後到 production。

實操上，我現在會先問一個很土但很有效的問題：這段 code 是不是「可審查」？不是可不可以跑，而是 reviewer 能不能在五分鐘內說出它的行為、失敗模式和風險。不能的話，就不是加速，是債務。

• 把 AI-authored diff 和 human-authored diff 分開標記。
• 先看行為與風險，不要先看格式。
• 把 review 時間也當成 delivery 指標，不要只看產出。

這不是 linter，別拿格式工具來假裝懂語意

Anthropic 這類工具真正有意思的地方，不是它會不會抓 typo，而是它想處理「這段 code 到底在幹嘛」這件事。linter 很有用，但它主要管的是語法、風格、一些明顯錯誤。它不會在意某個 credential 被塞進哪個流程，也不會知道 retry loop 放在熱路徑裡會不會變成 DoS 風險。這些東西不是格式問題，是行為問題。

也就是說，這種 review 工具如果真的有價值，重點一定是語意，不是表面。它要能看出 intent mismatch：作者以為自己在做 A，實際上 code 做的是 B。這種差距在 AI code 裡特別常見，因為模型很會補齊表面結構，卻不一定懂你真正想守住的邊界。

我自己碰過最煩的狀況，是生成的整合碼把 API key 從 env 讀進來後，又順手塞進 log path。作者沒注意，reviewer 也沒注意，因為那段 code 看起來太普通了。這種問題不會靠 prettier 或 lint 解決，得靠能讀懂行為的 review。你要的是「這段會不會把資料送錯地方」，不是「這段有沒有少一個分號」。

實操寫法很簡單：你在挑工具或設 review 流程時，不要問它會不會標記 style issue，要問它會不會指出 intent mismatch、credential handling、auth flow、data validation、error propagation。答不出來，就別把它當 review 工具，最多算半個 helper。

• 先拿 auth、billing、資料存取路徑試。
• 要求工具說明「為什麼危險」，不是只列出可疑行。
• 搭配測試，不要拿它取代測試。

真正的瓶頸是 review backlog，不是產 code 的速度

我覺得這篇文章最準的一點，是它把 review backlog 當成風險，而不是流程瑕疵。這差很多。因為大家很愛談 AI 讓 coding 變快，卻很少有人承認：當 code 變多，review 端不會自動長大。人還是那些人，時間還是那些時間。你如果讓模型一天吐十個 PR，最後卡住的一定不是模型，是人類 reviewer。

翻譯一下就是，code review 正在變成一層基礎設施，不是禮貌性關卡。以前你可以靠一個 senior engineer 快速掃過去，現在如果 AI 參與度高，那種做法很快就會崩。因為 reviewer 不只要看懂 code，還要知道這段是不是 AI 生成、是不是高風險、是不是需要更深的檢查。這不是「多做一點 review」而已，這是整個 pipeline 要重設。

我看過太多團隊把 agentic workflow 玩得很嗨，開一堆 code-producing agent，然後 PR queue 堆得像欠費單。大家都在 demo 裡看速度，沒人在意後面那排審查的人已經快被淹死。Anthropic 這種工具有價值，不是因為它很酷，而是它直接提醒你：如果產量上升，inspection 也要升級，不然你只是把風險做大。

實操上，我會把 review 當 pipeline 設計：低風險走快道，高風險走慢道。不要所有 PR 都用同一套規則，不然最後就是大家一起排隊、一起疲乏、一起亂過。

• 把 diff 分成 low / medium / high risk。
• auth、payments、secrets 一律走加強審查。
• 把 review latency 納入團隊指標。

Security team 會被拉進每一個 AI PR

文章裡提到 WordPress 7.0 的 AI API key vulnerability，這種例子我一看就懂，因為它很像 AI code 最容易漏掉的地方：看起來很順，實際上把敏感資料處理搞壞。模型可以幫你把 credential 流程寫得很整齊，但它也可能順手把 key 留在 log、cache、錯的 storage path，然後大家還覺得沒什麼，因為 code 沒報錯。

也就是說，AI review 不只是 developer convenience，它其實已經是 security posture 的一部分。這點我很堅持。你如果把 AI 當成單純的產能工具，最後很容易讓團隊對風險麻木。速度很快沒錯，可是只要一次 secret handling 出包，前面省下來的時間全部都要還回去，還附利息。

我之前也遇過一個 generated integration snippet：一開始從環境變數拿 API key，後面卻把同一把 key 帶進 log。作者根本沒意識到，因為那段 code 長得太無害。這就是我會希望 review 工具幫忙抓的東西，不是說它要取代安全工程師，而是至少先把明顯的高風險路徑挑出來。

實操寫法是：把 security review 前移，不要等 PR merge 後才做稽核。只要工具能提前提示 unsafe serialization、弱 input validation、敏感資訊外洩，你就少掉很多「看起來很快、其實很貴」的事故。

如果你想對照整個 AI 開發工具鏈，可以看 Claude、Cursor、GitHub Copilot、Sonar。但我先講白一點：沒有一個工具會自動幫你把 review discipline 做好。

Anthropic 其實是在幫市場命名一個新問題

這篇文章還有一個我很在意的點：它不是只在講功能，而是在幫一個新類別定義邊界。傳統 code review 工具大多是為人類寫的 code、傳統 static analysis、和比較穩定的開發節奏設計的。可 AI 生成 code 的失敗型態不一樣：量更大、錯得更像對、intent drift 更難看出來。

翻譯一下就是，很多周邊產品都要重新回答一個問題：你怎麼證明這段輸出可信？尤其當 input 是機器寫的，reviewer 又已經很忙的時候。這不只是 testing、documentation、security auditing 的問題，連 agent orchestration 都會被拉進來。因為只要生成速度夠快，後面每一層都會被迫升級。

我看這類產品，最怕的就是大家拿「AI for developers」這種大標籤亂包。講白了，誰都知道這很空。真正有用的是把問題說清楚：你到底在解 review、testing、security，還是 documentation？如果連痛點都講不準，產品通常也不會準。

實操上，如果你自己在做工具或內部流程，我會建議先把問題切小。不要想一次解所有 AI code 的治理問題，先解 review。review 解不掉，後面都只是補洞。

可抄的模板

# AI-generated code review policy（可直接貼進團隊 handbook）

## 目的
任何由 AI 生成或大量協助產出的程式碼，在 merge 前都必須經過可解釋的人工 review，並補上必要的風險檢查。

## 適用範圍
- 使用 Claude、Cursor、Copilot 或其他 AI 工具產出的新 code
- AI 協助的大型 refactor
- 任何會碰到 auth、billing、permissions、secrets、data access 的變更
- 任何 reviewer 無法快速說明行為與風險的 diff

## Review 原則
1. 先看行為，不先看風格。
2. 檢查 intent mismatch：這段 code 實際做的事，是否等於作者想做的事？
3. 檢查 input validation、error handling、edge cases。
4. 檢查 secret handling、logging、data exposure。
5. 任何影響 production 行為的 AI 生成邏輯，必須有對應測試。
6. 如果 reviewer 不能用白話說明這段 code，不能 merge。

## 風險分級
### Low risk
- 文案修正
- 小型 UI 調整
- 不進 production 的腳本

### Medium risk
- business logic
- API integration
- background job

### High risk
- authentication
- authorization
- payments
- secrets
- data pipeline
- security-sensitive code

## 各級要求
### Low risk
- 人工 review
- 若適用，基本測試

### Medium risk
- 人工 review
- unit / integration tests
- AI-assisted review pass

### High risk
- 人工 review
- AI-assisted review pass
- security review
- failure mode tests
- code owner 明確批准

## AI-assisted review 提示詞
在人工 review 前，先把 diff 丟給 AI 做第一輪檢查：

"Review this code for logical correctness, security risks, edge cases, and intent mismatch. Identify anything that could fail in production, expose data, weaken auth, or behave differently than the author likely intended. Summarize findings by severity and explain the risk in plain language."

## Merge checklist
- [ ] 我理解這段 code 在做什麼
- [ ] 我理解它怎麼失敗
- [ ] 我檢查過 security 風險
- [ ] 我檢查過 edge cases
- [ ] 高風險路徑有測試
- [ ] 必要時 code owner 已批准
- [ ] 我可以把這段 code 用白話講給另一位工程師聽

## 升級規則
如果 diff 是 AI 生成的，而 reviewer 無法清楚說明其行為，就不准 merge。

這份模板我會直接拿去改成團隊規範，因為它夠土，土到能落地。你不需要再發明一套漂亮但沒人看的制度。你需要的是讓大家知道：AI 可以幫忙寫，但不能直接幫忙背責任。

來源我拆的是 Jitendra Vaswani 在 SaaS Ultra 的文章：https://www.saasultra.com/anthropic-launched-a-code-review-tool/。文中的觀點是原始素材，我上面這份流程模板和團隊做法是我依照這個問題自己整理出來的可用版本。