方法对比

Vibe Coding 与 Spec Coding 对比

Vibe coding 适合探索,但如果直接用于生产改动就很危险。Spec coding 保留探索速度,但在实现前补上边界。

更新日期:2026-05-25

实际差别是什么

Vibe coding

通过提示词、示例和迭代快速探索。适合发现方向,不适合直接承诺生产行为。

Spec coding

实现前先写范围、验收标准、非目标和证据。

健康组合

先用 vibe coding 探索,再把选定方向转成 spec 后进入生产代码。

什么时候感觉不够用

问题不是实验。问题是让模型把模糊愿望直接变成生产行为,而中间没有可评审契约。

Spec coding 不是消灭速度,而是把慢问题前移:什么算完成、什么不做、用什么证据证明结果。

安全使用 Vibe Coding

  • 只在触碰生产文件前用模糊提示词探索。
  • 把选定方向转换成范围、非目标、标准和证据。
  • 实现前给 agent 允许写入路径。
  • 额外行为即使有用,也先按漂移处理。
  • 把最终 spec 放进 PR,让后来者看到决策来源。

可复制 Vibe To Spec 清单

当一个请求在聊天里听起来清楚,但仍给 AI 留下大量自我发挥空间时,用这份清单。

vibe-to-spec.md
# Vibe Request To Spec

模糊请求:
-

澄清问题:
- 影响谁?
- 精确改变哪个行为?
- 什么必须保持不变?
- 哪个失败或权限路径重要?
- 什么证据能证明完成?

Spec 版本:
## Outcome
-

## Scope
- In:
- Out:

## Acceptance Criteria
- [ ] Given ..., when ..., then ...
- [ ] 失败路径:
- [ ] 边界路径:

## Evidence
- 测试:
- 手工检查:
- 变更文件:

在这份内容可测试前,不生成生产代码。

转换示例

同一个请求从感觉改成行为后,安全性会高很多。

filled-example.md
模糊:
- 让 checkout 更可靠。

Spec:
## Outcome
- 当支付授权超时时,显示可恢复错误。

## Scope
- In:payment submit handler、checkout error banner、payment tests
- Out:provider client API、database schema、order confirmation page

## Acceptance Criteria
- [ ] Given 支付授权超时,when 用户提交 checkout,then 页面显示 "Payment is taking longer than expected",订单保持 pending。
- [ ] Given 用户在超时后重试,when provider 成功,then 订单只进入 paid 一次。
- [ ] Given provider 返回 card_declined,when checkout 提交,then 不显示重试 banner。

## Evidence
- npm test -- checkout-payment
- 截图:timeout banner 状态

真实场景:一句优惠码需求如何失控

创始人临时说“活动前把优惠码体验改一下”。Vibe coding 可以拿来探索文案和状态,但进入生产前必须切到 spec,否则模型会自行决定叠加折扣、过期券和重复应用行为。

Vibe 阶段

可以用松散提示词比较标签、空状态和优惠码输入框位置,但不要让这一轮直接改生产 checkout 逻辑。

Spec 阶段

冻结选定行为:同一时间只允许一个有效优惠码,过期券返回 coupon_expired,重复应用只保留一条折扣行。

合并证据

生成代码要附结账总额测试、过期券 API 证据和 UI 截图,再进入可发布判断。

什么时候从 Vibe 切到 Spec

真正有用的不是永远争论 vibe coding 和 spec coding 谁更好,而是掌握切换时机。问题还没定型时可以松散探索;一旦输出会影响生产行为、共享契约、用户数据、金钱、权限或评审责任,就应该切到 spec。

用 vibe 做探索

当你在比较方向、草拟文案、探索 UI 状态,或让 agent 解释可能方案时,模糊提示词是可以接受的。这个阶段的输出是思考材料,不是应该合并的产品决策。

编码前冻结决策

选定方向后,先写 outcome、非目标、范围、验收标准和证据。这样创意探索才变成可评审约定。编码 agent 应该实现这个约定,而不是通过 diff 继续发现产品行为。

把漂移当信号

如果生成实现提出额外字段、新状态、依赖变化或更干净的架构,不要马上合并这个想法。先把它记录成后续 spec,或在下一轮生成前明确更新当前 spec。

落地前的评审问题

Vibe Coding 与 Spec Coding 对比 不是只给 AI 看的一段提示词。它应该帮助人判断:这个任务是否已经可以进入实现、谁负责未决问题、哪些证据会随 PR 留下来。下面这些问题适合放在团队约定、PR 模板或实现前评审里。对搜索和广告审核来说,这类可复用、可执行的说明也能证明页面不是只有模板,而是有真实方法,并提高用户停留、复访、收藏和分享。

谁拥有决策?

在使用 Vibe Coding 与 Spec Coding 对比 前,先写清哪个人或角色可以批准范围变化。没有 owner 的开放问题会变成 AI 自行补空白的入口,也会让 reviewer 在合并前才发现产品、数据或权限决策还没有被确认。

什么会阻塞实现?

把必须回答的问题和可以带着风险继续的问题分开。阻塞项通常包括公开 API、数据迁移、权限边界、支付行为、回滚方案和用户可见文案。只要这些还没明确,就不要让 agent 直接生成生产代码。

PR 会留下什么证据?

最终 PR 至少应该链接 vibe-to-spec.md、列出变更文件、说明跳过的检查,并把测试、截图、日志或指标映射回验收标准。否则未来的人只能读 diff 猜当时为什么这样做。

Vibe Coding 容易失败的地方

没有停止条件

提示词鼓励迭代,却没有定义什么叫完成。

未经评审的产品决策

模型自己发明文案、状态、重试或错误行为。

用 diff 发现范围

Reviewer 直到代码生成后才知道这次到底改了什么。

相关资源

用这组对比选择下一步该产出的文档。

AI 规格包生成器

把模糊请求转换成边界清楚的 AI 编码包。

打开生成器

AI 编码验收标准

把选定方向改成通过/失败行为。

写标准

spec.md 模板

把最终决策提交为稳定事实来源。

复制 spec.md

Vibe vs Spec FAQ

Vibe coding 不好吗?

不是。它很适合探索。风险在于用模糊提示词直接修改生产行为。

Spec coding 会拖慢团队吗?

它增加一点前置步骤,但通常减少返工,因为成功和证据在代码前已经定义。

什么时候应该从 vibe 切到 spec?

当任务触碰生产行为、数据、API、权限、支付、后台任务或共享 helper 时,就该切换。

可以自由探索,但让生成代码变成产品决策之前,先写 spec。

转换提示词