SDD 规范驱动开发：用自然语言重塑全栈开发流程
这听起来像是天方夜谭？但事实上，它正在发生。仅需 60 分钟，从一段自然语言的需求描述，到前后端代码交付，全程由 AI 驱动。这不是科幻场景，而是 SDD——规范驱动开发——正在撬动的现实。
简单来说，SDD 是一种以“规范”为核心的开发新范式。其核心理念是：先用自然语言将需求描述清晰，由 AI 生成一份规范文档，再基于这份规范自动生成代码。这与传统的“需求评审→接口设计→后端开发→前端联调→Bug 修复”流程相比，差异一目了然。
在 SDD 的流程中，开发者不再是埋头敲代码的“翻译工”，而是转变为“规范的设计者”。AI 则负责将你写下的规范，翻译成可运行的代码。两者的角色和定位，发生了本质性的变化。
一、SDD vs 传统开发：核心差异在哪？
| 维度 | 传统开发 | SDD 模式 |
|---|---|---|
| 时间成本 | 一个简单功能 2~3 个工作日 | 60 分钟极速交付 |
| 沟通成本 | 前后端反复对齐，接口设计成本高 | 基于 Proto 契约，一次定义，两端同步 |
| 类型安全 | 前端手写类型易出错 | Proto 自动生成，100% 类型安全 |
| 代码质量 | 每一层都在手写重复 CRUD | 自动生成标准代码，质量一致 |
| 知识沉淀 | 需求文档散落，新人接手困难 | 每次变更自动沉淀为 Spec 文档 |
传统开发模式下，一个功能从想法到上线，最消耗精力的不是写逻辑，而是“翻译”。把需求翻译成接口设计，再把接口设计翻译成 DAO 层、Logic 层、Service 层，最后还得把接口字段翻译成 TypeScript 类型。每一层翻译都是潜在的出错点，每一次翻译都是重复劳动。SDD 的破局点，恰是让 AI 承担这些翻译工作，使开发者能专注于真正的业务逻辑和架构设计。
二、OpenSpec 体系如何落地？
要把 SDD 变成现实，离不开一套落地的工具和规范。OpenSpec 就是一个完整的规范体系，它包含几个核心文件，就像项目的“灵魂”和“操作手册”。
首先是project.md，它定义项目的技术栈、架构和代码目录结构。比如，前端用 React 19 + TDesign，后端用 tRPC-Go + GORM。有了它，AI 才能理解项目的上下文，生成的代码才不会“跑偏”。
然后是AGENTS.md，它给 AI 定下了“三思而后行”的决策流程：先理解背景，再设计规范，最后实现代码。这能有效约束 AI 的行为，避免它“自由发挥”导致不可控的局面。
还有WORKFLOW.md，它定义了前后端如何用 Proto 这种“契约语言”来协作。后端定义好接口，前端就能自动生成类型，从根本上消除了联调时类型不一致的烦恼。
最后，changes/和specs/这两个目录，一个负责记录每次变更的提案，一个负责沉淀完成后的知识资产。这样，项目就有了完整的“记忆”，新人接手时，读读 specs/ 就能快速理解业务逻辑，再也不用抓耳挠腮了。
三、实战效果：60 分钟交付一个功能
口说无凭，来看一个具体的例子——“成员管理功能”的开发。
当用自然语言描述完需求后，AI 会按照流程执行：
- 理解需求：它阅读 project.md，把模糊的描述拆解成明确的任务清单。
- 设计接口：自主设计 Proto IDL，生成 Request/Response 模型，并定义权限校验逻辑。
- 后端实现：遵循 tRPC-Go 框架，实现 DAO 层，贯通 Logic 到 Service 层。
- 前端实现：用 React 19 + TDesign 组件，实现列表、添加、删除的交互。甚至，它还能自主修复编译错误。
有趣的是，AI 展现出了惊人的自主修复能力。比如，当它发现测试文件遗漏了新增接口的 Mock 实现时，会立刻补充缺失的存根方法，确保编译通过。又如，当用户反馈接口字段被网关转换成了小写，AI 能瞬间行动，重构 TypeScript 定义，同时保留请求中的命名规范。
最终的结果是：开发耗时仅 60 分钟，而传统模式需要 2~3 天；前后端联调阶段，类型相关的 Bug 数量为 0；整个功能完成后，系统还自动生成了完整的 Spec 文档，成为项目宝贵的知识资产。
四、优点与局限（客观分析）
客观地看，SDD 的优势很明显：它降本增效，将开发时间从几天压缩到分钟级；它保证了 100% 的类型安全，显著降低了联调 Bug；它让每一次变更都沉淀为知识，新人或 AI 接手时能快速理解上下文；它还能输出风格一致的代码，避免了手写代码的“千人千面”。最终，开发者得以从“代码搬运工”的角色中解脱，回归到“设计者”的本职。
但任何方法论都有其适用范围。SDD 的学习成本不高，但理解 OpenSpec 体系仍需要一些时间。它更适合 CRUD 类的业务功能，对于复杂算法或高性能场景，仍需人工介入。此外，它对 AI 的能力也有依赖，团队需要统一采用这种模式，否则规范文件就可能沦为摆设。接口变更时同步更新 Proto 文件，也是一项必不可少的维护成本。
所以，在适用场景上，可以这样去判断：CRUD 类业务功能和前后端协作频繁的项目，强烈推荐；新人接手的老项目，推荐；而复杂算法或高性能场景，则需要谨慎评估；对于小型个人项目，则可能存在过度设计的风险。
五、谁适合用？怎么开始？
如果你是一位全栈开发者，一人负责前后端，想提升效率；如果你厌倦了前后端反复对齐接口文档的拉锯战；如果你接手了一个缺少文档的老项目，觉得难以理解业务逻辑；或者你追求高质量的工程实践，希望代码风格一致、类型安全——SDD 都值得一试。
想要开始，其实很简单。
- 第一步：在项目根目录创建规范文件，包括 project.md、AGENTS.md、WORKFLOW.md，以及 changes/ 和 specs/ 两个目录。
- 第二步：用自然语言描述需求，而不是直接写代码。
- 第三步：让 AI 基于你的描述生成规范提案，包含接口设计和任务清单。
- 第四步：审查提案，确认设计合理后，让 AI 生成前后端代码。
- 第五步：在 AI 生成的代码框架里，填充具体的业务逻辑。
SDD 的核心价值，不是让你躺平，而是让你干得更聪明。把重复劳动——翻译需求、生成代码、维护类型——交给 AI，把创造力——架构设计、业务逻辑、问题解决——留给自己。Proto 契约保证了类型安全，Spec 文档保证了知识可追溯，AI 保证了代码质量的一致性。
如果你也在探索 AI 辅助开发的可能性，不妨从写规范开始，而不是从敲代码开始。这或许就是下一个阶段的答案。
