Spec Kit：从可测试意图到可追踪验收
Spec Kit 是什么：把需求、实现与验收持续关联起来
理解 Specify CLI、助手指令和持久功能文档的分工，不把规格文档误当成编译器或上线证明。
你将学会
- 三类工作，不是一个万能生成器
- 用文档解释代码为什么存在
- 第一个功能应有清晰边界
开始前需要
- 了解基本需求、Git 与测试
- 分清本地开发和应用部署
追踪小功能从意图到证据的过程，区分流程约定与已验证行为。
先看结论
- CLI 配置、助手判断和人工验收属于不同责任。
- 持久文档把产品意图关联到实现证据。
- 任务清单完成不代表功能已在线上正常运行。
三类工作，不是一个万能生成器
在固定提交 d848fb4 中，GitHub Spec Kit 结合了 Specify CLI、面向编码助手的指令和功能文档模板。CLI 安装并配置流程，编码助手解释相关指令，人仍然负责决定需求和接受结果。它既不是替代模型，也不是托管应用的平台。
规格驱动流程把意图保存在 spec.md，把技术选择保存在 plan.md，把可执行工作项保存在 tasks.md。所谓规格可执行，描述的是开发方式，不代表任意自然语言都能确定性编译成正确软件。表达流畅的规格同样可能包含错误假设。
用文档解释代码为什么存在
标准流程先确立项目原则，再定义用户结果、规划实现、拆分任务、执行实现并检查收敛。以一个小型阅读列表为例，规格可以要求重启后恢复已保存条目，计划选择存储方式，任务则指出满足要求所需的代码修改和测试。
这样能建立从用户需要到实现证据的可审阅联系。任务打勾只是其中一个观察，不能独立证明行为正确、全部验收场景已执行，或者线上应用包含的就是同一版本。文档完成、实现完成和发布完成应分别记录。
第一个功能应有清晰边界
从一个能独立产生价值的用户旅程开始，不要立即为整个产品生成庞大规格。保留明确的非目标和未决问题。仓库规格模板要求故事优先级、独立测试、验收场景、功能需求、可衡量结果以及假设；占位标题并不等于已完成需求。
本系列阅读七份固定版本来源，包括分析与收敛指令、安装说明和两个脚本入口，并测试一个独立的合成追加约定模型。没有安装 Specify、运行真实编码助手、执行上游脚本，也没有测量交付速度。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
选一个能独立使用的用户旅程。
- 2
写清可观察结果和非目标。
- 3
沿需求、计划、任务、验证追踪证据。
可复制示例
{
"示例": true,
"功能": "本地阅读列表",
"需求": "重启后保留已保存条目",
"任务已勾选": false,
"行为已验证": false,
"生产已验证": false
}常见问题
Spec Kit 是一个语言模型吗？
不是，它为支持的编码助手集成提供工具和流程材料。
显示 Converged 就代表已经上线吗？
不是，审阅、交付和生产验证仍是独立步骤。
资料来源
- Spec Kit / README.md来源核查 2026-09-14
- Spec Kit / templates/spec-template.md来源核查 2026-09-14
- Spec Kit / templates/commands/converge.md来源核查 2026-09-14