如果你已經開始使用 Claude Code 寫程式，你可能很快會遇到一個問題：AI 很會寫程式碼，但不一定會像真正的工程團隊一樣工作。
真正的軟體開發，不只是「寫出功能」而已，它還包含需求判斷、產品取捨、架構審查、設計檢查、品質測試、安全稽核、文件更新、部署驗證與事後回顧。
這也是 gstack 受到開發者關注的原因。
gstack 是由 Garry Tan 開源的 Claude Code 外掛式工具組。它的核心概念很簡單：不要再把 Claude Code 當成單一聊天機器人，而是把它變成一支有分工、有角色、有流程的 AI 工程團隊。
官方 GitHub：
https://github.com/garrytan/gstack
下載 ZIP：
https://github.com/garrytan/gstack/archive/refs/heads/main.zip
內容目錄
gstack 是什麼？
gstack 可以理解成一套 Claude Code 的「專家角色技能包」。
安裝之後，你可以在 Claude Code 中使用一系列 slash command，讓 AI 以不同角色協助你完成軟體開發流程。例如：
- CEO：重新檢查產品方向與市場價值
- 工程主管：審查架構、資料流、邊界條件與測試策略
- 設計師：檢查 UI/UX 品質，避免 AI 產生粗糙介面
- QA：實際開啟瀏覽器測試網頁流程
- 資安主管：用 OWASP Top 10 與 STRIDE 角度檢查安全風險
- Release Manager：協助測試、合併、部署與驗證正式環境
換句話說，gstack 不是單純幫你多加幾個提示詞，而是把 AI 寫程式這件事，從「單人問答」升級成「團隊協作流程」。
為什麼它像一支 20 人的矽谷工程團隊？
一般使用 Claude Code 時，你可能會這樣下指令：
「幫我做一個登入頁。」
Claude Code 會照做，但它不一定會主動幫你思考：
- 這個功能真的重要嗎？
- 使用者流程是否清楚？
- 架構是否會造成未來維護困難？
- 邊界條件是否處理完整？
- UI 是否有 AI 生成感？
- 有沒有資安風險？
- 上線後要怎麼驗證？
gstack 的價值就在於把這些問題拆成不同角色，由不同指令分別處理。
你不再只是在叫 AI 寫程式，而是在指揮一組 AI 產品與工程團隊。
特色
1. 從提示詞升級為角色分工
gstack 最大的特色，是把 Claude Code 的能力拆成不同專家角色。你可以根據任務階段，呼叫 CEO、工程主管、設計師、QA、資安主管或發布工程師。
這讓 AI 不只是執行命令，而是從不同專業角度幫你審查決策。
2. 適合個人開發者與小團隊
對一人公司、獨立開發者、小型新創團隊來說，最缺的通常不是點子，而是完整的開發紀律。
gstack 可以補上這些角色：
- 產品判斷
- 架構審查
- 設計審查
- 程式碼審查
- QA 測試
- 資安檢查
- 部署流程
- 文件更新
它不會真的取代 20 個人，但可以讓一個開發者在流程上更接近成熟工程團隊。
3. 專為 Claude Code 設計
gstack 是圍繞 Claude Code 的工作方式設計的。安裝後會加入 Claude Code 的 skills，讓你直接在 Claude Code 中用 slash command 操作。
例如：
/plan-ceo-review /plan-eng-review /review /qa /ship
這比每次重新寫一大段提示詞更穩定，也更容易建立固定工作流程。
4. 可以實際操作瀏覽器做 QA
gstack 的 /qa 與 /browse 類指令不是單純在腦中想像測試流程，而是能搭配瀏覽器自動化工具，實際開啟網頁、點擊、觀察畫面、檢查錯誤。
這對前端開發、後台系統、SaaS 產品特別有用。
5. 支援團隊模式
如果你不是一個人開發，而是和其他工程師共同維護 repo，gstack 也提供 Team mode。你可以把 gstack 的要求寫入專案設定，讓團隊成員在使用 Claude Code 時都採用同一套 AI 協作規範。
這對團隊一致性很重要，因為 AI 工具最怕的不是不能寫，而是每個人用法不同、品質標準不同、上下文不同。
關鍵指令
以下是實務上最值得先學的 gstack 指令。
/office-hours
適合在專案早期使用。你可以用它描述你正在做的產品、功能或問題，讓 AI 協助你釐清方向。
適合情境：
- 新功能發想
- 專案方向討論
- 不確定下一步要做什麼
- 想讓 AI 先理解整體背景
/plan-ceo-review
用 CEO 或創辦人的角度檢查產品方向。
它會幫你思考：
- 這個功能是否真的值得做？
- 是否能創造足夠價值？
- 是否有更簡單、更有效的做法？
- 這是不是只是在做「看起來很忙」的功能？
適合在開始寫程式前使用。
/plan-eng-review
用工程主管角度檢查技術計畫。
它會關注：
- 架構是否合理
- 資料流是否清楚
- 邊界條件是否完整
- 測試策略是否足夠
- 是否有隱藏假設
適合在準備開發前使用，尤其是資料庫、API、權限、部署流程相關功能。
/plan-design-review
用設計師角度檢查功能規劃。
它會關注：
- 使用者流程是否清楚
- UI 是否直覺
- 視覺層級是否合理
- 是否有 AI 生成感
- 是否符合產品定位
如果你正在做前端頁面、後台介面、SaaS Dashboard，這個指令非常有價值。
/design-consultation
適合從零開始建立設計方向。
例如你可以請它協助：
- 設計首頁
- 規劃後台介面
- 建立設計系統
- 產生多種 UI 方向
- 檢查競品與市場風格
/review
用資深工程師角度檢查目前分支的程式碼。
它不是只看語法，而是會幫你找：
- CI 可能不會抓到的正式環境 Bug
- 架構問題
- 可維護性問題
- 遺漏的錯誤處理
- 測試不足的地方
開 PR 前可以先跑一次。
/investigate
除錯專用指令。
這個指令的重點是：先調查，再修復。
很多 AI 寫程式的問題，是一看到錯誤就直接亂改。/investigate 比較像真正的資深工程師，會先找根因、追資料流、確認假設，再提出修正方式。
/qa
用 QA 角度測試你的應用程式。
它適合用在：
- 前端頁面測試
- 表單流程測試
- 登入後台測試
- SaaS 使用者流程測試
- 修復 Bug 後的回歸測試
如果你有 staging URL，可以讓它實際操作頁面。
/qa-only
和 /qa 類似，但只產出報告，不直接修改程式碼。
適合你只想知道問題在哪裡，暫時不想讓 AI 動手修。
/cso
用資安主管角度做安全檢查。
它會從常見 Web 安全風險與威脅模型角度檢查問題，例如：
- 權限控管
- 資料外洩
- Injection 風險
- 身分驗證問題
- API 濫用
- 邊界條件
對 SaaS、會員系統、後台系統、金流系統特別重要。
/ship
協助準備發布。
它通常會處理：
- 同步主分支
- 執行測試
- 檢查覆蓋率
- 推送變更
- 開啟 PR
適合功能完成後使用。
/land-and-deploy
協助合併與部署後驗證。
它的目標不是只把程式碼合併，而是一路確認部署結果與正式環境健康狀態。
/canary
適合部署後觀察。
可以用來檢查：
- Console error
- 效能退化
- 頁面故障
- 部署後異常
/benchmark
做效能基準測試。
適合比較功能修改前後：
- 頁面載入速度
- Core Web Vitals
- 資源大小
- 前端效能變化
/document-release
發布後更新文件。
它可以協助你檢查 README、使用說明、版本紀錄是否跟實際功能一致。
/retro
做專案回顧。
適合每週或每個功能完成後使用，檢討：
- 哪裡做得好
- 哪裡卡住
- 測試健康度
- 發布節奏
- 下次如何改善
安裝方式
官方建議先準備以下工具：
- Claude Code
- Git
- Bun v1.0+
- Windows 使用者需額外準備 Node.js
Claude Code 安裝指令
在 Claude Code 中貼上以下指令：
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup
接著依照官方 README 的建議，在 CLAUDE.md 加入 gstack 區塊，讓 Claude Code 知道可以使用 gstack skills。
Team mode：讓整個團隊一起使用 gstack
如果你希望整個 repo 都採用 gstack，可以在專案目錄內執行：
(cd ~/.claude/skills/gstack && ./setup --team) && ~/.claude/skills/gstack/bin/gstack-team-init required && git add .claude/ CLAUDE.md && git commit -m "require gstack for AI-assisted work"
如果你不想強制團隊成員使用，可以把：
required
改成：
optional
Windows 使用者注意事項
如果你在 Windows 11 上使用 gstack，官方建議透過 Git Bash 或 WSL 使用。除了 Bun 之外，也需要 Node.js。
如果你使用 Git Bash，而且沒有開啟 Windows Developer Mode，安裝方式可能會改用檔案複製而不是 symlink。這種情況下，每次 git pull 更新 gstack 後，建議重新執行：
cd ~/.claude/skills/gstack && ./setup
gstack 適合誰？
1. 獨立開發者
如果你一個人同時要負責產品、設計、前端、後端、測試、部署，gstack 可以幫你補上流程與審查角色。
2. 技術創業者
如果你是創辦人，還想自己快速做 MVP、測試市場、修功能、部署產品，gstack 可以讓 Claude Code 更像一支小型產品工程團隊。
3. 小型工程團隊
如果團隊已經在使用 Claude Code，gstack 可以統一 AI 協作流程，避免每個工程師都用不同提示詞、不同品質標準。
4. 想建立 AI 開發流程的人
gstack 的價值不只在工具本身，也在於它示範了一種新的 AI 開發方法：
不是叫 AI「幫我寫程式」，而是讓 AI 依照產品、工程、設計、QA、資安、部署流程協作。
建議工作流程
如果你是第一次使用 gstack，可以先照這個流程：
/office-hours
先描述你要做的產品或功能。
/plan-ceo-review
確認這個功能是否值得做。
/plan-eng-review
確認架構與資料流是否合理。
/plan-design-review
確認使用者體驗與畫面設計是否足夠好。
/review
開發完成後做程式碼審查。
/qa
實際測試頁面與流程。
/cso
針對安全風險做檢查。
/ship
準備發布。
/land-and-deploy
合併、部署並驗證正式環境。
/retro
完成後做回顧，整理下次可以改善的地方。
gstack 的真正價值：讓 AI 開發變得有紀律
很多人使用 AI 寫程式時，最大的問題不是 AI 不夠強，而是流程太鬆散。
今天叫 AI 改一點，明天叫 AI 補一點，後天再叫 AI 修 Bug。久了之後，專案很容易變成：
- 架構混亂
- 文件過期
- UI 不一致
- 測試不足
- 部署流程不穩
- 功能越改越難維護
gstack 的出現，代表 AI 輔助開發正在從「聊天式開發」進入「流程式開發」。
它把專業團隊的工作方式拆成一個個明確指令，讓 Claude Code 不只是會寫程式，而是能依照更成熟的軟體工程流程工作。
近期留言