一段令人似曾相识的对话

“帮我加一个深色模式功能。”

“好的，已经为您添加了深色模式。”

——半小时后，您发现深色模式将所有图标都反色处理，按钮消失了，而白色模式下的文字却变成了灰色。

“不对，我要求的是只修改背景，不动图标和文字……”

“明白了，已修复。”

——十分钟后，深色模式确实正常了，但白色模式下那个新添加的按钮却不见了。

“你把我白色模式的样式也覆盖了？”

“抱歉，我重新实现……”

这不是段子，而是无数开发者正在经历的日常。这便是所谓的 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️⃣ 规范即“真相来源”

所有关于“系统应该做什么”的知识，都存放在版本可控的规范文件中（通常是 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项目的正确打开方式？

对比一：结果可预测性

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

对比二：变更可追溯性

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

对比三：团队协作

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

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

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

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

综合对比表

四、实战案例：用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：归档更新

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

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：

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说“帮我加个功能”的时候，不妨先停下来，问自己一句：

这段代码，您下周还会碰吗？