不扯概念了,直接说结论:如果你还在用"vibe coding"的方式让AI写代码,那你的项目大概率离失控不远了。今天聊的这套组合——SDD(Specification-Driven Development,规范驱动开发)+ OpenSpec + SuperPowers,是我最近在Claude Code里实际跑通的全栈开发工作流,专门解决AI写代码"跑得欢、收不住"的问题。
先说背景。今年AI编程的热词从"vibe coding"变成了"harness × SDD",ThoughtWorks的杰出工程师Birgitta Böckeler提出了SDD的三级分类框架,圈内一下子炸开了。核心观点很朴素:AI写代码之前,必须先把规范(Spec)写清楚,让AI像人类工程师一样先看图纸再动手。OpenSpec就是规范管理的工具,SuperPowers则是一套给Claude Code装的"技能包",把头脑风暴、测试驱动开发、计划执行这些工程实践变成AI可调用的流程。
这篇文章不是翻译官方文档,是我自己在真实项目里踩坑、调参、复盘后的全套经验,适合正在用Claude Code、Codex、OpenCode这类AI编程工具,但觉得产出质量不稳定、代码复用性差、越改越乱的同学。如果你还没听说过OpenSpec和SuperPowers,这篇文章正好给你补上;如果你已经在用了,那看看我的用法跟你有什么不同,尤其是踩坑那段,应该能帮你省不少时间。
1. SDD是什么:为什么"凭感觉编码"不够了
1.1 从Vibe Coding到规范驱动开发
先聊聊vibe coding为什么不够用。去年到今年上半年,"vibe coding"这个词非常火,核心玩法就是你给AI一句"帮我写个博客系统",然后AI哗哗生成一堆代码。初期确实爽,尤其是做原型、做Demo的时候,效率甩传统开发几条街。但到了项目中期,问题全冒出来了:AI生成的代码风格不统一、依赖关系混乱、改一个功能崩三个地方,甚至有时候AI自己都忘了之前生成过什么东西。
说白了,vibe coding的问题在于"没有上下文约束"。AI每次生成代码都像是在回答一道全新的题,它不知道你之前定过什么规则、文档里写过什么约束、哪些模块是核心不能动。这就好比你让一个实习生干活,但不给他看需求文档、不给他讲技术规范、不让他看现有代码,那他只能凭感觉写,写完大概率没法用。
SDD解决的就是这个问题。它的核心思想特别简单:先把规范写清楚,再让AI动手写代码。这个规范不是产品经理写的那种PRD,而是介于需求和代码之间的一种"可执行的规格说明",包含背景、需求、技术方案、验收标准、测试策略等。AI拿到这份规格之后,它的行为模式就从"自由发挥"变成了"按图施工",质量稳定性一下子就上来了。
1.2 Birgitta Böckeler的SDD三级分类框架
Birgitta Böckeler把SDD分成了三个层级,我自己用下来觉得这个分法确实精准,值得拆开讲。
第一级是没有规范或规范极弱。这时候AI基本纯靠提示词驱动,你告诉它做什么它就做什么,没有结构性约束。这是大多数vibe coding场景的现状,效率高但风险也高,适合做原型验证,不适合做生产级项目。
第二级是有规范,但规范是静态的。你会在项目里放一个README或文档,写清楚架构选型、命名规范、目录结构等。AI会参考这个文档来生成代码。但问题在于,这些规范不和实际代码产生关联,不随着项目的进展而更新,AI虽然不会跑偏太远,但也没法做到精细化控制。
第三级是规范真正驱动开发流程。这一层级下,规范是"活的",每一个需求变更都对应一次规范的更新,AI生成代码的过程本身就是在驱动规范演进。OpenSpec在做的就是这一层的事:规范不仅指导AI写代码,而且被纳入版本管理、审查流程、测试流程,跟代码一样有生命周期。SuperPowers再把TDD、计划执行这些实践注入进去,让AI从一个"会写代码的工具"变成"遵守工程纪律的协作者"。
我个人的建议是:如果你是个人开发者做小项目,起步至少从第二级开始;如果做的是团队项目、要么不做要么做正规一点的,直接上第三级,后面省下来的重构时间远超前期写规范的成本。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. OpenSpec:让规范从"文档"变成"代码"
2.1 OpenSpec的核心概念与目录结构
OpenSpec是个开源工具,它做的事情说白了就是把"规范"这种本来很虚的东西,变成了项目里一个实实在在的、可版本管理、可审查、可被AI读取的目录结构。
我用下来OpenSpec的核心概念主要有三个:
Spec(规范):描述项目的核心能力、技术约束、架构决策。它有点像项目的"宪法",是稳定不变的。比如"本项目是一个博客系统,支持Markdown、支持标签"——这些是高层描述,不随某个具体需求的增删而改变。在OpenSpec里,它们存放在 openspec/specs/ 目录下。
Change(变更):描述一次具体需求变更。比如"给博客增加全文搜索功能
