【Vibe Coding】Plan 模式 vs Spec 模式

AI
,

引言：从即兴创作到规范施工

2025 年，Vibe Coding 被柯林斯词典评为年度词汇，AI 辅助编程正式进入大众视野。但企业级实践中，纯粹的 Vibe Coding 很快暴露短板——质量不可控、知识难沉淀、团队协作成本高。

两种更结构化的范式随之涌现：Plan 模式与Spec 模式。它们不是对立的流派，而是 AI 编码工程化道路上不同成熟度的阶段。

全景对比

维度 Vibe Coding Plan 模式 Spec 模式
核心理念 自然语言描述，即时生成 先计划后执行，审核再动手 规格驱动，Spec 是唯一真理源
交互方式 自由对话，持续引导修正 两阶段：生成计划 → 执行计划 多阶段门控：Proposal → Spec → Design → Tasks
人类产出 一句 Prompt 计划文档（plan.md） 系列结构化工件（spec.md / design.md / tasks.md）
管控粒度 无 任务级（做哪几步） 逻辑级（做什么、遵循什么规则）
可靠性 低，依赖临场发挥 中，减少方向错误 高，产出可预期、可验证、可审计
知识沉淀 几乎为零 有限，计划可存档 系统性沉淀，Spec 成为版本化组织资产

Plan 模式：任务清单式协作

工作流

1
用户意图 → AI 生成步骤计划 → 人工审核 → AI 逐步执行

关键特征

  • 步骤驱动：把目标拆成 1、2、3… 每步可审核、可回滚
  • 人类掌控节奏：每步执行前确认，执行后可调整
  • 容错空间大：走偏了随时调头，无需推翻整体方案

局限

  • 步骤粒度难把握：太粗等于没计划，太细等于在写代码
  • 只回答了”做哪几步”，对”每步遵循什么规则”约束较弱
  • 上下文仅限本次任务，缺乏与团队历史经验的连接

适合场景

  • 探索性任务、中等复杂度功能开发
  • 重构遗留系统、搭建项目脚手架
  • 团队初步引入 AI 编码的起步阶段

Spec 模式：规范驱动开发

工作流

1
用户意图 → Proposal（为什么做）→ Spec（做什么）→ Design（怎么做）→ Tasks（原子任务）→ AI 自主实现 → 人工验收

关键特征

  • 规范驱动：Spec 定义输入、输出、边界、约束，是人类与 AI 之间的硬契约
  • 多阶段门控：proposal（为什么做）→ spec（做什么）→ design（怎么做）→ tasks（原子任务），每阶段有明确产出
  • 验收取代逐步审核：不需要盯过程，最终结果是否符合规格说了算
  • 真理源机制：specs/ 目录作为项目永久的知识库，新变更必须先读取历史 Spec，防止破坏既有逻辑

局限

  • 编写高质量 Spec 本身是工程能力，前期投入成本高
  • 规格遗漏会导致 AI “正确地做错事”
  • 不适合高度不确定的探索性工作

适合场景

  • 企业级复杂业务系统（电商交易、金融等高合规场景）
  • 跨模块协作频繁、需要知识沉淀的团队
  • 追求代码一致性、打造团队”AI 搭档”的中大型组织

正面交锋：同一任务的不同解法

任务：给现有 API 加分页

Plan 模式

1
2
3
4
5
6
7
1. 找到现有 API 入口文件
2. 分析当前查询逻辑
3. 添加 page/page_size 参数校验
4. 改写 SQL 加 LIMIT/OFFSET
5. 包装返回格式 { list, total, page, pageSize }
6. 写单元测试
7. 更新 API 文档

逐步执行，每步确认。过程可控，但”返回格式””参数校验规则”全靠人脑维护。

Spec 模式

1
2
3
4
Proposal: 现有 API 无分页，数据量大时性能差且前端体验不佳
Spec:     定义分页接口的参数、返回、约束（见下方 YAML）
Design:   采用 LIMIT/OFFSET 方案，总数用 COUNT 子查询，同一事务保证一致性
Tasks:    1. 修改查询逻辑  2. 添加参数校验  3. 包装返回格式  4. 补充测试
1
2
3
4
5
6
7
8
9
10
11
功能: 列表分页查询
接口: GET /api/items
参数:
  - page: number, 默认1, >=1
  - pageSize: number, 默认20, 范围[1,100]
返回:
  - { list: Item[], total: number, page: number, pageSize: number }
约束:
  - 向下兼容：不传分页参数时返回全部数据
  - 总数查询与数据查询在同一事务
  - 超出范围返回空列表而非报错

AI 自主实现，人工验收。业务规则、边界条件写在 Spec 里，门控流程确保每个阶段有明确产出，不依赖人的逐步把关。

如何选择？

1
2
3
4
5
6
7
8
9
10
11
12
13
              确定性高
                 |
           +-----+-----+
           | Spec 模式  |
           +-----+-----+
                 |
-----------------+-----------------
                 |
           +-----+-----+
           | Plan 模式  |
           +-----+-----+
                 |
             不确定性高
判断维度 偏 Plan 偏 Spec
需求清晰度 模糊，需要边做边探 清晰，能提前写明验收标准
技术路线 不确定，需要试错 确定，实现路径明确
不可逆性 低（新功能、独立模块），走偏了代价小 高（线上改动、数据迁移），必须精确定义约束与验收标准
团队规模 小团队或个人 中大型团队，跨模块协作
知识沉淀需求 低，用完即走 高，需要可复用的组织资产

升级信号

从 Plan 模式起步，当出现以下信号时考虑升级到 Spec 模式：

  1. 跨模块协作频繁，沟通成本激增
  2. 同样的业务错误被不同 AI 或开发者反复踩中
  3. 代码库风格开始混乱，维护成本上升
  4. 希望新同事或 AI 能快速理解系统全貌，而非从头摸索

混合实践：Plan + Spec

现实中的最佳解法往往是组合使用：

  1. Plan 阶段把大目标拆成若干子任务
  2. 对确定性高的子任务写 Spec，交给 AI 自主实现
  3. 对不确定的子任务走 Plan 逐步推进
  4. 每个子任务完成后做一次整体校验
1
2
3
4
大目标
  |-- 子任务A（不确定）--> Plan 模式，逐步推进
  |-- 子任务B（边界清晰）--> Spec 模式，AI 自主实现
  +-- 子任务C（边界清晰）--> Spec 模式，AI 自主实现

Plan 模式和 Spec 模式在实践中有显著的重叠区域。 Plan 侧重过程编排（做哪几步、按什么顺序），Spec 侧重结果定义（交付什么、遵循什么约束）。当 Plan 中的步骤描述逐渐加入验收标准和约束条件时，它就在自然演进为 Spec。两者可以平滑过渡。

写在最后

Vibe Coding 的核心不是选哪个模式，而是在合适的场景用合适的模式：

  • Plan 是过程控制 — 我告诉你每一步做什么
  • Spec 是结果控制 — 我告诉你最终要什么

当你发现自己在 Plan 里写了一堆”字段名是 xxx、类型是 yyy”的时候——那是该切 Spec 的信号。反过来，Spec 写到一半发现边界条件根本想不清楚——那就先 Plan 探一探。

未来的 AI 编程，核心竞争力不再是比拼谁的模型调用更快，而是谁的知识库更丰富、谁的规范更完善、谁的反馈闭环更高效。投资 Spec 模式，就是投资团队未来的生产力护城河。

工具服务于人，模式服务于场景。Vibe 它就好。