代碼不再是瓶頸，理解才是

隨着編碼代理的普及，軟件開發中稀缺的資源正在發生變化。生成一個看似合理的代碼變更所需的時間越來越少，但團隊仍需決定該變更是否合適、如何重塑系統以及下一步該做什麼。通過的測試並不能回答這些問題。這就是“可解釋性鴻溝”。模型可以承擔更多上下文並並行工作，但人類的理解能力卻無法以同樣的方式擴展。瓶頸從生產代碼轉向了足夠理解代碼以指導它。當團隊無法解釋一個變更時，它就不再塑造系統，而是開始接受輸出。

大多數審查界面從文件、行和註釋開始。這些證據必不可少，但當一個系統變更涉及路由、提供者、模板、測試和配置時，從這裏開始是很糟糕的。審查需要更高層次的抽象，但並非要求盲目信任的摘要。它需要一條從意圖到系統行為再到代碼的路徑，並且每個聲明都可追溯到差異。

理解保持判斷力活躍。審查者的工作不是統計更改的文件數量，而是回答一組不同的問題：系統層面發生了什麼變化？系統的哪些部分一起移動？邊界和假設在哪裏？什麼值得人類關注？這個設計是否應該成為系統的一部分？測試、靜態分析和代理可以驗證更多的實現細節，但人們仍需決定邊界是否合理、權衡是否值得、以及變更是否將系統引向有用的方向。如果沒有一個對變更的工作模型，審查者只能批准或拒絕；有了它，審查者可以改進設計、質疑假設或將變更與下一個決策聯繫起來。

差異是證據，而非路線。倉庫路徑告訴審查者代碼的位置，但不能解釋為什麼多個文件一起更改或哪個文件應該先讀。倉庫按實現組織代碼，而審查者則思考行為和決策。一個行為可能跨越路由、提供者、配置文件、模板和測試。差異仍然是確鑿的證據，但它需要一種有用的閲讀順序。

同一個變更，兩種閲讀順序。CodeRabbit 最近引入了“變更堆棧”，這是一種審查視圖，根據系統行為將相關編輯分組為命名路徑，然後將每條路徑鏈接回確切的文件和行。以 TanStack/cli 拉取請求 #490 為例，該變更涉及 45 個文件，涵蓋認證、環境處理、模板、包配置和測試。變更堆棧將相同的差異組織成基於相關係統行為的六條審查路徑。這兩種視圖回答不同的問題：GitHub 顯示代碼在哪裏更改，變更堆棧則提出哪些更改應該一起判斷。

有用的單位是行為。一條變更堆棧路徑可能將十個文件連接成一個單一的登錄流程。沒有一個文件包含審查者需要判斷的行為；它存在於路由、提供者、回調、配置和測試之間。系統行為圖給出了一個模型，審查者可以對照代碼進行測試。第一個問題從“這個流程是什麼？”變成了“它正確、完整且安全嗎？”作者、審查者和維護者可以挑戰同一個提議的流程，而不是帶着三個對差異的私人解釋。

地圖必須引回代碼。當抽象止於精美的摘要時，它是廉價的；可追溯性則更難。在這種審查中，審查者可以從拉取請求移動到變更層，從層到系統流程，再從流程到語義實體、文件和行。他們可以在高層次判斷行為，然後針對實現驗證每個聲明。抽象只有在兩個方向都保持開放時才有用：縮小以恢復意圖和行為，放大以驗證地圖與代碼。每一層都有一個職責：意圖解釋變更為何存在；系統行為顯示部件如何交互；層設定審查邊界；語義實體命名相關的函數、路由或類型；文件和行提供證據。去掉上層，審查者需要從座標重建系統；去掉下層，審查者被要求相信一個無法驗證的故事。

審查界面應成為一個堆棧，而非更漂亮的摘要。隨着編碼代理產生更多、更大的差異，更長的摘要不會使工作變得可控。兩者都讓審查者去重建系統。一個有用的審查模型應該是可檢查、可糾正和可討論的。每個層次回答不同的問題，並且每個層次都連接回代碼。沒有一種表示是足夠的；價值在於能夠在意圖、行為和確鑿證據之間移動而不中斷鏈條。目標不是閲讀更少的代碼，而是將閲讀代碼的時間用於測試一個連貫的模型，而不是從零開始構建一個。機器可以組織變更並暴露路徑，而人類則決定模型是否準確、邊界是否合理以及方向是否值得。差異仍是基本事實，堆棧使其可用於判斷。