1.4.3 如何选择和切换
核心决策标准
关键不是项目大小，而是需求明确度。
- 需求模糊 → Vibe Coding（通过对话澄清）
- 需求明确 → Spec Coding（按规范执行）
需求明确度判断框架
1. 需求清晰度（权重最高）
需求模糊的信号：
- 只有大方向，细节不确定
- "我觉得用户可能需要..."
- "大概做个类似XX但又有区别的东西"
- 需要看到实际效果才能确定下一步
需求明确的信号：
- 能说出具体的用户场景
- 知道每个功能的输入输出
- 有明确的成功标准
- 可以列出不做哪些功能
2. 项目复杂度
简单项目（Vibe 倾向）：
- 核心功能在3个以内
- 主要是给自己或少数人使用
- 不需要长期维护
复杂项目（Spec 倾向）：
- 功能相互关联，改一个影响其他
- 需要多人协作
- 用户基数大，稳定性要求高
3. 团队因素
适合 Vibe：
- 个人项目
- 临时项目
- 探索性项目
适合 Spec：
- 团队协作
- 需要工作交接
- 有明确的交付时间表
动态切换策略
从 Vibe 到 Spec
切换信号：
- 开始出现重复性需求
- 需要其他人理解项目
- 对话变得很长，AI 开始忘记
- 项目有了真实的用户
切换方法：
- 暂停新功能开发
- 回顾对话记录，总结现有功能
- 写下简单的需求文档
- 后续按规范执行
从 Spec 到 Vibe
切换信号：
- 需求发生重大变化
- 需要探索新的技术方案
- 现有规范限制了创新
切换方法：
- 明确探索的目标和边界
- 设定探索时间限制
- 探索完成后及时整理成果
混合使用模式
Vibe + Spec 并行
适用场景：大部分实际项目
操作方法：
- 整体架构用 Spec
- 具体功能实现用 Vibe
- 接口定义用 Spec
- UI 细节用 Vibe
分阶段使用
探索阶段：Vibe Coding
- 快速验证想法可行性
- 找到真正的用户需求
- 测试技术方案
开发阶段：Spec Coding
- 稳定的功能迭代
- 团队协作开发
- 质量控制
调整阶段：Vibe Coding
- 重大功能变更
- 技术方案升级
- 用户反馈驱动的改进
实际决策示例
示例1：个人记账工具
初始分析：
- 需求模糊：不清楚具体要哪些功能
- 复杂度低：应该比较简单
- 团队因素：个人使用
决策：Vibe Coding
执行过程：
- 先做基础记账功能
- 使用中发现需要统计分析 → 继续用 Vibe 添加
- 功能变多，开始混乱 → 切换到 Spec，整理现有功能
- 后续稳定迭代 → 保持 Spec
示例2：团队任务管理工具
初始分析：
- 需求明确：清楚要做什么功能
- 复杂度高：多个模块相互关联
- 团队因素：5人团队
决策：直接 Spec Coding
特殊情况：
- 探索新功能（如图表展示）→ 用 Vibe 快速试验
- 确定要保留的功能 → 补充到 Spec 文档中
示例3：创业项目验证
初始分析：
- 需求极模糊：不确定市场反应
- 复杂度未知：看用户反馈
- 团队因素：创始团队
决策：Vibe Coding 开始
演进路径：
- MVP 用 Vibe 快速开发
- 有用户反馈 → 整理需求文档
- 团队扩大 → 全面转向 Spec
- 产品稳定 → Spec 为主，Vibe 用于创新
选择建议
不要过度思考
如果纠结超过5分钟，就用 Vibe 开始。错误的开始比完美的规划更有价值。
定期重新评估
每完成一个重要阶段，重新评估是否需要调整方法。
保持灵活性
没有绝对的正确方法，适合当前阶段的才是最好的。
记住：Vibe 和 Spec 不是非此即彼，而是工具箱里的不同工具，在合适的时候使用合适的工具。
下一节我们学习 Context 管理技巧。