一句话定义：规范驱动开发（Spec-Driven Development，SDD）是一种协作方式——在让智能体（agent）动手写代码之前，先让它和你一起把"要做什么、做到什么程度算完成"写成一份规格（spec），再照着这份规格实现。
为什么"一句话需求"不靠谱
你跟装修队说"帮我装个好看的家"，结果大概率是返工。因为你没说：几口人住、要不要书房、插座留在哪面墙、预算卡在哪。"好看"在每个人脑子里是不同的东西。
跟智能体说"帮我实现个登录功能"是一回事。它必须替你默默做完几十个决定：手机号还是邮箱登录？密码强度怎么定？要不要验证码？登录态多久过期？错误提示是否暴露"该用户不存在"？你写一句话，它替你选了一整套答案，等你看到几百行代码才发现选错了——这时候改，比一开始说清楚贵得多。
SDD 的做法是把这些决定提前：先产出一份一页纸的规格，写清目标、非目标（明确不做什么）、数据字段、交互流程、边界情况和验收标准（acceptance criteria）。你和智能体都读一遍，确认无误，再开始生成代码。
它为什么更稳
第一，规格是可审查的中间产物。 几百行代码很难逐行核对，一页规格五分钟能读完。改一段文字的代价，远低于改一堆已经写好的代码。
第二，长任务里规格是锚点。 任务一长，早期对话可能被压缩或淡出上下文，智能体会"忘事"。规格可以反复贴回去，让它随时对齐。
第三，验收标准给了双方同一把尺子。 智能体能拿它自查，你也能拿它验收，而不是靠"感觉不太对"来回拉扯。
| 一句话提示 | 规范驱动开发 | |
|---|---|---|
| 输入 | 一句自然语言需求 | 目标、范围、字段、验收标准 |
| 智能体的发挥空间 | 大，细节全靠猜 | 受限，关键细节已定 |
| 问题暴露时机 | 代码写完才发现 | 评审规格时就能发现 |
| 返工成本 | 高 | 低 |
| 适合场景 | 一次性小脚本、试水 | 要长期维护、多人参与的功能 |
和相邻概念的区别
vs 提示词工程（Prompt Engineering）：后者关心"话怎么说"，SDD 关心"动手之前有没有想清楚"，交付物是文档而不是措辞技巧。
vs 测试驱动开发（Test-Driven Development，TDD）：TDD 先写测试，测试本身是代码；SDD 先写规格，规格是自然语言，先对齐"做对的事"，再往下生成测试和代码。两者可以叠加。
vs 传统需求文档：SDD 的规格更短、更具体、更强调可验证，而且默认读者里包含智能体——它得能被直接喂进去当上下文。
对你意味着什么
对从业者，工作重心会从"敲代码"往"写清楚"挪：把需求拆成可验证的条目，比多写几个函数更值钱。对普通职场人，这套思路同样适用——与其让 AI"帮我写个方案"，不如先让它列一版大纲和判断标准，你改完再让它展开，来回次数通常少很多。
具体怎么落地，各家工具的支持方式不同，以官方文档为准。但那条原则是通用的：先把"做对"定义清楚，再开始做。