先给 Vibe Coding 一个可执行的定义
如果只把 Vibe Coding 理解成“用一句话让 AI 生成代码”，很容易得到一个看起来完成、实际上无法交付的演示。我的定义更具体：人负责问题、边界和质量，AI 负责加速探索、实现与检查，双方围绕可以验证的结果持续迭代。
这套方式不排斥产品文档、设计或工程规范。恰恰相反，越希望 AI 提速，越需要把目标、约束、禁止项和退出条件说清楚。提示词不是魔法咒语，它更像一份压缩后的工作说明。
我使用的五步工作流
1. 先写用户任务，不先写功能清单
我会先问：用户在什么场景下卡住？他完成任务后应该得到什么变化？例如 Easy Resume 的重点不是“接入 AI”，而是让用户能边写边看、定位简历问题，并决定是否采纳建议；TabiFun 关注的是如何把散落的旅行照片重新组织成地点和路线；AI 衣橱 则要把衣物入库、穿搭选择和旅行打包连成一条真正可用的任务链。
2. 把第一版缩成一个可以闭环的范围
最小版本不是把每个功能都做得很浅，而是选择一个核心任务完整走通。范围需要同时写清“这版必须有”和“这版明确不做”。后者尤其重要，它能减少 AI 在模糊区域里主动扩张需求。
3. 让 AI 分块实现，每块都能单独检查
页面结构、状态、数据规则、导出、异常路径最好分开处理。每次只交付一个可以运行和验证的切片，并保留已经工作的确定性演示。这样遇到错误时，能够知道问题来自哪一层，而不是在一大段生成结果里猜。
4. 用证据验收，不用“看起来不错”验收
静态页面要检查真实 HTTP 路由、移动端、键盘操作、控制台和资源加载；导出文件要打开并查看实际结果；桌面或移动产品还要区分本地测试、运行时、CI、部署和真机证据。不同层级的“通过”不能互相代替。
5. 发布时保留回滚与事实边界
发布前需要知道改了什么、如何验证、失败后怎么恢复。文案里也只写已经能证明的能力，不用计划中的功能冒充当前能力。对独立开发者来说，可信度本身就是产品资产。
最常见的三个坑
- 把生成速度当成交付速度：代码出现得快，不等于需求正确、边界完整或体验可用。
- 没有采用门槛：AI 给出的改写、建议或自动操作如果直接覆盖原内容，用户会失去判断权。更稳妥的方式是先预览，再明确采纳。
- 没有退出条件：只写“优化一下”会让工作无限延伸。应该提前定义哪些检查通过才算完成，哪些外部条件尚未验证。
什么时候适合，什么时候不适合
Vibe Coding 很适合原型验证、内部工具、静态网站、清晰边界内的产品迭代，也适合让一个人快速验证多种方案。涉及资金、隐私、医疗、法律、高风险自动操作时，它仍可以协助，但需要更严格的人工审核、安全测试和权限边界。
我的判断标准很简单：如果一项工作可以被拆成清晰目标、可观察结果和安全回滚，AI 就很适合加入；如果连问题和责任人都不清楚，先补产品判断，不要急着生成代码。
最后：Vibe Coding 不是少思考，而是让思考更快落地
真正有价值的不是“我用 AI 做了一个东西”，而是更快地找到值得解决的问题，做出可以被使用的版本，并用证据说明它已经走到哪一步。AI 缩短实现时间，人仍然负责方向、取舍和结果。