Spike（技術探針）

在正式構建之前，通過一次性實驗來驗證想法。

技能元數據

來源	捆綁版（默認安裝）
路徑	skills/software-development/spike
版本	1.0.0
作者	Hermes Agent（改編自 gsd-build/get-shit-done）
許可證	MIT
平臺	linux, macos, windows
標籤	spike, prototype, experiment, feasibility, throwaway, exploration, research, planning, mvp, proof-of-concept
相關技能	sketch, subagent-driven-development, plan

參考：完整 SKILL.md

信息

以下是 Hermes 在觸發此技能時加載的完整技能定義。這是技能激活時代理所看到的指令。

Spike（技術探針）

當用戶希望在承諾進行實際構建之前試探某個想法——驗證可行性、比較方法或揭示僅靠研究無法回答的未知因素時，請使用此技能。Spike（技術探針）在設計上是一次性的。一旦它們完成了使命（償還了技術債務），就將其丟棄。

當用戶說出類似“讓我試試這個”、“我想看看 X 是否可行”、“做個 Spike 探探路”、“在我承諾做 Y 之前”、“Z 的快速原型”、“這甚至可能嗎？”或“比較 A 與 B”時，加載此技能。

何時不使用此技能

• 答案可以通過文檔或閱讀代碼得知——只需進行研究，不要構建
• 工作屬於生產路徑——請改用 plan 技能
• 想法已經過驗證——直接跳轉到實現階段

如果用戶安裝了完整的 GSD 系統

如果 gsd-spike 作為兄弟技能出現（通過 npx get-shit-done-cc --hermes 安裝），當用戶希望使用完整的 GSD 工作流時，優先選擇 gsd-spike：包括持久的 .planning/spikes/ 狀態、跨會話的 MANIFEST 跟蹤、Given/When/Then 結論格式以及與 GSD 其餘部分集成的提交模式。此技能是為沒有（或不想要）完整系統的用戶提供的輕量級獨立版本。

核心方法

無論規模大小，每個 Spike 都遵循以下循環：

decompose  →  research  →  build  →  verdict
   ↑__________________________________________↓
                  iterate on findings

1. 分解

將用戶的想法分解為 2-5 個獨立的可行性問題。每個問題對應一個 Spike。使用 Given/When/Then 框架以表格形式呈現：

#	Spike	驗證內容 (Given/When/Then)	風險
001	websocket-streaming	給定一個 WS 連接，當 LLM 流式傳輸 token 時，客戶端在 < 100ms 內接收數據塊	高
002a	pdf-parse-pdfjs	給定一個多頁 PDF，當使用 pdfjs 解析時，可提取結構化文本	中
002b	pdf-parse-camelot	給定一個多頁 PDF，當使用 camelot 解析時，可提取結構化文本	中

Spike 類型：

• standard（標準） — 一種方法回答一個問題
• comparison（比較） — 同一個問題，不同的方法（共享編號，字母后綴 a/b/c）

好的 Spike 問題： 具體的可行性，具有可觀察的輸出。 壞的 Spike 問題： 過於寬泛、無可觀察輸出，或僅僅是“閱讀關於 X 的文檔”。

按風險排序。 最可能導致想法被否決的 Spike 首先運行。如果困難的部分行不通，原型化簡單的部分毫無意義。

僅當用戶已經確切知道他們想要探測什麼並明確說明時，才跳過分解。此時將他們的想法視為單個 Spike。

2. 對齊（針對多 Spike 想法）

展示 Spike 表格。詢問：“按此順序全部構建，還是進行調整？”在編寫任何代碼之前，讓用戶刪除、重新排序或重新構建框架。

3. 研究（每個 Spike 在構建之前）

Spike 並非無需研究——你需要進行足夠的研究以選擇正確的方法，然後進行構建。針對每個 Spike：

1. 簡要說明。 2-3 句話：此 Spike 是什麼，為何重要，關鍵風險。

2. 如果存在真正的選擇，列出競爭方法：

   方法	工具/庫	優點	缺點	狀態
   ...	...	...	...	維護中 / 已廢棄 / 測試版

3. 選擇一個。 陳述原因。如果有 2 個或以上可信選項，則在 Spike 範圍內構建快速變體。

4. 對於沒有外部依賴的純邏輯，跳過研究。

在研究步驟中使用 Hermes 工具：

• web_search("python websocket streaming libraries 2025") — 查找候選項
• web_extract(urls=["https://websockets.readthedocs.io/..."]) — 閱讀實際文檔（返回 markdown）
• terminal("pip show websockets | grep Version") — 檢查項目虛擬環境中安裝的內容

對於沒有文檔頁面的庫，通過 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 在運行。默認選擇，按偏好順序排列：

1. 一個可運行的 CLI，接受輸入並打印可觀察的輸出
2. 一個演示行為的最小化 HTML 頁面
3. 一個帶有一個端點的小型 Web 服務器
4. 一個通過可識別的斷言來測試該問題的單元測試

深度優於速度。 絕不要在僅運行一次成功路徑後就宣稱“它工作了”。測試邊緣情況。跟進令人驚訝的發現。只有當調查是誠實時，結論才值得信賴。

避免使用複雜包管理、構建工具/打包器、Docker、環境變量文件、配置系統，除非 Spike 特別要求這些。硬編碼所有內容——這只是一個 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")
# Observe output, iterate.

並行比較 Spike（002a / 002b）—— 委託。 當兩種方法可以並行運行且都需要真正的工程工作（而不是 10 行代碼的原型）時，使用 delegate_task 進行分發：

delegate_task(tasks=[
    {"goal": "Build 002a-pdf-parse-pdfjs: ...", "toolsets": ["terminal", "file", "web"]},
    {"goal": "Build 002b-pdf-parse-camelot: ...", "toolsets": ["terminal", "file", "web"]},
])

每個子代理返回其自己的結論；你編寫頭對頭的比較分析。

5. 結論

每個 Spike 的 README.md 以以下內容結尾：

## Verdict: VALIDATED | PARTIAL | INVALIDATED

### What worked
- ...

### What didn't
- ...

### Surprises
- ...

### Recommendation for the real build
- ...

VALIDATED（已驗證） = 核心問題得到了肯定的回答，並有證據支持。 PARTIAL（部分有效） = 在約束條件 X、Y、Z 下有效 —— 請記錄這些約束。 INVALIDATED（無效） = 不起作用，原因如下。這是一個成功的 Spike。

比較 Spike

當兩種方法回答同一個問題時（002a / 002b），依次構建它們，然後在最後進行頭對頭比較：

## Head-to-head: pdfjs vs camelot

| Dimension | pdfjs (002a) | camelot (002b) |
|-----------|--------------|----------------|
| Extraction quality | 9/10 structured | 7/10 table-only |
| Setup complexity | npm install, 1 line | pip + ghostscript |
| Perf on 100-page PDF | 3s | 18s |
| Handles rotated text | no | yes |

**Winner:** pdfjs for our use case. Camelot if we need table-first extraction later.

前沿模式（選擇下一個要進行的 Spike）

如果已經存在 Spike，且用戶問“我接下來應該進行什麼 Spike？”，遍歷現有目錄並尋找：

• 集成風險 —— 兩個已驗證的 Spike 觸及相同的資源，但是獨立測試的
• 數據交接 —— 假設 Spike A 的輸出與 Spike B 的輸入兼容，但從未證實
• 願景中的空白 —— 假設具備但未經驗證的功能
• 替代方法 —— 針對 PARTIAL 或 INVALIDATED Spike 的不同角度

提出 2-4 個候選方案，格式為 Given/When/Then（給定/當/那麼）。讓用戶選擇。

輸出

• 在倉庫根目錄創建 spikes/（如果用戶使用 GSD 約定，則創建 .planning/spikes/）
• 每個 Spike 一個目錄：NNN-descriptive-name/
• 每個 Spike 包含一個 README.md，記錄問題、方法、結果、結論
• 保持代碼為一次性使用 —— 如果一個 Spike 需要 2 天時間來“清理以投入生產”，那它是一個糟糕的 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 安裝。