AI 編碼代理需要堆疊工作階段，而不是更長提示詞

AI 編碼助手正在進入更成熟的階段。過去常見做法是把大型需求放進一段提示詞，要求模型一次修改整個專案，然後希望差異還能審查。GitHub 關於 Copilot app 的 stacked sessions 與 pull requests 展示了更好的方式：把相關工作拆成清楚的工作階段、分支和合併請求，讓開發者可以比較、暫停、關閉或接續。

這很重要，因為代理式軟體同時強大且有風險。TechCrunch 報導 Anthropic 的安全測試指出，高階模型在受控情境中能完成複雜入侵任務，提醒我們自動化工具需要窄權限、可稽核證據與人工審查。對 BTTC 讀者來說，最好的 AI 流程不是一次寫最多程式碼，而是讓每個變更都能被檢查。評估生產力工具時，也可以查看 BTTC 軟體目錄。

堆疊工作階段為何重要

堆疊工作階段讓 AI 編碼更接近正常工程流程。開發者可以要求代理更新樣式、移除依賴、改善可及性或補充測試，而不必把所有想法塞入同一分支。每個工作階段都有自己的上下文和 pull request。若某條路線變得混亂，團隊可以關閉它，從正確基底重新開始，而不是整理巨大的混合差異。

真正的新技能是審查設計

生成能力提升後，瓶頸會轉向審查。團隊需要規定代理可修改哪些檔案、必須通過哪些測試、哪些區域不能碰，以及何時需要人工批准。好的代理任務應包含目標、小範圍、基礎分支、測試預期與回復方式。pull request 描述也要說明改了什麼、原因、測試方法和仍不確定之處。

安全測試帶來的訊號

Anthropic 安全測試不是叫人放棄 AI 編碼代理，而是提醒我們要把它們當成正式系統設計。代理應使用最低權限、隔離環境、有限密鑰與可稽核日誌。個人開發者也要使用獨立分支、閱讀 diff、執行測試、檢查生成命令，並在代理超出範圍時停止並縮小任務。

開發者可採用的流程

先建立簡單待辦：一個工作階段修 bug，一個補測試，一個寫文件，一個做重構。每個工作階段給窄提示詞，要求產生適合 pull request 的成果。依依賴順序審查，只合併通過測試且真正改善專案的部分。截圖、PDF 轉換、媒體壓縮、diff 檢視與筆記工具仍然重要，因為它們能加快人工審查。更多工具可參考 BTTC 部落格。

常見問題

堆疊工作階段只適合大型工程團隊嗎？

不是。單人開發者也能受益，因為每個工作階段都是清楚檢查點。

AI 編碼代理可以自動合併 PR 嗎？

一開始通常不建議。自動合併需要強測試、有限範圍、分支保護與明確責任。

第一個代理任務該選什麼？

選擇小而可驗證的任務，例如補測試、改善文件、修正 lint 或更新單一元件。

結論

下一波 AI 編碼不只比模型能力，也比流程紀律。GitHub Copilot 的堆疊工作階段重要，是因為它符合開發者維護品質的方式：小分支、pull request、測試與審查。讓代理準備工作，但把範圍、安全和最終決定留在人手中。