Vibe coding
通过提示词、示例和迭代快速探索。适合发现方向,不适合直接承诺生产行为。
通过提示词、示例和迭代快速探索。适合发现方向,不适合直接承诺生产行为。
实现前先写范围、验收标准、非目标和证据。
先用 vibe coding 探索,再把选定方向转成 spec 后进入生产代码。
问题不是实验。问题是让模型把模糊愿望直接变成生产行为,而中间没有可评审契约。
Spec coding 不是消灭速度,而是把慢问题前移:什么算完成、什么不做、用什么证据证明结果。
当一个请求在聊天里听起来清楚,但仍给 AI 留下大量自我发挥空间时,用这份清单。
# Vibe Request To Spec 模糊请求: - 澄清问题: - 影响谁? - 精确改变哪个行为? - 什么必须保持不变? - 哪个失败或权限路径重要? - 什么证据能证明完成? Spec 版本: ## Outcome - ## Scope - In: - Out: ## Acceptance Criteria - [ ] Given ..., when ..., then ... - [ ] 失败路径: - [ ] 边界路径: ## Evidence - 测试: - 手工检查: - 变更文件: 在这份内容可测试前,不生成生产代码。
同一个请求从感觉改成行为后,安全性会高很多。
模糊: - 让 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,否则模型会自行决定叠加折扣、过期券和重复应用行为。
可以用松散提示词比较标签、空状态和优惠码输入框位置,但不要让这一轮直接改生产 checkout 逻辑。
冻结选定行为:同一时间只允许一个有效优惠码,过期券返回 coupon_expired,重复应用只保留一条折扣行。
生成代码要附结账总额测试、过期券 API 证据和 UI 截图,再进入可发布判断。
真正有用的不是永远争论 vibe coding 和 spec coding 谁更好,而是掌握切换时机。问题还没定型时可以松散探索;一旦输出会影响生产行为、共享契约、用户数据、金钱、权限或评审责任,就应该切到 spec。
当你在比较方向、草拟文案、探索 UI 状态,或让 agent 解释可能方案时,模糊提示词是可以接受的。这个阶段的输出是思考材料,不是应该合并的产品决策。
选定方向后,先写 outcome、非目标、范围、验收标准和证据。这样创意探索才变成可评审约定。编码 agent 应该实现这个约定,而不是通过 diff 继续发现产品行为。
如果生成实现提出额外字段、新状态、依赖变化或更干净的架构,不要马上合并这个想法。先把它记录成后续 spec,或在下一轮生成前明确更新当前 spec。
Vibe Coding 与 Spec Coding 对比 不是只给 AI 看的一段提示词。它应该帮助人判断:这个任务是否已经可以进入实现、谁负责未决问题、哪些证据会随 PR 留下来。下面这些问题适合放在团队约定、PR 模板或实现前评审里。对搜索和广告审核来说,这类可复用、可执行的说明也能证明页面不是只有模板,而是有真实方法,并提高用户停留、复访、收藏和分享。
在使用 Vibe Coding 与 Spec Coding 对比 前,先写清哪个人或角色可以批准范围变化。没有 owner 的开放问题会变成 AI 自行补空白的入口,也会让 reviewer 在合并前才发现产品、数据或权限决策还没有被确认。
把必须回答的问题和可以带着风险继续的问题分开。阻塞项通常包括公开 API、数据迁移、权限边界、支付行为、回滚方案和用户可见文案。只要这些还没明确,就不要让 agent 直接生成生产代码。
最终 PR 至少应该链接 vibe-to-spec.md、列出变更文件、说明跳过的检查,并把测试、截图、日志或指标映射回验收标准。否则未来的人只能读 diff 猜当时为什么这样做。
提示词鼓励迭代,却没有定义什么叫完成。
模型自己发明文案、状态、重试或错误行为。
Reviewer 直到代码生成后才知道这次到底改了什么。
用这组对比选择下一步该产出的文档。
把模糊请求转换成边界清楚的 AI 编码包。
打开生成器把选定方向改成通过/失败行为。
写标准把最终决策提交为稳定事实来源。
复制 spec.md不是。它很适合探索。风险在于用模糊提示词直接修改生产行为。
它增加一点前置步骤,但通常减少返工,因为成功和证据在代码前已经定义。
当任务触碰生产行为、数据、API、权限、支付、后台任务或共享 helper 时,就该切换。
可以自由探索,但让生成代码变成产品决策之前,先写 spec。
转换提示词