代理程式設計中專注的力量

亞歷克斯·格雷夫利（Alex Graveley），GitHub Copilot 的創造者，用一支筆和一張紙改變了作者對代理程式設計的看法。在一次週二訪問中，當作者提到還需要一週時間才能實現自助服務時，格雷夫利卻斷言只需四小時。他寫下十個步驟，交給作者，這就是全部計劃。

作者經歷了代理程式設計的所有階段：從ChatGPT複製貼上、Cursor、Claude Code、Codex，再到子代理和編排框架，始終假設更多工具意味著更多產出。然而，格雷夫利指出，真正的瓶頸是未定向的範圍，而不是模型或工具。沒有固定清單，並行代理只會增加在製品，而不是吞吐量。十個會話可能導致五個半成品功能，卻無一交付。

格雷夫利將那些不推動指標或為使用者掃除障礙的工作稱為“虛假工作”。在初創公司中，唯一重要的是獲取使用者並消除這一目標的障礙。他的方法直截了當：在紙上列出十個步驟，使用兩個Claude Code會話，其他一概不用。清單是與自己達成的關於今日交付內容的契約。

每個新專案，他都會建立一份全新的CLAUDE.md檔案，只有遇到令人煩惱的問題時才新增規則。例如，Claude頻繁詢問是否提交？那就更新檔案。他稱之為“煩惱驅動開發”：不預先載入規則，而是透過摩擦來贏得它們。會話結束時，規則包括：保持一切簡潔，避免不必要的抽象和註釋，當下一步明確時直接執行，儘可能通用，並儘可能並行化獨立步驟。

在提示方面，作者傾向於填充大量上下文，而格雷夫利則保持提示簡短。對於許多團隊已經解決的任務（如ECS、認證、資料庫遷移），更多上下文意味著更多噪聲。模型已經知道通用路徑，它不知道的是你的特定約束，那才是你應投入上下文預算的地方。

關於早期最佳化，作者習慣超前考慮可靠性和擴充套件性，但格雷夫利指出：“為少量使用者構建可擴充套件性其實是逃避。”這種方法改變了範圍紀律，而非質量標準。十步清單是一種強制函式，而不是質量捷徑。每一步都要驗證其有效性。紀律在於編寫足夠緊湊的清單，使每一步都有明確的完成狀態。

它消除了因範圍過大的代理導致的架構漂移。簡短提示、嚴格範圍、明確的步驟審查——這就是治理。簡單但有效。會話結束時，他們完成了十步中的第六步。格雷夫利說：“不要停下來，直到完成清單。明天重複。”到了晚上，任何請求訪問的使用者都可以端到端地完成註冊。

在代理程式設計時代，專注是超能力。那些看起來像速度的範圍蔓延正在吞噬你大部分AI編碼收益。更多會話、更多產出，但真正重要的東西卻交付得更少。作者最初以為瓶頸是工具，但離開時僅帶著一張劃掉的清單。里程碑交付了。

現在看看你在做什麼。你能用清晰的步驟寫在紙上嗎？如果不能，你只是在跟著感覺走，而不是遵循明確的計劃。