最佳实践：如何让两者协同工作？

这才是本文最重要的部分。 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，让它指出模糊之处
团队Review：Spec是团队的共同语言，必须达成共识
特别关注边界条件：错误处理、降级策略、性能约束、安全要求
产出物：一份经过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
影响大 → SDD
5.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评审
代码提交 → 自动检查是否符合Spec
Spec文件成为Code Review的必备输入
关键原则
Spec是"唯一可信来源"。任何时候，Spec和代码有冲突，先对齐Spec。
先Spec后代码。需求变更时，先改Spec，再让AI重新生成。
Vibe探索，Spec交付。用Vibe Coding找到方向，用SDD确保质量。
不做过度规约。Spec定义行为边界，不是替代AI思考。
七、结语
回到文章开头的问题：当代码可以像聊天一样生成，我们还需要规格说明吗？

需要，比以往任何时候都需要。