讓工程師參與決策：AI 程式助理規劃模式的不足與協作新解方

經驗豐富的工程師在撰寫程式碼之前會做大量工作。他們會找出使用者需求、檢視現有程式碼運作方式，並與團隊達成共識。這些知識存在於人腦中：產品人員了解使用者，工程師則熟悉程式碼庫、架構和團隊偏好。即使是最好的程式碼生成模型，也仍缺乏團隊所擁有的這些知識。它們擅長快速生成程式碼，但我希望這些知識能先融入規劃中，然後代理（agent）才開始建構任何東西。在我看來，這才是工程師應扮演的角色。

現有的規劃模式有何不足？Claude Code、Codex 和 Cursor 都具備規劃模式，我會將它們用於小型變更。代理會讀取程式碼、提出幾個問題，然後撰寫一份計畫。對於只涉及一兩個檔案的變更來說，這已經足夠。然而，對於更大的變更，我卻不斷遇到相同的限制。

這些規劃模式既不具備協作性，也缺乏視覺化。計畫以文字形式出現在聊天視窗中，而且只有我一個人能看到。一位比我更了解支付程式碼的同事，根本沒有機會說「不要把那個放在那裡」。此外，冗長的文字計畫會隱藏其結構，例如在第四段中，兩個模組之間錯誤的依賴關係很容易被忽略。

人類與代理協作：我認為所有軟體開發者都將成為代理的管理者。這種模式只有在人與代理的協作方式經過精心設計時才能奏效。代理負責撰寫程式碼，而人類則負責決策、審查和引導。因此，在 QualityLayer 中，計畫以文件的形式存在於程式碼儲存庫（repo）中。

每個工程決策都以兩句話呈現，而涉及多個動態部分的內容則會附上圖表，因為我可以在幾秒鐘內從圖片中發現錯誤的依賴關係。代理不確定的項目會被標記出來，以便我優先閱讀。我可以在任何部分發表評論，而代理則會在文件中回覆。當計畫正確無誤時，我會批准它，然後才開始建構。

讓團隊參與：一份計畫只有在團隊能夠看到時才能發揮作用。我可以分享計畫，並就某個特定決策詢問一位同事。他們可以在應用程式中回覆，或者讓自己的代理起草答案，閱讀後再發送。沒有帳號的人員，例如設計師或產品經理，可以透過訪客連結加入。針對產品人員，還有一個「產品層級」視圖，它會優先顯示對使用者造成的變更，而工程細節則只需點擊一下即可查看。

批准之後：在我批准計畫後，代理會將其分解成小片段來建構，每個片段都從一個失敗的測試開始。一個未參與程式碼撰寫的代理會檢查我與代理之間約定的每個要點，並向我展示證據。在審查階段，我會批准完成的變更，然後 QualityLayer 會開啟一個拉取請求（pull request）。它永遠不會自動合併。計畫和證據會保留在程式碼儲存庫中，因此任何審查拉取請求的人都可以了解該變更為何會是現在這個樣子。

無需工具也能嘗試這個概念：你可以利用任何代理來實現部分功能。要求它將計畫寫成 Markdown 檔案，並為每個決策附上 Mermaid 圖表。提交該檔案，然後請同事對只包含計畫的拉取請求發表評論。這只需要幾分鐘，而且在改變方向仍然容易的時候，就能收到評論。

我希望透過這一切，能讓我再次成為一名真正的工程師，而代理則負責處理打字工作。QualityLayer 支援 Claude Code、Codex、OpenCode、Pi、Cursor、Grok 和 Antigravity。專案儲存庫：https://github.com/maxritter/qualitylayer