附录A. 本教程与 Spec Kit 和 Kiro 的对应关系
本教程使用 Qwen Code 的 SDD 作者方言：
mission.md
tech-stack.md
roadmap.md
requirements.md
plan.md
validation.md这不是唯一可能的格式。Spec Kit 和 Kiro 解决类似的问题，但对工件的命名不同，阶段划分方式也不同。
主要区别
在本教程中，validation.md 被单独提取为一个文件。这是有意为之：代理和人类都需要一组明确的事实来决定是否可以合并分支。
在其他系统中，这一理念可能分散在任务、检查清单、计划分析或验收标准中。
对应关系表
| 本教程 | Spec Kit | Kiro | 含义 |
|---|---|---|---|
mission.md | 项目宪法 | steering 文件 | 项目为何存在 |
tech-stack.md | 宪法与计划 | steering 文件、design | 技术约束 |
roadmap.md | 规范与任务的顺序 | 功能与任务列表 | 阶段顺序 |
requirements.md | /speckit.specify 和 /speckit.clarify | requirements | 需要构建什么 |
plan.md | /speckit.plan 和 /speckit.tasks | design 和 tasks | 如何分解实现 |
validation.md | 部分 /speckit.analyze、检查清单和任务 | 任务和测试中的标准 | 哪些事实允许合并 |
QWEN.md | 代理集成规则 | steering 文件 | 代理在项目中应如何行为 |
| Qwen Code 技能 | 命令、扩展和预设 | agent hooks 和 steering | 可重复的过程 |
如何迁移流程
如果团队使用 Spec Kit，不必强行推广本教程中的文件名。迁移的是理念：
- 项目宪法必须明确；
- 歧义需要在计划之前澄清；
- 计划应将架构决策与任务列表分开；
- 验证事实需要在实现之前可见；
- 实现应与工件对比，而非与聊天记忆对比。
如果团队使用 Kiro，迁移三个层次：
- steering 文件用于持久规则；
- specs 用于具体功能；
- 任务和测试作为可验证的实现路径。
为什么教程使用自己的格式
教程的格式有意比工业级命令集更简单。
原因：
- 无需专用 CLI 工具即可轻松阅读文件；
- Qwen Code 可以直接处理它们；
validation.md将验证作为独立的思考阶段；- 结构适用于小型项目，也便于迁移到其他代理；
- 读者看到的是过程，而不仅仅是类似
/speckit.implement的命令。
缺点也存在：在大型团队中，需要补充关于合并请求、路线图负责人、规范评审和任务模板的约定。这些主题在第16部分中展开。
如何选择格式
在以下情况使用本教程的格式：
- 正在学习 SDD；
- 项目较小；
- 团队希望在普通 Markdown 文件中看到所有决策；
- 需要不依赖特定平台的流程。
在以下情况使用 Spec Kit：
- 团队需要现成命令和模板；
- 需要单独的歧义澄清步骤；
- 重视扩展、预设和可重复工作流；
- 有多个项目，需要统一标准。
在以下情况使用 Kiro：
- 团队已在 Kiro 中工作；
- 需要内置 specs、steering 文件和代理钩子；
- 重视与 IDE 流程的紧密集成。
格式不应成为教条。关键是意图、计划、验证和决策应存在于可评审的工件中。