规格驱动开发（Spec-Driven Development，缩写 SDD）是一种配合 AI 编程 Agent 的工作方式：把结构化、可版本控制的规格文档当成项目的唯一事实来源，代码是从规格生成出来的产物，而不是反过来。
它的口号式表述是：规格不再服务于代码，代码服务于规格。传统流程里，需求文档写完就进抽屉，代码越走越远，文档很快过期；SDD 反过来——要改行为，先改规格，再让 Agent 重新生成计划和实现。
先用一句话抓住它
SDD 是「先把要做什么和怎么算做完写清楚，再让 AI 去写代码」，而不是边聊边改。
打个装修的比方。Vibe Coding 像是站在毛坯房里对师傅说「这面墙看着不太对，往左挪挪」——小改动很快，但改到第二十处时，师傅已经不记得最初为什么要留那个洞了。SDD 像是先出一版图纸，标清尺寸、材料和验收标准，师傅照图施工，要变更就改图纸再施工。前者适合小房间，后者适合整套房子。
它要解决的三个问题
SDD 的支持者通常把它定位成对编程 Agent 三类失败的回应：
意图漂移。多轮对话下来，实现慢慢偏离最初想要的东西，而且没人能指出是哪一步偏的——因为没有一个书面基准可以对照。
上下文衰减。代码库长到超出上下文窗口后，Agent 记不住早期做过的决定，于是重复造轮子或者违反已有约定。这本质上是上下文工程问题，SDD 的做法是把关键决定固化成文档，让它每次都能被重新读进来。
结果无法判定。没有明确的验收标准时，「做完了吗」只能靠人肉看一遍。有了写清楚的验收条件，Agent 可以自己判断是否达标，也可以生成对应的测试。
典型流程
宪法（constitution）是项目级的长期规则文档：用什么语言和框架、测试要求、可访问性和安全底线、依赖引入政策。它通常就放在仓库根目录，和 AGENTS.md 是同一类东西，纳入版本控制。
规格只回答「做什么、为什么、怎么算完成」，刻意不写实现细节。这一层的关键是验收标准要写得可判定。业界常用 EARS（Easy Approach to Requirements Syntax）这类句式模板来约束写法——「当【触发条件】时，系统应当【可观察的行为】」——因为这种结构人和模型都容易解析。
计划才进入技术选择，任务把计划拆成可以独立完成和验证的步骤，最后才是实现。GitHub 开源的 Spec Kit 是这套流程的一个具体工具化实现，把每个阶段做成了斜杠命令。
和相邻做法的区别
和 Vibe Coding 的区别：Vibe Coding 靠对话即时反馈驱动，适合探索、原型和一次性脚本；SDD 靠书面规格驱动，适合多模块、有状态、需要长期维护的系统。二者不是对错关系，是任务规模的分界。
和传统需求文档的区别：传统 PRD 写给人看，写完就和代码脱节；SDD 的规格是给人和 Agent 共同使用的活文档，改需求必须先改它，所以它不会过期。
和驾驭工程的关系：驾驭工程关注的是给 Agent 搭建整套运行环境——工具、反馈回路、验证机制；SDD 是这套环境里关于「意图如何表达和固化」的那一部分。
和 Agent Skills、AGENTS.md 的关系：AGENTS.md 告诉 Agent「这个项目是怎么回事」，Skills 告诉它「某项能力怎么做」，规格告诉它「这次要做成什么样」。三者是不同粒度的上下文供给。
容易误解的地方
「SDD 就是写更详细的提示词」——差别在于持久性和版本化。提示词是一次性的，规格进仓库、走评审、随代码演进，是可以被追溯和 diff 的资产。
「规格越详细越好」——写到实现细节层面就变成了用自然语言写代码，既慢又容易和实际实现冲突。规格该停在「做什么和验收标准」，把「怎么做」留给计划阶段和 Agent。
「有了 SDD 就不用看代码了」——生成的代码仍然需要评审。规格保证的是方向和验收口径，不保证实现质量、安全性和性能。
「适合所有项目」——不适合。写一个一次性脚本、改一个错别字、做个周末原型，SDD 的开销明显盖过收益。它的适用面是多模块、有状态管理、涉及权限和数据模型、要长期维护的项目。
什么时候值得用
一个实用的判断：如果这个改动你需要向另一个人解释清楚才能交接，那它值得写规格；如果你自己十分钟就能做完并验证，那就别绕。
落地时的常见起手式是先做最轻的一层——在仓库根目录写一份项目规则文件（技术栈、测试怎么跑、命名约定、不能碰的地方），这一步成本极低但收益立竿见影。等团队习惯了让 Agent 先读规则再动手，再逐步把「每个功能先写规格」加进流程，比一上来就套全套流程更容易坚持下去。