gstack + superpowers：各自管什麼，配合起來怎麼用
整理版優先睇
gstack 管動作、superpowers 管思維，兩者互補提升開發效率
呢篇文係作者親身經驗，佢將 gstack 同 superpowers 一齊裝咗嚟用，發現兩者職責完全唔衝突，仲互補得好齊整。gstack 負責「動作」，將起骨架、測試、部署呢啲繁瑣步驟壓縮成一行命令；superpowers 負責「思維」，確保 AI 喺協作過程中唔會跳步——先澄清需求、先寫測試、先定位 bug 再改、完成前自檢。
作者用自己寫嘅「xiaobai 目標股診斷器」做例子，展示由 brainstorming 到部署嘅完整流程。第一步靠 superpowers 嘅 brainstorming 釐清報告對象、數據來源等關鍵問題；第二步用 gstack 嘅 /ship 起好項目骨架；第三步用 TDD 寫核心邏輯，權重自動做成可配參數；第四步用 /qa 一次跑曬測試、lint、類型檢查；第五步遇到 bug 時，systematic-debugging 幫佢列出假設逐步排查；第六步完成前 verification-before-completion 自檢發現港股支援問題，自動補測試；第七步用 /design-shotgun 探索 UI 風格。全程幾乎冇喺環境或配置上花時間。
結論係：兩個一齊用，起步唔卡，中間唔返工，小項目效率翻倍。最適合腦中有啲唔完整想法、想快速做出可用工具嘅開發者。邊界係：極細腳本直接寫更簡單，完全唔熟嘅領域先要去睇資料，強合規或要交接團隊嘅項目需要加 openspec 嗰層。建議由一個一直想做但…
- gstack 管動作入口與出口，superpowers 嵌入動作中間，兩者職責完全互補。
- gstack 將高頻繁瑣動作（起骨架、測試、部署、審查）壓縮成一行命令，減少摩擦。
- superpowers 確保 AI 協作唔跳步：先 brainstorming 釐清需求，再用 TDD 寫測試，bug 時 systematic-debugging，完成前 verification-before-completion。
- 兩者疊加產生乘法效應：起步唔卡（gstack）、中間唔返工（superpowers），小項目效率由一週變兩三日。
- 最適合場景：腦中有不完整想法，想快速做出可自用或小團隊用嘅工具；唔適合極小腳本、完全陌生領域或強合規項目。
gstack 管「動作」：將繁瑣壓成一行命令
gstack 係一組 slash command 嘅集合，裝完之後喺 Claude Code 裏可以直接調。佢將項目週期裏高頻但繁瑣嘅動作做成命令，等你唔使每次都從頭嚟。
gstack 嘅定位係「減少摩擦」，將中間步驟壓縮成一行命令
- /ship：從零起項目骨架，或者將現有項目推到可部署狀態。
- /qa：跑測試 + lint + 類型檢查 + 自動 fix 嘅一條龍。
- /investigate：當你唔知段 code 做咩、揾唔到 bug 原因時用，做系統性追溯。
- /plan-eng-review / /plan-ceo-review / /plan-design-review：分別從工程師、產品、設計師角度 review 你嘅方案。
- /design-shotgun：一次俾三種 UI 方案你揀。
- /health：項目健康度體檢。
- /canary：金絲雀發佈相關。
gstack 讓你唔使再逐個敲指令，直接一條命令搞掂
superpowers 管「思維」：確保 AI 唔跳步
superpowers 係一組 skill，唔係命令，裝完之後 Claude Code 會喺合適場景自動觸發。佢管住「AI 喺協作過程中嘅方法論」，定位係「減少草率」。
superpowers 嘅定位係「減少草率」，防止 AI 跳步
- brainstorming：當你話「我想做 X」時啓動，問幾個澄清問題，幫你諗清輪廓。
- writing-plans：多步任務前用，寫一份可執行計劃。
- test-driven-development：寫功能或修 bug 時啓動，先寫測試再寫實作。
- systematic-debugging：測試掛咗或行為異常時啓動，先列假設逐個排除。
- verification-before-completion：喺準備話「完成咗」之前自檢一遍。
- executing-plans：拎住 plan 之後按步驟跑。
- using-git-worktrees：需要並行多個分支時自動起 worktree。
brainstorming 幫你釐清模糊想法，TDD 強制先測試再寫 code，systematic-debugging 避免亂改，verification-before-completion 堵住遺漏
各自管邊段：動作中間的完美互補
將一個項目從想法到能用嘅過程拆開，兩個工具嘅覆蓋面係：gstack 站在「動作嘅入口」同「動作嘅出口」，superpowers 嵌喺「動作嘅中間」。前者解決「做呢件事嘅成本」，後者解決「做呢件事嘅方式」。
gstack 管動作入口/出口，superpowers 管動作中間嘅思維流程
實例：xiaobai 目標股診斷器嘅完整流程
以下係作者用兩個工具開發 xiaobai 目標股診斷器嘅實際步驟，展示咗點樣無縫配合。
- 1 第一步：想清楚要做咩（superpowers brainstorming）— 自動觸發問幾條關鍵問題，釐清報告對象、輸出格式、數據來源、權重配置等。
- 2 第二步：起骨架（gstack /ship）— 建立 Python CLI + Web 報告嘅項目結構，包括 src、tests、pyproject.toml、CI、README。
- 3 第三步：寫核心邏輯（superpowers TDD）— 先寫測試再寫實現，權重自動做成可配參數。
- 4 第四步：跑測試（gstack /qa）— 一條龍跑測試、lint、類型檢查，自動 fix 類型錯誤。
- 5 第五步：bug 處理（superpowers systematic-debugging）— 列三個假設逐個排查，定位到字典順序問題，改一行 code 解決。
- 6 第六步：自檢（superpowers verification-before-completion）— 發現未支援港股代碼，自動補測試先確認完成。
- 7 第七步：UI 探索（gstack /design-shotgun）— 一次俾三種 Web 風格，揀咗極簡白底。
成個過程冇喺環境或配置上花時間，所有時間都喺業務邏輯上
邊界與開始建議
呢套組合唔係萬能。極細腳本（30行）直接寫更好；完全唔熟嘅領域 brainstorming 幫唔到你；強合規、要交接團隊嘅項目需要再加 openspec 嗰層。
- 1 裝 gstack（跟官方文檔）。
- 2 裝 superpowers（一組 skill，俾 Claude Code 識別）。
- 3 揾一個你想做但一直未動手嘅小工具。
- 4 打開 Claude Code，話「我想做 X」，等 brainstorming 接管。
- 5 跟住流程走一次，唔使睇曬所有 skill list，用得着就嗰五六個。
最小路徑：裝兩個工具，揾一個小工具，講一句「我想做 X」就開始
把 gstack 和 superpowers 裝在一起跑了一段時間，最大的感受是這倆工具職責完全不衝突，而且互補得很整齊。一個管"動作"，一個管"思維"。你寫代碼的時候，前者把腳手架、測試、部署這些雜事壓到幾乎零成本，後者讓 Claude 在寫代碼的過程中保持基本的工程方法論。
這篇拆開講，兩個工具各自是什麼、各管你項目的哪一段，最後用我自己在寫的一個工具（xiaobai 目標股診斷器）把整條流水線串一遍。
gstack 管"動作"
gstack 是一組 slash command 的集合，裝完之後在 Claude Code 裏可以直接調。它把項目週期裏高頻但繁瑣的動作做成命令，讓你不用每次都從頭來。
我自己最常用的幾個：
/ship：從零起項目骨架，或者把現有項目推到可部署狀態。包含建倉庫、配 CI、寫基礎測試、配置 deploy 平台 /qa：跑測試 + lint + 類型檢查 + 自動 fix 的一條龍 /investigate：當某段代碼你不知道在幹什麼、某個 bug 找不到原因時用，做系統性追溯 /plan-eng-review/ /plan-ceo-review//plan-design-review：分別從工程師、產品視角、設計師角度對你的方案做 review/design-shotgun：讓 AI 一次給三種 UI 方案，你挑 /health：項目健康度體檢，看測試覆蓋、依賴陳舊度、技術債等 /canary：金絲雀發佈相關
它的定位是"減少摩擦"。你心裏有想法、想動手，gstack 讓中間那些"先建文件夾、再 npm init、再裝依賴、再寫 README、再配 GitHub Actions"的步驟壓縮成一行命令。
superpowers 管"思維"
superpowers 是一組 skill。它不是命令，你不用記任何關鍵字。裝完之後 Claude Code 會在合適的場景自動調起來。它管的是"AI 在協作過程中的方法論"。
關鍵 skill：
- brainstorming
：你說"我想做 X"的時候啓動。它會問你三五個澄清問題，把模糊的想法擠出形狀 - writing-plans
：多步任務前用，把要做的事寫成一份可執行計劃 - test-driven-development
：寫功能或修 bug 時啓動。先寫測試再寫實現 - systematic-debugging
：測試掛了或行為異常時啓動。先列假設逐個排除，不直接改代碼 - verification-before-completion
：在它準備說"完成了"之前自檢一遍。這個救過我很多次 - executing-plans
：拿到 plan 之後按步驟跑 - using-git-worktrees
：需要並行多個分支時自動起 worktree
它的定位是"減少草率"。AI 寫代碼很快，但快到一定程度容易跳步：沒問清需求就動手、沒寫測試就聲稱完成、bug 沒定位就亂改。superpowers 把這些容易跳過的環節釘迴流程裏。
各自管哪一段
把一個項目從想法到能用的過程拆開，兩個工具的覆蓋面是這樣：
/ship | ||
/qa | ||
/plan-eng-review | ||
/design-shotgun | ||
/ship | ||
/health/canary |
簡單說：gstack 站在"動作的入口"和"動作的出口"，superpowers 嵌在"動作的中間"。前者解決"做這件事的成本"，後者解決"做這件事的方式"。
一個例子：xiaobai 目標股診斷器
最近在寫的一個工具：輸入股票代碼，輸出多維診斷報告（技術面、基本面、資金面、消息面），給我自己用。下面是這兩個工具在這個項目裏實際怎麼配合。
第 1 步：想清楚要做什麼（superpowers / brainstorming）
我打開 Claude Code，第一句話："我想做一個個股診斷工具，輸入代碼輸出報告。"
brainstorming 自動觸發，問了幾個我沒想透的問題：
報告給誰看？只你自己還是要分享？輸出格式是終端、Web 還是 PDF？ 數據從哪裏取？打算用哪個數據源（Tushare、akshare、付費 API）？數據延遲可以接受多大？ "診斷"是規則引擎還是給 LLM 讓它自由發揮？前者可控但呆板，後者靈活但不可重現 多個維度的權重要不要可配？默認值打算怎麼定？
回答完這五六個問題，我對這工具的輪廓比開始時清晰多了。這一步不寫代碼，只澄清。耗時 8 分鐘左右。
第 2 步：起骨架（gstack / /ship）
/ship它問我項目類型（Python CLI + 簡單 Web 報告）、deploy 目標（暫時不部署，本地用），然後建好倉庫結構：src/、tests/、pyproject.toml、基礎 CI、README 模板。我什麼都沒寫，目錄已經能跑。
第 3 步：寫核心邏輯（superpowers / TDD）
接下來開始寫診斷引擎。我說："先寫技術面打分模塊。輸入是 K 線數據，輸出 0-100 的分數。"
test-driven-development 接管。它先寫了一個測試：給定一段已知是上漲趨勢的 K 線，期望分數大於 70。讓測試紅，再寫實現，讓測試綠。
中間有一處我是真的沒想到的：它在 brainstorming 階段已經記下了"指標的權重要可配"這件事，寫實現時直接把權重做成了配置參數，沒讓我再提一遍。這種"想過的事不會丟"的感覺，是 superpowers 給人的安全感來源。
第 4 步：跑測試（gstack / /qa）
/qa跑測試、lint、類型檢查。第一次跑發現一個我自己沒注意的問題：mypy 報某個函數返回類型不一致。/qa 自動給了 fix 建議，我接受。一條龍完成。
第 5 步：bug 處理（superpowers / systematic-debugging）
寫到資金面打分時遇到一個怪事：同一只股票同一天跑兩次結果不一樣。
systematic-debugging 啓動。它沒直接改代碼，先列出三個假設：數據源返回有隨機性、緩存有問題、計算時用了未排序的數據。然後讓我跟着它一個個驗證。最後定位是第三個：我從字典裏取數據，Python 字典的順序在某些場景下不穩定。改一行代碼解決。
沒有這個 skill，AI 大概率會上來就亂改一通"可能是 XX 問題"，浪費半小時。
第 6 步：自檢（superpowers / verification-before-completion）
寫完所有模塊，我說"我覺得做完了"。
它在準備說"OK"之前自檢了一下，發現了一件事：我提過"想支持港股代碼"，但代碼裏只測了 A 股。它自己加了一個港股的測試，跑過之後才確認完成。
第 7 步：UI 探索（gstack / /design-shotgun）
CLI 跑通後我想做一個簡單的 Web 報告頁。
/design-shotgun它一次給了我三種風格：偏 Bloomberg 終端的暗色多面板、偏紙質感的極簡白底、偏現代金融科技的卡片式。我挑了第二種。這一步如果讓我自己想，能耗一下午。
為什麼效率會翻倍
單看每一步，gstack 幫你省 5 分鐘、superpowers 幫你少返工一次。聽起來都不大。但放在一個完整項目裏，效果是這樣：
gstack 讓起步不卡，不用糾結腳手架。從想法到能跑的代碼，壓縮到分鐘級 superpowers 讓中間不返工。AI 不會跳過 brainstorming，不會跳過 TDD，不會未驗證就聲稱完成 兩個一起，每一段都"摩擦最小 + 方法不跳步"。這種乘法效應在 3-5 天的小項目上最明顯
我自己的體感：單獨用 gstack，做小項目從一週縮到兩三天；單獨用 superpowers，返工次數減半但起步還是慢；兩個一起，xiaobai 這個工具我大概用了一個半週末從零做到能用，裏面絕大部分時間是在寫業務邏輯，沒有在折騰環境、配置、調測試框架這些事上。
一些邊界
這套組合不是萬能。
項目極小（30 行腳本）：直接寫。工具有摩擦，再輕也是摩擦 你完全不熟領域：brainstorming 幫不了你假設都沒有的狀態，先去看資料 強合規、需要長期維護、要交接給團隊：這套太輕，需要再加 openspec 那一層（B 系列會講）
最適合的場景是：你腦子裏有個不完整的想法，想做一個能跑、能用、能給自己或幾個朋友用的東西。這種場景下 gstack + superpowers 幾乎可以讓你只關心業務邏輯本身。
你可以怎麼開始
最小路徑：
裝 gstack（按官方文檔） 裝 superpowers（一組 skill，讓 Claude Code 能識別） 找一個你想做但一直沒動手的小工具 打開 Claude Code，說"我想做 X"，讓 brainstorming 接管 跟着流程走一遍
跑完一次你會有手感。不用看完所有 skill 列表，用得多的就那五六個，剩下的等撞上場景再翻文檔。
下一篇我會拿一個具體的小項目，把這套流程從頭到尾走一遍，記每一步的真實耗時和產出。