SDD 规约驱动开发实战：在 Claude Code 里跑通先规约后编码

大家好，我是小林。

先说一个我猜你也遇到过的场景。

你在做一个项目，想加个小功能，于是打开 AI 编程工具，随手一句「帮我加个用户登录」。它刷刷刷写了一堆，你一看，嗯，还行。然后你说「密码要加密」，它又改。你说「登录失败要有提示」，它再改。改到第三轮，你发现它把前面写好的注册接口给动了，某个地方莫名其妙就崩了。

于是你又得回过头去，一句一句跟它掰扯，这里不对，那里改回来。一个下午就这么耗掉了。

讲真，这种「越改越乱」的感觉，几乎每个用 AI 写过代码的人都体会过。

很多人第一反应是：模型不够聪明呗，换个更强的不就好了。

其实还真不是模型的锅。

你换成再强的模型，只要你还是「想一句说一句」这么喂它，结果不会好到哪去。问题出在你给它的东西本身就是碎的，它当然只能碎着做。

这篇我就想聊聊这个事，顺便把最近在国外开发者圈里越吵越热的一个词讲清楚，叫 Spec-Driven Development，说人话就是「规约驱动开发」。名字听着挺唬人，其实核心就一句话，先把要做成什么样讲清楚，再让 AI 动手。

我会带你从头跑一遍这套流程，最后还会在 Claude Code 里做一个具体的例子，让你直接能上手。

为什么你跟 AI 越聊越乱？

我们先搞清楚，前面那个「越改越乱」到底是怎么来的。

现在大部分人用 AI 写代码，是一种什么姿势呢？就是聊天式的。想到哪说到哪，AI 做一步你看一步，不对就再说一句。这种方式有个特别流行的叫法，vibe coding，凭着感觉写。

vibe coding 爽不爽？说实话，太爽了。

你不用写文档，不用画流程图，脑子里有个模糊的想法，嘴一张 AI 就给你端上来了。做个小玩具、写个一次性的脚本、周末捣鼓个小 demo，这套简直是神器，我自己也天天这么干。

但你有没有发现，一旦这个东西稍微有点规模，或者你打算长期维护它，vibe coding 就开始露馅了。

为什么？

我给你打个比方。凭感觉跟 AI 写代码，特别像你口头跟一个外包说需求。你说「做个电商」，他问「要支付吗」，你说「要」，他做完了你才想起来「诶还要退款」，他又加。加完你又想起「得有优惠券」。你说一句他做一句，你俩谁的脑子里都没有一张完整的图。

最后做出来的东西，和你一开始想要的，往往是两码事。

代码这边更麻烦。AI 每次只看得到你这一句话加上眼前这点上下文，它并不真的知道整个项目要往哪走。所以它做第五步的时候，很可能已经忘了第一步为什么那么设计，一不留神就把前面的东西给推翻了。

你以为是 AI 记性差？

倒也不全是。真正的根子是，你压根没给过它一张完整的、大家都认的图。它手里只有一堆你随口甩过来的碎片，它能不乱吗。

所以你看，问题从来不在「模型笨」，在「缺一份对齐」。你和 AI 之间，少了一样两边都点头认可的东西。

这个东西，就是我们接下来要说的规约。

规约驱动，到底把什么摆到了明面上？

好，那规约驱动开发到底是个什么玩意，它凭什么能治前面那个病？

先别急着记概念，我们顺着刚才的毛病往下想。

你跟 AI 越聊越乱，是因为「要做成什么样」这件事一直飘在半空，只存在于你脑子里，和 AI 每次临时理解的那一点点。那最直接的解法是什么？把它写下来，摆到明面上，让你和 AI 看的是同一份东西。

这就是规约驱动最朴素的出发点。

但它不止是「写个文档」这么简单。

它真正做的事情，是把一件事从头到尾拆成几个台阶，然后逼着你和 AI 在每个台阶上都停一下、对一次。

哪几个台阶呢？大概是这么个顺序。

第一步，先讲清楚你到底要做什么、为什么要做，注意这一步只谈需求，不谈技术。第二步，再定用什么技术、怎么架构去实现它。第三步，把这套实现拆成一条条具体的、能干的活。第四步，才轮到 AI 照着这些活去把代码写出来。

你发现没有，vibe coding 是把这四步全糊在一起、一口气塞给 AI 的。而规约驱动，是把它们一个个掰开，铺在桌面上。

掰开有什么好处？

好处大了。每一步的产物，你都能亲眼看到，能改，能拦。

AI 把需求理解错了？在第一步你就看出来了，当场纠正，别等它代码都写完了才发现方向就是错的。技术方案你不认同？第二步拦下来。任务拆得不对？第三步调。等真到写代码那一步，前面全对齐好了，它闷头干就行，出岔子的概率自然低一大截。

说白了，规约驱动干的这件事，就是把「对齐」这个动作，从你脑子里那种模模糊糊的默契，变成了白纸黑字、看得见摸得着的一步步确认。

对了，这里我得强调一句，规约不是一次定死的合同。

你在后面任何一步发现前面想岔了，随时能回去改规约，改完再往下走。它是活的，是你和 AI 之间那份不断更新的共识，而不是刻在石头上的东西。这一点后面还会再说。

spec-kit 一套命令跑下来是什么体验？

道理讲完了，你可能还是觉得有点虚。

别急，现在有现成的工具帮你把这套流程跑起来，最出名的一个是 GitHub 官方出的，叫 spec-kit，现在都有100k+ star。

我先带你从整体上看一遍它是怎么转的，等会再上手做具体例子。

spec-kit 的用法，核心就是几条斜杠命令。你在 AI 编程工具里一条条敲下去，它就带着你把规约驱动那几个台阶挨个走完。

第一条命令，是打地基用的。

/speckit-constitution

这条叫「宪法」，听着夸张，其实就是让你先定几条这个项目从头到尾都要守的铁律。比如「所有接口都要写测试」「代码风格统一用某个规范」。定好之后，后面每一步 AI 都会拿这几条来对照，不会跑偏。

接下来这条，是整套流程里最关键的一条。

/speckit-specify

这一步，你告诉它你要做什么、为什么做。记住，这里只说需求，别提技术。你别急着说「用 React」「用 Postgres」，你就说「我要一个能让团队协作管任务的工具，能建项目、能分配任务、能拖动卡片」。

它会根据你这段话，生成一份正儿八经的需求规约文档。这份文档就是你和 AI 之间第一份对齐的东西。

然后是定方案的一步。

/speckit-plan

到这一步，才轮到技术。你把技术栈、架构选型告诉它，比如「前端用什么、后端用什么、数据库用什么、要不要实时更新」。它会基于前面那份需求文档，产出一份技术实现方案。

注意这个顺序，先有需求，再谈技术。这跟很多人上来就问「这个用什么框架好」正好反过来。

再往下，是拆活。

/speckit-tasks

这条命令，会把前面那份技术方案，拆成一条条具体的、可执行的任务清单。原本一个笼统的「做一个任务管理工具」，到这里就变成了几十个明确的小活，每一条 AI 都能单独下手。

最后，才是真正写代码。

/speckit-implement

到这一步，前面该对齐的都对齐了，AI 拿着那份任务清单，一条条照着实现。因为方向、方案、任务全都提前敲定过，它这时候基本就是个执行者，不太会再自作主张地乱改。

你回头看看这一路，是不是正好就是前面说的那几个台阶，想清楚做什么、定方案、拆任务、写代码，一步都没少，只不过 spec-kit 把每一步都变成了一条你亲手敲的命令。

这么一圈跑下来你会发现，它其实没教你什么高深的东西，它就是把「先想清楚再动手」这句老话，硬生生做成了一套你不得不走的流程。

在 Claude Code 里，怎么真的用起来？

光看命令还是隔了一层，我带你在 Claude Code 里从零跑一个具体的例子，你就彻底明白了。

假设我们要做一个特别常见的东西，一个团队看板工具，能建项目、能加任务、能把任务卡片在「待办、进行中、已完成」几列之间拖来拖去。就拿这个当例子。

装工具、进项目

第一步，先把 spec-kit 的命令行工具装上。它是 GitHub 官方的一个小工具，用 uv 装一下就有了（没装过 uv 的话先装个 uv，网上一搜一大把）。

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

装好之后你就有了 specify 这个命令。接着在你想放项目的地方初始化，关键是告诉它你用的 AI 工具是 Claude Code。

specify init my-kanban --integration claude

敲下去它不会闷头就跑，先弹个选择让你挑用哪种脚本，Mac 上直接选 sh（也就是 POSIX shell）就行。

上面这里我就直接选择了 sh。

跑完之后，它会在当前位置建一个叫 my-kanban 的文件夹，这就是你这个项目的目录，spec-kit 那套东西全装在里面了。

你待会在 Claude Code 里敲斜杠唤出来的这几条，底下其实是一组 skill，装在项目里的 .claude/skills/ 目录下，speckit-specify、speckit-plan、speckit-tasks 这些各占一个文件夹。

说人话就是，skill 就是你提前写好、教 Claude Code 干某一类活的说明书。spec-kit 不过是把「写规约、定方案、拆任务」这几件事，各做成了一份说明书塞进你项目里，你敲一下斜杠就能把对应那份调出来用。

而 skill 是 Claude Code 启动的时候才去扫描加载的。所以你不能在外面开着 Claude Code 干等，得先进到 my-kanban 这个目录里，再从这里把 Claude Code 打开，它才认得这些 skill。

cd my-kanban
claude

进到 Claude Code 之后，敲一个斜杠，就能看到 speckit 那一串 skill 蹦出来了，/speckit-specify、/speckit-plan、/speckit-tasks 一排列在那，随手可用。

好，skill 有了，正式开跑。

specify：先说清楚要做什么

我在 Claude Code 里敲：

/speckit-specify 做一个团队看板工具，用户能创建项目、往项目里加任务、
给任务分配负责人、在看板上把任务卡片拖动到不同状态列。第一版先简单点，
用户先预先定好几个，不做登录，就用来验证核心流程能不能跑通。

你看我这段话，从头到尾没提一个技术词。没有 React，没有数据库，就是在讲这东西是给谁用的、能干啥。这是故意的，这一步就该只谈需求。

Claude Code 收到之后，不会急着写代码，它会生成一份需求规约文档，把功能点、用户角色、每个功能算「做完了」的标准，都一条条列清楚。

你打开specs/001-team-kanban/spec.md这份文档，你会发现这是非常详细的需求文档了，所以你一定要停下来读一遍，这是整个流程里性价比最高的一次检查。你现在花两分钟看一眼它有没有理解错，能省掉后面两小时的返工。

plan：再定技术方案

需求这份对齐好了，接着把技术方案定下来。

/speckit-plan 前端用 React，后端用 Node 加 Express，数据库用 SQLite 先跑起来，
看板的拖拽用现成的拖拽库，接口按项目、任务两块分开设计。

这回轮到技术了。Claude Code 会基于刚才那份需求文档，产出一份技术方案。

包括大概分几个模块、接口怎么设计、数据表长什么样。这份你同样过一遍，不认同的地方直接改。

tasks：把方案拆成任务

方案 OK 了，接着拆任务。

/speckit-tasks

这条我基本不用带什么参数，它自己会把方案拆成一条条具体的任务，比如「搭好项目骨架」「建任务这张数据表」「写创建项目的接口」「做看板拖拽的前端组件」，一二三四列得明明白白。

到这里，前面三步的产物你都亲眼看过、点头认可了，方向、方案、任务全对齐了。

你看前面做了那么多功夫，其实一行代码都还没有写，全都是在规划需求、方案设计、任务清单之类的文档，因为只有把这些理清楚了，到了实际开发，才能拿到我们想要的效果。

implement：放手让它写代码

铺垫了这么多，终于到这一步，放手让它写！

/speckit-implement

这时候 Claude Code 就拿着那份任务清单，一条条往下实现。因为该定的全定了，它这一趟基本就是个老老实实的执行者，不太会再冒出「我觉得这样更好」然后把你的设计给改了。

猛猛干了 10分钟之后，前端和后端都开发完了。

开发完之后，我们来运行项目看看效果，如果你不会运行项目，也不用怕的，直接让Claude Code 帮你运行项目。

运行成功！

我自己测试了这个任务看版，修改任务的负责人、拖拉拽任务都是没问题，体验起来还是很ok的，可以说是很好完成了我这次的任务。

最重要的是，上面这一整套我全都是一次跑通，没有遇到任何 bug。

你发现没有，先花功夫把规约立起来，不但没让它变慢，整个开发过程反而顺滑得不行，完全无障碍。

你把这一趟和文章开头那个「越改越乱」的场景摆一块对比一下，差别就出来了。

开头那个，是你一句一句喂，AI 一步一步猜，猜错了再回炉。而这一趟，是你先花点时间把要做的、怎么做的、拆成哪些活，全部摊开对齐，然后 AI 才动手。前面这点功夫花下去，后面写代码那一段，顺得不是一星半点。

对了，还有个实操上的小提醒。我这个看板例子还算小，一条 /speckit-implement 就一把跑完了。

但要是项目再大些，别指望一条命令从头到尾给你全撸完。更稳的做法是分阶段来，先让它把项目骨架和任务的基本增删跑通，验一下，再上看板拖拽，最后才加分配负责人这些。

一口气全塞给它，上下文太长，它反而容易顾此失彼。

你把整个过程倒回去看，其实就四步，先 specify 说清要什么，再 plan 定方案，接着 tasks 拆活，最后才 implement 写代码，而真正敲代码只是排在最末尾的一小步。

需求含糊、项目又大，靠什么兜底？

上面这套流程，你要是拿去做个小项目，跑得会很顺。

但真实工作里，事情往往没那么干净。需求经常是含糊的，你自己一开始都没完全想明白。项目也经常是大的，牵一发动全身。这种时候，光靠前面那四步，还不太够。

spec-kit 其实还留了几条命令，专门用来兜这个底。小项目你可以跳过，但正经活，我劝你老老实实用上。

第一条，是用来把含糊点问清楚的。

/speckit-clarify

这条命令有意思，它不急着往下走，而是反过来问你。它会盯着你那份需求文档，把里面它觉得含糊、有歧义、你没交代清楚的地方，一个个揪出来问你。

比如你说「任务可以分配给负责人」，它可能会追问：一个任务能分给多个人吗？没人认领的任务算什么状态？

用它的时机也有讲究，最好在 specify 出了需求文档、还没开始 plan 之前就跑。先把这些模糊点问清楚，再让它去定技术方案。不然需求是糊的，方案跟着一起糊，等你 plan、tasks 都做完了才回头补，就跑晚了。

你可能会觉得，它怎么这么啰嗦。

但你想想，这些问题要是现在不问清楚，会怎么样？它就只能自己瞎猜一个答案写下去，等你验收的时候发现不对，返工的成本可比现在回答几个问题高多了。

它现在啰嗦，是在帮你把「想不清楚」这件事，提前暴露在写代码之前。

第二条兜底命令，是做一致性检查的。

/speckit-analyze

这条一般在拆完任务、正式写代码之前用。它会把你前面那几份东西，需求、方案、任务清单，放一块交叉比对，看看有没有互相打架的地方。

比如需求里说要支持实时更新，但技术方案里压根没提这块怎么实现。又比如任务清单里，漏了需求里明明写了的某个功能。这些「对不上」的地方，靠人眼一个个核对特别累，交给它扫一遍，省心不少。

你把这几条兜底的命令连起来看，会发现它们干的其实是同一件事，在你正式写代码之前，尽可能多地把「没想清楚」「对不上」的坑给填了。

这就是我特别想让你 get 到的一个点。规约驱动真正值钱的地方，不是那几份文档本身，而是它逼着你把「先想清楚再写」这件事，从一句正确的废话，变成了一道你绕不过去的工序。

人是有惰性的，你嘴上说「我会先想清楚」，真上手还是忍不住直接开写。而这套流程，是把「想清楚」这一步，用命令给你焊死在了写代码前面。

这不就是又回到瀑布流了吗？

讲到这，我猜屏幕前已经有同学要抬杠了。

小林你等等，你说的这套，先写需求、再定方案、再拆任务、最后写代码，这不就是老掉牙的瀑布流吗？绕了一大圈，怎么 AI 时代反而复古了？

这个问题问得好，我一开始也犯嘀咕。但你仔细想想，还真不是一回事。

传统瀑布流最要命的地方在哪？在于它那几份文档是「死」的。需求评审会一开，文档一签字，就基本定死了，中间想改，走变更流程能把人折腾疯。所以做到一半发现方向错了，也只能硬着头皮往下做。

规约驱动这套，规约是活的。

我前面反复强调过，你在任何一步发现前面想岔了，随时能回去改。改需求、改方案、改任务，改完接着往下走，甚至推翻重来一遍都没什么成本，因为这些规约本来就是让 AI 几秒钟就能重新生成的东西。

它跟瀑布流长得像，但内核完全不同。瀑布流是「一次定死，扛着往前」，规约驱动是「随时对齐，边走边改」。表面都是分阶段，一个是石头，一个是橡皮泥。

所以说白了，重点从来不是「要不要写文档」这种形式，而是你和 AI 之间那份共识，到底是清晰的还是模糊的、是能改的还是死的。

当然，我也得说句公道话，这套东西不是万能药，更不是什么活都得这么伺候。

你要是就写个几十行的小脚本，跑一次就扔，那你还一本正经地 constitution、specify、plan、tasks 走一整套，纯属给自己找罪受，vibe coding 一把梭反而最快。

那到底啥时候值得上这套？

我自己的判断标准很简单，就问一句：这东西你是不是打算长期维护、后面还要不断往上加功能？是，那就值得在前面花点功夫把规约立起来。不是，随手写写的一次性东西，别折腾，凭感觉写完事。

说到底，用不用这套，取决于你手里的活值不值得你为它「先想清楚」。

最后

写到这我其实挺想聊聊一个更大的感受。

这一两年 AI 编程工具越来越猛，很多人下意识觉得，以后拼的是谁的工具更强、谁的模型更聪明、谁的 prompt 写得更花哨。

但你真用得多了会发现，事情正在悄悄反过来。

模型已经足够聪明了，聪明到你只要把事情讲清楚，它基本都能给你做出来。那瓶颈卡在哪？卡在「你到底能不能把事情讲清楚」这件事上。

规约驱动这套流程，剥掉那些命令和工具的外壳，内核就一句话，逼着你把想要的东西想明白、说清楚。它值钱，不是因为它多先进，恰恰是因为它替你补上了大多数人最缺的那一环。

所以我越来越觉得，AI 时代真正拉开差距的，不是谁 prompt 写得花，也不是谁工具堆得多。

是谁能把一件事，讲清楚。

好了，这篇就到这。

你要是最近正被 AI「越改越乱」折磨，不妨挑个正经点的项目，试着先写规约再动手，跑一遍你就知道那种顺畅是什么感觉了。

我们下篇见！

PS：对了，我那个 MewCode Agent 项目也是用 AI 编程开发出来的。它虽然没用 spec-kit，但走的也是「规约驱动」这套思路，让 AI 动手写代码之前，先把规划做好，依次产出 spec.md（做什么）→ plan.md（怎么做）→ task.md（按什么顺序做）→ checklist.md（做对了没），最后才落到代码。感兴趣想一起学的，可以看这个🔗：MewCode Agent 项目（Java/Python/Go/TS）