AI 輔助開發中最容易陷入的陷阱是「無限探索」：讓 Claude 分析三個方案、每個方案各列五個 sub-option、列完再細化⋯⋯最後一整個下午只產出了幾頁 markdown 沒有一行 code。
評估「治過度思考」工具時，測試了 gsd-build/get-shit-done——一套為實用主義設計的 Claude Code 指令集。核心理念：把目標拆到可做就立刻做，做完再 review。搭配強約束的時間盒 + 明確 deliverable，實測把單位時間的 shippable output 提升顯著。
這篇是 GSD 的哲學、安裝、核心命令、實戰對比。
一、GSD 的核心哲學
對立 Superpowers（詳見前文）的「先想好再做」：
- Superpowers：適合複雜、高風險的系統設計
- GSD：適合日常大量中小任務
GSD 三條原則：
1. 時間盒：所有任務有明確截止點
2. 立刻 shippable：每階段必須產出可 demo 的成品
3. 批評留到最後：不在思考階段做 quality gating
二、適用場景
| 場景 | GSD 適用度 |
|---|---|
| Sprint 中的 bug fix | ⭐⭐⭐⭐⭐ |
| MVP / PoC 快速原型 | ⭐⭐⭐⭐⭐ |
| 日常工具腳本 | ⭐⭐⭐⭐⭐ |
| 大型架構重構 | ⭐ |
| 涉及資料庫 schema 改動 | ⭐⭐ |
| 高安全需求系統 | ⭐ |
簡單說：「做錯成本低、重做便宜」的情境下最適用。
三、前置需求
| 項目 | 版本 | 說明 |
|---|---|---|
| Claude Code | 最新 | |
| Git | 2.0+ | 自動 commit |
| Timer 工具 | 選配 | pomodoro-cli 佳 |
四、安裝
cd ~/.claude/commands
git clone https://github.com/gsd-build/get-shit-done gsd
驗證：/gsd 應在 autocomplete 出現。
五、核心指令
5.1 /gsd start <task> --time=<N>
啟動一個時間盒：
User: /gsd start 寫一個 GitHub webhook 接 Slack 通知 --time=30
Claude: ==== GSD START ====
Task: GitHub webhook → Slack
Timebox: 30 minutes
End at: 14:30
Deliverables（30 分後一定要有）:
1. 可跑的 HTTP server (Python)
2. 接 GitHub webhook payload
3. 解析成 Slack message
4. 發到指定 channel
Starting timer. 立刻開始實作，不討論替代方案。
關鍵：Claude 不會再問「你要用 Python 還是 Node」這類問題，直接挑一個開始做。
5.2 /gsd commit
做到關鍵節點自動 commit：
User: /gsd commit
Claude:
git add -A
git commit -m "feat: basic webhook receiver"
✓ committed: abc1234
保留進度點，出事可回滾。
5.3 /gsd ship
時間盒到，產出 shippable：
User: /gsd ship
Claude: ==== GSD SHIP ====
Time up! 檢查 deliverables：
✓ HTTP server running on :3000
✓ Webhook endpoint /github accepts payload
✓ Slack message sent successfully
✓ Basic error handling
✗ Missing: signature verification (improvement)
Shippable state achieved.
Followup improvements noted in TODO.md。
5.4 /gsd stack
把「本來要做但沒做」的改善堆疊起來：
User: /gsd stack "add rate limit"
Claude: ✓ Added to GSD backlog.
目前 backlog: 3 items
下次開新 GSD session 時可從 stack pop。
5.5 /gsd retrospect
週末跑一次，review 一週 GSD sessions：
User: /gsd retrospect --since "1 week ago"
Claude: ==== WEEKLY RETRO ====
Total sessions: 12
Shipped: 10
Timeboxes missed: 2 (why?)
- #5: 其實需求模糊，建議先 /plan（see Superpowers）
- #9: external API 斷線，不是方法問題
Backlog grew: 18 items
Recommendation: review backlog, promote 3 to next week
六、和 Superpowers 互補使用
決策邏輯：
任務 < 30 min 可完成？ → GSD
任務 ≥ 30 min 但 low-risk？ → GSD
任務 ≥ 30 min 且 high-stakes？ → Superpowers（先 think 再做）
把兩個 framework 當成不同場景的工具，不是競爭關係。
七、實戰：一週的 GSD 紀錄
某週我的 GSD 分佈：
| # | 任務 | 時長 | Shipped |
|---|---|---|---|
| 1 | 把 Notion API 換成 v2 | 25m | ✓ |
| 2 | k8s CronJob 改 retry policy | 15m | ✓ |
| 3 | prometheus alert rule 調 threshold | 10m | ✓ |
| 4 | 寫一個 k8s pod topology 視覺化腳本 | 30m | ✓ |
| 5 | GitHub Action secrets audit 腳本 | 20m | ✓ |
| 6 | RSS reader scraper 更新 | 15m | ✓ |
| 7 | LSP config 升級 | 10m | ✓ |
| 8 | Vim keymap 整理 | 25m | ✓ |
總共 150 分鐘，完成 8 個小任務。對比沒用 GSD 之前，類似任務只做完 3~4 個就結束一天。
八、常見坑點
8.1 Timebox 太短
症狀：10 分鐘根本做不完，反而焦慮。
解法：用 Pomodoro 原則，最低 25 分鐘。任務真的很小就批次化（一次做 5 個）。
8.2 不適任務用 GSD
症狀：硬用 GSD 做 OAuth 整合，半天爛尾。
解法：OAuth、DB migration、複雜 business logic 先走 Superpowers 流程。
8.3 Commit 太細碎
症狀：每 5 分鐘 commit 一次，git log 爆炸。
解法：建議 commit 時機：
- 功能階段完成
- 有 working state
- 大型重構前
8.4 Backlog 膨脹
症狀：stack 無限累積，變成另一個焦慮來源。
解法：每週 retro 強制消化。沒做的三個月後自動丟（真的重要早就做了）。
九、融入團隊
9.1 Daily standup 改口
以前：「我今天要做 A」
GSD 版：「我今天要 ship A、B、C，預計 total 90 分鐘」
強制目標具體化。
9.2 PR 描述模板
## GSD Session Output
Task: <一句話>
Timebox: <N min>
Shipped: <list>
Deferred to backlog: <list>
reviewer 能快速理解 scope。
9.3 個人 ship metric
每週 track：shipped / total_sessions。這比「codeline 數」更能反映生產力。
十、跟敏捷文化的關係
GSD 基本上是 XP + Agile 實踐的 AI 版本：
- Time-boxing ≈ Scrum sprint
- Ship-first ≈ Walking skeleton
- Batch retrospect ≈ Sprint retro
- Backlog stack ≈ Product backlog
對熟悉敏捷的團隊，GSD 的心態幾乎零學習成本。
十一、結語
AI 輔助開發最大的陷阱不是「AI 不夠強」，而是「AI 讓你思考太多」。Claude 在探索模式極強，太容易帶著開發者一起發散。GSD 是這個生態裡最有價值的「執行紀律工具」，把 AI 的 exploration 能力約束在 shippable output 上。
對習慣「做事派」的開發者，GSD 會像找到遺失的工具。對習慣「想派」的開發者，它是必要的反作用力。
下一篇會寫「GSD + Claude Memory 的結合」——把 backlog 跨會話持久化，真正變成個人任務管理系統。
發佈留言