Vibe Coding 的下一步，是学会放手
最近在开发一些项目的时候，我逐步接触到了 Vibe Coding 这个全新的编程方式。
它最容易让我着迷的地方，是把想法变成代码的速度。过去需要反复查阅文档、搭建环境、调试实现的工作，现在可以从一段自然语言描述开始。
但代码生成得越快，另一个问题就越明显：谁来确认这些代码真的可用？
如果每一轮修改都需要人运行程序、点击页面、检查日志，再告诉 AI 哪里出了问题，那么人并没有退出开发过程，只是从写代码的人变成了测试员和监工。AI 提高了编码速度，人仍然被绑在验证和纠错上。
我现在更关心的是，Vibe Coding 能否继续向前走一步：人提出目标，系统完成开发、验证和交付，只有遇到无法判断的情况才找人。
完成开发，不等于生成代码
要实现这一步，首先需要改变对“完成”的定义。
代码写完、文件保存、测试命令执行过，都不能单独证明任务已经完成。真正的完成应当对应明确的验收标准：功能是否达到预期，原有能力是否受到影响，软件能否在真实环境中运行。
因此，人需要提供目标和验收条件，而不是详细指导 AI 怎么写。AI 在实现之后，应当自己运行测试、操作软件、检查结果。如果失败，就继续修改；如果通过，则提交日志、截图或录屏等运行证据。
这里所说的“AI 对结果负责”，是一种很具体的要求：它不能只报告自己做了什么，还必须证明交付物确实满足要求。AI 自己宣布完成，不算完成。
重复出现的问题，应该交给系统处理
让 AI 自己验证，只是第一步。如果流程仍然依赖人不断提醒，自动化就很不稳固。
一个任务应当按照固定流程执行：
1 | 接收任务 → 修改代码 → 运行验证 → 失败则返工 → 成功后送审 |
流程之外，还需要持续积累规则。某类错误反复出现，就应该把它转化为自动检查、测试用例或开发约束，而不是指望下一次提示词写得更周到。
系统也必须知道自己什么时候不该继续。反复返工仍无进展、需求存在矛盾、运行环境异常，或者验收结果无法确认时，都应该停止并报告原因。否则，所谓自动纠错很容易变成自动消耗资源，甚至在错误方向上不断修改。
一个能够放手的系统，首先要能够可靠地停下。
写代码的 AI，不能给自己签字
开发 AI 提交的证据，还需要经过独立验收。
实现和验收应当由不同的 AI 承担，验收方最好使用不同模型。它需要根据验收标准检查真实运行结果，必要时重新执行关键流程，而不是直接相信开发 AI 的总结。
验收结果可以分为三种：
- 通过，进入自动合并和发布流程。
- 不通过，附上具体问题，退回修改。
- 无法确认，停止流程并交给人判断。
不同模型可以减少部分共同盲点，但独立验收仍然可能误判。因此，最终依据不能是另一个 AI 的一句“看起来没问题”，而应是可复现的运行结果和明确的合并条件。自动发布也需要权限限制、失败回滚和完整记录。
独立验收的意义，在于让不合格的代码无法仅凭开发方自己的结论进入发布环节。
人的工作会向上移动
全自动 Vibe Coding 并不意味着人不再重要。人不再逐行指导实现，却要更认真地定义目标、设计验收标准、维护规则，并处理系统无法判断的例外。
这也带来了新的风险。AI 可以高效地执行一个错误目标，自动闭环还会加快错误进入发布的速度。目标模糊、验收条件缺失、权限边界不清，都会因为自动化而产生更大的影响。涉及数据迁移、安全权限等高风险改动时，人工审批仍应留在流程中。
所以，我理解的“放手”有很清楚的条件：人不参与写代码和测试，每次交付都有运行证据，不合格代码无法合并，异常情况能够自动停下。
达到这些条件之后，Vibe Coding 才从一种更轻松的编码方式，变成一套可以托付结果的开发系统。人也才能真正从屏幕前移开，把注意力放回那些无法由代码自行回答的问题上：要做什么，做到什么程度，以及什么风险值得承担。