---
title: "1.4.3 如何选择和切换"
---


![01-awakening_1.4-vibe-vs-spec_1.4.3-vibe-vs-spec.png](/images/Basic/01-awakening_1.4-vibe-vs-spec_1.4.3-vibe-vs-spec.png)
# 1.4.3 如何选择和切换

## 核心决策标准

**关键不是项目大小，而是需求明确度。**

- **需求模糊** → Vibe Coding（通过对话澄清）
- **需求明确** → Spec Coding（按规范执行）

## 需求明确度判断框架

### 1. 需求清晰度（权重最高）

**需求模糊的信号：**
- 只有大方向，细节不确定
- "我觉得用户可能需要..."
- "大概做个类似XX但又有区别的东西"
- 需要看到实际效果才能确定下一步

**需求明确的信号：**
- 能说出具体的用户场景
- 知道每个功能的输入输出
- 有明确的成功标准
- 可以列出不做哪些功能

### 2. 项目复杂度

**简单项目（Vibe 倾向）：**
- 核心功能在3个以内
- 主要是给自己或少数人使用
- 不需要长期维护

**复杂项目（Spec 倾向）：**
- 功能相互关联，改一个影响其他
- 需要多人协作
- 用户基数大，稳定性要求高

### 3. 团队因素

**适合 Vibe：**
- 个人项目
- 临时项目
- 探索性项目

**适合 Spec：**
- 团队协作
- 需要工作交接
- 有明确的交付时间表

## 动态切换策略

### 从 Vibe 到 Spec

**切换信号：**
- 开始出现重复性需求
- 需要其他人理解项目
- 对话变得很长，AI 开始忘记
- 项目有了真实的用户

**切换方法：**
1. 暂停新功能开发
2. 回顾对话记录，总结现有功能
3. 写下简单的需求文档
4. 后续按规范执行

### 从 Spec 到 Vibe

**切换信号：**
- 需求发生重大变化
- 需要探索新的技术方案
- 现有规范限制了创新

**切换方法：**
1. 明确探索的目标和边界
2. 设定探索时间限制
3. 探索完成后及时整理成果

## 混合使用模式

### Vibe + Spec 并行

**适用场景**：大部分实际项目

**操作方法：**
- 整体架构用 Spec
- 具体功能实现用 Vibe
- 接口定义用 Spec
- UI 细节用 Vibe

### 分阶段使用

**探索阶段**：Vibe Coding
- 快速验证想法可行性
- 找到真正的用户需求
- 测试技术方案

**开发阶段**：Spec Coding
- 稳定的功能迭代
- 团队协作开发
- 质量控制

**调整阶段**：Vibe Coding
- 重大功能变更
- 技术方案升级
- 用户反馈驱动的改进

## 实际决策示例

### 示例1：个人记账工具

**初始分析：**
- 需求模糊：不清楚具体要哪些功能
- 复杂度低：应该比较简单
- 团队因素：个人使用

**决策：Vibe Coding**

**执行过程：**
1. 先做基础记账功能
2. 使用中发现需要统计分析 → 继续用 Vibe 添加
3. 功能变多，开始混乱 → 切换到 Spec，整理现有功能
4. 后续稳定迭代 → 保持 Spec

### 示例2：团队任务管理工具

**初始分析：**
- 需求明确：清楚要做什么功能
- 复杂度高：多个模块相互关联
- 团队因素：5人团队

**决策：直接 Spec Coding**

**特殊情况：**
- 探索新功能（如图表展示）→ 用 Vibe 快速试验
- 确定要保留的功能 → 补充到 Spec 文档中

### 示例3：创业项目验证

**初始分析：**
- 需求极模糊：不确定市场反应
- 复杂度未知：看用户反馈
- 团队因素：创始团队

**决策：Vibe Coding 开始**

**演进路径：**
1. MVP 用 Vibe 快速开发
2. 有用户反馈 → 整理需求文档
3. 团队扩大 → 全面转向 Spec
4. 产品稳定 → Spec 为主，Vibe 用于创新

## 选择建议

### 不要过度思考

如果纠结超过5分钟，就用 Vibe 开始。错误的开始比完美的规划更有价值。

### 定期重新评估

每完成一个重要阶段，重新评估是否需要调整方法。

### 保持灵活性

没有绝对的正确方法，适合当前阶段的才是最好的。

**记住：Vibe 和 Spec 不是非此即彼，而是工具箱里的不同工具，在合适的时候使用合适的工具。**

下一节我们学习 [Context 管理技巧](./1.4.4-context-management.md)。