前言：上下文腐化的困境

最近在探索 AI 輔助程式設計工具時，接觸到了 GSD (get-shit-done) 這個規約驅動開發系統。說實話，這名字本身就很有意思——直白乾脆，透著一股務實勁兒。但真正吸引我的，是它對上下文腐化 (context rot) 問題的治理思路。

如果你也是經常使用 AI 程式設計輔助工具的開發者，應該也遇過這樣的情況：剛開始與 AI 對話時，它的輸出品質很高，回應也很精準。但隨著對話進行，累積的上下文越來越多，AI 的輸出品質開始明顯下滑。這不是模型的問題，而是一個被稱為「上下文腐化」的現象。

研究顯示，當單一會話的上下文總量逐漸超過 50% 之後，模型輸出的品質會顯著下降。這就像一個程式設計師在處理複雜專案時，需要記住的細節越來越多，但大腦的「工作記憶」有限，資訊過載後判斷力和創造力都會受到影響。

傳統的 AI 程式設計工具往往採用單一大上下文的方式，把所有需求、設計、程式碼都塞進一個長對話中。這種做法在面對複雜專案時，很快就會觸及上下文的瓶頸。而 GSD 的出現，正是為了解決這個問題。

GSD 的核心特點：粒度可控的工作流

作為後端程式設計師，我一直很看重「粒度」這個概念。好的系統設計應該是模組化的，每個模組職清晰、邊界明確。GSD 的設計理念與此不謀而合——小粒度的階段性工作流與 subagent 執行機制。

GSD 將整個開發過程分解成多個階段 (phase)，每個階段都有明確的目標和邊界。每個階段由專門的 subagent 負責執行，這些 subagent 各司其職：有的負責研究需求，有的負責制定計畫，有的負責執行，還有的負責驗證結果。

這種設計有幾個明顯的優勢：

上下文隔離。 每個 subagent 只需要處理自己階段相關的上下文，不會被其他階段的資訊干擾。這就像微服務架構中的服務隔離，每個服務只需要關注自己的業務邏輯。

職清晰。 研究階段的研究員不需要知道執行階段的具體細節，驗證階段的審核員也不需要了解規劃階段的決策過程。這種關注點分離讓每個環節都能保持高品質輸出。

可追溯性。 每個階段都會產生明確的產出物——研究文件、計畫文件、驗證報告等。這些文件不僅是開發過程的記錄，也為後續的維護和迭代提供了清晰的參考。

對於習慣了後端開發思維的我來說，這種粒度可控的方式非常有吸引力。它讓我能夠像設計系統一樣「設計」開發流程，而不是被動地跟著 AI 的節奏走。

實戰體驗：開發一個密碼產生器

了解了 GSD 的基本理念後，我決定用它來嘗試一個簡單的專案——密碼產生器。選擇這個專案是因為它足夠小，能在短時間內驗證 GSD 的工作流；同時又有足夠的功能點，能體現出 GSD 的各個階段是如何協作的。

整個開發過程遵循了 GSD 的標準流程。首先是研究階段，GSD 啟動了一個研究 agent 來了解密碼產生器的常見需求、安全標準和技術實作方案。這個 agent 產出了詳細的研究文件，包括密碼強度的定義、使用者介面設計的考量點等。

接著是規劃階段，規劃 agent 根據研究文件制定開發計畫，將整個專案分解為多個階段：使用者介面設計、密碼產生邏輯實作、安全性驗證等。每個階段都有明確的輸入輸出和驗收標準。

執行階段則是最實際的部分。GSD 的執行 agent 按照計畫逐步實作功能，每完成一個階段都會觸發驗證 agent 進行檢查。這個過程很像 CI/CD 流水線——每個環節都有自動化測試把关。

特別值得一提的是，整個過程我並沒有過多干预。我只是在專案開始時說明需求，然後 GSD 就自動推進了整個開發流程。這種感覺有點像在指揮一個訓練有素的開發團隊——你只需要說明目標，團隊就會自動完成剩下的工作。

最終的結果是一個功能完整的密碼產生器，介面簡潔，邏輯清晰。但比結果更重要的是，我清晰地看到了 GSD 的工作流是如何把一個模糊的想法轉化成具體產品的。

與 OpenSpec 的對比：規約制定的細膩之處

在探索 GSD 的過程中，我也想到了之前接觸過的 OpenSpec。兩者都是規約驅動開發的方式，但在規約制定的細節和嚴謹程度上，GSD 給我留下了更深的印象。

如果你對規約驅動開發有興趣，可以看看我之前的文章 OpenSpec in OpenCode 使用心得。

OpenSpec 的理念是讓開發者編寫詳細的規約文件，然後 AI 根據規約產生程式碼。這種方式的好處是規約編寫者有充分的控制權，但問題在於規約的編寫本身就需要大量時間和專業知識。而且，一旦規約有遺漏或歧義，AI 產生的程式碼就可能出現問題。

GSD則採取了不同的策略。它不是要求開發者預先編寫完整的規約，而是透過多個 agent 協作，逐步推導出完整的規約。研究 agent 負責收集需求和技術背景，規劃 agent 負責制定實作方案，執行 agent 負責具體實作，驗證 agent 負責品質把关。每個 agent 在完成自己工作的同時，也在不斷地補充和完善規約。

這種方式的好處是規約的產生是動態的、迭代式的。你不需要在專案開始時就預見所有細節，系統會在推進過程中自動發現和填補規約的空白。這更像敏捷開發中的「湧現式設計」，而不是瀑布開發中的「預先設計」。

另外，GSD 在規約的驗證上也更加嚴格。每個階段的產出物都會被後續階段作為輸入使用，這實際上形成了一種自動的規約驗證機制。如果規約不完整或有錯誤，後續階段的 agent 就會遇到問題，從而暴露出規約的問題。

這種細膩和嚴謹，對於追求程式碼品質的後端程式設計師來說，是很大的加分項。它讓我相信，用 GSD 開發的專案，不僅程式碼本身是可靠的，整個開發過程也是可追溯、可驗證的。

總結

初次嘗試 GSD，給我的感受是它確實抓住了 AI 程式設計的核心痛點。上下文腐化不是一個可以忽視的小問題，它會直接影響專案品質。GSD 透過粒度可控的工作流和專業的 subagent 機制，有效地控制了上下文的規模，保證了每個環節的輸出品質。

作為一個後端程式設計師，我很欣賞 GSD 的設計哲學——它把軟體工程中的一些經典原則（模組化、關注點分離、可追溯性）應用到了 AI 輔助開發中。這種融合傳統智慧和技術的方式，讓 GSD 不僅僅是一個工具，更像是一套方法論。

當然，GSD也不是銀彈。對於非常簡單的專案，使用 GSD 可能會有「殺雞用牛刀」的感覺。但對於中等複雜度以上的專案，特別是需要團隊協作、長期維護的專案，GSD 的價值就會充分體現出來。

關於 AI 輔助開發範式的更多討論，可以參考我之前的文章 Vibe Coding: Harness Engineering 範式轉變。

未來，我計畫在更多專案中嘗試 GSD，進一步探索它的能力邊界。AI 輔助程式設計正在快速發展，而 GSD 這樣的工具，讓我們看到了一個可能的方向：不是用 AI 取代程式設計師，而是讓 AI 成為程式設計師的得力助手，幫助我們更好地完成工作。

你有試過 GSD 或其他規約驅動開發工具嗎？歡迎在留言區分享你的經驗。