10 年前在群暉，沒過 review 的 commit 是不能進 release build 的，但現在我幾乎沒在「逐行 review code」了⋯
剛出社會在群暉（Synology）的時候，我學到的 review 是這樣的 — 兩個人坐下來，開著 DiffMerge，一行一行看。那時候要求嚴到一個程度：任何一個 Git commit 沒有經過 review，絕對不准進 release build，而且還要 coder 講一次、reviewer 問問題，在 commit message 標注 reviewer。
那套訓練到現在我都很感激。它逼你養成一種下意識 — 看到一段 code，會反射性地想「這裡會不會 race、這個 edge case 有沒有顧到、這個 naming 之後會不會誤導人」。
（然後 TMD 徐名蔚 會說：「你看，multithreading lock 寫反了，還不是靠我抓出來的」）
問題是，2026 年，有需要嗎？
真的是⋯有需要嗎？
逐行看，會讓人變成 bottleneck
現在的狀況很簡單 — AI 產出的量，已經多到不可能再用「兩個人坐下來一行一行看」的方式處理。而且不只是量，是速度。我這邊一個 session 跑下來，產出的 code 量可能是以前一整天手寫的好幾倍。如果我還堅持每一行都自己過一遍，那整條流水線最慢的環節，就會變成我這個人。
老實說，這是一件很反直覺的事 — 越資深、看得越仔細，就越可能變成那個拖慢全隊的瓶頸。
我從去年 11 月之後就沒有實際寫過一行 code，但這半年我一直在想的就是：那「嚴謹」這件事，到底該擺到哪裡去。
嚴謹搬家
Chad Fowler 有一個講法我很喜歡，叫 Relocating Rigor — 嚴謹度不會因為 AI 進來就消失，它只是換了位置。
以前嚴謹集中在「中間那層」 — 也就是逐行看 code 對不對。現在那一層可以交出去了，嚴謹往兩頭搬：往上游搬到 spec 跟 intention，往下游搬到自動化的 verification。中間被掏空的那層，就是給 agent 跟不同 model 去填的。
所以我現在的 review，基本上只剩兩個真正重要的方向 — 一個在最前面，一個在最後面。
一、上游：Intention 與 Spec 的 review
這是現在最該花時間的地方。
在 AI 動手實作之前，我要先把三件事確認清楚：
- spec 對不對
- 業務需求有沒有抓到
- 我的 intention 有沒有被正確翻譯成它聽得懂的東西
這層完全是人工在做的，沒辦法外包。因為「這個東西該不該做、方向對不對」這種判斷，本來就不是 code-level 的問題。
我自己的習慣是 — 在 agent 開始寫之前，我就已經先把真正該長成什麼樣子的架構原型看過一遍了。等於我先在腦袋裡（或在一張圖上）把方案 review 完，才放它去做。
Addy Osmani 講過一句我覺得很到位的話，大意是現在 reviewer 的角色更像 editor 或 architect，而不是逐行檢查的 inspector。我目前的體感完全就是這樣。
二、下游：架構的 review，但我不看 code，我看圖
實作完之後，我要 review 的是架構層級的東西 — 擴展性、穩定性、高流量下會不會垮、延遲壓不壓得下來。
這邊有一個事實我自己要老實承認 — 直接讀 AI 整理的 MD 或讀 AI 生成的程式碼對我來說其實非常吃力，一來太多、二來太雜。Anthropic 是有建議用 HTML 格式來呈現輸出啦，但我到現在還是不太想用這種還要額外寫一個消耗一堆 Token 的格式。
所以我的做法是：要求 AI 先產出一張 Conceptual Map 或 Conceptual Diagram，我直接看那張圖（一定是純文字）。這時候我做的事情，本質上就是一個 Technical Architect — 我看的是整個大架構長得對不對，而不是某一行寫得漂不漂亮。
我現在看的，不是這行 code 對不對，是這個 agent 到底有沒有在做我要它做的事。
真的逼不得已才會進去逐行看 — 通常是 AI 已經卡太久，怎麼弄都做不出我要的東西，那時候我會捲起袖子下去翻 Code。因為說真的，現在寫 code 太快了。只要方向錯，我直接整批廢掉重來就好，根本不值得花時間去逐行修一份方向就錯的東西。
三、中間那層，交給 Cross Model 跟 Cross Context
那中間被掏空的逐行檢查，誰來做？
兩個概念 — Cross Model 跟 Cross Context。
Cross Context 的意思是：review 的那個 agent，不要給它「產出時的對話歷史」。讓它在一個乾淨的 session 裡，只看最終產物。這跟人類世界「不要讓寫 code 的人 review 自己的 code」是同一個道理 — 寫的人知道太多，他會自動腦補那些其實沒寫出來的東西。有一篇講 Cross-Context Review（CCR）的研究就是在驗證這件事，光是把 context 切開，抓錯的能力就上升。在 Claude Code 裡，sub-agent 天生就是這個 — 每次叫一個 sub-agent，它就是一個全新的 context。
Cross Model 則是換一個 model 來看。不同架構的 model，blind spot 是不一樣的。A model 寫的時候會習慣性漏掉的東西，換 B model 來看，往往一眼就抓到。我自己有時候就會調 codex 去看 Claude 寫的東西，反過來也行。
最近 superpowers 這個 plugin 在做的兩段式 review 也是類似的精神 — 先做 functional review，再做 quality review，兩段分開跑，抓到的問題類型不一樣（方向我蠻認同）。
四、防止 agent 偷懶 — Acceptance Metrics 一定要先寫
這裡有一個很實際的坑 — AI 會 rationalization，也會 hallucination。白話講就是：它有時候會「合理化」自己沒做完的事，跟你說「這樣就可以了」，或是直接幻想出一個其實不存在的結果。
對付這個，靠的還是 Cross Session 的驗證 — 用另一個 agent、在另一個乾淨的脈絡裡，去檢查它到底有沒有真的做到。
但驗證要有效，前提是驗收指標（Acceptance Metrics）要先定義得非常清楚。
- 指標夠明確，AI 就沒有模糊空間可以敷衍
- 指標含糊，它就會用最省力的方式「交差」
至於每個案子的 acceptance metrics 具體怎麼訂 — 老實說這個要看 case，沒有萬用解，我自己也還在一個個磨。
所以現在到底怎麼落地
把上面整理成我目前實際在做的三件事：
- 把腦力集中在 intention 跟業務邊界的切割 — 怎麼定義意圖、怎麼把不同的業務邏輯切乾淨，這是我現在花最多時間的地方
- 在 AI 動手前，先把架構原型看過一遍 — 等它開始做的時候，是照著一個我已經點頭的方案在跑
- 後期的 code review 大幅簡化 — 因為它是照預定架構在實作，我最後要確認的，其實只剩 bounded context 有沒有守住、邊界有沒有跑掉
這套東西，文件 review 其實一模一樣 — 我也不會逐字讀一份長 spec，我要 AI 先給我那份文件的 conceptual map，先確認骨架對了，細節再說。
繞了一圈，我發現 Martin Fowler 最近正式定義的 Refinement Code Review 講得很準 — review 不再是 merge 前那道「准你過 / 不准你過」的閘門，而是一個持續精煉、focus 在 codebase 長期健康的活動。
對我來說，那道閘門已經往兩頭搬走了。前面搬到 intention，後面搬到 verification。
中間那層，就盡量不碰。碰了，往往代表我前面 spec 或是後面 verification 沒寫好。
那學怎麼 review 容易嗎？
超級難的，要乖乖地把 computer science 學紮實。