
> 从Vibe Coding的混沌中醒来，拥抱确定性

![thumb_0.png](https://developer.qcloudimg.com/http-save/yehe-11177336/b819d0ee0c23b2e5806423734f9c78bc.jpg)


## 一段似曾相识的对话

“帮我加个深色模式。”

“好的，已添加深色模式。”

——半小时后，你发现深色模式把所有的图标都反色了，按钮不见了，而白色模式下的文字变成了灰色。

“不对，我说的是只改背景，不改图标和文字...”

“明白了，已修复。”

——十分钟后，深色模式是好了，但白色模式下那个新加的按钮消失了。

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

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

这不是段子，这是无数开发者正在经历的日常。这就是所谓的 **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工作流图]（*此处建议配图：下面这个流程图的精美可视化版本*）

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

**四个步骤详解：**

| 步骤 | 做什么 | 产出物 | 关键角色 |
|:---|:---|:---|:---|
| **1. 起草提案** | 你提想法，AI自动生成结构化文档 | `proposal.md`（为什么改）<br>`specs/`（规范增量）<br>`tasks.md`（任务清单） | AI负责起草 |
| **2. 审查对齐** | 你和AI共同审查，迭代修改直到达成共识 | 最终版规范文档（已锁定） | **人**负责决策 |
| **3. AI实施** | AI严格按照锁定的任务清单执行 | 符合规范的代码 | AI负责执行 |
| **4. 归档更新** | 将本次变更合并到主规范，成为新的真相来源 | 更新后的主规范目录 | 系统自动完成 |

### 🔑 三个核心概念

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

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

```yaml
# 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：归档更新

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

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

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

---

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

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

**什么时候用Vibe Coding？**
- 🎨 快速原型验证想法
- 📝 一次性数据处理脚本
- 🧪 技术可行性探索
- 👤 个人小工具

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

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

---

## 六、如何开始使用SDD？

### 第一步：选择一个SDD框架

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

| 框架 | 特点 | 适用场景 |
|:---|:---|:---|
| **OpenSpec** | 棕地优先、工具无关、免费 | 已有项目的渐进式改造 ⭐推荐 |
| **SpecKit** | 绿地优先、结构化强 | 从零开始的新项目 |
| **Kiro** | 轻量、简洁 | 个人项目、小团队 |

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

安装OpenSpec：
```bash
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

——半小时后，你发现深色模式把所有的图标都反色了，按钮不见了，而白色模式下的文字变成了灰色。

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

高级软件开发工程师

人工智能

开发工具

职业发展

探索AI编程新范式：告别VibeCoding混乱，拥抱规范驱动开发(SDD)。SDD通过先写规范再编码的方式，解决AI开发中的需求漂移、边界模糊问题，提升代码可预测性和团队协作效率。适用于生产环境、多人协作和长期维护项目，让AI成为严格执行者而非自由发挥者。

单元测试

回归测试

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

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

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐