AI编程新范式:规范驱动开发实战指南

AI编程新范式 5人7天干完20人数周的活 SDD 到底是什么魔法？ 深度解析 SDD、OpenSpec、Superpowers AI 时代程序员的下一张王牌 传统开发 vs SDD 传统开发 💬 口头需求 💻 直接写代码 🐛 发现偏差 ♻ 反复返工 SDD 开发 📄 写 Spec 规范 🤖 AI 按规实现 ✅ 按规验证 🚀 一次到位 — 先想清楚，再动手 — 5个人，7天，上线了一个传统需要20人数周才能完成的产品。 不是加班卷，不是偷工减料。第一天，他们没有写一行代码——整整一天只写了 Spec（规格说明文档）。 这是阿里 Qoder 团队最近分享的真实案例。而它背后那套方法论，正在悄悄改变 AI 时代的软件开发逻辑。它有个名字：SDD —— Spec-Driven Development，规范驱动开发。 📌 SDD 是什么：代码只是 Spec 的副产品 先说一个你可能有过的痛苦：把需求扔给 AI，它哗哗写了几百行代码，一运行——跑偏了。改完这里，那里又偏；加个新需求，整个逻辑乱了。 这不是 AI 不够强，是你给它的"上下文"不够准。AI 不会追问你"边界情况怎么处理"，它只会按给定信息尽力推断——推断错了，就是 Bug。 💡 SDD 的核心只有一句话：先定义 WHAT，再让 AI 做 HOW。 SDD 并非全新发明，TDD（测试驱动开发）、API-First 都有相似影子。但 SDD 是专为 AI 编程时代设计的——在 AI 可以秒速写代码的今天，"想清楚"的价值远高于"写得快"。 微软给了 SDD 一个精辟评价： "SDD is version control for your thinking." — Microsoft 代码可以被 AI 秒级重写，真正有价值的是代码背后的决策：为什么这么做，边界在哪里，成功标准是什么。SDD 管理的正是这些。 🔄 SDD 的四阶段流程 SDD 把开发分成四个阶段，人和 AI 有明确分工： ① Specify（规格定义） 由人主导，写出 spec.md：定义问题边界、成功标准、非目标约束。 ② Plan（方案规划） 人 + AI 协作，生成 plan.md：架构选型、模块划分、接口定义。 ③ Implement（代码实现） AI 主导，按 tasks.md 逐步实现，每步可自动验证。 ④ Validate（验证确认） 人 + AI 共同对照规范做测试与 Review，确保产出符合 Spec。 GitHub 官方推出的 Spec-Kit（69k+ Stars）把这个流程固化成了工具链。它引入了一个三文件体系： spec.md：做什么、为什么做，不涉及技术实现 plan.md：怎么做，技术方案和架构，由 AI 起草人来审 tasks.md：分几步做，每步都是可独立验证的原子任务 还有一个 constitution.md（项目宪法），定义全局不可违背的约束：代码规范、安全要求、测试标准……这份文档一写，每次让 AI 实现功能就不需要反复叮嘱同样的事情了。 ✅ 好 Spec 有六要素：问题陈述、可量化的成功标准、用户故事、验收条件、非目标边界、技术约束。 反面例子是这种："系统需要一个快速的搜索功能，结果要准确。"——"快速"是多快？搜什么范围？没有边界的 Spec，等于给 AI 全权委托。 🔧 OpenSpec：变更管理的利器 OpenSpec（Fission-AI 出品，GitHub 开源）把 SDD 理念聚焦在一个具体问题上：每次代码变更，都要有完整的设计文档可追溯。 安装一行命令搞定： npm install -g @fission-ai/openspec@latest openspec init OpenSpec 的核心是一条 Artifact 依赖链，每个文档都是上一个的细化： proposal.md → design.md → specs/*.md → tasks.md → 代码实现 （为什么做）（怎么做）（做成什么样）（分几步）（执行） 实际使用时，一个命令就能触发整条链： /opsx:ff 启动时检查并拉起后台服务 AI 会自动生成 proposal、design、specs、tasks 四份文档。然后： /opsx:apply — AI 逐任务实现代码 /opsx:verify — 对照规范自动验证实现 /opsx:archive — 变更归档，形成可追溯的知识库 最独特的地方是 OpenSpec 的 主 Spec + Delta Spec 体系：每次变更产生增量 spec，归档时同步到项目级主 spec。六个月后回头看，每个功能为什么这么做，一目了然。 💬 OpenSpec 解决的是"AI 写代码容易，但决策追溯难"的问题。 ⚡ Superpowers：多代理协作的完整流水线 如果说 OpenSpec 是"记录型工具"，那 Superpowers（Jesse Vincent 开源）就是"执行型框架"——它的核心不是文档，而是多个 AI 子代理协同工作。 支持 Claude Code、Cursor、Codex、Gemini CLI 等平台，本质是一套 Markdown 格式的 Skills 集合，每个 skill 定义了 AI 在特定阶段该做什么： brainstorming — 苏格拉底式对话，先问 10 个问题，再出方案 writing-plans — 把任务拆成每步 2~5 分钟的可执行 task subagent-driven-development — 每个 task 派遣独立子代理 test-driven-development — 强制 RED-GREEN-REFACTOR requesting-code-review — 两阶段审查：Spec 合规 + 代码质量 最酷的是它的子代理分工机制：每个 task 执行时，Controller 负责编排，同时派遣三个独立子代理： Implementer 子代理：实现代码 + 写测试 + 自审查 Spec Reviewer 子代理：对照规范逐条检查"做对了吗" Code Quality Reviewer 子代理：审查"做好了吗" 关键设计：每个子代理拥有独立的上下文，Controller 精确裁剪传递信息，避免上下文污染。这才是多代理比单代理质量高的底层原因。 另外，Superpowers 把 TDD 写进了每个 task 的 Plan 里——如果 Implementer 没有先写测试就写代码，Spec Reviewer 直接拒绝，不讲情面。 🤖 Superpowers 的哲学：用多代理协作代替"单点全知"，用隔离上下文保证质量。 📊 三者怎么选？一张表说清楚 有个比喻很形象： Spec-Kit — 建筑规范手册（按什么规矩干） OpenSpec — 施工变更单（改了什么，为什么改） Superpowers — 施工队工作手册（怎么干，谁来干） Spec-Kit 更适合从零建立规范体系，项目刚启动时用它奠定基础；OpenSpec 侧重变更管理和决策追溯，已有项目的增量迭代首选；Superpowers 注重执行质量和自动化，适合对代码质量要求高、希望 TDD 全程把控的团队。 三者并不互斥。最佳实践是：用 Spec-Kit 定项目宪法，用 OpenSpec 管变更文档，用 Superpowers 做执行流水线——组合使用，效果最大化。 🤔 对普通程序员意味着什么 在北京做后端的时候，我们团队最大的痛点不是"代码写不出来"，而是"写出来不是想要的"。需求理解偏差、边界模糊、返工——这些才是真正吞噬效率的黑洞。 SDD 本质上是把"想清楚"这件事显式化、工程化了。它不是在帮你偷懒，而是在帮你把最有价值的那部分思考——"定义清楚要做什么"——留给人来做，把"怎么实现"交给 AI。 以前我们说"程序员要学会沟通需求"，现在变成了"程序员要学会写高质量的 Spec"。底层能力是一样的：清晰思考、结构化表达。只是输出对象从人换成了 AI。 🌸 AI 时代最值钱的能力，不是会用工具，而是知道要做什么——以及为什么。 顺便说一句：5人7天案例里，那个"什么都没做"的 DAY 0，恰恰是整个项目最关键的一天。所有后续的效率，都建立在那一天把问题想清楚的基础上。 SDD 工具选型速查 工具 核心定位 适合场景 Spec-Kit 规范体系建立 新项目启动 OpenSpec 变更追溯管理 存量项目迭代 Superpowers 多代理执行 质量要求高 — 三者可组合使用，效果最大化 — 🌙 最后说一句 SDD 不是银弹，也不是所有人都需要立刻全套上。但它代表的那个方向是对的：在 AI 可以实现一切的时代，"想清楚要做什么"变成了程序员最核心的竞争力。 从一个写了十年代码的程序员角度来说：这不是在威胁你的饭碗，而是在重新定义你的价值——从"写代码的人"变成"定义代码该长什么样的人"。 先想清楚，再动手。以前是好习惯，现在是核心方法论。 — 一个从北京回到西安、从大厂回归生活的程序员