从Vibe Coding的混沌中醒来，拥抱确定性
一段似曾相识的对话
“帮我加个深色模式。”
“好的，已添加深色模式。”
——半小时后，你发现深色模式把所有的图标都反色了，按钮不见了，而白色模式下的文字变成了灰色。
“不对，我说的是只改背景，不改图标和文字...”
“明白了，已修复。”
——十分钟后，深色模式是好了，但白色模式下那个新加的按钮消失了。
“你把我白色模式的样式也改了？”
“抱歉，我重新实现...”
这不是段子，这是无数开发者正在经历的日常。这就是所谓的 Vibe Coding——凭感觉编程。
一、Vibe Coding：AI时代的“野路子”
Vibe Coding这个词最近很火，形容的是那种“我跟AI聊着天，代码就写出来了”的开发方式。听起来很酷，但实际体验往往是：
🔴 痛点1：需求像流沙
你提一句，AI改一版，再提一句，AI再改一版。需求在对话中不断漂移，没人记得最初要的是什么。
真实案例：某开发者让AI“优化一下登录页”，AI把整个认证流程重写了，还顺便改了密码找回逻辑。最后花了3小时回滚代码。
🔴 痛点2：AI爱“自由发挥”
你说“优化一下登录功能”，AI可能重写整个认证模块，顺便把你没提到的密码找回页面也改了个遍。
根本原因：AI没有“边界感”。它不知道什么该改、什么不该改，因为没有明确的规范约束它。
🔴 痛点3：回归测试靠肉眼
改完A功能，B功能坏了。修好B，C又出问题。没有规范文档，你甚至不确定“正确的行为”应该是什么。
数据说话：根据某团队的内部统计，使用Vibe Coding模式的项目，平均每个功能变更会引入2.3个非预期的副作用。
🔴 痛点4：协作基本靠吼
今天你让AI加了个API，明天另一个同事让AI改了个参数，两个变更在代码库里打架，冲突解决起来像拆弹。
根本原因：没有“真相来源”。每个人和AI的对话都是孤立的，规范只存在于各自的脑子里（甚至脑子里都没有）。
![痛点配图]（此处建议配图：一个开发者被各种箭头和问号包围，表情崩溃的插画）
二、SDD：给AI立规矩
Spec-Driven Development（规范驱动开发） 的出现，正是为了结束这种混乱。
SDD的核心思想极其朴素：先写规范，再写代码。规范是合同，代码是履约。
📐 SDD核心工作流
![SDD工作流图]（此处建议配图：下面这个流程图的精美可视化版本）
flowchart LR
A[📝 起草变更提案] --> B[👀 审查并对齐]
B --> C[🤖 AI按规范实施]
C --> D[📦 归档更新主规范]
D -.->|作为下一个变更的基础| A
四个步骤详解：
| 步骤 | 做什么 | 产出物 | 关键角色 |
|---|---|---|---|
| 1. 起草提案 | 你提想法，AI自动生成结构化文档 | proposal.md（为什么改）specs/（规范增量）tasks.md（任务清单） | AI负责起草 |
| 2. 审查对齐 | 你和AI共同审查，迭代修改直到达成共识 | 最终版规范文档（已锁定） | 人负责决策 |
| 3. AI实施 | AI严格按照锁定的任务清单执行 | 符合规范的代码 | AI负责执行 |
| 4. 归档更新 | 将本次变更合并到主规范，成为新的真相来源 | 更新后的主规范目录 | 系统自动完成 |
🔑 三个核心概念
1️⃣ 规范即“真相来源”
所有关于“系统应该做什么”的知识，都存储在版本可控的规范文件中（通常是 specs/ 目录）。
# specs/auth/login.spec.md
## 功能：用户登录
### 验收标准：
- [ ] 用户输入正确邮箱和密码，登录成功并跳转到首页
- [ ] 用户输入错误密码3次，账户被锁定15分钟
- [ ] 登录成功后，生成JWT token，有效期2小时
代码可以重构，规范是锚点。
2️⃣ 变更即“提案”
任何修改都不是直接在代码上“改一改”，而是创建一个完整的变更提案文件夹：
changes/add-dark-mode/
├── proposal.md # 为什么需要深色模式
├── tasks.md # 具体要做哪些事（可勾选）
└── specs/
├── theme/spec.md # 深色模式的规范（增量）
└── settings/spec.md # 设置页的规范变更
提案通过审查，才能进入实施。
3️⃣ AI即“履约方”
AI不再是根据模糊对话自由发挥的“艺术家”，而是严格按照规范清单执行的“工程师”。
AI知道：
- ✅ 必须做什么（来自
tasks.md） - ✅ 不能做什么（规范没有写的，就不能改）
- ✅ 怎样算完成（验收标准）
三、为什么SDD是AI项目的正确打开方式？
对比一：结果可预测性
| Vibe Coding | SDD | |
|---|---|---|
| 输出确定性 | ❌ 不可预测 | ✅ 可审计、可验证 |
| 回归风险 | ❌ 高（改A坏B） | ✅ 低（规范明确边界） |
| 验收标准 | ❌ 模糊（“差不多就行”） | ✅ 清晰（可勾选的清单） |
SDD的保障：规范的每一句话都是可验证的。AI的每一次输出都可以对照规范检查。通过，则合并；不通过，则打回。
对比二：变更可追溯性
| Vibe Coding | SDD | |
|---|---|---|
| 历史记录 | ❌ 依赖聊天记录（不可用） | ✅ 每个变更独立提案 |
| 决策上下文 | ❌ 丢失 | ✅ proposal.md记录“为什么” |
| 谁改的、改了什么 | ❌ 无从得知 | ✅ Git+规范，清清楚楚 |
SDD的保障：三个月后回头看，你不仅能知道代码改了什么，还能知道当初为什么这么改。
对比三：团队协作
| Vibe Coding | SDD | |
|---|---|---|
| 多人并行 | ❌ 冲突频繁 | ✅ 规范即文档，天然支持 |
| 知识传递 | ❌ 靠口口相传 | ✅ 规范就是活的文档 |
| 新人上手 | ❌ 一脸懵 | ✅ 读规范就懂系统 |
SDD的保障：产品经理可以审规范，测试可以写基于规范的用例，另一个开发者可以基于相同的规范让AI生成风格一致的代码。
对比四：棕地友好（已有项目）
很多规范驱动框架只适合新项目，但SDD（尤其是OpenSpec）专门为已有项目设计。
| 传统规范驱动 | SDD | |
|---|---|---|
| 适用场景 | 新项目（绿地） | 已有项目（棕地）✅ |
| 改造成本 | 低（从零开始） | 低（渐进式引入） |
| 典型工具 | SpecKit | OpenSpec |
SDD的保障：你可以从一个混乱的现有代码库开始，从下一个功能开始建立规范，而不是推翻重来。
综合对比表
| 维度 | Vibe Coding | SDD |
|---|---|---|
| 需求表达 | 模糊的自然语言对话 | 结构化的规范文档 |
| AI行为 | 自由发挥，不可预测 | 严格遵循规范，行为可控 |
| 变更追踪 | 靠对话历史（基本不可用） | 每个变更有独立提案和审计记录 |
| 回归风险 | 高，改A坏B | 低，规范明确了边界 |
| 团队协作 | 困难 | 规范即文档，天然支持协作 |
| 知识沉淀 | 几乎为零 | 规范不断积累，成为资产 |
| 适用场景 | 原型、一次性脚本 | 任何需要长期维护的项目 |
| 学习曲线 | 低 | 中（值得投入） |
四、实战案例：用SDD开发一个深色模式
让我用一个真实场景演示SDD的完整流程：
场景
你有一个现有的博客系统，需要增加深色模式。
❌ Vibe Coding的做法
你：帮我加个深色模式
AI：好的，我改了全局CSS
你：不对，图片不要反色
AI：修复了
你：设置页的开关呢？
AI：加上了
你：白色模式的代码被你覆盖了？？？
AI：抱歉...
结果：3小时后，深色模式勉强能用，白色模式坏了两个页面。
✅ SDD的做法
步骤1：起草提案
你输入想法，AI自动生成：
changes/add-dark-mode/
├── proposal.md
│ ├── Why: 提升夜间阅读体验，用户调研显示43%的用户在夜间访问
│ ├── What: 增加深色主题切换功能
│ └── Impact: 影响全局样式、设置页、文章阅读页
├── tasks.md
│ ├── [ ] 1. 在设置页增加主题切换开关（浅色/深色/跟随系统）
│ ├── [ ] 2. 实现主题切换逻辑（localStorage存储+CSS变量）
│ ├── [ ] 3. 适配文章阅读页的深色样式
│ ├── [ ] 4. 确保图片、代码块在深色模式下不变色
│ └── [ ] 5. 编写单元测试（主题切换+持久化）
└── specs/theme/spec.md
├── ## 新增功能：主题切换
├── ### 场景1：用户手动切换主题
│ ├── GIVEN 用户在设置页
│ ├── WHEN 点击“深色模式”开关
│ └── THEN 页面立即切换为深色主题，且选择被保存
└── ### 场景2：用户关闭深色模式
└── ...
步骤2：审查对齐
你审阅提案，发现一个问题：“‘跟随系统’这个需求我没提啊。”
AI回复：“基于最佳实践建议增加，如果你不需要，我可以删除。”
你说：“好，删除‘跟随系统’，保留手动切换即可。”
AI更新提案。你确认后，提案锁定。
关键：此时一行代码都没写，但人和AI对“要做什么”已经100%达成一致。
步骤3：AI实施
AI严格按照 tasks.md 执行，每完成一项就勾选：
- [x] 1. 在设置页增加主题切换开关
- [x] 2. 实现主题切换逻辑
- [x] 3. 适配文章阅读页的深色样式
- [ ] 4. 确保图片、代码块不变色 ← 正在执行
- [ ] 5. 编写单元测试
AI不会擅自增加“跟随系统”功能，因为你已经明确删除了它。
步骤4：归档更新
任务全部完成后，执行归档命令。系统自动：
- 将
changes/add-dark-mode/specs/中的规范增量合并到主specs/目录 - 移动整个提案到
changes/archive/文件夹 - 更新主规范的版本记录
结果：你的博客系统现在有了深色模式，主规范也更新了。下一个开发者（或未来的你）可以从规范中了解到：“哦，深色模式是这样设计的，边界条件是这些。”
五、别误会，我不是说Vibe Coding一无是处
探索性原型、个人小工具、一次性数据处理脚本——这些场景下，Vibe Coding的“快”是无可替代的优势。
什么时候用Vibe Coding？
- 🎨 快速原型验证想法
- 📝 一次性数据处理脚本
- 🧪 技术可行性探索
- 👤 个人小工具
什么时候必须用SDD？
- 🏢 生产环境的核心业务代码
- 👥 多人协作的项目（>2人）
- 📅 持续迭代超过3个月的项目
- 🔄 需要长期维护的系统
- 🐛 对稳定性和可追溯性有要求的场景
一句话判断：如果这个代码你下周还会碰，就值得用SDD。
六、如何开始使用SDD？
第一步：选择一个SDD框架
目前最成熟的轻量级选择：
| 框架 | 特点 | 适用场景 |
|---|---|---|
| OpenSpec | 棕地优先、工具无关、免费 | 已有项目的渐进式改造 ⭐推荐 |
| SpecKit | 绿地优先、结构化强 | 从零开始的新项目 |
| Kiro | 轻量、简洁 | 个人项目、小团队 |
我的推荐：如果你的项目已经有代码了，选OpenSpec。它可以在不推翻现有代码的前提下，让你从下一个功能开始用SDD。
安装OpenSpec：
npm install -g @openspec/cli
openspec init
第二步：从一个小功能开始
不用翻新整个项目。选下一个要做的功能，用SDD的流程走一遍。
好选择：新增一个独立的小功能（如“增加一个导出按钮”） 坏选择：重构整个认证模块
第三步：克制“先写代码”的冲动
这是最难的一步。你的肌肉记忆会催你：“先写几行代码看看效果。”
忍住。 先写规范。让AI和你一起审查，直到双方都清楚“要做什么”。
一个好的规范应该满足：
- ✅ 验收标准可量化（“响应时间<200ms”而不是“要快”）
- ✅ 边界条件明确（“密码错误3次锁定”而不是“错误太多就锁定”）
- ✅ 非功能性需求清晰（“支持Chrome和Safari最新版”）
第四步：把AI当作“严格执行者”
一旦规范锁定，让AI严格按任务清单执行。
可以做的事：
- ✅ “请继续执行tasks.md的第3项”
- ✅ “这个实现不符合spec.md的第2条验收标准，请修改”
不可以做的事：
- ❌ “顺便帮我加个loading动画”（这应该回去改提案，重新走流程）
第五步：归档即学习
每个变更完成后，花5分钟看看归档的规范：
- 这次的设计决策是什么？
- 有哪些坑被提前规避了？
- 下次类似的变更，可以直接复用哪些规范？
归档的规范就是团队的知识资产，比任何Wiki都管用，因为它和代码是同步的。
七、常见问题Q&A
Q1：SDD会不会太“重”了？小项目没必要吧？
A：看项目的生命周期。一个周末项目确实没必要。但如果是“下周还要继续改”的项目，SDD的前期投入会在第二次、第三次变更时迅速回本。
经验法则：如果这个功能你要改3次以上，SDD就是划算的。
Q2：AI能自动生成规范吗？还是要我手写？
A：AI可以生成初稿。你只需要输入一个想法（如“增加深色模式”），AI就会自动生成完整的提案结构，包括规范文档和任务清单。
你的角色是审查者和决策者，不是“文档打字员”。
Q3：规范写得不够好怎么办？
A：规范也是代码的一部分，可以迭代。第一次写得粗糙没关系，每次变更都可以优化规范。
但关键是：一旦进入实施阶段，规范就不能改了。要改，就中止实施，回去改提案，重新审查。
Q4：团队其他人不用SDD怎么办？
A：渐进式引入。你可以从自己负责的模块开始用SDD，规范文件放在代码库里。别人即使不用，也能读到规范，这本身就是一种知识传递。
当大家发现“你负责的模块从来没出过莫名其妙的bug”时，他们会主动来问的。
Q5：SDD和TDD（测试驱动开发）是什么关系？
A：它们是互补的。
- SDD：关注“做什么”（行为规范）
- TDD：关注“怎么做”（实现正确性）
理想组合：SDD定义验收标准（可以转化为测试用例），TDD确保代码通过测试。
八、写在最后
AI编程助手不是魔法棒，它是一把锋利但需要驾驭的工具。
Vibe Coding教会了我们与AI“聊天”的能力，这很重要。但项目开发的本质不是聊天，而是在不确定性中构建确定性。
SDD提供的，正是这样一种能力：用规范建立共识，用契约约束行为，用可追溯的流程管理变更。
你的行动清单
如果你读到这里，觉得SDD值得一试，这是你的下一步：
- 今天：选一个SDD框架（推荐OpenSpec），在本地安装
- 明天：选一个你正在做的小功能，用SDD走一遍完整流程
- 本周：复盘体验——SDD让你多花了多少时间？帮你避免了哪些坑？
- 下个月：如果效果好，推广给团队，从核心模块开始建立规范
下一次，当你要对AI说“帮我加个功能”的时候，不妨先停下来，问自己一句：
“我的规范，写好了吗？”
如果这篇文章对你有帮助，欢迎点赞、在看、转发。也欢迎在评论区分享你被Vibe Coding坑过的经历——我赌你至少有一个故事。
📚 延伸阅读
- OpenSpec官方文档：[链接]
- Spec-Driven Development: The Missing Link in AI Programming
