超越 Git Diff：使用 Stage CLI 簡化 AI 生成的程式碼審查

AI 程式碼代理的興起徹底改變了我們撰寫程式碼的方式，但同時也產生了一個新的瓶頸：審查流程。當代理在整個倉庫中修改數十個檔案以實作單一功能時，產生的 git diff 往往是一團混亂的變更，依檔案路徑而非邏輯意圖排列。對開發者而言，這意味著需要花更多時間在腦中重建代理的邏輯，而不是實際審查程式碼。

為了解決這個問題，Charles 與 Dean 推出了 Stage CLI，一款開源工具，旨在彌合 AI 生成變更與人類理解之間的鴻溝。Stage CLI 透過拋棄傳統依倉庫目錄樹排列的 diff，導入「chapters」式的體驗，讓開發者能以結構化、敘事性的流程審查變更。

傳統 Diff 的問題

在一般的 IDE 或 CLI 工具中，diff 會以檔案清單的形式呈現。如果 AI 代理在 src/utils/ 中更新一個工具函式、在 src/components/ 中更新一個元件，並在 tests/ 中更新測試，這些變更會依檔案系統結構分開。審查者必須在檔案之間來回切換，才能理解單一的邏輯變更。

如同一位 Hacker News 使用者 @hajekt2 所指出的：

「使用 AI 生成的程式碼時，最難的部分是審查它。當代理因不同原因修改多個檔案時，普通的 git diff 會變得雜亂。將變更分組為「chapters」似乎是個正確的想法。」

Stage CLI 的運作方式

Stage CLI 作為您現有 AI 工作流程的本地擴充功能運作。它不會取代您的程式碼代理；相反地，它會指示代理執行一系列特定任務：

  1. Analyze Changes: 代理讀取當前分支的變更。
  2. Logical Decomposition: 代理根據程式碼變更的意圖，而非檔案位置，將這些變更拆解為獨立的、邏輯性的「chapters」。
  3. Browser-Based Review: 此工具在本機瀏覽器中開啟這些章節，提供豐富的視覺介面以審查程式碼。

此方式讓開發者能夠追蹤實作的「story」——可能從資料模型的變更開始，接著是商業邏輯，最後是 UI 更新——不論實際觸及了哪些檔案。

社群回饋與觀點

Stage CLI 的推出在開發者之間引發了關於如何處理 AI 生成程式碼的熱烈討論。

「CLI」與瀏覽器的辯論

其中一個爭議點在於工具的交付方式。雖稱為「CLI」，實際上會觸發基於瀏覽器的體驗。一些使用者，如 @adamtaylor_13 與 @tim-projects，表示偏好終端機原生的體驗，認為離開終端機的阻力可能會讓部分高階使用者卻步。

邏輯分組的價值

儘管介面偏好各異，大家普遍認同邏輯分組的 concept 非常有價值。@pi-victor，亦即類似 TUI 工具 Parley 的創作者，承認雖然他們的工具支援對 diff 留言，卻缺乏 Stage CLI 所提供的「chapters」組織方式。

效能與規模

對於處理大規模變更的單人開發者而言，效能是關鍵因素。使用者 @ihatemodels 分享了他們的工作流程：使用 GitHub 網頁版審查提交，然後將評論回饋給 Claude Code。他們指出，當提交涉及數百甚至數千行程式碼時，UI 的效能與虛擬化（windowing）是必不可少的，否則工具將變得無法使用。

AI 審查的未來

關於 Stage CLI 的討論顯示出一個更大的趨勢：需要「Socratic method」式的審查。隨著 AI 代理變得更強大，工程負責人的目標也從單純抓錯轉變為確保人類與 AI 都能對系統保持深入的理解。

正如 @mkw5053 所建議的，挑戰在於在提升交付速度與品質的同時，確保初級開發者變得「更有能力，而不僅是更高產」。像 Stage CLI 這樣的工具是朝此方向邁出的第一步，將審查流程從掃描 diff 的例行工作，轉變為結構化的教育與品質保證練習。

Sources