文章目录
- 前言
- [SDD 的核心定义与发展层级](#SDD 的核心定义与发展层级)
- 规范（Spec）到底是什么？
- [评测 SDD 工具：实际场景困境](#评测 SDD 工具：实际场景困境)
- [三大 SDD 工具剖析](#三大 SDD 工具剖析)
-
- [1. Kiro](#1. Kiro)
- [2. spec-kit](#2. spec-kit)
- [3. Tessl Framework](#3. Tessl Framework)
- 实践观察与思考
- 思考与总结
前言
伴随生成式 AI 的爆发，越来越多开发工具开始强调"规范优先"（Spec-Driven Development，简称 SDD）理念。本文通过拆解 Kiro、spec-kit、Tessl 三款主流工具，帮助开发者理解 SDD 当前的定义、实践范式，以及工具间的对比与选型思路。
SDD 的核心定义与发展层级
规范驱动开发（SDD）目前尚无统一定义。总结现有资料，SDD 主要指"在编写 AI 辅助代码前，先写规范文档（documentation first），规范成为人和 AI 的'唯一事实源'"。
常见 SDD 实践大致分为三层：
| 层级 | 特点与流程描述 |
|---|---|
| 1. 规范优先（Spec-first） | 优先撰写规范文档，贯穿 AI 辅助开发流程；但规范仅为暂时性产物，任务完成后可删除。 |
| 2. 规范锚定（Spec-anchored） | 规范文档成为长期资产，持续与功能进化同步更新维护。 |
| 3. 规范即代码源（Spec-as-source） | 规范作为唯一编辑对象，开发者只维护规范，代码完全由 AI 自动生成。 |
实际上，绝大多数 SDD 实践都停留在"规范优先"阶段，是否向后续层级演变，取决于具体工具及团队规范策略。
规范（Spec）到底是什么？
"规范"目前还没有通用严格定义，但可理解为：
规范是一组结构化、面向行为的自然语言文档，用以准确表达软件功能、为 AI 代码生成提供指令基础。
它不同于更通用的上下文文档（如 AGENTS.md、架构描述），后者强调项目"背景知识"，而规范更强调具体功能实现的细化要求。[1]
规范 VS. 内存库（Memory Bank）关系示意：
- Memory Bank：全局性知识与原则，覆盖项目所有 AI 交互，长期有效。
- Spec：针对具体变更或新功能，任务驱动型，短期或持续跟进。
评测 SDD 工具：实际场景困境
评测 SDD 工具的难点在于：
- 需在全新项目与存量项目间切换测试，涵盖不同问题规模与复杂度；
- 评审、迭代规范产物耗时费力，需大量人工干预。
如 GitHub 在介绍 spec-kit 时所言："你的角色不仅是导航，更要反复校验和优化。"
三大 SDD 工具剖析
1. Kiro
- 定位：轻量级 SDD 实践工具，主要支持规范优先。
- 工作流 ：需求（Requirements）→ 设计（Design）→ 任务（Tasks）三步。
- 需求：采用用户故事（As a ...）与验收准则（GIVEN/WHEN/THEN）结构
- 设计：涵盖数据流、模型、架构等组成部分
- 任务：明确与需求的映射关系，并支持逐步查看/运行任务
- 内存库（Memory Bank/Steering）：如 product.md、tech.md、structure.md，非必选，仅辅助理解。
工作目录结构示例：
/steering
product.md
tech.md
structure.md
/category-label-enhancement
requirements.md
design.md
tasks.md
适合任务驱动、快速迭代，长期维护支持较弱。[1]
2. spec-kit
- 定位：GitHub 主推、偏向 CLI 的 SDD 工具，支持常见 AI 编码助手（如 Copilot）。
- 工作流 ：宪法（Constitution）→ 规范（Specify）→ 计划（Plan）→ 任务（Tasks）
- 宪法文件：高层原则、不可变规则，贯穿每个变更
- 规范文档：多文件分层设计（如 data-model、plan、tasks、api、component）
- Checklists 贯穿各阶段，反复提醒质量与完整性
-
目录结构 ：
/.specify memory scripts templates /specs/001-when-a-user data-model.md plan.md tasks.md spec.md research.md api.md component.md
- 目前仍以"短周期变更"流程为主，不完全支持规范锚定及长期维护需求。[1]
3. Tessl Framework
https://docs.tessl.io/introduction-to-tessl/quick-start-guide-tessl-framework
- 定位：正在测试阶段，CLI 配置为主，探索规范锚定和"规范即源"级实践。
- 工作流：支持规范反向生成（如根据 JS 文件生成 spec），规范中通过 @generate/@test 控制生成逻辑。
- 当前实现为"一规范对应一代码文件"，代码与规范同步且代码禁止人手编辑（如文件头部注释
// GENERATED FROM SPEC - DO NOT EDIT）。
-
目录结构示例 ：
/.tessl/framework KNOWLEDGE.md AGENTS.md ... dynamic-data-renderer.spec.md dynamic-data-renderer.js
- 强调规范与代码的双向同步，提升自动化和规范复用可能性。
实践观察与思考
- 工作流适应性：各工具均有预设流程，但对于不同规模任务需更高灵活性（修 bug vs.新功能开发）。
- 规范评审体验：频繁筛查、对比大量 Markdown 规范文档，实际效率不一定高于代码评审。
- 控制感受误差：AI 有时忽视规范细节，或过度遵循规则导致冗余、重复，需人力持续迭代优化。
- 功能 vs 技术规范分离难题：实际撰写规范很难纯粹只写"业务需求"，往往掺杂技术实现细节------这是行业长期痛点。
- 目标用户定位：谁负责撰写和维护规范？开发还是产品经理？各工具未明确指引。
思考与总结
SDD 目前在定义和实践上尚处于早期探索阶段，各家工具差异明显，需根据自身项目体量、团队习惯审慎选择。如果忽视工作负载和团队协作实际，盲目"流程重"或"规范重"，反而可能适得其反。
SDD 是否真能解决开发过程痛点，还需持续观察更多实战案例与工具演进。[1]
本文译自 Martin Fowler 博客，部分内容有改写和补充，仅供技术交流参考