Spike
當使用者想在真正開始建構之前試探某個點子時，請使用此技能——用來驗證可行性、比較不同做法，或是揭開再多研究也無法回答的未知數。Spike 是設計來丟棄的。一旦它們完成了使命，就把它們丟掉。
當使用者說「讓我試試這個」、「我想看看 X 能不能用」、「先把這個 spike 出來」、「在我 commit Y 之前」、「快速 prototype 一下 Z」、「這有可能嗎？」或「比較一下 A 和 B」時，就載入此技能。
何時不該使用
- 答案是從文件或閱讀程式碼就能知道的——直接做研究就好，不要建構
- 這項工作是生產路徑上的——請改用
plan技能 - 點子已經驗證過——直接跳去實作
若使用者安裝了完整的 GSD 系統
如果 gsd-spike 顯示為同級技能（透過 npx get-shit-done-cc --hermes 安裝），當使用者想要完整的 GSD 工作流程時，請優先使用 gsd-spike：它提供持久的 .planning/spikes/ 狀態、跨 session 的 MANIFEST 追蹤、Given/When/Then 的判決格式，以及與 GSD 其他部分整合的 commit 模式。此技能是給沒有（或不想要）完整系統的使用者使用的輕量級獨立版本。
核心方法
無論規模大小，每個 Spike 都遵循這個循環：
分解 → 研究 → 建構 → 判決
↑__________________________________________↓
根據發現迭代
1. 分解
將使用者的點子拆解成 2-5 個獨立的可行性問題。每個問題就是一個 Spike。以表格呈現，並使用 Given/When/Then 框架：
| # | Spike | 驗證 (Given/When/Then) | 風險 |
|---|---|---|---|
| 001 | websocket-streaming | Given 一個 WS 連線，when LLM 串流 token，then 客戶端在 100ms 內收到 chunks | 高 |
| 002a | pdf-parse-pdfjs | Given 一份多頁 PDF，when 用 pdfjs 解析，then 結構化文字可被提取 | 中 |
| 002b | pdf-parse-camelot | Given 一份多頁 PDF，when 用 camelot 解析，then 結構化文字可被提取 | 中 |
Spike 類型：
- 標準——一個方法回答一個問題
- 比較——同一個問題，不同方法（共用編號，以字母
a/b/c為後綴）
好的 Spike 問題： 具體的可行性，且有可觀察的輸出。
不好的 Spike 問題： 太廣泛、沒有可觀察的輸出、或者只是「閱讀關於 X 的文件」。
依風險排序。 最可能讓點子失敗的 Spike 先跑。如果困難的部分行不通，先去 prototype 簡單的部分是沒有意義的。
只有在使用者已經確切知道他們想要 spike 什麼且如此表示時，才跳過分解步驟。此時就把他們的點子視為單一 Spike。
2. 對齊（適用於多 Spike 的點子）
呈現 Spike 表格。問：「按這個順序全部建構，還是要調整？」讓使用者在寫任何程式碼之前，可以刪除、重新排序或重新框架。
3. 研究（每個 Spike，在建構之前）
Spike 並非不需要研究——你研究到足以選出正確方法，然後再動手建構。每個 Spike：
-
簡述。 2-3 句話：這個 Spike 是什麼、為什麼重要、主要風險。
-
呈現競品方法（如果真的有選擇的話）：
方法 工具/函式庫 優點 缺點 狀態 ... ... ... ... 持續維護 / 已廢棄 / Beta -
選一個。 說明原因。如果有 2 個以上都可信，就在 Spike 內建立快速變體。
-
對於沒有外部依賴的純邏輯，跳過研究。
在研究步驟中使用 Hermes 工具：
web_search("python websocket streaming libraries 2025")——找出候選web_extract(urls=["https://websockets.readthedocs.io/..."])——閱讀實際文件（回傳 markdown）terminal("pip show websockets | grep Version")——檢查專案的 venv 中安裝了什麼
對於沒有文件頁面的函式庫，透過 read_file 複製並閱讀它們的 README.md / examples/。如果使用者已設定 Context7 MCP，那也是很好的資料來源 —— mcp_*_resolve-library-id 然後 mcp_*_query-docs。
4. 建構
每個 Spike 一個目錄。保持獨立。
spikes/
├── 001-websocket-streaming/
│ ├── README.md
│ └── main.py
├── 002a-pdf-parse-pdfjs/
│ ├── README.md
│ └── parse.js
└── 002b-pdf-parse-camelot/
├── README.md
└── parse.py
偏向使用者可以互動的東西。 Spike 會在唯一的輸出只是一行顯示「它動了」的日誌時失敗。使用者需要感覺到 Spike 在運作。預設選擇，依偏好順序：
- 一個可執行的 CLI，接受輸入並印出可觀察的輸出
- 一個能展示行為的最小化 HTML 頁面
- 一個只有一個端點的小型網頁伺服器
- 一個用可識別的斷言來測試問題的單元測試
深度重於速度。 絕對不要在執行一次快樂路徑後就宣稱「它動了」。測試邊緣案例。跟隨令人驚訝的發現。只有在調查誠實時，判決才值得信賴。
避免（除非 Spike 特別需要）：複雜的套件管理、建構工具/bundlers、Docker、環境變數檔案、設定系統。把所有東西都寫死——這只是一個 Spike。
建構一個 Spike —— 典型的工具序列：
terminal("mkdir -p spikes/001-websocket-streaming")
write_file("spikes/001-websocket-streaming/README.md", "# 001: websocket-streaming\n\n...")
write_file("spikes/001-websocket-streaming/main.py", "...")
terminal("cd spikes/001-websocket-streaming && python3 main.py")
# 觀察輸出，迭代。
平行比較 Spike（002a / 002b）—— 委派。 當兩種方法可以平行執行，且兩者都需要真正的工程（而不是 10 行的 prototype）時，使用 delegate_task 進行發散：
delegate_task(tasks=[
{"goal": "建構 002a-pdf-parse-pdfjs: ...", "toolsets": ["terminal", "file", "web"]},
{"goal": "建構 002b-pdf-parse-camelot: ...", "toolsets": ["terminal", "file", "web"]},
])
每個子代理會回傳自己的判決；你則負責撰寫兩者的比較報告。
5. 判決
每個 Spike 的 README.md 結尾如下：
## 判決：VALIDATED | PARTIAL | INVALIDATED
### 可行之處
- ...
### 不可行之處
- ...
### 意外發現
- ...
### 對正式建構的建議
- ...
VALIDATED（已驗證） = 核心問題得到肯定的答案，且有證據。
PARTIAL（部分可行） = 在 X、Y、Z 的限制下可行——請記錄下來。
INVALIDATED（不可行） = 因為這個原因而無法運作。這是一個成功的 Spike。
比較型 Spike
當兩種方法回答同一個問題時（002a / 002b），接連建構它們，然後在最後進行頭對頭比較：
## 頭對頭比較：pdfjs vs camelot
| 面向 | pdfjs (002a) | camelot (002b) |
|-----------|--------------|----------------|
| 抽取品質 | 9/10 結構化 | 7/10 僅限表格 |
| 設定複雜度 | npm install，1 行 | pip + ghostscript |
| 100 頁 PDF 效能 | 3 秒 | 18 秒 |
| 處理旋轉文字 | 否 | 是 |
**勝出者：** 對於我們的使用案例是 pdfjs。如果之後需要以表格為主的抽取，再用 camelot。
前線模式（挑選下一個 Spike 的對象）
如果 Spike 已經存在，而使用者問「我接下來該 spike 什麼？」，請遍歷現有目錄，尋找：
- 整合風險——兩個已驗證的 Spike 會觸及相同的資源，但卻是獨立測試的
- 資料交接——Spike A 的輸出被假設與 Spike B 的輸入相容，但從未驗證
- 願景中的缺口——假設有能力卻未經證實的功能
- 替代方法——針對 PARTIAL 或 INVALIDATED 的 Spike 從不同角度切入
提出 2-4 個候選，以 Given/When/Then 呈現。讓使用者挑選。
輸出
- 在儲存庫根目錄下建立
spikes/（如果使用者使用 GSD 慣例，則是.planning/spikes/） - 每個 Spike 一個目錄：
NNN-描述性名稱/ - 每個 Spike 的
README.md記錄問題、方法、結果與判決 - 讓程式碼保持可丟棄——一個需要花兩天時間「為生產環境清理」的 Spike 就是一個壞的 Spike
出處
改編自 GSD (Get Shit Done) 專案的 /gsd-spike 工作流程 —— MIT © 2025 Lex Christopherson (gsd-build/get-shit-done)。完整的 GSD 系統提供持久的 Spike 狀態、MANIFEST 追蹤，以及與更廣泛的規格驅動開發管線的整合；安裝方式：npx get-shit-done-cc --hermes --global。