用途
spike 是一次一次性的可行性实验。当某项变更带有尚未验证的技术风险——比如一条未测试过的技术路线、一个外部 API、一个悬而未决的“这到底能不能做”——就应该在编写任何 OpenSpec 产物之前先做 spike。其目的是用写一个脚本的代价回答那个高风险问题，让不可行的想法以最低成本被及早否决。
核心原则：代码是用完即弃的。一个还需要清理的 spike 就是做过头了。只有裁决结论会保留下来。
何时使用
它是由风险触发的，而不是强制步骤。只有当可行性确实不明朗时才做 spike。如果方案明显可行，就直接进入规划阶段。先做足够的研究以选定方案，然后优先 spike 风险最高的未知项——如果最难的部分走不通，去原型化简单的部分毫无意义。
使用方式
流程由以下几个步骤组成：
- 分解（Decompose）——把问题拆成 2–5 个具体的可行性问题（Given/When/Then 形式），按风险排序。最危险的未知项排在最前面。
- 对齐（Align）——把这些问题和计划展示出来，在你开始写代码之前让用户先做裁剪。
- 最小化构建（Build minimal）——在临时位置（/tmp、REPL、一次性 curl）写最小的可运行代码，绝不要放在该变更的 worktree 内。所有东西都硬编码。不要打包、Docker、配置或构建工具。这只是一次 spike。
- 观察（Observe）——运行它并捕获真实输出。没有可观察结果的 spike 什么也证明不了。
- 裁决（Verdict）——恰好给出以下之一作为结论，再加一句话说明原因：
- VALIDATED —— 方案可行；继续规划该变更。
- PARTIAL —— 只有一部分可行；把范围收窄到该子集，然后再规划。
- INVALIDATED —— 方案不可行；不要创建该变更。
适用场景
适合用于存在真实技术不确定性的改动前置阶段，尤其是需要先判断外部依赖是否可用、某条实现路径是否成立、或某类技术方案是否可行的情况。在 spec-driven-tdd 工作流中，它属于 Plan 阶段的一部分，用于决定 /opsx:propose 是否应该运行。
限制
- 风险触发，非强制：可行性明确时不建议使用。
- 代码必须是一次性的：不在变更的 worktree 内编写，不引入打包、Docker、配置或构建工具。
- 无观察结果则无效：没有可观察输出的 spike 不构成验证。
- 裁决必须明确：只允许 VALIDATED、PARTIAL、INVALIDATED 三种结论之一。
- 实验结束后应丢弃临时代码，只把裁决交回调用方。