芯耀
与非AI
359
原标题：面试官皱眉：“你会Vibe Coding吗？”，我笑了：“何至会？我都是Spec Coding”，他：“什么时候可以入职？”
大家好，我是小林。
我猜你也遇到过的场景。
你在做一个项目，想加个小功能，于是打开 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 那套东西全装在里面了。
它其实是一组 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：对了，我那个仿 Claude Code 的 MewCode Agent 项目也是用 AI 编程开发出来的。
它虽然没用 spec-kit，但走的也是「规约驱动」这套思路，让 AI 动手写代码之前，先把规划做好，依次产出 spec.md（做什么）→ plan.md（怎么做）→ task.md（按什么顺序做）→ checklist.md（做对了没），最后才落到代码。
