方法对比

Vibe Coding 与 Spec Coding 对比

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

更新日期：2026-05-25

vibe-to-spec.md可复制

模糊请求：
- 让 checkout 更好。

转换成 spec：
- 结果：
- 非目标：
- 范围：
- 验收标准：
- 证据：

标准不可测试前，不写生产代码。

实际差别是什么

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 容易失败的地方

没有停止条件

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

未经评审的产品决策

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

用 diff 发现范围

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

Vibe vs Spec FAQ

Vibe coding 不好吗？

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

Spec coding 会拖慢团队吗？

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

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

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

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

转换提示词