告别Vibe Coding：为什么SDD（Spec-Driven Development）才是AI项目开发的正确打开方式

从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工作流图]（此处建议配图：下面这个流程图的精美可视化版本）

1flowchart LR
2    A[📝 起草变更提案] --> B[👀 审查并对齐]
3    B --> C[🤖 AI按规范实施]
4    C --> D[📦 归档更新主规范]
5    D -.->|作为下一个变更的基础| A
6

四个步骤详解：

🔑 三个核心概念

1️⃣ 规范即“真相来源”

所有关于“系统应该做什么”的知识，都存储在版本可控的规范文件中（通常是 specs/ 目录）。

1# specs/auth/login.spec.md
2## 功能：用户登录
3### 验收标准：
4- [ ] 用户输入正确邮箱和密码，登录成功并跳转到首页
5- [ ] 用户输入错误密码3次，账户被锁定15分钟
6- [ ] 登录成功后，生成JWT token，有效期2小时
7

代码可以重构，规范是锚点。

2️⃣ 变更即“提案”

任何修改都不是直接在代码上“改一改”，而是创建一个完整的变更提案文件夹：

1changes/add-dark-mode/
2├── proposal.md          # 为什么需要深色模式
3├── tasks.md             # 具体要做哪些事（可勾选）
4└── specs/
5    ├── theme/spec.md    # 深色模式的规范（增量）
6    └── settings/spec.md # 设置页的规范变更
7

提案通过审查，才能进入实施。

3️⃣ AI即“履约方”

AI不再是根据模糊对话自由发挥的“艺术家”，而是严格按照规范清单执行的“工程师”。

AI知道：

• ✅ 必须做什么（来自 tasks.md）
• ✅ 不能做什么（规范没有写的，就不能改）
• ✅ 怎样算完成（验收标准）

三、为什么SDD是AI项目的正确打开方式？

对比一：结果可预测性

SDD的保障：规范的每一句话都是可验证的。AI的每一次输出都可以对照规范检查。通过，则合并；不通过，则打回。

对比二：变更可追溯性

SDD的保障：三个月后回头看，你不仅能知道代码改了什么，还能知道当初为什么这么改。

对比三：团队协作

SDD的保障：产品经理可以审规范，测试可以写基于规范的用例，另一个开发者可以基于相同的规范让AI生成风格一致的代码。

对比四：棕地友好（已有项目）

很多规范驱动框架只适合新项目，但SDD（尤其是OpenSpec）专门为已有项目设计。

SDD的保障：你可以从一个混乱的现有代码库开始，从下一个功能开始建立规范，而不是推翻重来。

综合对比表

四、实战案例：用SDD开发一个深色模式

让我用一个真实场景演示SDD的完整流程：

场景

你有一个现有的博客系统，需要增加深色模式。

❌ Vibe Coding的做法

1你：帮我加个深色模式
2AI：好的，我改了全局CSS
3你：不对，图片不要反色
4AI：修复了
5你：设置页的开关呢？
6AI：加上了
7你：白色模式的代码被你覆盖了？？？
8AI：抱歉...
9

结果：3小时后，深色模式勉强能用，白色模式坏了两个页面。

✅ SDD的做法

步骤1：起草提案

你输入想法，AI自动生成：

1changes/add-dark-mode/
2├── proposal.md
3│   ├── Why: 提升夜间阅读体验，用户调研显示43%的用户在夜间访问
4│   ├── What: 增加深色主题切换功能
5│   └── Impact: 影响全局样式、设置页、文章阅读页
6├── tasks.md
7│   ├── [ ] 1. 在设置页增加主题切换开关（浅色/深色/跟随系统）
8│   ├── [ ] 2. 实现主题切换逻辑（localStorage存储+CSS变量）
9│   ├── [ ] 3. 适配文章阅读页的深色样式
10│   ├── [ ] 4. 确保图片、代码块在深色模式下不变色
11│   └── [ ] 5. 编写单元测试（主题切换+持久化）
12└── specs/theme/spec.md
13    ├── ## 新增功能：主题切换
14    ├── ### 场景1：用户手动切换主题
15    │   ├── GIVEN 用户在设置页
16    │   ├── WHEN 点击“深色模式”开关
17    │   └── THEN 页面立即切换为深色主题，且选择被保存
18    └── ### 场景2：用户关闭深色模式
19        └── ...
20

步骤2：审查对齐

你审阅提案，发现一个问题：“‘跟随系统’这个需求我没提啊。”

AI回复：“基于最佳实践建议增加，如果你不需要，我可以删除。”

你说：“好，删除‘跟随系统’，保留手动切换即可。”

AI更新提案。你确认后，提案锁定。

关键：此时一行代码都没写，但人和AI对“要做什么”已经100%达成一致。

步骤3：AI实施

AI严格按照 tasks.md 执行，每完成一项就勾选：

1- [x] 1. 在设置页增加主题切换开关
2- [x] 2. 实现主题切换逻辑
3- [x] 3. 适配文章阅读页的深色样式
4- [ ] 4. 确保图片、代码块不变色  ← 正在执行
5- [ ] 5. 编写单元测试
6

AI不会擅自增加“跟随系统”功能，因为你已经明确删除了它。

步骤4：归档更新

任务全部完成后，执行归档命令。系统自动：

1. 将 changes/add-dark-mode/specs/ 中的规范增量合并到主 specs/ 目录
2. 移动整个提案到 changes/archive/ 文件夹
3. 更新主规范的版本记录

结果：你的博客系统现在有了深色模式，主规范也更新了。下一个开发者（或未来的你）可以从规范中了解到：“哦，深色模式是这样设计的，边界条件是这些。”

五、别误会，我不是说Vibe Coding一无是处

探索性原型、个人小工具、一次性数据处理脚本——这些场景下，Vibe Coding的“快”是无可替代的优势。

什么时候用Vibe Coding？

• 🎨 快速原型验证想法
• 📝 一次性数据处理脚本
• 🧪 技术可行性探索
• 👤 个人小工具

什么时候必须用SDD？

• 🏢 生产环境的核心业务代码
• 👥 多人协作的项目（>2人）
• 📅 持续迭代超过3个月的项目
• 🔄 需要长期维护的系统
• 🐛 对稳定性和可追溯性有要求的场景

一句话判断：如果这个代码你下周还会碰，就值得用SDD。

六、如何开始使用SDD？

第一步：选择一个SDD框架

目前最成熟的轻量级选择：

我的推荐：如果你的项目已经有代码了，选OpenSpec。它可以在不推翻现有代码的前提下，让你从下一个功能开始用SDD。

安装OpenSpec：

1npm install -g @openspec/cli
2openspec init
3

第二步：从一个小功能开始

不用翻新整个项目。选下一个要做的功能，用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

《告别Vibe Coding：为什么SDD（Spec-Driven Development）才是AI项目开发的正确打开方式》 是转载文章，点击查看原文。