SDD:从AI辅助编程到规范驱动开发

你是否也曾经历这样的场景：你兴致勃勃地对 AI 说：“嘿，帮我加个用户筛选功能！” 半小时后，它确实交出了一堆代码。但你定睛一看，头皮发麻——代码里充斥着各种“坏味道”：随处可见的 Map<String, Object>、意义不明的“魔术数字”、以及被忘在九霄云外的安全校验……

这代码，看似能跑，实则处处是坑。你叹了口气，默默开始返工，收拾 AI “自由发挥”后留下的烂摊子。

AI 编程，快是真快，但“不靠谱”也是真的。我们陷入了一个怪圈：花大量时间“调试”提示词，却依然无法保证 AI 精准理解我们的意图。聊天记录无法成为可靠的需求规格，AI 凭“感觉”写代码，我们则在无尽的返工中消耗生命。

如果有一种方法，能给 AI 装上“缰绳”，让它从一个天马行空的艺术家，变成一个严谨可靠的工程师呢？

答案就是 SDD（Specification-Driven Development，规范驱动开发）。这不仅仅是一个新术语，更是一套能彻底改变你和 AI 协作模式的“秘密武器”。它让 AI 告别“瞎猜”，让代码质量从“能跑就行”跃升到“专业可靠”。

今天，我们就来揭开这个秘密。

AI 编程的根本痛点：“自由发挥”= 不可控

想象一下，你让一个小孩画一栋房子，但只告诉他“要好看”，没给任何图纸。结果，你可能会得到一个有三个烟囱、彩虹色墙壁的奇幻城堡。它很有创意，但绝不是你想要的那个能住人的家。

现在的 AI 编程很多时候就像这样。我们给它的指令太模糊，它只能靠“猜”。

这个问题的根源在于，AI 的“自由发挥”是其天性，但对于严肃的软件工程来说，这却是灾难。文章中的例子一针见血：当开发者要求 AI 实现一个简单的个人资料筛选功能时，AI 生成的代码充满了各种“代码坏味道”：

• 滥用万能类：大量使用 Map<String, Object> 作为返回值，这就像一个什么都能装的垃圾袋，让接口的调用者完全不知道里面到底有什么，导致类型不安全，后期维护极其困难。

• 魔术数字横行：用 status=1 这样的数字直接代表状态，没人知道 1 究竟是“激活”还是“待审核”，代码可读性极差。

• 安全校验缺失：敏感的管理接口“裸奔”，没有任何权限验证，等于把家门钥匙挂在了门外。

这些问题，靠人工 Code Review 去一一纠正，效率低下且容易遗漏。我们需要一种方法，在 AI 写下第一行代码之前，就彻底杜绝这些问题。

SDD 的核心理念：规范即合同，先画图纸再施工

SDD 的核心思想简单到可以用一句话概括：在动手之前，先和 AI 一起把“要做什么”和“为什么做”写清楚。

这份写清楚的文档，就是 规范（Specification，简称 Spec）。它不是事后补的文档，而是开发开始前，人和 AI 共同遵守的“合同”。

SDD 通过一个清晰的四步闭环工作流，将这份“合同”落到实处：

1. 提案 (Proposal)：你想做一个新功能？别急着写代码。先和 AI 一起写一份提案，说清楚“为什么要做这个功能”（业务价值）和“大致怎么做”。

2. 审查 (Review)：这份提案不是摆设。你需要和 AI（甚至团队成员）一起反复讨论、修改，直到这份“图纸”清晰无误，所有人都达成共识。

3. 实现 (Implement)：AI 现在才能开始写代码。但它不是自由发挥，而是严格按照已经敲定的“图纸”和任务清单来施工。

4. 归档 (Archive)：功能开发测试完成后，这次的变更记录和最终的规范会被永久保存下来，成为项目需求库的一部分。

这个流程就像给需求文档装上了一个 Git 版本控制系统，每一次变更都有迹可循，每一次开发都有据可依。

实战利器 OpenSpec：让 SDD 流程自动化

理论听起来很棒，但如何实践呢？开源工具 OpenSpec 让这一切变得异常简单。它是一个轻量级的命令行工具，能将 SDD 流程无缝集成到你现有的 AI 编程助手中（如 Cursor, Copilot）。

假设你要给应用加一个按角色和团队筛选个人资料的功能。你不再需要费力地描述需求，只需在 AI 对话框里输入：

/openspec:proposal 实现按角色和团队筛选个人资料的功能

AI 会立刻为你创建一个结构化的文件夹，包含三个核心文件：

• proposal.md：写清楚为什么要做这个功能。

• tasks.md：列出具体的开发任务清单。

• specs/：精准标注要修改的代码位置。

接下来，你可以和 AI 反复沟通，比如“给这个功能加上验收标准”，AI 会不断更新这些文档。当你确认所有细节都无误后，输入：

/openspec:apply

AI 就会像一个一丝不苟的建筑工人，严格按照图纸施工，绝不越雷池一步。开发完成后，再用一条命令归档：

/openspec:archive

整个过程清晰、可追溯、可评审。AI 从一个“猜心”的伙伴，变成了一个“听话”的执行者。

多 AI 协同：打破单一模型的能力边界

当任务变得更复杂时，比如一个涉及多国合规、动态定价的跨境保险项目，单个 AI 模型的能力就捉襟见肘了。它可能擅长写代码，但不擅长分析海量的法律文档。

这时，就需要组建一个“AI 梦之队”。

通过 MCP（Machine-to-Machine Communication Protocol）协议，我们可以让不同的 AI 模型协同工作，各司其职：

• Claude (统筹者)：作为总指挥，负责理解需求，并决定将任务分配给哪个“专家”。

• Codex (代码专家)：专注于编写高质量、符合规范的代码。

• Gemini (分析专家)：擅长阅读和理解海量的文档、代码库，提供深度分析。

最关键的是，这种协作不是靠 Claude “智能”判断，而是靠一份写死的“强制规则”文件（如 CLAUDE.md）。这份规则明确规定：“遇到代码问题，必须调用 Codex”、“遇到大文本分析，必须调用 Gemini”。

这种“显式约束”远比“隐式智能”更可靠，它保证了在复杂的任务面前，最合适的专家总能出现在最需要它的地方。

分阶段开发：给 AI 的工作流加上“断点”

你有没有想过，为什么不能让 AI 一口气生成所有代码？因为那样风险太高了。如果 AI 在一开始就理解错了需求，那么它后面生成的几千行代码都会建立在一个错误的基础上，最终导致“错上加错”，难以修复。

因此，在 SDD 实践中，分阶段、交互式的开发模式至关重要。这意味着：

• 设置断点：要求 AI 每完成一个小的阶段（如接口定义、服务实现、单元测试），就必须暂停。

• 人工审查：在 AI 暂停时，由人类开发者进行快速审查，确认当前阶段的产出完全正确。

• 确认后继续：只有在人类点击“确认”后，AI 才能继续下一阶段的开发。

这种模式将人类置于关键决策点，让 AI 成为高效的执行者，而非盲目的代码生成器。它能确保问题在萌芽阶段就被发现和纠正，极大地提升了最终代码的采用率。

深度洞察：SDD 背后的思维变革

理解了 SDD 的“术”，我们更需要洞察其背后的“道”。SDD 不仅仅是一套工具或流程，它代表了 AI 时代软件工程思维的深刻变革。

洞察一：管理概率预期，而非追求绝对正确

传统软件工程追求的是确定性，而 AI 模型的输出天然带有概率性。SDD 的智慧在于，它不试图消除 AI 的不确定性（这既不可能也不必要），而是通过规范，将这种不确定性收敛到业务可接受的范围内。

这就像水利工程，面对汹涌的洪水，最高效的方法不是筑高墙去“堵”，而是挖渠道去“疏导”。SDD 就是那套精密的渠道系统，它将 AI 随机的“概率输出”，最终引导汇聚为“确定的交付成果”。这是一种从“对抗 AI 随机性”到“驾驭 AI 随机性”的思维转变。

洞察二：规范的“粒度”决定了协作的效率

SDD 不是银弹，并非所有场景都适用。文章中提到一个关键问题：“改个按钮样式，有必要走一遍 SDD 流程吗？” 答案是否定的。

这揭示了规范的“粒度”问题。

• 粒度太粗（如只说“加个筛选功能”），AI 依然会瞎猜。

• 粒度太细（细到规定每行代码怎么写），则完全丧失了 AI 的提效价值。

最佳的粒度，是明确“要改什么模块、达到什么效果、有哪些核心约束”。这恰好是 OpenSpec 这类工具的设计哲学。它要求你在新增功能、架构调整、接口变更这类“伤筋动骨”的改动上使用规范，而在调整样式、修复小 bug 这类“皮肉之伤”上则可以灵活处理。找到合适的粒度，是在 AI 协作中实现成本与收益平衡的关键。

洞察三：显式约束远比隐式智能更可靠

多 AI 协同的案例中，最反直觉的发现是：让 Claude 成功调度 Codex 和 Gemini 的，不是它有多“聪明”，而是一套写死的、强制性的规则。

规则里明确写着：“对于任何非平凡的任务，你必须自问：Codex 能帮忙吗？”、“如果你跳过工具，必须解释为什么”。

这说明在当前的 AI 工程实践中，清晰、明确、可强制执行的规则，远比我们寄希望于的、模糊的“通用智能”更可靠。这是一种深刻的工程化思维，它追求的是系统的稳定性和可预测性，而不是单点的“灵光一现”。

总结与行动建议

SDD 的核心价值，在于它为我们和 AI 的协作提供了一套标准的、可工程化的范式。它通过“规范先行”的理念，将 AI 从一个创意无限但行为随机的“实习生”，调教成了一个严谨可靠、指哪打哪的“高级工程师”。

如果你也想让你的 AI 编程体验从“能跑”升级到“靠谱”，不妨从今天开始，尝试在你的工作流中引入 SDD 的思想。

以下是几条可立即执行的建议：

1. 从一个小功能开始：选择一个即将开发的新功能，尝试用 OpenSpec 或类似工具，先和 AI 一起编写一份简单的 proposal.md。

2. 明确“完成”的标准：在提案中，不仅要写“做什么”，更要写清楚“做到什么程度算完成”（即验收标准）。

3. 把规范当作代码来管理：将你的 openspec/ 目录提交到 Git 仓库，让需求和变更像代码一样被版本化管理。

4. 拥抱“断点”思维：在与 AI 协作时，主动要求它分步进行，并在每个关键步骤后进行人工确认。

5. 分享你的规范：如果你的团队也在使用 AI，将你们共同制定的规范（无论是 SDD 文件还是 Agent Skills）共享出来，让团队的整体水平共同提升。

AI 编程的浪潮已至，单纯追求“写得快”的时代正在过去。未来，真正的核心竞争力在于如何“写得对”，如何构建人与 AI 之间高效、可靠、可扩展的协作体系。而 SDD，正是开启这扇大门的第一把钥匙。