程式碼不再是瓶頸，理解才是

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

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

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

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

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

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

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

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