Superpowers、GSD 和 gstack 是 2026 年成長最快的三個 Claude Code 開發框架，截至 4 月分別累積約 94,000、35,000 和 50,000 個 GitHub Star。 它們試圖解決同一個根本問題：AI 寫程式已經夠快了，但輸出品質不可靠。三個框架的解法完全不同——Superpowers 約束流程、GSD 約束上下文、gstack 約束視角。這篇文章把它們的原始碼和架構拆開來看，分析各自的設計假設、互補空間，以及一個來自 Andrej Karpathy 的 AutoResearch 專案帶來的新可能。
AI 寫程式的信任危機
2024 到 2025 年，AI 程式工具的競爭焦點是速度。誰能更快生成程式碼，誰就拿到用戶。到了 2026 年，焦點轉了。根據 ByteIota 的分析，Claude Code 在開發者「最愛用」調查中拿到 46% 的票，Cursor 19%，GitHub Copilot 9%。但即便是最受歡迎的工具，裸跑的 Claude Code 仍然會跳過測試、架構混亂、安全漏洞四處埋。
問題出在哪？AI 模型的能力不差，差在缺乏紀律。你叫它加一個功能，它可能寫完了，但測試沒附、實作方式跟討論的不一樣、程式碼品質時好時壞。這像團隊裡那個寫得飛快但從不做 code review 的初級工程師。
社群的反應是搞框架，給 AI 加規矩。而這三個框架分別從三個不同維度下手。
Superpowers：用流水線紀律壓住 AI 的散漫
Jesse Vincent（GitHub 帳號 obra）是 Perl 圈的老手，做過 Request Tracker（上千個組織在用的開源票務系統），擔任過 Perl 5 的 pumpking（負責語言發布的人），後來共同創辦了高階人體工學鍵盤公司 Keyboardio。他在 2025 年 10 月 Anthropic 推出 Claude Code 外掛系統的當天發布了 Superpowers 的第一版。
到 2026 年 1 月 15 日，Superpowers 被正式收進 Anthropic 官方外掛市場。截至 3 月，它的 GitHub Star 數已經超過 94,000，是 2026 年成長最快的開源專案之一，高峰期一天增加接近 2,000 顆星。
Superpowers 的核心假設很直接：AI 的問題不在能力，在太散。給它一套嚴格的開發流程，它的輸出就會穩定。
它把整個開發週期切成七個階段：
| 階段 | 做什麼 | 關鍵機制 |
|---|---|---|
| Brainstorm | 結構化的需求對話，不是隨便聊 | 蘇格拉底式提問，按模組展示設計 |
| Spec | 生成規格書，每部分需要人確認才往下 | 強制分段確認 |
| Plan | 產出詳細實施計劃 | 細到每一步改哪個檔案、預期結果、驗證方式 |
| TDD | 強制測試驅動開發 | 先寫測試再寫程式碼，寫反了會被刪除重來 |
| Subagent Dev | 分派子任務給獨立 agent | 每個任務開新的上下文窗口 |
| Review | 自動程式碼審查 | 對照計劃、coding standards、架構原則 |
| Finalize | 收尾，可開 PR 或合併 | 自動化 git 操作 |
這裡面最有意思的設計是 TDD 的強制性。其他框架會「建議」你寫測試，Superpowers 會在你沒寫測試就開始寫程式碼的時候，把那段程式碼刪掉，然後強制你從測試開始。chardet 函式庫的 7.0.0 版本就是用 Superpowers 方法論開發的，結果是效能提升 41 倍，準確率從 94.5% 升到 96.8%。
安裝只要兩行指令：
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
Superpowers 也支援 Cursor、Codex、OpenCode 和 Gemini CLI。
GSD：徹底隔離上下文，讓每個任務都拿到乾淨的 200K 窗口
GSD（Get Shit Done）的作者 Lex Christopherson（網名 glittercowboy / TÂCHES）的自我定位很清楚：「我是一個獨立開發者。我不寫程式，Claude Code 幫我寫。」
GSD 要解決的問題跟 Superpowers 不同。它針對的是上下文衰退（context rot）。你跟 Claude 聊了半小時，它會開始偷工減料、遺忘指令，甚至出現幻覺。這不是錯覺。根據社群測試，上下文窗口用到 50% 以上品質就開始下滑，70% 以上幻覺率明顯升高。專案越大、對話越長，問題越嚴重。
GSD 的做法是徹底隔離上下文。它把工作拆成原子任務，每個任務都開一個全新的 Claude 實例，拿到一個乾淨的 200K 上下文窗口。主對話只做調度，負載維持在 30-40%，不幹重活。所有專案狀態存成文本放在磁碟上，新 session 可以讀回來接著做。
GSD 原本是一組 Markdown 提示詞（v1），後來重寫為 TypeScript 應用程式（v2）。v2 的差異在於它不再依賴 LLM「讀懂提示詞然後乖乖照做」，而是直接在 TypeScript 層面控制 agent session——清上下文、注入檔案、管理 git 分支、追蹤成本和 token、偵測卡住的迴圈、crash 恢復。
| 功能 | v1（Markdown 提示詞） | v2（TypeScript 應用） |
|---|---|---|
| 上下文管控 | 靠 LLM 自律 | 程式碼層面強制清除 |
| crash 恢復 | 沒有 | 自動從斷點恢復 |
| 成本追蹤 | 沒有 | 內建 token 和費用監控 |
| 並行任務 | 靠 LLM 自己呼叫自己 | 原生支援 wave-based 並行 |
| 卡住偵測 | 沒有 | 自動偵測 stuck loop |
GSD 的品質閘門也值得一提：schema drift detection 會在 ORM 檔案修改但沒有對應 migration 時發出警告；scope reduction detection 會在規劃器偷偷砍掉你的需求時攔住它。
每個 commit 都是原子的，可以單獨 revert，git bisect 能精確找到出問題的任務。
gstack：用角色治理取代通用 AI
gstack 的作者是 Y Combinator 的 CEO Garry Tan。他在 Palantir 做過工程師 / PM / 設計師，共同創辦了 Posterous（後來賣給 Twitter），看過數千家新創公司從車庫走到上市。gstack 是他個人的 Claude Code 工作流，2026 年 3 月 12 日開源後，16 天內拿到 50,000 顆 GitHub Star。TechCrunch 報導了這件事，社群反應兩極——有人說是神器，有人質疑「config 檔憑什麼拿這麼多星」。
gstack 的設計假設和前兩者不在同一個維度。它不管你流程怎麼跑，不管上下文乾不乾淨，它管的是「誰來做什麼決定」。
目前 gstack 有 23 個以上的 slash command（它稱為 skill），每個對應一個特定角色。幾個有代表性的：
| Skill 指令 | 角色 | 做什麼 |
|---|---|---|
| /office-hours | YC 合夥人 | 六個關鍵問題重新框定你的產品 |
| /plan-ceo-review | CEO | 用四種模式（擴展/選擇性擴展/維持/縮減）挑戰產品方向 |
| /plan-eng-review | 工程經理 | 鎖定框架、畫資料流、列邊界情況 |
| /review | 程式碼審查者 | 多維度審查：架構、安全、測試覆蓋 |
| /qa | QA 工程師 | 開真實瀏覽器（Playwright）執行 E2E 測試 |
| /ship | 發布工程師 | 一鍵推程式碼，自動跑測試覆蓋稽核 |
| /design-review | 設計審查 | 偵測 AI 生成的千篇一律 UI |
讀完 gstack 的架構和原始碼，它至少在做五件不同的事：
第一，角色聚焦。 讓 Claude 以工程經理身份審查程式碼，它會自動忽略「UI 顏色不好看」這種回饋，專注在框架和可維護性。以 CEO 身份評估產品，它會問的是「這個需求背後的真正用戶問題是什麼」，而不是直接開始寫 code。
第二，資料編排。 /office-hours 產生的設計文件會被 /plan-ceo-review 讀取做產品審核，再被 /plan-eng-review 讀取鎖定架構。每一步的輸出成為下一步的輸入，形成一條有序的決策鏈。
第三，品質管控。 Review Readiness Dashboard 追蹤哪些審查跑了、缺什麼。工程審查是唯一的硬性閘門，CEO 和設計審查是建議性的。
第四，決策偏好注入。 gstack 有一個叫做 Boil the Lake 的核心哲學。湖泊可以煮沸，例如把一個模組的測試覆蓋率做到 100%。海洋煮不開，例如從頭寫一個完整系統。這個原則內建在每個 skill 裡，幫助 AI 判斷任務的合理邊界。
第五，認知負載適配。 當偵測到你開了多個並行對話，skill 會進入 ELI16 模式（Explain Like I'm 16），重新交代完整上下文，避免上下文碎片化。
三個框架的互補地圖
把三者放在一起看，它們約束的維度完全不重疊：
| 維度 | Superpowers | GSD | gstack |
|---|---|---|---|
| 核心假設 | AI 太散，需要流程紀律 | AI 品質取決於上下文乾淨度 | AI 品質取決於用什麼視角思考 |
| 約束對象 | 開發過程 | 運行環境 | 決策視角 |
| 強項 | TDD、子任務拆分、計劃執行 | 長時間自主作業、crash 恢復 | 產品思考、多角色審查、瀏覽器 QA |
| 弱點 | 構建階段以外的產品思考較少 | 角色分工不明確 | 構建階段沒有自己的 skill |
| 作者背景 | Jesse Vincent，Perl 社群資深開發者 | Lex Christopherson，獨立開發者 | Garry Tan，YC CEO |
| GitHub Stars（2026 年 4 月） | ~94,000 | ~35,000 | ~50,000 |
gstack 最有意思的結構性缺陷在這裡：它的流程是思考（/office-hours）→ 規劃（/plan-*-review）→ 構建 → 審查（/review）→ 發布（/ship），但構建階段沒有對應的 skill。Claude Code 在這個階段回到默認模式，直到你手動執行 /review。而構建階段恰恰是 Superpowers（TDD + 子任務）和 GSD（上下文隔離 + 原子 commit）最擅長的地方。
理論上可以把它們組合。但卡在一個技術問題：Superpowers 在構建過程會彈出互動問答，Claude Code 的輸入會被卡住。GSD v2 因為是 TypeScript 應用而不是 Markdown 提示詞，整合難度更高。
AutoResearch：無人值守的持續優化迴圈
Andrej Karpathy 在 2026 年 3 月 7 日發布了 AutoResearch，一個讓 AI agent 自主跑實驗的開源專案。發布一週內拿到超過 26,000 顆 GitHub Star，截至 4 月已超過 65,000 顆。
AutoResearch 的運作邏輯很簡單：agent 修改程式碼，在固定時間預算（預設 5 分鐘）內跑一輪訓練，測量一個指標，指標改善就保留（commit），沒改善就重置（revert）。循環重複。Karpathy 自己用它跑了兩天約 700 次實驗，找到約 20 個真正的改進，把一個他認為已經優化到底的 GPT-2 訓練腳本再加速了 11%。
Shopify CEO Tobi Lütke 把同樣的模式套到 Shopify 的模板引擎上，跑了 93 次自動 commit，渲染效能提升 53%。
這個迴圈模式搬到軟體工程裡，可以填補 gstack 在構建階段之後的空白。想像一個額外的 /optimize skill：自動修改程式碼 → 跑測試 → 測量覆蓋率和 Lighthouse 分數 → 指標漲了就提交，沒漲就重置。這是在 gstack 的發布階段之後增加一個全新能力：無人值守的持續優化。
Karpathy 自己也在思考下一步——他在 X 上寫道，AutoResearch 要走向「多 agent 非同步協作」，類似 SETI@home 的分散式研究社群。目前 GitHub 的分支結構（以 master 為主幹，PR 合併後回歸）不太適合這種模式，但方向已經明確。
並行開發的現實：git worktree 比 Conductor 實在
gstack README 裡推薦用 Conductor 來做並行開發，但沒有提供官方方案。實際底層還是 git worktree。Claude Code 本身原生支援 -w 參數指定 worktree，開幾個 tmux 窗口就能做到一樣的事。
# 開 worktree
git worktree add ../feature-auth feature-auth
# 在新窗口啟動 Claude Code
claude -w ../feature-auth
社群已經有人提 PR 要把這個做成 gstack 的內建功能。對於需要同時跑多條開發線的團隊，這比等一個還不存在的 Conductor 官方方案務實得多。
怎麼選：取決於你的痛點在哪
| 你的痛點 | 先試這個 | 原因 |
|---|---|---|
| AI 寫的程式碼品質不穩定，測試覆蓋率低 | Superpowers | 強制 TDD，流程紀律最嚴 |
| 專案大，Claude 對話到後半段品質崩壞 | GSD | 上下文隔離徹底，原子任務設計 |
| 產品方向不確定，需要多角度審查 | gstack | 角色治理，CEO/工程/設計多維審查 |
| 三者都想要 | gstack + 手動整合 Superpowers 的 TDD 原則 | 目前沒有一鍵整合方案 |
| 已經有穩定流程，想做持續優化 | AutoResearch 模式 | 適合有明確指標的迭代 |
坦白說，我認為「框架戰爭」的說法有誤導。這三者不在搶同一群用戶。Superpowers 對標的是缺乏工程紀律的 solo developer，GSD 對標的是專案複雜度超過上下文窗口承載量的情境，gstack 對標的是需要產品思考能力的 founder-engineer。它們的適用場景幾乎不重疊，真正的問題是怎麼把它們組合起來。
Superpowers 跟 GSD 的差異到底在哪？
Superpowers 約束的是開發流程——七個階段、強制 TDD、子任務分派。GSD 約束的是運行環境——每個任務拿到乾淨的 200K 上下文窗口，主對話負載控制在 30-40%。Superpowers 確保 AI「怎麼寫」的品質，GSD 確保 AI「在什麼狀態下寫」的品質。兩者解決的問題不同，理論上可以疊加使用。
gstack 適合什麼類型的開發者？
gstack 最適合一個人要同時扮演 CEO、工程師、設計師、QA 的 founder-engineer。它的角色系統把「用什麼視角思考」結構化了。如果你只是需要 AI 幫你寫一個函式庫、不涉及產品決策，Superpowers 或 GSD 可能更直接。
三個框架可以一起用嗎？
理論上可以。gstack 負責思考和審查，Superpowers 的 TDD 原則套在構建階段，GSD 的上下文隔離防止長對話品質衰退。但目前沒有一鍵整合方案，需要手動配置。主要技術障礙是 Superpowers 在構建過程的互動問答會卡住 Claude Code 的輸入流。
AutoResearch 模式用在軟體工程可行嗎？
可行，但需要有明確的量化指標。測試覆蓋率、Lighthouse 分數、回應時間這些有明確數字的維度適合用 AutoResearch 的 ratchet loop。涉及主觀判斷的維度（UI 美感、程式碼可讀性）不太適合。Shopify CEO Tobi Lütke 已經在內部工具上驗證了這個模式，93 次自動 commit 帶來 53% 的渲染效能提升。
這些框架會被 Claude Code 原生功能取代嗎？
Anthropic 在 2026 年 1 月把 Superpowers 收進官方外掛市場，這個訊號說明他們更傾向把好的社群方案整合進來，而不是自己重做。Claude Code 的 sub-agent 和 worktree 功能已經在原生支援，但流程編排、角色治理這些更高層的抽象短期內不太可能變成原生功能。
引用來源
- GitHub — obra/superpowers（官方倉庫）
- GitHub — gsd-build/get-shit-done（官方倉庫）
- GitHub — garrytan/gstack（官方倉庫）
- GitHub — karpathy/autoresearch（官方倉庫）
Author Insight
我們團隊在 2025 年底從 Cursor 全面遷移到 Claude Code，過程中實際測試了 Superpowers 和 GSD 的不同配置。體感上最明顯的差異：Superpowers 的強制 TDD 確實壓住了回歸 bug 的數量，但構建速度會慢一截，因為測試先行需要更多 token 和時間。GSD 的上下文隔離在處理超過 50 個檔案的專案時效果明顯——Claude 到第三個小時還能維持第一個小時的輸出品質。gstack 的 /plan-ceo-review 我個人覺得是被低估的功能，它強迫你在寫程式之前想清楚「這個功能到底解決什麼問題」，砍掉了很多做到一半才發現方向不對的浪費。
對大多數團隊，我會建議先選一個跟你最痛的點對應的框架，用兩週驗證效果，再考慮要不要疊加第二個。三個一起上的管理成本不低，除非你已經對每個都很熟了。如果你的團隊正在評估 AI 開發工具導入策略，歡迎跟 Tenten 團隊預約諮詢，我們可以根據你的專案規模和技術棧做具體建議。
