用途
Spike Summary 用于记录一次时间盒限制的探索（spike）结果——即为了在正式投入实现之前降低不确定性而进行的聚焦调研。这类探索旨在回答具体问题，例如“我们能否集成这个 API？”或“这项技术是否适用于我们的使用场景？”。把结论记录下来，团队就能基于信息做出决策，而不必让参与 spike 的人反复解释。
何时使用
- 完成一次时间盒限制的技术探索之后
- 需要评估技术选型或供应商选项时
- 概念验证工作需要为团队决策提供依据时
- 需要调查某个拟议方案的可行性时
- 在把工程资源投入一种新方案之前
何时不要使用
- 你要记录的是最终架构决策本身——应使用 develop-adr；spike 负责提供信息，ADR 负责做决定。
- 该探索属于用户研究，而非技术或设计可行性——应使用 discover-interview-synthesis。
- 你想提出 spike 指向的解决方案——应使用 develop-solution-brief。
- spike 尚未发生：本技能只记录结果；应先限定时间盒并实际运行探索。
使用方式
当被要求记录一次 spike 时，按以下步骤操作：
- 清晰陈述问题：说明该 spike 要回答的具体问题。好的 spike 问题应聚焦，并能在现有时间盒内得到回答。如果问题在探索过程中发生了变化，请同时记录原始版本和最终版本。
- 定义时间盒：记录分配的时间（例如 3 天）和实际花费的时间。如果超出时间盒，请说明原因并注明剩余工作。
- 描述方法：说明尝试了什么、按什么顺序、为什么这样做，帮助后续读者理解方法，并了解是否考虑过其他路径。
- 呈现带证据的发现：记录学到了什么，并附上具体证据——代码示例、性能基准、截图或 API 响应。区分已验证的发现与仍需测试的假设。
- 给出明确建议：直接回答原始问题——继续、不继续，或有条件继续。避免模棱两可，团队需要可执行的指引。
- 记录产出物：链接到探索期间创建的代码、原型、图表或文档。这些产出物往往在摘要之外仍有持续价值。
- 记录开放问题：注明该 spike 未能回答的问题，以及可能需要哪些进一步调查。
输出格式
使用 references/TEMPLATE.md 中的模板组织输出。一份完整的 spike summary 应填写模板的每个部分：Overview、Background、Approach、Findings、Recommendation、Artifacts、Open Questions 和 Follow-up Items。
质量检查清单
定稿前请确认：
- 原始问题已清晰陈述
- 时间盒已记录（计划与实际）
- 发现由证据支撑，而非仅凭观点
- 建议直接回答了问题
- 产出物（代码、图表）已链接或附带
- 开放问题指出了剩余的未知项
示例
完整示例见 references/EXAMPLE.md。
限制
关于该技能支持的平台、收费方式、价格、集成方式及具体安装步骤，资料中暂未提供。