大多數關於與 Agent 協作的指引，都在優化 Agent 的理解能力：context 檔案、MCP 伺服器、文件化的技能（skills）、餵給它正確的資訊，讓 Agent 能對你的程式碼庫進行推理。卻很少有人討論如何確保人類仍然理解 Agent 正在改動的系統。

Addy Osmani 曾寫過一篇很棒的文章談 comprehension debt（理解債）—— AI 生成程式碼所帶來的隱藏成本。AI 產生程式碼的速度遠遠快於人類能夠評估的速度，而這個落差會掏空團隊對自身程式碼庫的理解。

我們不斷優化 Agent 的理解能力，卻讓人類的理解逐漸流失。正是這個落差，讓我開始認真思考自己的工作方式，以及在能夠快速推進、又不失去維持程式碼庫健康所需的理解之前，究竟需要先建立哪些基礎。

程式碼審查原本在做的事

審查不只是品質把關。它是理解在團隊中擴散的方式。當有人仔細閱讀你的程式碼到足以批准的程度，他其實正在建立對「改了什麼、為什麼改」的心理模型。正是透過這個機制，團隊才能共同掌握自己的程式碼庫。

Agent 讓這個機制承受壓力，不是因為它把程式碼寫得更差，而是因為它產生程式碼的速度，超過了審查流程原本設計能處理的負荷。有時候快速推進並信任 Agent 是正確的選擇，特別是在測試覆蓋完整、大家都很熟悉的程式碼區塊。但一旦出錯，後果會不斷累積。每一次沒有被真正理解的改動，都會讓下一次審查變得更沒意義，因為你已經是在用一個早已偏移的心理模型，去推敲新的程式碼。

實際嘗試後的體悟

我一開始遇到這個問題時的直覺是靠流程來解決。把 Agent 產生的大型變更拆成一連串較小的 MR，每個 MR 講述故事中連貫的一部分，每個都能獨立部署，就像在快轉之後用慢動作重播一樣。這麼做確實有它的道理。我曾把一個大型 MR 重新整理 commit，讓審查者可以一個一個檢視，最後順利合併，沒有遇到什麼阻礙。讓變更易於閱讀、說一個連貫的故事，永遠是正確的直覺。

但我手上也有五個堆疊在舊有程式碼庫上的 MR，到現在還放在草稿狀態。我理解這些改動在做什麼，卻不信任現有的測試覆蓋率能捕捉到可能出錯的副作用和功能行為。少了這份信心，整個變更背後就隱含著需要人工驗證的期待，而這等於是把你自己沒有處理掉的風險，丟給審查者去承擔。

流程可以讓變更變得更易讀，卻無法取代根本不存在的安全網。

現在的「理解」是什麼樣子

那已經不是逐行審查了，那在現在已經不可行，假裝還做得到，只會讓某些審查淪為形式。但也不是完全放掉。我認為它可以分成三個層次來運作。

第一層是行為面：它是否如預期運作？這正是測試覆蓋率成為團隊最重要投資的地方。真正涵蓋使用者實際會走過的路徑、涵蓋真實行為的覆蓋率，再加上能在編譯時期就攔住型別錯誤的型別安全。如果編譯器和測試套件都有確實發揮作用，審查者就不需要逐行追蹤。而那些覆蓋率薄弱、或團隊一直依賴人工測試的地方，正是 Agent 帶來的速度不再是速度、而變成疏忽的地方。

第二層是架構面：我們是否大致理解這些改動是如何運作的，能否據此更新對系統的心理模型？這一點 Agent 可以直接幫上忙。請 Agent 總結變更集中有意義的決策，不是機械式的改了什麼，而是人類需要評估的選擇：曾考慮過哪些替代方案、哪些是不直觀的決策、如果是作者親自做程式碼走讀（walkthrough）會特別點出來的地方。把這些當作 MR 描述的基礎。我已經把這個做法打包成一個agent skill，可以直接放到你自己的工作流程裡，它會產生結構化的 MR 描述和 commit 結構建議，讓你可以審視、運用，幫助審查者更容易讀懂 Agent 產生的變更。

第三層是規範面：程式碼是否符合團隊約定好的規範？Linting 會自動處理掉其中很大一部分，任何能丟給 linter 的事，就能讓人類審查者少花一分注意力。至於 linter 抓不到的部分，我之前也寫過關於agent skills 的文章。如果你的規範已經寫得足夠清楚、足以指引 Agent 寫程式，那它也應該清楚到足以指引 Agent 來審查程式碼。

把過程攤開來

好的作者責任一直都很重要，現在更重要。審查者並沒有參與你的 Agent 對話過程，他對你想做什麼、權衡過哪些取捨、Agent 做了哪些你經過思考後決定保留的決策，完全沒有背景脈絡。這些脈絡不會透過 diff 自動傳遞，你必須有意識地把它傳遞出去。

這意味著要標出需要人類審查者關注的架構決策，並說明改了什麼、為什麼改。意味著要仔細思考 commit 的結構，讓變更的故事在別人還沒開始讀程式碼前，就已經在審查中一目了然。也意味著要寫出能證明你真的理解 Agent 產出內容的描述，因為如果你無法清楚解釋，就代表你很可能已經退化為被動的委派。

Addy 引用的Anthropic 研究發現，那些把 AI 當成被動委派工具、只是讓它產生程式碼而自己沒有保持積極參與的工程師，在理解度測驗中的分數，顯著低於那些把 AI 當作思考工具來用的人。Agent 並不會取代工程師。它是個工具，你仍然需要理解它在做什麼、為什麼這樣做，而不只是知道它能動。那份理解也是你的審查者應得的：引導他們去理解，而不是讓他們從零開始自行拼湊。

並非每個變更都帶有相同的風險，也不都需要同樣深度的審查，而把這一點說清楚，也是好的作者責任的一部分。Ship / Show / Ask 是一個很好用的框架，可以根據變更的性質以及你與團隊之間已建立的信任，來調整審查的強度。

想要快速推進，需要什麼

那五個卡在草稿的 MR，並不是被流程卡住，也不是因為我不懂程式碼。卡住的原因是安全網還沒到位。那是首要的責任，要在發佈前就把它補好，而不是發佈後才來補。

但只有堅實的測試套件、卻沒有做好作者責任，也只代表你的審查者能確認沒有東西壞掉。這跟理解「改了什麼、為什麼改、Agent 做了哪些你經過思考後決定保留的決策」是兩回事。Agent 給你的是速度，而讓這個速度真正成立的關鍵，是你能否解釋你做了什麼、為什麼這樣做，而不只是證明它能動。