好奇心花园🪴

搜索

SearchSearch

最近的笔记

Spike（技术验证）— 在正式构建前通过一次性实验验证想法

2026年5月24日10分钟阅读

{/* 此页面由 website/scripts/generate-skill-docs.py 从技能的 SKILL.md 自动生成。请编辑源文件 SKILL.md，而非此页面。 */}

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、writing-plans、subagent-driven-development、plan

参考：完整 SKILL.md

:::info 以下是当此技能被触发时 Hermes 加载的完整技能定义。这是技能激活时代理所看到的指令。 :::

Spike（技术验证）

当用户想要在投入正式构建之前摸索一个想法时使用此技能——验证可行性、比较方法，或揭示单靠研究无法回答的未知因素。Spike 天生是一次性的。一旦完成了它的使命就应丢弃。

当用户说”让我试试这个”、“我想看看 X 是否可行”、“spike 一下”、“在我投入 Y 之前”、“Z 的快速原型”、“这甚至可能吗？“或”比较 A 和 B”时加载此技能。

何时不要使用此技能

  • 答案可以通过文档或阅读代码获得——只需做研究，不要构建
  • 工作是生产路径——改用 writing-plans / plan
  • 想法已验证——直接跳到实现

如果用户安装了完整的 GSD 系统

如果 gsd-spike 作为同级技能出现（通过 npx get-shit-done-cc --hermes 安装），当用户想要完整的 GSD 工作流时，优先使用 gsd-spike：持久的 .planning/spikes/ 状态、跨会话的 MANIFEST 追踪、Given/When/Then 结论格式，以及与 GSD 其余部分集成的提交模式。本技能是轻量级独立版本，适用于没有（或不想要）完整系统的用户。

核心方法

无论规模大小，每个 spike 都遵循此循环：

分解  →  研究  →  构建  →  结论
   ↑__________________________________________↓
                  根据发现迭代

1. 分解

将用户的想法分解为 2-5 个独立的可行性问题。每个问题就是一个 spike。将其呈现为具有 Given/When/Then 框架的表格：

#Spike验证内容（Given/When/Then）风险
001websocket-streaming给定 WS 连接，当 LLM 流式输出 Token 时，则客户端接收时间 < 100ms高
002apdf-parse-pdfjs给定多页 PDF，当用 pdfjs 解析时，则可提取结构化文本中
002bpdf-parse-camelot给定多页 PDF，当用 camelot 解析时，则可提取结构化文本中

Spike 类型：

  • 标准（standard） — 一种方法回答一个问题
  • 比较（comparison） — 同一问题，不同方法（共享编号，字母后缀 a/b/c）

好的 spike 问题： 具有可观察输出的具体可行性。 差的 spike 问题： 过于宽泛、没有可观察输出，或仅仅是”阅读关于 X 的文档”。

按风险排序。 最可能扼杀想法的 spike 最先运行。如果困难部分行不通，为简单部分制作原型没有意义。

仅在用户已经确切知道他们想要 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") — 检查项目的 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 的效果。默认选择（按偏好排序）：

  1. 一个可运行的 CLI，接收输入并打印可观察输出
  2. 一个演示行为的极简 HTML 页面
  3. 一个带一个端点的小型 Web 服务器
  4. 一个带有可识别断言的单元测试，用于验证问题

深度优先于速度。 在完成一次快乐路径运行后永远不要说”它工作了”。测试边缘情况。跟进令人惊讶的发现。只有调查是诚实的，结论才是可信的。

避免以下内容，除非 spike 特别需要：复杂的包管理、构建工具/打包器、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 行原型）时，使用 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 包含问题、方法、结果、结论
  • 保持代码的一次性——一个需要花 2 天”清理用于生产”的 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 安装。

关系图谱

反向链接

  • 无法找到反向链接