模式选择决策树
本节给你一个系统化的决策方法，帮助你在 Vibe / Plan / Spec 之间做出正确选择。
决策框架：5 个核心问题
回答这 5 个问题，你能快速判断该用哪种模式：
1. 任务有多大？
2. 是否要长期维护？
3. 团队协作吗？
4. 风险有多高？
5. 是否有明确规范？快速决策表
| 任务特征 | 推荐模式 |
|---|---|
| 不确定做什么 | Vibe |
| 验证想法 | Vibe |
| 学习新东西 | Vibe |
| 1-2 个明确任务 | Plan |
| 修 Bug | Plan |
| 中等功能 | Plan |
| 跨多个模块 | Spec |
| 团队协作 | Spec |
| 关键业务 | Spec |
| 长期维护 | Spec |
决策树
开始
│
├─ 任务目标清晰吗？
│ ├─ 否 → Vibe Coding
│ └─ 是 ↓
│
├─ 需要长期维护 / 多人协作吗？
│ ├─ 是 → Spec Coding
│ └─ 否 ↓
│
├─ 任务复杂度？
│ ├─ 简单（< 1 小时） → Vibe Coding
│ ├─ 中等（1 小时 - 2 天） → Plan Coding
│ └─ 复杂（> 2 天） → Spec Coding
│
└─ 风险等级？
├─ 低 → Vibe Coding
├─ 中 → Plan Coding
└─ 高 → Spec Coding按场景决策
场景 1：技术调研
任务：评估新的状态管理库（Zustand vs Jotai）
特征：
- 目标不明确
- 需要试错
- 时间短
决策： Vibe Coding```
用 Zustand 写个 todo 例子 用 Jotai 写个 todo 例子 对比一下
### 场景 2：POC 原型
**任务**：为投资人 demo 一个新想法
**特征**：
- 短期（1-2 天）
- 不考虑可维护性
- 速度优先
**决策**： **Vibe Coding**```
> 30 分钟做一个炫酷的登录页
> 加几个交互动画
> 时间到就停场景 3：日常功能开发
任务：做一个用户列表组件
特征：
- 目标明确
- 中等复杂度
- 需要可维护
决策： Plan Coding```
我要做用户列表组件，先告诉我方案 方案 OK 后实施 测试 + Review
### 场景 4：Bug 修复
**任务**：登录页面白屏
**特征**：
- 目标明确（修 Bug）
- 需要诊断
- 风险中等
**决策**： **Plan Coding**```
> 先分析可能的根因
> 给出排查方案
> 按方案修复
> 加回归测试场景 5：大型新功能
任务：完整的支付模块
特征：
- 跨多个文件
- 多人协作
- 关键业务
- 长期维护
决策： Spec Coding```
先写完整规范（需求 + 设计 + 验收） 团队 Review 规范 按规范拆任务 AI 按规范实现 按规范验收
### 场景 6：紧急修复
**任务**：生产环境 P0 Bug
**特征**：
- 紧急
- 没时间规划
- 风险高
**决策**： **Plan Coding**（快速 Plan）紧急！先定位 Bug 给出最快修复方案 实施 + 验证 事后补规范
### 场景 7：依赖升级
**任务**：React 17 → 18
**特征**：
- 跨整个项目
- 需要细致规划
- 风险高
**决策**： **Spec Coding**```
> 写升级规范（影响范围 + 步骤 + 验证）
> 按规范逐步升级
> 每一阶段独立验证场景 8：学习新技术
任务：第一次用 Svelte 写组件
特征：
- 学习目的
- 无明确目标
- 试错
决策： Vibe Coding```
教我用 Svelte 写一个组件 我边看边问
## 按团队角色决策
### 独立开发者
| 任务 | 模式 |
| --- | --- |
| 个人项目探索 | Vibe |
| 个人项目功能 | Plan |
| 个人项目核心 | Spec |
### 团队主力开发者
| 任务 | 模式 |
| --- | --- |
| 自己的探索 | Vibe |
| 分配的功能 | Plan |
| 协作的核心模块 | Spec |
### Tech Lead / 架构师
| 任务 | 模式 |
| --- | --- |
| 调研新技术 | Vibe |
| 设计架构 | Plan |
| 制定规范 | Spec |
## 按代码生命周期决策代码的"保质期"有多长？ ├── < 1 天（一次性脚本） → Vibe Coding ├── 1 天 - 2 周（短期功能） → Plan Coding ├── 2 周 - 6 月（中期项目） → Plan Coding └── > 6 月（长期项目） → Spec Coding
## 模式切换的信号
### 从 Vibe 切换到 Plan
| 信号 | 含义 |
| --- | --- |
| 验证了想法 | 值得做下去 |
| 决定保留代码 | 需要可维护 |
| 团队要使用 | 需要协作 |
| 发现潜在问题 | 需要规划解决 |
### 从 Plan 切换到 Spec
| 信号 | 含义 |
| --- | --- |
| 多人协作开发 | 需要统一规范 |
| 代码将长期维护 | 需要文档 |
| 业务关键 | 需要严格验收 |
| 涉及多模块 | 需要架构设计 |
## 实战组合策略
### 策略 1：Vibe → Plan → ShipVibe 验证想法（30 分钟） ↓ Plan Coding 实现（1-3 天） ↓ 测试 + Review 上线
**适用**：大多数日常任务
### 策略 2：Spec → Plan → VibeSpec Coding 写规范 ↓ Plan Coding 实施 ↓ Vibe 微调优化
**适用**：大型新功能
### 策略 3：Plan → Vibe → PlanPlan Coding 开始 ↓ 遇到细节用 Vibe 探索 ↓ 回到 Plan 继续
**适用**：复杂任务中的小探索
### 策略 4：Spec → Spec → Spec大规范 → 子规范 → 任务规范
**适用**：超大型项目，每个子模块单独规范
## 反模式：错误的模式选择
### 反模式 1：用 Vibe 做生产直接用 Vibe Coding 写生产代码
**问题**：代码不可维护，几个月后无法理解。
**对策**：Vibe 后必须经过 Plan Coding 整理。
### 反模式 2：用 Spec 做小任务修一个按钮颜色也要写 10 页规范
**问题**：效率极低，规范流于形式。
**对策**：小任务用 Plan 或 Vibe。
### 反模式 3：用 Vibe 做关键模块支付模块用 Vibe Coding 随便写
**问题**：风险极高，可能造成损失。
**对策**：关键模块必须 Spec Coding。
### 反模式 4：用 Spec 做探索想试一下新框架，先写 20 页规范
**问题**：过度规划，扼杀创新。
**对策**：探索用 Vibe，确定后再 Spec。
## 检查清单
选模式前，问自己：
- [ ] 这个任务的"保质期"是多久？
- [ ] 谁会用这段代码？（只有我 / 团队 / 客户）
- [ ] 出错的代价有多大？
- [ ] 是否需要多人协作？
- [ ] 是否已有相关规范？
## 团队中的模式选择规范
### 团队应明确
```markdown
## AI Coding 模式选择规范
### Vibe Coding
适用范围：
- 个人探索
- 技术调研
- 学习目的
禁止：
- 直接用于生产代码
- 未经 Plan 整理就合并
### Plan Coding
适用范围：
- 日常功能开发
- Bug 修复
- 中等重构
要求：
- 写清楚方案
- 通过 Review
### Spec Coding
适用范围：
- 大型新功能
- 关键业务模块
- 多人协作项目
要求：
- 完整规范文档
- 团队 Review
- 按规范验收总结
三种模式没有优劣，只有合适不合适：
- Vibe：探索的开始
- Plan：生产的主力
- Spec：协作的基石
实战原则：
- 不要只用一种模式2. 按任务特征选模式3. 模式之间可以切换4. 团队要有共识下一章：代码质量保障 — 模式选对了，还要有质量保障。