为什么你跟AI越聊越乱？
先用一个场景来开场。
你正在做一个项目，想加个小功能。于是你打开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 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）就行。
跑完之后，它会在当前位置建一个叫my-kanban的文件夹，这就是你这个项目的目录，spec-kit那套东西全装在里面了。它其实是一组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“越改越乱”折磨，不妨挑个正经点的项目，试着先写规约再动手，跑一遍你就知道那种顺畅是什么感觉了。