025年，AI编程工具全面爆发。Cursor、Claude Code、GitHub Copilot、Windsurf……开发者们从未如此"高产"——一个曾经需要两周的登录模块，现在两小时就能跑起来。
但与此同时，另一种声音也开始出现：
“AI写的代码，看是能看，但改起来真费劲。”
“跑了两周，突然发现整个架构方向都是歪的。”
“功能实现了，但边界条件全没考虑。”
这两种声音，恰好对应了当前AI编程的两种范式：Vibe Coding 和 Spec Driven Development（规格驱动开发）。
前者追求速度与直觉，后者追求严谨与可维护性。它们不是非此即彼的对立关系，而是AI编程光谱的两端。理解它们各自的定位，学会让它们协同工作，是每个AI时代的开发者都必须掌握的技能。
二、Vibe Coding：编程的"自由式"
2.1 什么是 Vibe Coding？
"Vibe Coding"这个词由前特斯拉AI总监、OpenAI联合创始人Andrej Karpathy提出。他的原话是：
“The hottest new programming language is English.”
换成中文也一样——最热门的编程语言，是自然语言本身。
在实际操作中，Vibe Coding的工作流是这样的：
不满意
满意
💡 灵感/想法
✍️ 写一句Prompt
🤖 AI生成代码
😃 满意吗？
🔧 调整Prompt
✅ 交付
整个过程就像一场对话：你描述想法，AI给你结果，你来来回回调整，直到差不多能用。
2.2 Vibe Coding 的魔力
为什么Vibe Coding让开发者如此"上头"？
极低的启动门槛。不需要写详细的设计文档，想到什么说什么，AI立刻给你反馈。这种感觉就像画画时先用铅笔打草稿——快速、自由、不设限。
探索效率极高。当你想验证一个想法、测试一个API、或者快速搭建一个Demo时，Vibe Coding是最佳选择。传统方式需要先设计、再编码、再调试；Vibe Coding可以让你在30分钟内看到可运行的原型。
创造力解放。因为你不用纠结于实现细节，所以可以把更多精力花在"想要什么"而不是"怎么做"上。这种体验特别适合前端页面、工具脚本、数据分析等探索性工作。
2.3 Vibe Coding 的暗面
然而，Vibe Coding的自由是有代价的，而这个代价会随项目规模呈指数级增长：
问题 表现
模糊性累积 “做个登录功能”——AI默认选了最简单的实现，而你忘了说要支持验证码
边界条件缺失 能跑通Happy Path，但错误处理、限流、降级策略一概没有
架构一致性差 每次对话都是独立的，AI不知道你项目的整体架构约束
可维护性黑洞 代码"能用"，但重构成本极高——因为没有人真正理解全部逻辑
幻觉放大 AI擅自在代码里"加戏"，引入你从未要求的功能或依赖
Karpathy本人也承认这一点。他在提出Vibe Coding的同时，也调侃说自己在Vibe Coding时经常"全盘接受AI的建议"，因为"懒得去深究"。
问题不在于模型不够强大。问题在于，我们是在凭感觉进行开发。
因此Vibe Coding也可以称之为意识流编程。
三、SDD：编程的"规范派"
3.1 什么是 SDD？
Spec Driven Development（规格驱动开发）并不是一个新概念。它的思想根源可以追溯到：
契约式设计（Design by Contract）：Bertrand Meyer在1986年提出的概念，强调软件模块之间应该通过明确的"契约"来交互
行为驱动开发（BDD）：用自然语言描述系统行为，然后驱动开发
测试驱动开发（TDD）：先写测试，再写代码
SDD的核心思想很简单：在写代码之前，先用结构化的规格说明（Spec）定义清楚"系统应该做什么"。
这听起来像是回到了瀑布模型的"需求文档先行"，但实际上完全不同——SDD的规格说明是活的，它直接驱动AI生成代码、测试、文档，并且随项目演进持续迭代。
3.2 SDD 的工作流
不清晰
清晰
📋 编写Spec文件
🤖 AI评审Spec
🔍 Spec是否清晰？
👤 人工修正Spec
🧪 根据Spec生成测试
💻 根据Spec生成代码
📊 根据Spec验证结果
📖 Spec即为文档
与Vibe Coding的关键区别在于：你不再只是"描述想法"，而是在"定义行为与约束"。
3.3 一份好的 Spec 长什么样？
SDD的Spec可以用Markdown文件来写，清晰、可版本控制、可直接喂给AI。来看一个例子：
任务：用户认证功能
API 定义
- 端点：
POST /api/user/login - 输入格式：JSON
- 输出格式：JSON
行为规约
- 输入：用户名（支持手机号/邮箱/普通用户名）+ 密码
- 连续登录失败 ≥ 3 次时，额外要求4位图形验证码
- 登录成功返回 200，响应体包含：
- access_token（JWT，有效期2小时）
- refresh_token（UUID，有效期14天）
- user_id、角色列表、scope
- 认证失败返回 401，响应体包含错误码和错误描述
安全约束
- 同一IP每分钟限流10次
- 连续10次失败后锁定账户：
- 首次锁定15分钟，每次递增15分钟，上限12小时
- 密码存储使用 bcrypt（cost=12）
可观测性
- 记录登录日志：请求时间、IP、User-Agent、来源（APP/Web）
- 暴露 Prometheus 指标：login_total、login_failure_total、login_latency
技术栈
- 语言：Python 3.12+
- 框架：FastAPI
- 数据库：PostgreSQL
- 缓存：Redis
注意：这份Spec里，没有一行代码，但定义了一切。AI拿到它之后，可以：
生成符合约定的API实现
生成对应的单元测试和集成测试
生成API文档
在重构时验证行为一致性
四、正面交锋：Vibe Coding vs SDD 全方位对比
4.1 核心差异一览
维度 Vibe Coding SDD（规格驱动开发）
思考方式 反应式：边做边想 结构式：先想再做
输入 自然语言Prompt 结构化Spec（Markdown/YAML/JSON）
驱动因素 直觉 & 对话反馈 行为规约 & 约束条件
AI的角色 主力编码者 协作执行者
人的角色 提示词工程师 产品经理 + 架构师
文档 事后补救（大概率没有） Spec即文档
测试 手动验证为主 Spec驱动自动生成
可追溯性 弱（谁知道AI为什么这么写） 强（Spec是唯一可信来源）
4.2 一个具体案例的对比
假设需求是：“构建一个商品推荐API”。
Vibe Coding 的做法
你：用嵌入向量构建一个推荐API
AI：好的，这是代码…
你：加上分页
AI：已添加…
你：排除同品牌商品
AI：已排除…
你：好像没做超时处理？
AI：抱歉，我来加上…
结果：功能"能用"，但你很可能漏掉了：
相似度阈值（推荐了完全不相关的商品怎么办？）
冷启动策略（新商品没有嵌入向量怎么办？）
降级方案（向量搜索服务挂了怎么办？）
评估机制（你怎么知道推荐效果好还是差？）
SDD 的做法
在写一行代码之前，先定义：
推荐API行为规约
输入
- product_id: string（必填）
处理流程
- 根据 product_id 从向量库检索嵌入向量
- 执行余弦相似度搜索
- 过滤规则：
- 排除同品牌（brand_id 相同）
- 相似度阈值 < 0.82 的视为不相关
- 排除已下架商品
- 结果排序：相似度降序
- 限制返回 top 10
降级策略
- 向量库不可用时 → 回退到基于标签的规则推荐
- 匹配结果 < 3 时 → 自动回退到热门商品推荐
性能要求
- P99延迟 < 200ms
- 需要 Redis 缓存（TTL: 30分钟）
可观测性
- 记录每次推荐请求的延迟和相似度分布
- 提供离线评估脚本（基于标注数据集）
拿到这份Spec，AI可以一次性生成：
完整的推荐服务实现
单元测试（覆盖正常流程、降级策略、边界条件）
评估脚本
监控面板配置
4.3 适用场景矩阵
场景 推荐范式 原因
快速原型/ Hackathon Vibe Coding 速度优先，明天就可能扔掉
个人工具脚本 Vibe Coding 你一个人用，知道所有隐式假设
探索性数据分析 Vibe Coding 需求在不断变化，Spec跟不上
前端UI快速迭代 Vibe Coding 肉眼可见，调就完了
生产级后端API SDD 边界条件多，出问题影响大
多服务协作系统 SDD 契约不清晰 = 下游全崩
金融/医疗等合规系统 SDD 可审计性是不可妥协的
多人协作的大型项目 SDD Spec是团队的共同语言
需要长期维护的核心模块 SDD 代码会换人，Spec会留下
五、最佳实践：如何让两者协同工作？
这才是本文最重要的部分。 Vibe Coding和SDD不是二选一，而是可以根据项目阶段交替使用。以下是我在实践中总结的组合策略。
5.1 三阶段混合工作流
阶段三：Spec 驱动实施
阶段二：Spec 固化
阶段一：Vibe 探索
不对
对了
💡 模糊想法
🤖 Vibe Coding快速出原型
👀 体验 & 验证可行性
🤔 方向对吗？
📝 沉淀为Spec草稿
📋 完善Spec
🤖 AI评审Spec
🔧 补充边界条件
👥 团队Review
✅ Spec定稿
🧪 生成测试
💻 生成实现
📊 验证 & 部署
🔄 迭代更新Spec