大多數關於與 Agent 協作的指引，都在為 Agent 的理解能力做最佳化：context files、MCP servers(MCP 伺服器)、documented skills、餵入正確的資訊讓 Agent 能夠對你的 codebase 進行推理。卻很少人討論如何確保人類仍能理解 Agent 正在改動的系統。

Addy Osmani（艾迪·歐斯馬尼）寫了一篇很棒的文章，談到 comprehension debt(理解債)——AI 生成程式碼的隱藏成本。AI 產生程式碼的速度遠快於人類能夠評估的速度，而這個落差掏空了團隊對自身程式碼庫的理解。

我們在為 Agent 的理解能力做最佳化，同時人類的理解卻在流失。正是這個落差，讓我開始仔細思考自己一直以來的工作方式，以及在能夠快速前進、又不失去讓程式碼庫保持健康的理解之前，必須先建立哪些基礎。

程式碼審查原本在做的事

審查不只是品質保證。它是理解在團隊中擴散的方式。當有人仔細閱讀你的程式碼到足以核准的程度時，他們正在建立一個關於改了什麼、為什麼這樣改的心智模型。這就是團隊能對自身程式碼庫保持集體方向感的機制。

Agent 為這個機制帶來壓力，不是因為它讓程式碼變差，而是因為它產生程式碼的速度，快於審查流程原本設計所能處理的範圍。有時候快速前進並信任 Agent 是正確的決定，尤其是在測試覆蓋完整、已被充分理解的程式碼庫區塊。但一旦出錯，後果會疊加。每一次未被充分理解的變更，都會讓下一次審查變得更沒意義，因為你是在用一個已經偏移的心智模型去推論新的程式碼。

從嘗試中學到的事

我一開始遇到這個問題時的直覺是從流程著手。把 Agent 產生的大型 changesets 拆成更小、依序排列的 MR，每一個都講述故事中連貫的一部分，每一個都可以獨立部署，就像在快轉之後的慢動作重播。這麼做確實有其道理。我曾將一個大型 MR 重新整理 commits，讓審查者可以逐一審閱，結果順利合併。讓變更易於理解、說一個連貫的故事，永遠是正確的直覺。

但我同時也有五個堆疊在 legacy codebase 上的 MR 正處於草稿狀態。我理解這些變更在做什麼，但我不信任現有的測試覆蓋率能捕捉到可能出錯的副作用與功能行為。缺乏這份信心，整個變更底下就隱含著需要人工驗證的期待，而這等於是要求審查者去承擔你尚未處理的風險。

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

現在的理解是什麼樣子

它不再是逐行審閱，那已經不可行，假裝做得到只會讓某些審查淪為形式。但它也不是什麼都不做。我認為它在三個層次上運作。

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

第二是架構面：我們是否大致理解這些變更如何運作、能否更新我們對系統的心智模型？這是 Agent 可以直接幫上忙的地方。請 Agent 摘要 changeset 中有意義的決策，不是機械式的變更，而是人類需要評估的選擇：曾考慮過哪些替代方案、哪些是不顯而易見的決策、作者在 code walkthrough 中會特別標示什麼。以此作為 MR 描述的基礎。我已將這個做法封裝成一個你可以放進自己工作流程的 agent skill(agent 技能)，它會產生結構化的 MR 描述與 commit 結構建議，你可以審閱並用來幫助讓 Agent 產生的 changesets 對審查者來說更易讀。

第三是標準面：程式碼是否符合團隊約定的規範？Linting 會自動處理掉其中很大一部分，任何能推進 linter 的事，就能讓人類審查者少花一份注意力。對於 linting 無法捕捉的部分，我之前寫過關於 agent skills 的文章。如果你的標準文件完整到足以引導 Agent 寫程式碼，那它也完整到足以引導 Agent 來審查程式碼。

展現你的思考過程

好的作者責任一直都很重要，現在更是如此。審查者並沒有參與你的 Agent 協作過程，他們對於你想做什麼、權衡過哪些取捨、Agent 做了哪些你有意識保留下來的決策，沒有任何背景理解。這些脈絡不會透過 diff 自動傳遞，你必須有意識地傳遞它。

這意味著要標示出需要人類審查者關注的架構決策，並描述改了什麼、為什麼這樣改。這意味著要仔細思考 commit 結構，讓變更的故事在審查時、在別人還沒讀程式碼之前就已清晰可見。這意味著要寫出能證明你理解 Agent 產出內容的描述，因為如果你無法清楚解釋，就有風險代表你已經轉為被動委派。

艾迪·歐斯馬尼引用的 Anthropic 研究發現，將 AI 用於被動委派、只是讓它產生程式碼而未保持主動參與的工程師，在理解度測驗中的得分，顯著低於將 AI 作為思考工具的人。Agent 並不會取代工程師。它是一項工具，你仍然需要理解它在做什麼、為什麼這樣做，而不只是知道它能動。這份理解正是你的審查者應得的：引導他們走向理解，而不是讓他們從零開始重建。

並非每個變更都帶有相同的風險、或需要相同深度的審查，而明確指出這一點也是好的作者責任的一部分。Ship / Show / Ask 是處理這個問題很有用的框架，它根據變更的性質與你和團隊之間已建立的信任來校準審查的程度。

快速前進需要什麼

那五個處於草稿狀態的 MR，並不是被流程或我對程式碼的理解所卡住。它們被卡住是因為安全網還沒就位。這是首要義務，在發布前就把它補上，而不是發布後才補。

但只有紮實的測試套件而沒有做好作者責任，只代表你的審查者能確認沒有東西壞掉。這不等同於理解改了什麼、為什麼這樣改，或是 Agent 做了哪些你有意識保留下來的決定。Agent 給你速度，讓這個速度真正成立的，是你有能力解釋你建了什麼、為什麼這樣建，而不只是它能動。