一、两种范式的碰撞2025年AI编程工具全面爆发。Cursor、Claude Code、GitHub Copilot、Windsurf……开发者们从未如此高产——一个曾经需要两周的登录模块现在两小时就能跑起来。但与此同时另一种声音也开始出现AI写的代码看是能看但改起来真费劲。跑了两周突然发现整个架构方向都是歪的。功能实现了但边界条件全没考虑。这两种声音恰好对应了当前AI编程的两种范式Vibe Coding和Spec Driven Development规格驱动开发。前者追求速度与直觉后者追求严谨与可维护性。它们不是非此即彼的对立关系而是AI编程光谱的两端。理解它们各自的定位学会让它们协同工作是每个AI时代的开发者都必须掌握的技能。二、Vibe Coding编程的自由式2.1 什么是 Vibe CodingVibe 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 什么是 SDDSpec Driven Development规格驱动开发并不是一个新概念。它的思想根源可以追溯到契约式设计Design by ContractBertrand 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 ### 行为规约 1. 输入用户名支持手机号/邮箱/普通用户名 密码 2. 连续登录失败 ≥ 3 次时额外要求4位图形验证码 3. 登录成功返回 200响应体包含 - access_tokenJWT有效期2小时 - refresh_tokenUUID有效期14天 - user_id、角色列表、scope 4. 认证失败返回 401响应体包含错误码和错误描述 ### 安全约束 - 同一IP每分钟限流10次 - 连续10次失败后锁定账户 - 首次锁定15分钟每次递增15分钟上限12小时 - 密码存储使用 bcryptcost12 ### 可观测性 - 记录登录日志请求时间、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 CodingSDD规格驱动开发思考方式反应式边做边想结构式先想再做输入自然语言Prompt结构化SpecMarkdown/YAML/JSON驱动因素直觉 对话反馈行为规约 约束条件AI的角色主力编码者协作执行者人的角色提示词工程师产品经理 架构师文档事后补救大概率没有Spec即文档测试手动验证为主Spec驱动自动生成可追溯性弱谁知道AI为什么这么写强Spec是唯一可信来源4.2 一个具体案例的对比假设需求是构建一个商品推荐API。Vibe Coding 的做法你用嵌入向量构建一个推荐API AI好的这是代码... 你加上分页 AI已添加... 你排除同品牌商品 AI已排除... 你好像没做超时处理 AI抱歉我来加上...结果功能能用但你很可能漏掉了相似度阈值推荐了完全不相关的商品怎么办冷启动策略新商品没有嵌入向量怎么办降级方案向量搜索服务挂了怎么办评估机制你怎么知道推荐效果好还是差SDD 的做法在写一行代码之前先定义## 推荐API行为规约 ### 输入 - product_id: string必填 ### 处理流程 1. 根据 product_id 从向量库检索嵌入向量 2. 执行余弦相似度搜索 3. 过滤规则 - 排除同品牌brand_id 相同 - 相似度阈值 0.82 的视为不相关 - 排除已下架商品 4. 结果排序相似度降序 5. 限制返回 top 10 ### 降级策略 - 向量库不可用时 → 回退到基于标签的规则推荐 - 匹配结果 3 时 → 自动回退到热门商品推荐 ### 性能要求 - P99延迟 200ms - 需要 Redis 缓存TTL: 30分钟 ### 可观测性 - 记录每次推荐请求的延迟和相似度分布 - 提供离线评估脚本基于标注数据集拿到这份SpecAI可以一次性生成完整的推荐服务实现单元测试覆盖正常流程、降级策略、边界条件评估脚本监控面板配置4.3 适用场景矩阵场景推荐范式原因快速原型/ HackathonVibe Coding速度优先明天就可能扔掉个人工具脚本Vibe Coding你一个人用知道所有隐式假设探索性数据分析Vibe Coding需求在不断变化Spec跟不上前端UI快速迭代Vibe Coding肉眼可见调就完了生产级后端APISDD边界条件多出问题影响大多服务协作系统SDD契约不清晰 下游全崩金融/医疗等合规系统SDD可审计性是不可妥协的多人协作的大型项目SDDSpec是团队的共同语言需要长期维护的核心模块SDD代码会换人Spec会留下五、最佳实践如何让两者协同工作这才是本文最重要的部分。Vibe Coding和SDD不是二选一而是可以根据项目阶段交替使用。以下是我在实践中总结的组合策略。5.1 三阶段混合工作流阶段三Spec 驱动实施阶段二Spec 固化阶段一Vibe 探索不对对了 模糊想法 Vibe Coding快速出原型 体验 验证可行性 方向对吗 沉淀为Spec草稿 完善Spec AI评审Spec 补充边界条件 团队Review✅ Spec定稿 生成测试 生成实现 验证 部署 迭代更新Spec阶段一Vibe 探索快速试错这个阶段的目标是验证想法的可行性不是写出完美代码。用Vibe Coding快速搭建MVP大胆尝试不同的技术路线不要纠结代码质量——这段代码大概率会被重写把重点放在这样做的用户体验对吗而不是代码写得优雅吗产出物一个能跑的原型 对需求的初步理解阶段二Spec 固化沉淀共识一旦确认方向正确立刻刹车转入Spec模式。把探索阶段积累的理解整理成结构化的Spec让AI帮你Review把Spec发给AI让它指出模糊之处团队ReviewSpec是团队的共同语言必须达成共识特别关注边界条件错误处理、降级策略、性能约束、安全要求产出物一份经过Review的Spec文件建议放在项目仓库的/specs/目录下阶段三Spec 驱动实施严谨交付先让AI根据Spec生成测试用例TDD SDD的组合拳再让AI生成实现代码用Spec验证产出跑测试、做Code Review、对照Spec逐条检查随着需求变化先更新Spec再更新代码——保持Spec永远是唯一可信来源产出物可交付的代码 测试 文档Spec本身就是文档5.2 Vibe中写Spec——反向操作另一个非常实用的技巧是用Vibe Coding的方式来帮你写Spec。比如你想做一个支付模块自己不确定要考虑哪些边界条件直接把需求丢给AI你我准备做一个支付模块的Spec帮我brainstorm一下需要考虑哪些方面特别是容易遗漏的边界条件 AI列出几十个要点包括幂等性、回调重试、分布式事务、对账、退款流程…… 你很好基于这些帮我生成一份初始Spec草稿。Vibe Coding负责发散SDD负责收敛。这个组合非常强大。5.3 按模块粒度灵活切换不是整个项目只能选择一种范式。同一个项目里可以按模块粒度灵活切换项目/ ├── specs/ │ ├── user-auth.spec.md ← SDD安全敏感边界条件多 │ ├── payment.spec.md ← SDD金融合规不能出错 │ └── recommendation.spec.md ← SDD算法行为需要精确控制 ├── src/ │ ├── admin-dashboard/ ← Vibe Coding内部工具快速迭代 │ ├── analytics-reports/ ← Vibe Coding探索性需求频繁变化 │ └── landing-page/ ← Vibe Coding营销页面视觉驱动判断标准问自己如果这个模块出bug影响有多大影响小 → Vibe Coding影响大 → SDD5.4 Spec 的恰到好处原则SDD最大的陷阱是过度规约Over-Specification。记住Spec不是写作文不需要面面俱到。它只需要定义做什么和不做什么的边界。好的Spec像篱笆划定边界而非规划每一寸土地。Spec层级包含内容示例必须API契约、数据模型、安全约束、降级策略同一IP每分钟限流10次建议推荐的技术方案、性能目标P99 200ms缓存TTL 30分钟避免具体实现细节、类结构、内部算法使用工厂模式创建PaymentProcessor当发现自己在Spec里写请使用XXX设计模式时停笔。那是AI该操心的事情。六、给团队的实践路线图如果你所在的团队正在引入AI编程以下是一个循序渐进的路线图第一步从Vibe Coding开始第1-2周让团队成员先用Vibe Coding的方式感受AI编程的魅力。建立对AI能力的直觉什么它能做好什么它容易搞砸。第二步引入轻量Spec第3-4周选一个中等复杂度的模块尝试写一份Spec再让AI实现。对比一下Vibe Coding的产出和SDD的产出让团队自己感受到差异。第三步建立Spec模板与规范第5-8周沉淀团队的Spec模板明确什么该写、什么不该写。把Spec文件纳入代码仓库和代码一起做版本管理。第四步将Spec融入CI/CD第9周起Spec变更 → 自动触发AI评审代码提交 → 自动检查是否符合SpecSpec文件成为Code Review的必备输入关键原则Spec是唯一可信来源。任何时候Spec和代码有冲突先对齐Spec。先Spec后代码。需求变更时先改Spec再让AI重新生成。Vibe探索Spec交付。用Vibe Coding找到方向用SDD确保质量。不做过度规约。Spec定义行为边界不是替代AI思考。七、结语回到文章开头的问题当代码可以像聊天一样生成我们还需要规格说明吗需要比以往任何时候都需要。不是因为代码质量下降了——AI生成的代码在语法层面几乎不会出错。而是因为
一、两种范式的碰撞2025年AI编程工具全面爆发。Cursor、Claude Code、GitHub Copilot、Windsurf……开发者们从未如此高产——一个曾经需要两周的登录模块现在两小时就能跑起来。但与此同时另一种声音也开始出现AI写的代码看是能看但改起来真费劲。跑了两周突然发现整个架构方向都是歪的。功能实现了但边界条件全没考虑。这两种声音恰好对应了当前AI编程的两种范式Vibe Coding和Spec Driven Development规格驱动开发。前者追求速度与直觉后者追求严谨与可维护性。它们不是非此即彼的对立关系而是AI编程光谱的两端。理解它们各自的定位学会让它们协同工作是每个AI时代的开发者都必须掌握的技能。二、Vibe Coding编程的自由式2.1 什么是 Vibe CodingVibe 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 什么是 SDDSpec Driven Development规格驱动开发并不是一个新概念。它的思想根源可以追溯到契约式设计Design by ContractBertrand 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 ### 行为规约 1. 输入用户名支持手机号/邮箱/普通用户名 密码 2. 连续登录失败 ≥ 3 次时额外要求4位图形验证码 3. 登录成功返回 200响应体包含 - access_tokenJWT有效期2小时 - refresh_tokenUUID有效期14天 - user_id、角色列表、scope 4. 认证失败返回 401响应体包含错误码和错误描述 ### 安全约束 - 同一IP每分钟限流10次 - 连续10次失败后锁定账户 - 首次锁定15分钟每次递增15分钟上限12小时 - 密码存储使用 bcryptcost12 ### 可观测性 - 记录登录日志请求时间、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 CodingSDD规格驱动开发思考方式反应式边做边想结构式先想再做输入自然语言Prompt结构化SpecMarkdown/YAML/JSON驱动因素直觉 对话反馈行为规约 约束条件AI的角色主力编码者协作执行者人的角色提示词工程师产品经理 架构师文档事后补救大概率没有Spec即文档测试手动验证为主Spec驱动自动生成可追溯性弱谁知道AI为什么这么写强Spec是唯一可信来源4.2 一个具体案例的对比假设需求是构建一个商品推荐API。Vibe Coding 的做法你用嵌入向量构建一个推荐API AI好的这是代码... 你加上分页 AI已添加... 你排除同品牌商品 AI已排除... 你好像没做超时处理 AI抱歉我来加上...结果功能能用但你很可能漏掉了相似度阈值推荐了完全不相关的商品怎么办冷启动策略新商品没有嵌入向量怎么办降级方案向量搜索服务挂了怎么办评估机制你怎么知道推荐效果好还是差SDD 的做法在写一行代码之前先定义## 推荐API行为规约 ### 输入 - product_id: string必填 ### 处理流程 1. 根据 product_id 从向量库检索嵌入向量 2. 执行余弦相似度搜索 3. 过滤规则 - 排除同品牌brand_id 相同 - 相似度阈值 0.82 的视为不相关 - 排除已下架商品 4. 结果排序相似度降序 5. 限制返回 top 10 ### 降级策略 - 向量库不可用时 → 回退到基于标签的规则推荐 - 匹配结果 3 时 → 自动回退到热门商品推荐 ### 性能要求 - P99延迟 200ms - 需要 Redis 缓存TTL: 30分钟 ### 可观测性 - 记录每次推荐请求的延迟和相似度分布 - 提供离线评估脚本基于标注数据集拿到这份SpecAI可以一次性生成完整的推荐服务实现单元测试覆盖正常流程、降级策略、边界条件评估脚本监控面板配置4.3 适用场景矩阵场景推荐范式原因快速原型/ HackathonVibe Coding速度优先明天就可能扔掉个人工具脚本Vibe Coding你一个人用知道所有隐式假设探索性数据分析Vibe Coding需求在不断变化Spec跟不上前端UI快速迭代Vibe Coding肉眼可见调就完了生产级后端APISDD边界条件多出问题影响大多服务协作系统SDD契约不清晰 下游全崩金融/医疗等合规系统SDD可审计性是不可妥协的多人协作的大型项目SDDSpec是团队的共同语言需要长期维护的核心模块SDD代码会换人Spec会留下五、最佳实践如何让两者协同工作这才是本文最重要的部分。Vibe Coding和SDD不是二选一而是可以根据项目阶段交替使用。以下是我在实践中总结的组合策略。5.1 三阶段混合工作流阶段三Spec 驱动实施阶段二Spec 固化阶段一Vibe 探索不对对了 模糊想法 Vibe Coding快速出原型 体验 验证可行性 方向对吗 沉淀为Spec草稿 完善Spec AI评审Spec 补充边界条件 团队Review✅ Spec定稿 生成测试 生成实现 验证 部署 迭代更新Spec阶段一Vibe 探索快速试错这个阶段的目标是验证想法的可行性不是写出完美代码。用Vibe Coding快速搭建MVP大胆尝试不同的技术路线不要纠结代码质量——这段代码大概率会被重写把重点放在这样做的用户体验对吗而不是代码写得优雅吗产出物一个能跑的原型 对需求的初步理解阶段二Spec 固化沉淀共识一旦确认方向正确立刻刹车转入Spec模式。把探索阶段积累的理解整理成结构化的Spec让AI帮你Review把Spec发给AI让它指出模糊之处团队ReviewSpec是团队的共同语言必须达成共识特别关注边界条件错误处理、降级策略、性能约束、安全要求产出物一份经过Review的Spec文件建议放在项目仓库的/specs/目录下阶段三Spec 驱动实施严谨交付先让AI根据Spec生成测试用例TDD SDD的组合拳再让AI生成实现代码用Spec验证产出跑测试、做Code Review、对照Spec逐条检查随着需求变化先更新Spec再更新代码——保持Spec永远是唯一可信来源产出物可交付的代码 测试 文档Spec本身就是文档5.2 Vibe中写Spec——反向操作另一个非常实用的技巧是用Vibe Coding的方式来帮你写Spec。比如你想做一个支付模块自己不确定要考虑哪些边界条件直接把需求丢给AI你我准备做一个支付模块的Spec帮我brainstorm一下需要考虑哪些方面特别是容易遗漏的边界条件 AI列出几十个要点包括幂等性、回调重试、分布式事务、对账、退款流程…… 你很好基于这些帮我生成一份初始Spec草稿。Vibe Coding负责发散SDD负责收敛。这个组合非常强大。5.3 按模块粒度灵活切换不是整个项目只能选择一种范式。同一个项目里可以按模块粒度灵活切换项目/ ├── specs/ │ ├── user-auth.spec.md ← SDD安全敏感边界条件多 │ ├── payment.spec.md ← SDD金融合规不能出错 │ └── recommendation.spec.md ← SDD算法行为需要精确控制 ├── src/ │ ├── admin-dashboard/ ← Vibe Coding内部工具快速迭代 │ ├── analytics-reports/ ← Vibe Coding探索性需求频繁变化 │ └── landing-page/ ← Vibe Coding营销页面视觉驱动判断标准问自己如果这个模块出bug影响有多大影响小 → Vibe Coding影响大 → SDD5.4 Spec 的恰到好处原则SDD最大的陷阱是过度规约Over-Specification。记住Spec不是写作文不需要面面俱到。它只需要定义做什么和不做什么的边界。好的Spec像篱笆划定边界而非规划每一寸土地。Spec层级包含内容示例必须API契约、数据模型、安全约束、降级策略同一IP每分钟限流10次建议推荐的技术方案、性能目标P99 200ms缓存TTL 30分钟避免具体实现细节、类结构、内部算法使用工厂模式创建PaymentProcessor当发现自己在Spec里写请使用XXX设计模式时停笔。那是AI该操心的事情。六、给团队的实践路线图如果你所在的团队正在引入AI编程以下是一个循序渐进的路线图第一步从Vibe Coding开始第1-2周让团队成员先用Vibe Coding的方式感受AI编程的魅力。建立对AI能力的直觉什么它能做好什么它容易搞砸。第二步引入轻量Spec第3-4周选一个中等复杂度的模块尝试写一份Spec再让AI实现。对比一下Vibe Coding的产出和SDD的产出让团队自己感受到差异。第三步建立Spec模板与规范第5-8周沉淀团队的Spec模板明确什么该写、什么不该写。把Spec文件纳入代码仓库和代码一起做版本管理。第四步将Spec融入CI/CD第9周起Spec变更 → 自动触发AI评审代码提交 → 自动检查是否符合SpecSpec文件成为Code Review的必备输入关键原则Spec是唯一可信来源。任何时候Spec和代码有冲突先对齐Spec。先Spec后代码。需求变更时先改Spec再让AI重新生成。Vibe探索Spec交付。用Vibe Coding找到方向用SDD确保质量。不做过度规约。Spec定义行为边界不是替代AI思考。七、结语回到文章开头的问题当代码可以像聊天一样生成我们还需要规格说明吗需要比以往任何时候都需要。不是因为代码质量下降了——AI生成的代码在语法层面几乎不会出错。而是因为
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
