在 AI 辅助编程飞速发展的当下，“Spec-Driven Development（SDD，规格驱动开发）” 逐渐成为技术领域的热门概念。它打破了传统 “代码先行” 的开发模式，将 “规格说明（Spec）” 推至核心位置，重塑了人类与 AI 协作的编程流程。本文从SDD的核心定义、核心层次、关键要素、工具实践到现存挑战，全面解析这一新兴开发范式。
SDD 的核心定义：以规格为 “单一真相源”
SDD 尚未形成统一的行业标准定义，但从 GitHub、Tessl 等平台的实践与工具设计中，可提炼其核心内涵：在编写/生成代码前先构建结构化规格，以规格作为人类与 AI 的共识基础，指导开发全流程的开发方法。
GitHub 将其描述为 “软件维护的核心是规格演进，开发的通用语言升级至更高维度，代码仅为最终实现环节”；Tessl 则强调 “规格而非代码是首要产物，用结构化、可测试的语言描述意图，由智能Agent生成匹配代码”。本质上，SDD 是 “文档先行” 理念（更是ATDD：）在 AI 时代的升级 —— 规格不再是可有可无的辅助文档，而是贯穿开发、维护、演进全生命周期的 “单一真相源”。
SDD 的三层实现维度：从基础到进阶
SDD 并非单一模式，而是根据规格的生命周期与作用范围，分为三个递进的实现层次，不同工具的定位也因此有所差异：
1. Spec-first（规格优先）：开发的起点
这是 SDD 的基础形态，要求在启动任何编码任务前，先编写详尽的规格说明，再将其作为 AI 辅助开发的核心输入。所有 SDD 工具均默认遵循这一原则，它确保了开发的每一步都有明确的意图指引，避免 AI 生成的代码偏离需求。
2. Spec-anchored（规格锚定）：维护的核心
任务完成后不丢弃规格，将其长期保留并持续迭代，作为功能后续演进、bug 修复的核心依据。这种模式下，规格成为功能的 “数字档案”，无论项目迭代多久，开发者与 AI 都能通过规格追溯原始意图，确保变更的一致性。
3. Spec-as-source（规格即源码）：终极形态
规格成为项目的核心源文件，人类仅需维护和编辑规格，无需直接触碰代码 ——AI 会根据规格自动生成、更新代码，甚至在代码中标注 “// GENERATED FROM SPEC - DO NOT EDIT” 以禁止人工修改。这是 SDD 的理想状态，实现了 “意图与实现的彻底分离”。
SDD 的关键要素：Spec 与记忆库
要理解 SDD 的运作逻辑，需明确两个核心要素的定义与边界：
1. 什么是 Spec（规格说明）？
Spec 是结构化、面向行为的 artifacts（或一组相关文件），以自然语言编写，核心作用是明确软件功能意图，为 AI 编码代理提供可解析的指导。其关键特征包括：
无统一格式：不同工具对 Spec 的结构、细节深度要求不同，可是 “用户故事 + 验收标准”（如 Kiro），也可包含 API 定义、测试关联（如 Tessl）；
聚焦具体功能：仅服务于特定任务或功能模块，比如 “分类标签格式化” 功能的 Spec，不会涉及项目全局规则；
连接意图与代码：是人类意图的结构化表达，也是 AI 生成代码的直接依据，避免自然语言指令的模糊性。
2. Spec 与记忆库（Memory Bank）的边界
SDD 中，Spec 并非项目的全部上下文，需与 “记忆库” 明确区分 —— 记忆库是存储项目全局通用信息的集合，二者分工截然不同：
维度 | Spec（规格说明） | 记忆库（Memory Bank） |
适用范围 | 特定任务 / 功能（如 “动态数据渲染”） | 整个代码库（如产品架构、技术栈规则） |
生命周期 | 随功能创建 / 变更而存在 | 贯穿所有 AI 编码会话，长期有效 |
核心作用 | 指导单个功能的 AI 编码与验证 | 确保所有功能符合项目统一标准 |
例如 Kiro 将记忆库命名为 “steering”，默认生成 product.md（产品全局信息）、structure.md（项目结构）、tech.md（技术规范）三类文件，为所有功能的开发提供统一上下文；而 Spec 仅针对具体功能，聚焦 “该功能要做什么”。
SDD 工具实践：三款代表性工具解析
SDD 的价值需通过工具落地，文中重点研究的 Kiro、spec-kit、Tessl，虽同为 SDD 工具，但在定位、形态和实现路径上差异显著：
1. Kiro：轻量灵活的 Spec-first 工具
Kiro 是三款工具中最轻量化的存在，严格遵循 Spec-first 模式，但暂未强调 Spec-anchored 或 Spec-as-source。其核心特征包括：
固定工作流：以 “需求→设计→任务” 为核心流程，每个环节对应独立的 Markdown 文档（requirements.md、design.md、tasks.md）；
规格结构清晰：需求文档采用 “用户故事 + 验收标准” 格式（如 “连字符转空格、首字母大写” 的明确规则），设计文档涵盖架构、数据流、测试策略等，任务文档则与需求一一对应，便于分步执行；
记忆库（steering）灵活非强制：Kiro 的记忆库名为 “steering”，默认生成三类全局文件，但核心工作流不依赖其存在 —— 开发者即便未使用该功能，也能完成开发任务，体现了轻量、灵活的定位。
2. spec-kit：GitHub 的可定制化 SDD 方案
spec-kit 是 GitHub 推出的 SDD 工具，以 CLI 形式分发，支持为多种 AI 编码助手搭建工作空间，核心特征如下：
强定制化：所有 artifacts 直接集成到项目工作区，通过 “/specify” 等斜线命令与 AI 交互，支持自定义 prompt 模板；
记忆库（constitution）为核心前提：将记忆库命名为 “constitution（章程）”，包含项目不可变更的高层原则，贯穿所有开发步骤，确保 AI 生成的代码符合项目全局规则；
多文件规格体系：一个功能的规格由 spec.md、plan.md、tasks.md 等多个文件组成，包含详细的审查清单（如 “无实现细节”“需求可测试”），但也导致文档冗余问题。
值得注意的是，spec-kit 虽提及 “规格演进”，但为每个规格创建独立分支的设计，使其更偏向 Spec-first，尚未完全实现 Spec-anchored 的长期维护目标。
3. Tessl Framework：探索 Spec-as-source 的先锋
仍处于私有 beta 阶段的 Tessl，是唯一明确追求 Spec-anchored，并探索 Spec-as-source 的工具，其核心突破在于：
规格即源码：Spec 是项目的核心维护对象，代码文件标注 “// GENERATED FROM SPEC - DO NOT EDIT”，人类仅需编辑 Spec，AI 负责代码生成；
双向映射：支持通过 CLI 从现有代码反向生成 Spec（tessl document --code ...js），也可通过 Spec 生成代码（tessl build），适配绿场与棕场项目；
结构化 Spec 设计：Spec 包含 API 定义、功能能力、测试关联等模块，通过@generate“@test” 等标签明确 AI 的生成任务，降低 LLM 的解读偏差。
Tessl 的探索为 SDD 的终极形态提供了可能，但目前仍受限于 “一 Spec 对应一文件” 的映射关系，其规模化应用尚待验证。
SDD 的现实挑战：潜力与待解难题
尽管 SDD 理念前沿，但在实际应用中仍面临诸多挑战，这也是其尚未成为主流开发范式的核心原因：
1. 工作流适配性不足
Kiro 和 spec-kit 均提供固定的 opinionated 工作流，但难以适配不同规模的问题：用 Kiro 修复小 bug，会被拆分为多个用户故事和验收标准，显得 “小题大做”；用 spec-kit 开发中等规模功能，会生成大量重复的 Markdown 文档，增加审查负担。
2. 文档审查负担过重
SDD 将 “审查代码” 转化为 “审查规格文档”，但 spec-kit 等工具生成的文档冗长且重复，部分文档还包含嵌入代码，导致审查效率低于直接审查代码。如何优化规格审查体验，是 SDD 工具需解决的关键问题。
3. AI 执行偏差风险
即便有详尽的规格和全局规则，AI 仍可能出现执行偏差：要么忽略部分指令（如 spec-kit 重复生成已有代码），要么过度执行规则（如因遵循章程而生成冗余功能）。更大的上下文窗口并未完全解决 AI “理解不精准” 的问题。
4. 功能与技术规格的分离难题
SDD 的核心诉求之一是分离功能意图（“做什么”）与技术实现（“怎么做”），但实际开发中，开发者常困惑于何时保持功能纯粹性、何时加入技术细节，且行业缺乏成熟的分离标准，导致规格易混入实现细节。
5. 目标用户模糊
SDD 工具的教程常包含 “用户故事”“产品目标” 等偏产品经理的工作内容，但未明确目标用户：是让开发者兼顾需求分析，还是让产品与开发协作完成规格？模糊的定位导致工具难以精准满足用户需求。
总结与展望：SDD 的未来方向
SDD 的核心价值在于建立了人类与 AI 的 “协作契约”—— 通过结构化规格，减少 AI 编码的不确定性，同时让开发流程更聚焦于 “功能意图” 而非 “语法细节”。其三个层次的实现路径，也为不同需求的项目提供了灵活选择：小型项目可采用 Spec-first 简化开发，中大型项目可尝试 Spec-anchored 保障维护一致性，前沿探索可聚焦 Spec-as-source 实现效率跃迁。
但 SDD 的成熟仍需解决诸多问题：工具需提供更灵活的工作流适配不同问题规模，优化规格文档的简洁性与审查体验，提升 AI 对规格的执行精度；行业需建立 Spec 的通用规范，明确功能与技术规格的分离标准；同时，工具需明确目标用户与协作模式，让产品、开发等角色能高效参与。
值得注意的是，SDD 与模型驱动开发（MDD）有相似之处，而 MDD 因抽象层尴尬、 overhead 过高未能普及。SDD 借助 LLM 解决了 MDD 的 “解析与生成” 难题，但需警惕重蹈 “过度文档化”“灵活性不足” 的覆辙。未来，SDD 的成功关键在于 “平衡”—— 在规格的结构化与灵活性之间、在 AI 自动化与人类控制之间、在前期投入与长期收益之间，找到适合不同项目的平衡点。
随着 AI 编码技术的迭代与工具的成熟，SDD 有望成为 AI 时代的主流开发范式之一，让开发者从重复的编码工作中解放，更专注于创意与价值本身。但这一过程需要技术社区的持续探索、实践与反思，才能让 SDD 真正落地为 “让开发更高效、更可靠” 的解决方案。
