02-SDD到底是什么

SDD 规范驱动开发实操手册 · 第 2 篇 / 共 8 篇

全系列按「说明 → 介绍 → 使用 → 实操 → 排障 → 收益」推进，每篇都可独立阅读，收藏专栏后按序看不会断。

上一篇讲了为什么要做，这一篇讲它凭什么成立：一次典型的失败、三句话定义、与既有方法论的差异，以及决定成败的「规范四个层次」。2.6 节的 EARS 句式是全系列最该背下来的东西。

第二章 介绍：SDD 到底是什么

2.1 从一次典型的失败说起

一个真实场景（几乎每个用 AI 写代码的团队都经历过）：

需求是"给结算页加优惠券"。你跟 AI 说了一句，它给了 200 行代码，跑起来了，你很满意。第二天产品说"一人只能领一张"，改。第三天说"退款要把券退回来"，再改。第四天测试发现"并发下超卖了 3 张券"，AI 说"我帮你加个锁"，加完把原本正常的过期逻辑弄坏了。

到第二周，你打开这个文件，发现自己也说不清现在的业务规则到底是什么——规则散落在 17 次对话、43 个 commit 和 3 个人的记忆里。

这不是 AI 不行，是输入不行。AI 一直在从你的对话历史里猜意图，而对话是会衰减的：上下文一满，前面的约束就被挤掉了。你以为是"它忘了"，其实是你从来没把约束写在一个不会忘的地方。

2.2 SDD 的三句话定义

第一句：规范是唯一真源，代码是规范的产物。 需要改变系统时，先改规范，再由规范驱动代码变更。代码可以重写，规范不能丢。

第二句：规范必须先于代码存在，且以可验证的形式存在。 "可验证"是关键词。它把 SDD 和"写设计文档"区分开了。

第三句：规范是人与机器共读的。 给人看，用于评审与交接；给 AI 看，作为每次生成的输入约束。所以它必须结构化、短句、可编号、可追溯——这恰好也是好需求文档的标准。

2.3 与既有方法论的差异

一句话概括区别：TDD 用测试锁住行为，SDD 用规范产生行为。 测试回答"它现在对不对"，规范回答"它应该是什么、为什么"。

2.4 四个核心理念

意图显式化。 把"我想要一个能用的筛选"变成"用户可选择起止日期；只填一端按开区间；清空恢复全量；状态可分享"。隐含假设一旦写出来，就能被发现、被质疑、被测试。

约束前置。 技术选型、性能底线、安全要求、兼容范围，在生成代码之前就定下来。事后补约束的代价是重构，事前定约束的代价是十分钟。

任务可追溯。 每个任务能追回一条需求，每条需求能追回一个用户故事，每个用户故事能追回一个问题陈述。这条链断了，就会出现"这个字段是谁加的、能不能删"的经典困局。

变更走提案。 需求变化不是"直接改代码"，而是产生一个变更单元（提案 + 规范增量 + 任务），实施后归档，规范随之演进。这让"系统现在的行为"永远有一份可查的答案。

2.5 规范的四个层次（落地成败的分水岭）

这是全书最重要的一张表。大部分团队 SDD 失败，是因为把所有东西塞进一个文件。

纪律只有一条：上一层不写下一层的内容。 spec 里出现"用 Redis 做原子扣减"就是越界——那是 L2 的事。越界的后果是：技术方案一变，行为规范跟着作废，规范再也追不上代码。

2.6 EARS：让需求可测试的最小语法

EARS（Easy Approach to Requirements Syntax）是需求工程里的一套受限句式，被 Kiro 采纳为标准写法。它的价值不在学术，在于逼你把触发条件写出来。

中文场景下，我建议固定用这五种句式：

反例对照，这四句都是不合格的规范：

写作时守住三条：一句一条（不要用"并且""同时"连接两个行为）、给编号（FR-001 起，永不复用）、禁形容词（快速、友好、合理、尽量——全部删掉换成数字或明确条件）。

2.7 边界：什么该用、什么不该用

SDD 有明确的性价比拐点。用错场景，它就是纯负担。

手册建议的强制线：凡是涉及数据库结构变更、跨服务调用、资金或库存计算、权限判定的需求，一律走完整 SDD。 这四类改动的返工成本最高，规范投入产出比最好。其他按上表分级。

2.8 主流工具怎么选

我的建议：新团队从 Spec Kit 起步（生态最广、可换 AI 助手、Markdown 全透明）。存量系统改造用 OpenSpec 的"增量规范"思路，避免一上来要求补全历史文档。无论用哪个，第四章的实操流程是通用的——工具只是帮你把文件生成出来，判断标准在你脑子里。

下一篇：方法论清楚了，怎么装进现有工程？三个开工决策、命令行安装、目录约定、五阶段流程与四道门禁。

系列目录见专栏。如果这篇对你有用，点个赞让更多被 AI 写崩过项目的人看到。