关于 spike
用于在规划变更前，通过一次性实验验证尚不确定的技术方案。它优先测试风险最高的问题，以最小可运行原型获取结果，并输出判断而非生产代码。
主要功能
- 01明确可行性问题
- 02优先验证最高风险项
- 03构建最小临时实验
- 04记录可观察结果
- 05给出可行性结论
适用场景
- 01测试不确定的外部 API 方案
- 02确认拟议变更是否可行
- 03在编写规格前厘清技术风险
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/spike确认已加载。
详细介绍
spike
一次性可行性实验。当变更存在尚未验证的技术风险时——例如未经测试的方法、外部 API，或一个尚无答案的“这是否可行？”问题——应在编写任何 OpenSpec 产物之前进行验证。这样做是为了用编写脚本的成本回答高风险问题，尽早低成本地放弃不可行的想法。
**核心原则：**代码是一次性的。需要清理的验证就做过头了。只有结论会保留。
何时使用
由风险决定，而非强制要求。只有在可行性确实不明确时才进行验证。如果方法显然可行，就直接进入规划。先做足够的调研以选定方法，然后优先验证风险最高的未知因素——如果最难的部分行不通，就没有必要为简单部分制作原型。
流程
- 拆解 — 提出 2–5 个具体的可行性问题（Given/When/Then），并按风险排序。最危险的未知因素排在最前面。
- 对齐 — 展示问题和计划；在编写代码前让用户调整范围。
- 最小化构建 — 在临时位置（
/tmp、REPL 或一次性curl）编写最小的可运行内容——绝不放在变更的工作树中。所有内容都硬编码。不做打包、Docker、配置或构建工具。这只是一次验证。 - 观察 — 运行并记录实际输出。没有可观察结果的验证毫无证明力。
- 给出结论 — 只能以以下其中一项结束，并说明原因：
- VALIDATED — 方法可行；继续规划变更。
- PARTIAL — 只有部分内容可行；将范围缩小到该部分，然后规划。
- INVALIDATED — 方法不可行；不要创建该变更。
验证之后
丢弃临时代码。将结论交还给调用方——在 spec-driven-tdd 的 Plan 阶段，它决定是否运行 /opsx:propose。
评论
支持 Markdown