先写规范再让AI写代码:SDD在软件工程中怎么落地

你让 AI 写一个支付退款模块。它甩来 200 行代码，能跑。但你一看：退款金额没校验是否为负数，错误处理是 AI 自己编的 try-catch 吞异常，日志格式和项目其他模块完全不统一。你让它改，改了三遍每次都在别的地方冒新问题。

这不是 AI 笨。是你没给它一套可执行的规范，它在自由发挥。

SDD（Spec-Driven Development，规范驱动开发）解决的就是这件事：把规范从"给人看的文档"变成在软件工程流程里可执行、可验证、可强制执行的契约。

这篇不讲 SDD 的概念全景，讲一件事：在真实的软件开发流程里，SDD 具体怎么落地，每一步做什么，你照着能走。

  

一、SDD 插在软件工程流程的哪里

一个标准的软件工程流程是这样的：需求分析 -> 架构设计 -> 编码 -> 测试 -> 部署。

SDD 不是替代这个流程，是在里面插了三个东西：

  

在需求分析和架构设计之间，插入"规范定义"

你不再直接从需求跳到编码，而是先把需求翻译成一份结构化、可执行的规范。这份规范不是 PRD，是带验收标准的契约。

在编码环节，插入"规范驱动生成"

AI 读规范、读宪法、在约束下生成代码，不是读你的聊天消息自由发挥。

在测试环节，插入"规范验证闭环"

验证不再是人肉跑一遍看结果对不对，而是 CI 自动检查：生成的代码是否满足规范里的每一条断言。

三个插入点合起来，就是把人定规则、AI 执行、机器验证这条链路从概念变成流水线。

二、落地第一步：写可执行规范，不是写 PRD

这是 SDD 落地的第一道坎。多数团队卡在这里：规范写了，但写的是自然语言描述（"实现一个退款功能，要支持部分退款"），AI 读完了还是靠猜。

可执行规范和 PRD 的区别在于：每一条需求都带验收标准，验收标准能被自动转换为测试用例。

一份完整的 SDD 规范包含六个模块：

  

第六个模块"测试标准"是关键。Amazon Kiro 用 EARS 表示法把验收标准写成这种格式：

  

这种写法的好处是确定的：它能被自动转换为测试用例。AI 生成的代码跑不过这些断言，就不算完成。规范从"文档"变成了可执行契约。

你在写规范时常犯的一个错误：只写"做什么"，不写"做到什么程度"和"错了怎么办"。结果是 AI 按自己的理解编错误处理逻辑，编得不对，你返工。六个模块里的第四、五、六模块就是堵这个口子的。

三、落地第二步：宪法约束，让 AI 不自由发挥

规范写好了，AI 生成代码时还有一个问题：它不知道你的项目有哪些不可协商的规则。它按通用最佳实践写代码，但你的项目有自己的安全红线、架构约束、代码风格。

SDD 的解法是 Constitution 宪章机制。一份 constitution.md 定义项目最高约束，所有规范和代码都必须在宪法框架内生成。

  

宪法里写什么？四类东西：

安全红线：所有用户输入必须校验，所有数据库操作必须参数化，敏感数据不得出现在日志里。违反任何一条，CI 直接拦住。

架构约束：支付模块只能调用支付服务，不能直接访问数据库。退款流程必须走消息队列异步处理。

代码质量标准：命名规范、复杂度限制、单文件行数上限。AI 不能写 500 行的巨型函数。

设计系统规则：涉及前端时，UI 组件只能用项目设计系统里的。

arXiv 2026 年 1 月的一篇论文做了实验：把 CWE/MITRE Top 25 安全约束写入宪法层，银行微服务案例安全缺陷降低了 73%。关键理念是"by construction 而非 by inspection"，在生成时就约束住，而不是生成后再检查。

Amazon Kiro 把这个机制做进了 IDE：Steering 文件定义项目宪法，Agent Hooks 在编辑器内实时监控 AI 生成的代码是否偏离宪法，偏了立即告警。不是等代码审查才发现，是写的时候就被拦住。

你落地时最小可做的事：先写一份 20 行的 constitution.md，只列安全红线和架构约束两条。这一份就够拦住 AI 80% 的自由发挥。

四、落地第三步：验证闭环，让检查不靠人盯着

规范定义了"应该怎样"，宪法约束了"不能怎样"，但谁来检查 AI 生成的代码是否真的遵守了？

靠人审查不现实。AI 一分钟生成 200 行代码，你审查 200 行要 5 分钟。SDD 的解法是把验证做成 CI 门禁。五根支柱，每根跑一件事：

安全验证：跑漏洞扫描，检查输入校验、权限控制、数据加密。AI 生成的代码里有 SQL 拼接？拦住。

测试验证：跑单元测试、集成测试。规范里的 EARS 断言被自动转成测试用例，AI 生成的代码跑不过？不算完成。

代码质量验证：跑规范检查、复杂度分析、重复率检查。AI 写了个 500 行函数？拦住。

性能验证：跑基准测试，检查响应时间、吞吐量。退款查询逻辑全表扫描？拦住。

上线就绪验证：检查部署配置、监控告警、回滚方案。没有监控埋点？拦住。

这呼应了《全链路自动化》里说的"别只交代码，交证据"。AI 不只吐代码，还要吐证据：过了安全扫描、过了测试断言、过了质量检查。证据不是人写的，是 CI 跑出来的。

你落地时最小可做的事：先接前三根支柱（安全扫描 + 测试断言 + 质量检查）进 CI。后两根可以后续补。

五、落地第四步：规范保鲜，最大的落地难题

前面三步走完了，你遇到 SDD 落地最大的难题：规范腐烂。

需求变了，你改了代码，但忘了改规范。三个月后规范和代码已经不匹配了。新人来看规范以为是对的，AI 来读规范以为是对的，结果都在一个错误的规范上做文章。

  

arXiv 论文把这个风险叫 False Confidence（虚假自信）：规格写错了，AI 会忠实地实现错误的东西，而且实现得很漂亮、很完整、很自信。你以为规范在保护你，实际上它在精确地放大你的错误。

SDD 的三层成熟度就是按这个问题分级的。Spec-First 解决了"先想后做"但缺持续对齐；Spec-Anchored 用 CI 检查规范与代码对齐，规范成了活的文档；Spec-as-Source 是终极形态，但技术尚未成熟。

判断你在哪一层的方法很简单：你今天改了一个功能，是先改规范还是先改代码？如果答案是"先改代码，规范可能后面补也可能不补"，你还在 Spec-First，而且规范已经开始腐烂了。

六、真实落地案例

民生银行

民生银行从 2025 年启动 SDD 探索。依托私有化部署的 Cloud IDE + 民生 Code CLI + 通义千问，通过企业级、领域级、项目级三级规格驱动生成代码。五环节闭环：规格 -> 计划 -> 任务 -> 实现 -> 验证。

实际效果：单元测试行覆盖率接近 70%，私域规范完成度超过 70%。他们诚实列出了 SDD 不适用的 6 类场景和"规格保鲜"难题。规格保鲜就是规范腐烂问题，民生银行在金融级实践中都遇到了，说明这不是"你做得不够好"的问题，是 SDD 方法论本身要持续解决的难题。

奇富科技

奇富科技的路径更完整：从工具引入，到 SDD 规范驱动，再到 Harness Engineering。落地数据：需求交付效率提升 65%，迭代周期缩短 55%，测试用例自动生成率提升 80%。

他们的关键认知是：AI Coding 的上限不取决于工具，取决于上下文和工程资产的沉淀。SDD 规范就是工程资产的核心组成部分。没有规范沉淀，AI 每次都在从零开始猜。

七、工具选择：不是选工具，是选规范格式

2026 年主流的 SDD 工具，区别不在"谁更好"，在"你的规范用什么格式"。

GitHub Spec Kit（MIT，约 9 万 stars）：支持 30+ AI 编程助手。四层优先级让规范可企业化定制。用多种 AI 工具、想保持规范格式统一，选它。

Amazon Kiro（2025 年 11 月 GA，25 万+ 开发者）：三文档结构用 EARS 表示法，Agent Hooks 在 IDE 内实时抓漂移。用 AWS 生态、想要 IDE 一体化体验，选它。是 Amazon Q Developer 的官方接班人。

OpenSpec（MIT，约 2.8 万 stars）：棕地友好，delta spec 只描述变更不重写整份规范。已有项目想接入 SDD，选它。

Superpowers（13 万+ stars）：强制 TDD 红绿重构，双阶段审查。信奉测试先行、想把 SDD 和 TDD 结合，选它。

选型原则：先定规范格式，再选工具。

八、什么时候别用

探索性原型：需求还不确定，写规范本身就是浪费。先让 AI 甩几个原型出来看看方向。

微小任务：写一个工具脚本、改一个 CSS 颜色值。写规范的成本超过编码本身。

紧急热修复：线上挂了，先修了再说。

还有一个更根本的禁忌：需求本身是荒谬的。规范只会让荒谬更精确。你把一个错误的需求写成了一份精确的规范，AI 会忠实地实现这个错误，而且实现得很漂亮。

SDD 在软件工程中的落地，核心就四步：写可执行规范、用宪法约束 AI、做验证闭环、解决规范保鲜。

这四步不是一蹴而就的。先从 Spec-First 做起：下次让 AI 写代码前，先花 10 分钟把六模块规范填一遍，把 EARS 验收标准写三条。这一步就够拦住 AI 大部分的自由发挥。

再往 Spec-Anchored 迈：把规范检查接进 CI，让规范和代码对齐自动化。

规范写清楚了，但喂给 AI 的上下文一多就乱、就漂。AI 记不住你三天前写的规范。这是下一篇上下文工程要解决的问题：怎么管喂给 AI 的上下文，让它在第 20 轮对话里还记得第 1 轮的规范。

两条线，都从这里出发。