Spec Kit：从可测试意图到可追踪验收
Spec Kit 架构：功能意图、模板优先级与已安装指令
分清持久功能文档、运行时模板解析和特定助手的指令文件，定位配置改变为什么没有产生预期结果。
Spec Kit 架构：功能意图、模板优先级与已安装指令知识学习CN编辑简报更新 2026-09-14
你将学会
- 产品意图和流程指令是不同层次
- 模板选择与指令安装发生在不同时间
- 按责任选择扩展、预设或组合包
开始前需要
- 了解基本需求、Git 与测试
- 分清本地开发和应用部署
追踪小功能从意图到证据的过程，区分流程约定与已验证行为。
先看结论
- 功能意图与流程模板属于不同层。
- 运行时模板选择不同于安装时写入指令。
- 真正生效的配置比“已经安装”更重要。
产品意图和流程指令是不同层次
功能的规格、计划和任务描述要构建的产品；模板和助手指令描述怎样生成并检查这些材料；项目原则提供约束。混淆这些层次会让排查困难：修改模板，不会自动让已经存在的功能规格变得正确。
例如隐私要求应出现在功能意图及相关项目原则中。预设可以要求以后生成的文档包含隐私章节，但章节存在本身并不保证运行时行为满足要求。必须分别审阅文档内容和它要求实现的行为。
模板选择与指令安装发生在不同时间
README 给出的优先级依次是项目本地覆盖、预设、扩展和核心模板。它说明模板在运行时解析，而扩展和预设的指令文件在安装时写入助手目录。因此，改动某个文件不一定会改变一个已初始化集成里实际看到的指令。
不能仅凭这个摘要推断完整的组合算法。已阅读的 Python 解析器入口把内容解析委托给 common 辅助函数，自己处理结果与错误。本次没有执行或全面审核优先级及模板组合引擎。
按责任选择扩展、预设或组合包
扩展增加能力，预设调整已有指令与格式，组合包则为某类角色包装选定组件。单个项目的小调整可以使用本地覆盖。层数越多，越需要记录有效配置以及实际指令来自哪里，而不是只保存一份安装清单。
排查异常结果时，先确认正在生成哪个文档、实际模板来源、已安装指令和所选集成，再决定修改什么。较新的核心模板不一定优先于有意保留的本地覆盖，盲目重装反而可能掩盖原因。
如何选择
| 比较维度 | 方案 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
检查集成实际使用的指令。
- 4
记录真正采用的模板来源。
可复制示例
json
{
"排查": true,
"功能文档": "spec.md",
"文档所述优先级": [
"项目本地",
"预设",
"扩展",
"核心"
],
"实际来源": null,
"已检查指令刷新": false,
"已测试完整解析器": false
}常见问题
修改核心模板一定会改变结果吗？
不一定，更高优先级的覆盖可能仍然生效。
本次测试了完整模板解析器吗？
没有，只检查入口和 README 约定，没有测试完整组合引擎。
资料来源
- Spec Kit / README.md来源核查 2026-09-14
- Spec Kit / scripts/python/resolve_template.py来源核查 2026-09-14
- Spec Kit / templates/commands/converge.md来源核查 2026-09-14