企业官网建设流程全解析

最近几周我基本处在一种“白天和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-kit

1.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补上了那张地图。

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_KEY="sk-xxx" export SPEC_KIT_MODEL="claude-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 - 所有交互逻辑使用原生 JavaScript，DOM 操作不得使用第三方库 ## 功能要求 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-kit，Agent本身的上下文窗口仍然是有限度的。如果规格文件特别长，或者迭代轮数特别多，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”的真正含义。