前言

当我零基础接触vibe coding的时候，我会觉得很兴奋，但随着时间发展，会觉得做这件事情没有任何壁垒，任何人都可以口喷出做软件，我在其中到底负责什么？又学到了什么呢？
迷茫涌上心头，到后来我了解到 web coding 时代，我更需要要做的是提出需求、提出框架和最后的代码审核，而我们要学习的就是如何设计规范，也就是SDD开发。

1. Vibe Coding 是什么？

Vibe Coding 是 Andrej Karpathy 在 2025 年提出的概念，常被译为“氛围编程”。它是一种以自然语言与 AI 编程工具交互、由 AI 协助生成和修改代码的开发方式。

2. Vibe Coding 的特征

• 交互随意：开发者可以用较口语化、非结构化的自然语言表达需求
• 交互性强：开发过程以多轮对话与持续调整为主
• 即时反馈：AI 可以快速生成、修改和解释代码，缩短试错周期

3. Vibe Coding 带来的系统性问题

3.1 需求蒸发

决策已做出，但没有留下任何痕迹。
在大型项目中，需求和决策分散在各地，可能随着某个对话窗口结束而消失，无法持续沉淀为团队可复用、可追溯的依据。

3.2 上下文漂移

单次对话可承载的上下文有限。早期提出的核心要求可能在上下文压缩或切换后被忽略，进而造成后续实现缺失或偏离，

3.3 不可审计

如果缺少明确的需求、架构和决策记录，就难以判断系统设计是否合理、可靠，也难以追溯关键决策的依据。

3.4 不可复现

当设计思路只存在于对话中，后来者很难理解“为什么这样设计”；发生 Bug 时，也难以快速定位问题来源。

3.5 不可维护

代码可能在多轮生成与修改后逐渐堆叠，缺少清晰的模块边界和文档支撑，最终没人敢改、也没人能改。

4. 三次范式迁移

软件开发方法论可粗略分为三类：

1. 瀑布式开发
2. 敏捷开发
3. SDD 开发

4.1 瀑布式开发：重规范，弱变化

瀑布式开发在编码前就依次完成需求分析、架构设计和代码实现等工作；通常只有完成上一步，才能进入下一步。

它的问题在于：一旦客户需求发生变化，前面的工作往往需要重新调整，响应变化的效率较低。

4.2 敏捷开发：轻规范，适应变化

敏捷开发强调“可工作的软件胜过详尽的文档”。项目初期的需求可以不完全明确，并通过短周期迭代持续校正方向。

但它也可能带来问题：需求文档被弱化甚至缺失。过去，团队成员可以依靠共同的项目上下文弥补这一缺口；而在 AI 深度参与开发后，这种依赖会被放大为风险。

4.3 SDD 开发：有规范，也能适应变化

SDD（Spec-Driven Development，规格驱动开发）把规格置于核心位置，代码是规格的派生工件。

它不是回到瀑布模型，而是试图弥补敏捷开发中规范沉淀不足的问题：在保持迭代能力的同时，用持续更新的规格文件保存项目上下文和关键约束。

5. SDD 开发流程

SDD 开发可以分为两层：

5.1 框架层

• 需求分析：
• 架构设计：
• 接口设计：
• 任务拆解：

5.2 代码层

• AI 生成代码：
• AI 检验代码：

6. 三代软件开发方法论的差异

软件开发方法论	核心假设	第一手工件	代码的角色	迭代方式	文档态度	代码生产者	适合场景
瀑布模型（1970 年）	需求可以预先确定	文档（规格说明书）	文档的实现	不迭代，一次到位	重度文档，动辄百页	人类开发者	需求极其稳定的系统
敏捷开发（2001 年）	需求会变，拥抱变化	代码（可工作的软件）	唯一真相来源	2 周一个 Sprint	轻文档，“够用就好”	人类开发者	人类团队的软件开发
SDD 模式（2025 年）	需求会变，但变化应被规范化记录	规格（proposal.md、design.md 和 tasks.md）	规格的衍生物	规格先行，代码跟进；规格和代码同步迭代	结构化规范——不重不轻，恰好够 AI 执行	AI Agent（在规格约束下）	人机协作的 AI 辅助开发

一句话总结：Vibe Coding 解决了“快速写代码”的问题；SDD 则试图解决“如何让 AI 在复杂项目中持续、可靠地写代码”的问题。