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 安装。