★ FEATURED ARTICLE 最近几周我基本处在一种“白天和AI写代码晚上给AI收拾烂摊子”的状态里。Vibe-coding确实让人上瘾尤其是想法刚冒出来、AI三分钟给你拼出一个能跑的页面、脚本或者数据处理管道那一下真的很爽。但等需求稍微一变或者项目文件一多之前AI记得清清楚楚的约束和偏好说丢就丢。改一行加一个功能它甚至能顺手把另一处本来正常的功能给改坏而你还得在聊天记录里往回翻半天去找它到底是哪一轮开始“忘记”的。如果你也被这个问题反复折磨那我下面要说的Spec-kit很可能是你从“AI写得快但管不住”走向“AI写得快而且方向和预期一致”的关键一步。这篇文章就是围绕“用Spec-kit解锁Vibe-coding”的一次完整从0到1实操记录。我会先讲清楚Vibe-coding为什么会失控再拆解Spec-kit的核心设计思路然后用一个真实的小项目把全过程跑一遍最后分享我实测中总结出来的坑和应对方法以及它到底改变了我的工作流中哪些东西。适合所有已经在用或者准备用AI编程助手但觉得纯对话式开发越来越难控制的开发者特别是做原型、内部工具、个人项目这一类场景的朋友。1. Vibe-coding的爽与痛为什么我最后会去找Spec-kit1.1 Vibe-coding到底是怎么火起来的Vibe-coding这个词的走红其实就在近一两年。它描述的是一种非常直观的编程方式你不再一行一行敲代码而是用自然语言把你想要的东西描述给AI让它直接生成代码、修改代码、排查错误整个过程中你可以完全沉浸在“表达意图”的状态里而不用管语法细节和框架API。这种模式能火起来背后是三层条件同时成熟了底层大模型的代码能力到了能实际干活的程度AI编辑器和聊天面板成为IDE里的标准配置第三是越来越多非专业程序员也涌入来写点自己的小工具他们需要的就是“说人话拿结果”。这个模式火得很快因为它确实解决了过去很多人的痛点。以前想做个网页小工具你得先学HTML、CSS、JavaScript再框架、打包、部署走一圈。现在你只需要跟AI说“做一个今日待办的界面左侧日期列表右侧任务卡片支持拖拽排序”几分钟就有个像模像样的东西出来。对一个有想法但不想被工程细节淹没的创作者来说Vibe-coding就像从“自己开机床加工零件”变成了“和熟练技工描述需求”效率的提升不是一星半点。1.2 坚持用了几周之后我遇到的三道坎但新鲜劲儿过了之后问题就陆续浮出来了。最典型的第一道坎是上下文丢失。你前面二十轮对话里反复强调过“所有金额计算必须用整数分避免浮点误差”到第三十轮的时候AI新增一个统计报表功能时还是按它自己熟悉的浮点数方式处理。你没有重复这个要求它就像从来没听过一样。你当然可以说“提醒它一下”但提醒本身就是成本而且这种提醒会越积越多。第二道坎是提示词疲劳。当一个项目在线聊天里持续迭代超过两三天你会发现真正干活的时间被压缩了更多时间花在“把旧需求重新描述一遍”“把之前它做过的事情再说一次”“把聊天记录翻出来截图给它看”这些杂事上。对话本身变成了一个不断膨胀、无法检索、也没有清晰边界的垃圾场你很难告诉一个新会话“去接着上个会话往下做”因为模型根本不知道该优先听哪句。第三道坎最要命是重构灾难。前期AI快速堆出来的代码在逻辑上是“看起来能跑”但结构并不一定健康。等到你想加一个大功能或者调整数据流转方式你会发现让AI动大手术的风险极高。它可能改好了一个模块却把另一个本来好好的导出逻辑给顺手“优化”坏了。而它的解释还特别诚恳“我调整了模块间的依赖关系让代码更整洁”——问题是你并没有让它这么做。我给这三道坎做了一个简单的对比维度对话驱动的Vibe-coding规格驱动的Spec-kit上下文保存靠聊天轮次易丢失固化在规格文件中随时可读可改可查需求变更重新描述容易遗漏直接改规格迭代基线清晰结果可控性时好时坏依赖运气按验收标准逐条核验偏差能定位可回溯性聊天记录混乱难检索规格产物变更记录链路完整多人协作很难交接给另一个人规格就是交接文档新会话秒懂所以问题不是Vibe-coding不好而是纯粹靠对话来承载一个项目的生命周期从机制上就不可持续。就像你在路边摊问路问一次两次没问题但如果你要做一趟长途旅行你还是需要一张地图。Spec-kit给我的感觉就是给Vibe-coding补上了那张地图。2. 坐在驾驶座上Spec-kit怎样把Vibe-coding变成可驾驶的2.1 从“和AI聊天”到“给AI下达规格”Spec-kit这个工具的核心理念一句话就能概括把项目的“意图”从对话里剥离出来沉淀成一份结构化的规格文件AI的实现过程围绕规格文件展开而不是围绕聊天记录展开。打个比方以前你和AI的关系是“找了一个很聪明但记性不太好的实习生”你每次布置任务都得把背景讲一遍他不记得了你得再讲一遍现在你变成了“给了一个写清楚的brief”任务从哪来、做到什么程度算完都白纸黑字写在那里AI只需要照着执行不要自由发挥。这个转变看似简单其实把Vibe-coding里最不稳定的一环——模型的短期记忆用文件系统替代掉了。我在实际使用中最直接的感受是聊天面板里我可以随便说、随便试说错了也不要紧因为真正的“约定”都记录在规格文件里。AI那端的工作模式也变了它不再是从一段乱糟糟的对话里“猜”你的意图而是读取规格逐条拆解成实现任务每一步都对照规格里的验收标准来检查自己。它的行为方式从我熟悉的“聊天搭子”变成了“按合同干活”。2.2 规格文件的三个基本构件我自己用下来一份合格的规格文件通常包含三个基本构件缺一个后面就会出问题。第一是目标与范围。这一部分要回答两个问题这个项目要做什么以及明确不做什么。很多人写规格的时候只写要做什么结果AI在实现过程中“顺手”加了一堆没有要求的功能比如自动登录、主题切换、数据导出全部来了。范围写不清楚AI的“顺手”就是最不可控的部分。第二是技术约束。包括技术栈、运行环境、依赖要求、对外接口约定以及你对代码风格的偏好。例如“使用React 18 TypeScript组件目录按feature组织禁止引入UI组件库样式全部手写CSS”每一条都是一道篱笆。AI不会因为篱笆多了就束手束脚相反约束越清晰它越容易给出你预期内的产物。第三是验收标准。这是整个文件里最有价值的部分它定义了一个任务“干完”的明确标志。比如“用户输入空字符串点提交页面不能崩溃且需要显示提示文案”。有了验收标准生成出来的东西不是“感觉差不多”而是可以逐条打钩。AI的自我校验和你的最终验收都挂在这同一个钩子上。这三个构件合在一起就是AI的完整开工说明。Spec-kit里的工作流就是把这份说明变成Agent的计划、执行步骤和验证清单。2.3 最小闭环流程Spec-kit的日常使用大致是这样一个最小闭环你先写或者让它帮你生成一份规格文件然后调用工具让AI按规格实现生成之后你根据验收标准测试产物发现问题就回到规格文件做更新再让它重新生成或局部修改如此循环。整个过程和传统开发最大的区别是反馈循环被压缩到了分钟级而且每一次迭代的“副本”都留了记录你随时可以退回到上一个可用的版本。很多人会问这不就是“先写文档再开发”的老套路吗表面上有点像但底层逻辑完全不同。传统流程里文档和代码是两张皮文档写完之后丢给开发开发过程中需求变化靠开会备忘最后文档往往和代码脱节。在Spec-kit这里规格文件和代码产物是绑定的AI每一轮的产出变动都对应着规格的某个条款你审查的永远是“规格对不对”和“实现是否匹配规格”这两件事。文档不再是昙花一现的静态描述而是整个迭代过程的活地图。但要注意这里的规格文件不是传统意义上的软件需求规格说明书不要求你写几十页的用例图、状态图、时序图。Spec-kit的规格文件可以非常轻量更像是一份写得比较详细的开发工单重点在于“边界清晰”和“可验证”而不是“规定详尽”。3. 从0到1实战用一个情绪板生成器把Spec-kit跑通3.1 环境准备与项目初始化光讲理念不落地都是空的我带一个实际项目走一遍完整流程。我们做一个叫“情绪板生成器”的小网页用户输入一个主题关键词比如“夏日海边的清晨”页面自动生成一组匹配主题的文字卡片集合每张卡片包含标题、描述、标签和一个对应的渐变色整体形成一面情绪墙。这个项目不大不小既能体现规格对交互细节的控制力又不至于让AI在单次会话里过于吃力。第一步是环境准备。Spec-kit以命令行工具的方式提供安装非常直接我这里用的是Python发行版pip install spec-kit装完之后你需要把大模型API的密钥配置到环境变量里比如export SPEC_KIT_MODEL_API_KEYsk-xxx export SPEC_KIT_MODELclaude-4.5-sonnet然后初始化项目目录mkdir moodboard-generator cd moodboard-generator spec-kit init初始化会在当前目录生成一个基础的项目结构和默认的规格模板文件目录形态大概是下面这样moodboard-generator/ ├── SPEC.md # 规格文件核心的一切从这里开始 ├── .spec-kit/ │ ├── config.yaml # 工具配置模型、工作模式、验证选项 │ └── sessions/ # 各轮实现会话记录带时间戳回溯用 └── output/ # 生成产物的默认输出目录这个结构设计得很克制没有给你塞一堆用不上的样板目录真正的重点就一个文件SPEC.md。配置里值得留意的字段除了模型选择之外还有一个叫verification_mode的选项取值可以是loose、strict和interactive默认是loose。我建议一开始用strict等流程习惯了再调。3.2 写出第一份规格文件spec-kit init生成的SPEC.md里带了一些占位模板我直接把内容替换成我们项目的完整规格## 目标 构建一个单页情绪板生成器。用户输入一个主题词后页面生成一组与该主题匹配的文字情绪卡片。 ## 范围 不涉及用户登录、后端服务、持久化存储。 不引入前端框架不使用构建工具。 ## 技术约束 - 纯前端实现一个 index.html一个 styles.css一个 app.js - 不能引用外部 CDN 和字体资源 - 使用 CSS Grid 布局卡片间距固定为 16px - 所有交互逻辑使用原生 JavaScriptDOM 操作不得使用第三方库 ## 功能要求 1. 页面顶部有一个输入框和“生成”按钮 2. 点击生成后根据主题词请求 AI 生成 6 张卡片的内容标题、描述、两个标签 3. 每张卡片渲染为一个面板颜色区域根据卡片语义自动从预设色板挑选不同色相 4. 生成过程中显示 loading 状态禁止重复点击 5. 页面底部显示当前主题词和生成时间 ## 验收标准 1. 输入主题词并点击“生成”后10 秒内页面上出现 6 张卡片 2. 6 张卡片的背景色色相互不相同且相邻卡片对比度明显 3. 生成过程中按钮被禁用文字变成“正在生成中...” 4. 输入为空时点击按钮页面提示“请先输入主题词”卡片区不变化 5. 生成完成后再次点击生成旧卡片被替换而不是追加 6. 页面不依赖联网资源离线打开仍能正常运行这里有几个写规格的关键细节。第一每条功能要求都写成了可操作的行为描述而不是形容词比如“颜色区域根据卡片语义自动从预设色板挑选不同色相”就是可操作的相比之下“界面精美”就是不可操作的。第二验收标准全部用了“能观察到的行为”来定义比如“按钮变成正在生成中...”“旧卡片被替换而不是追加”这样AI自我校验和你的验证才能统一。第三每一个“不做什么”的约束都对AI的生成策略有明显影响因为它会自动规避这些方向不浪费token去设计数据库、定义API。3.3 让Agent按规格实现规格文件写好后调用实现命令spec-kit run 实现当前规格这条命令会读取当前的SPEC.md把规格拆分成的功能条目逐个分发给Agent执行。整个执行过程是流水式的Agent先读取规格拆解任务、列出计划然后逐项写代码每次写完后对照验收标准中的相关条款自查。命令行的输出会和聊天式编程完全不同它给你展示的是任务拆解、每步的状态和结果摘要而不是一大段自然语言的解释。跑完之后output/目录下会生成完整的静态站点文件output/ ├── index.html ├── styles.css └── app.js这一步产出的东西比我在对话式Vibe-coding里拿到的最显著的进步就是干净。AI没有给我“顺便”加上React脚手架、npm配置、Toast插件之类的多余内容因为规格里的范围条款和技术约束把它限制住了。另外在.spec-kit/sessions/里可以看到这次运行的完整记录包括它读了什么、改了哪些文件、每步的验证结论是什么。一旦后续发现它某一步跑偏你可以直接定位到那一轮的会话内容不用再靠聊天记录人肉检索。3.4 按验收标准验收并迭代生成完只是开始真正的功夫在验收环节。我按照规格里的六条验收标准逐项测试。第一条和第二条顺利通过AI关于色相分配的提示词处理得不错6张卡片的背景色确实没有重复色相。第三条loading状态也没问题。问题出在第四条和第五条。输入为空点击“生成”页面确实弹了提示但提示是用alert()弹的而不是页面内的提示文案——规格本身没有明确到底是哪种提示方式AI选择了最省事的实现。而且注意规格里写的是“页面提示”严格来说alert()也勉强算页面提示但这个体验太粗糙了这不是我想要的。第五条的“旧卡片被替换而不是追加”实测结果是旧卡片还在新卡片被追加到了末尾。逐条打钩的时候这两条过不了。这个问题的处理方式决定了Spec-kit和对话式开发最根本的分野。在旧的聊天流里你会多说几句“把alert改成页面内显示旧的替换掉”AI改一版但可能又引入新的偏差。在Spec-kit里你应该去改规格把这个预期明确写进验收标准## 验收标准更新 4. 输入为空时点击按钮在输入框下方出现红色提示文案“请先输入主题词”不使用浏览器弹窗卡片区不变化 5. 生成完成后再次点击生成页面先清空卡片区再渲染新的6张卡片保证一次完整替换然后再次运行spec-kit update 根据更新后的验收标准修正实现这次Agent读取更新后的规格对照差异部分做定向修改。整个修改过程它不会碰其他已经通过验收的部分因为规格里每个功能和验收标准是绑定到一起的它明确知道“哪条规则对应哪里”。二次验收第四、第五条顺利通过全部列表打钩项目第一版收工。这里的核心心法就一句话不要用对话里的“随口要求”去指挥AI而是把要求沉淀成规格条款让AI照着改。你写规格花的时间会在后续每一轮迭代里成倍地省回来。4. 规格拆解的艺术把模糊想法变成可执行的说明4.1 拆粒度一个原子规格只做一件事跑通一个流程之后接下来真正决定你和Spec-kit合作水平高低的是你拆分规格的能力。我见过很多一开始用Spec-kit的人喜欢把规格写成一个长长的清单从页面配色一路写到数据库索引全部揉在一个SPEC.md里。这样做的结果就是Agent在单次运行里要同时处理十几项任务每项任务之间的耦合纠缠不清一旦后端的任务失败前面已经验证通过的前端部分也要跟着重来。我自己实践的粒度原则是让每一个规格文件只承载一个原子级别的任务。“原子”的边界怎么判断一个任务如果拆成两个子任务之后无法单独验收那就说明它是一个不可再拆的原子任务。例如“做一个待办列表页面”是一个页面级原子任务因为它可以单独验收样式的交互效果但“做一个带用户系统的待办列表页面”就不是一个原子任务因为它跨越了前端列表、后端接口、数据库、登录流程四块可独立验收的内容。所以我的一个项目通常会拆成多轮会话每个会话对应一份单独的规格。比如情绪板生成器这个项目我会把规格进一步拆成三份页面骨架和卡片渲染是一份AI生成卡片内容的接口封装是一份用户交互和边界处理是一份。每份规格完成并验收之后再进入下一份后一份的规格里引用前一份的产物作为输入条件。当然原子化也不是越细越好。我一个错误示范是把“写一个返回当前时间的函数”也当成一个规格任务让Agent单独跑一轮。这种细粒度的任务用对话随手就能完成单独拉一轮Spec-kit反而浪费了它的设计价值。合理的判断标准是这个任务是否有明确的验收边界以及它是否会在后续多轮迭代中反复被修改。两个条件至少满足一个才值得建一个规格。4.2 写验收标准时最容易漏掉的四件事我给不少朋友看过他们的规格文件发现大家写功能描述都头头是道但写验收标准时普遍漏掉四类内容。第一类是边界输入。最经典的例子就是“如果用户什么都不输入直接点按钮会怎样”“如果输入超长文本会怎样”“如果是复制粘贴的换行内容会怎样”。AI默认会假设输入是正常合理的不写边界规则它不会主动处理结果就是你在验收时才发现一堆异常状态没覆盖。第二类是空状态。你要求页面展示卡片列表但第一次打开页面数据为空的时候应该展示什么很多规格写“展示卡片列表”AI就真的只写了一个列表渲染逻辑初始化渲染一个空容器。空状态文案、引导操作这些不写进验收标准AI几乎永远不会主动做。第三类是性能基线。“页面加载时间不超过2秒”“生成过程中浏览器不卡顿”“卡片超过100张时仍然流畅滚动”这种指标在对话里你可能提一句但如果不变成验收条款Agent不会把它当作硬性要求因为模型对“不卡顿”的主观理解和你的主观体验之间偏差可能非常大。第四类是异常反馈。AI调用失败、网络中断、后端返回错误码用户端应该看到什么Spec-kit生成的应用默认就是什么反馈都没有静默失败。在验收标准里明确“AI请求失败时卡片区显示‘生成失败请稍后重试’”后端异常才有人管。写进验收标准的内容有一个共性就是它们全部是“可被外部观察到的行为”而不是“内部应该怎么实现的描述”。比如“使用防抖函数处理输入”这不是验收标准因为防抖是实现细节你没法从一个黑盒的角度验证它但“用户停止输入1秒后页面自动更新搜索结果”这个是验收标准因为它描述的是可观察的用户行为。把代码层面的事情留给AI自己发挥把你真正关心的事情写成行为句子这是规格文件最好用的写作姿势。4.3 一个反面案例与修正过程空谈原则不如看一个具体案例。我一开始写情绪板生成器的时候功能要求第3条最初版本是这样的“每张卡片渲染为一个面板颜色区根据卡片语义自动从预设色板挑选颜色整体协调好看。”听起来没什么问题但“协调好看”完全是一个主观描述。Agent生成的色板是清一色的低饱和莫兰迪色系单独看确实协调但六张卡片放在一起色相区分度很低我验收第二条“色相互不相同”直接挂了。我当时的修改思路是把形容词改成可量化的规则## 功能要求更新版 3. 颜色区使用HSL颜色模式所有卡片从预设的6个基础色相0度、60度、120度、180度、240度、300度中选取保证卡片两两色相差不小于50度同一色相下明度保持在70%到90%区间内这次AI的产出马上就不一样了。色相规则一旦量化结果可测、可猜、可核验也不依赖“好看”这种主观判断。从这次之后我养成一个习惯规格里的每一个描述性词汇都要过一遍“可测量吗”这个拷问如果不可测量就继续挖直到写出了能让你写测试用例的句子为止。5. 实测几周后我总结的坑与应对策略5.1 Agent会“礼貌性跑偏”规格没锁死的地方它自由发挥用了Spec-kit几周之后我发现一个比较隐蔽的问题我称之为“礼貌性跑偏”。也就是说Agent在实现规格的时候大体方向是对的但它总会顺手在规格的“灰色地带”里夹带一点私货。规格里写“使用原生JavaScript”它可能严格遵守但你没写“按钮样式怎么处理”它就把按钮做成了某个特定框架风格和页面整体设计语言完全不搭。这类跑偏的特点是你不说它完全不觉得自己做错了因为规格里确实没有限制。应对方法只有一个——把你觉得“理所当然应该这样”的每一件事都写进规格。不要相信AI有“常识”你对“按钮就是要圆角”“输入框聚焦时要有个边框提示”“页面标题文字不能折行”这些判断在它那里全是可选项。我在实际项目中专门建了一个“样式与体验基线”的规格章节把这类容易产生主观偏差的偏好全部固定下来## 样式与体验基线 - 全局字体使用系统字体栈字号最小12px行高1.6 - 按钮统一圆角8px主按钮使用主题色填充次按钮使用浅灰背景无边框 - 输入框聚焦时边框颜色变为主题色同时外部出现3px的浅色光晕 - 卡片在鼠标悬停时向上位移2px过渡时间150ms - 所有有交互行为的元素按钮、输入框、卡片必须设置cursor: pointer别小看这些“细节条款”它们把AI从“做出来一个能用但不合你审美的界面”直接拉到了“做出来一个符合你统一设计体系的界面”。审美和代码风格这两个说不清道不明的东西一旦格式化成可执行的条目Agent的生成质量会有一个质的跳跃。5.2 规格与代码脱节改完代码不更新规格后面越来越乱Spec-kit一个很容易被忽视的陷阱是“规格和代码脱节”。场景是这样的你跑了spec-kit run生成了一版代码验收时发现某个交互逻辑不理想你懒得改规格直接说“帮我把搜索改成防抖的”Agent改了代码。此时规格文件里对应的条款还是旧的。几轮之后你再看SPEC.md会发现它已经不能描述项目的真实状态了这个文件就失去了“唯一事实来源”的价值。这个问题在对话式Vibe-coding里也存在但Spec-kit把它放大了。因为规格文件的位置太重要了它被当成后续所有迭代的锚点。如果你更新它不积极后续Agent读到的是一份过时的地图生成的结果一定和你的预期渐行渐远。我给自己定的规矩很简单**所有对产物行为的变更必须先改规格再让Agent基于新规格改代码。**哪怕只是一个小到“按钮文案从‘生成’改成‘开始’”我也走这个流程。前期可能觉得小题大做习惯之后你会发现这个规矩保住的是你项目的“可理解性”让任何人都能在任何时候翻开SPEC.md就知道当前项目做成了什么样子。5.3 对话上下文仍然会超限但规格文件降低了后果还有一个现实问题绕不过去即便使用Spec-kitAgent本身的上下文窗口仍然是有限度的。如果规格文件特别长或者迭代轮数特别多Agent在某个节点之后还是会“遗忘”前面规格里的部分条款。我实测下来这种遗忘往往不在主路径上而是在细节条款上比如第10条验收标准之前的某个约束到第15条实现时它已经没在追踪了。关键的区别是在对话式Vibe-coding里这种遗忘是灾难性的因为上下文写在聊天流里你不会定期回看等发现问题的时候错误已经扩散到很多文件里了。但在Spec-kit的环境里规格文件就在那里每次Agent运行前都会重新读取和系统化拆分遗忘发生在哪一轮那一轮的会话记录就有迹可循你可以直接把对应的条款抽出来重新让它执行修正的成本低得多。我习惯的做法是把规格拆分到更小的单位每个规格文件控制在60到80行以内并且在一份规格里尽量只放一个功能域的内容。这样即使Agent到后面记忆模糊重读整个文件的开销也很小遗忘的部分更容易被Agent自我检测到。如果项目确实很大我会采用“主规格子规格”的结构主规格定义项目全局的目标和约束每个功能域一个子规格整个项目拆到三四个锁屏程度的规格文件让Agent可以分阶段读取和执行。5.4 多人协作时规格文件要进入评审流程最后是协作场景。我这段时间尝试和一位同事用Spec-kit一起维护一个内部工具。一开始我们认为规格文件写得清楚AI改的代码应该可以少评审。实际跑了一周发现一个隐患如果同事直接在设备上修改了Spec.md再跑一轮Spec-kit结果就是规格偏离了讨论时确定的方案因为他可能把“记录我们聊的内容”和“记录实际要实现的”搞混了。同时因为规格文件是所有迭代的锚点谁改了它谁就实际上决定了之后所有人的实现方向。所以后来我们定的规矩是规格文件的修改必须走Pull Request评审和代码评审同等对待。任何一次修改都明确标注变更原因和影响范围这样AI指导实现所依据的“唯一事实来源”才是大家共同确认过的而不是某个人随手改的。这样做还有一个附加好处新加入项目的人不再需要翻半天的聊天记录直接看规格文件的评审历史就能理解项目当前的所有决策是怎样一步步沉淀下来的。6. 从“解锁”到“习惯”Spec-kit给工作流带来的变化6.1 它没有替代Vibe-coding它给了它骨架很多人觉得Spec-kit是“给AI编程套回了传统软件工程的枷锁”我自己用下来完全不这么认为。它改变的不是“你还在跟AI对话写代码”这个事实而是每一次对话在哪个语境下发生。以前语境是那条越来越长的聊天记录现在语境是那份越来越清晰的规格文件。Vibe-coding最爽的部分——快速把想法变成原型、随时改需求马上看结果——都被保留了只是这个“爽”不再是建立在流沙上面的。举个例子我给情绪板生成器做第二轮迭代的时候我想加一个“收藏夹”功能。在旧的聊天流里我大概要花十分钟跟AI解释现有代码结构、数据从哪来到哪去、哪些地方需要改然后还提心吊胆怕它改坏其他东西。在Spec-kit的流程里我只需要在功能要求里加一条“卡片右上角显示收藏按钮点击后加入本地收藏列表支持跨会话保留”然后跑一次spec-kit update。Agent读取现有的规格和代码结构在约束边界内完成了全部改动验收通过之后整个迭代的记录都清晰留在会话记录里。这个体验上的差异比效率提升本身更让人安心。6.2 可以尝试的扩展玩法踩完坑跑通流程我还在探索一些更进阶的用法这里分享几个我认为方向明确而且已经有实际效果的。第一个玩法是把单元测试并入验收标准。Spec-kit支持在规格文件的验收标准区引用测试文件我对纯逻辑模块比如卡片内容生成逻辑、数据格式化函数写了配套的单元测试然后标注为“必须通过npm test”。这样AI生成代码之后会自己跑测试通了才算完成。效果很直接逻辑模块的生成质量比我手动验收时要稳定得多因为它自己就能验证“用户的输入是否符合参数要求”这种容易被漏掉的细节。第二个玩法是把规格文件直接当作项目的技术文档备用。以前我们通常是项目写完再回头补文档费时而且时效性差。现在只要每一轮交互都遵循“先改规格再改代码”的规矩SPEC.md本身就是一份始终最新的、可读性良好的技术说明。同事接手项目时我只需要说一句“先看这个文件”他就能在最短的时间里了解当前系统的全貌和设计决策。对团队来说光这一点省下的沟通成本就非常可观。第三个玩法是批处理式的小工具生成。我有几个一次性脚本类的需求比如把某个目录下的CSV文件批量转成JSON、给一堆图片生成缩略图并统一命名等以前我会打开聊天面板逐一描述现在我把每类任务写成一份很小的规格文件用一行命令批量跑。这个场景下Spec-kit的价值尤其明显任务之间有共性但参数各异规格文件就是绝佳的模板改几行描述就能生成一个新工具全程不用写一行手动的代码。6.3 一些反思什么时候不该用Spec-kit当然我也没有完全抛弃对话式Vibe-coding。有些场景下Spec-kit反而是多余的动作纯探索性的原型验证你只想知道某个想法“能不能实现”没有稳定的需求方向这时候规格会让你陷入过早的固化一次性五行的脚本写个规格文件的时间和写代码的时间差不多纯属于成本不值还有学习阶段的尝试比如你想看看AI会怎么处理一个开放性的问题这时候你会希望给它最大的自由度。对这些场景还是回到对话驱动的Vibe-coding更合适。Spec-kit不是要取代所有AI编程模式它是给你一个旋钮让“可控性”和“自由度”按项目的实际需要重新分配。我自己现在的工作模式是80%的项目走Spec-kit流程剩下20%的探索和试验继续纯对话这两者并不互斥反而形成了很好的互补。最后分享一个实操细节第一次用Spec-kit时不要想着一次就把整个项目写进规格里挑一个足够小、边界足够清晰的功能比如“一个输入框一个按钮一组卡片展示”先完整跑通一遍“写规格—生成—验收—更新”的循环。跑通之后你会发现这个循环带给你的节奏感完全不同于聊天里那种随时可能失控的兴奋感——它是一种“需求在往前推进而每一步都有据可依”的踏实感。整个工作流被Spec-kit重新组织之后我使用AI编程的频率没有变低但焦虑感明显减少了这可能才是“解锁Vibe-coding”的真正含义。
阅读完成 · 觉得有帮助？
