Vibe Coding 这个说法，指的是不完全读代码，靠对话和感觉让工具把程序写出来。对没写过代码的人，它的吸引力是真实的：你终于不用等排期，就能看见一个像自己业务的界面。幻觉也几乎同时到来：既然它能写出按钮，它就应该能理解我的生意、守住我的数据、并在我离开后继续正确运行。
这三件事，对话本身都做不到。模型擅长把你刚说过的话变成看起来合理的实现，不擅长发现你没说出口的规则。你没说「金额不能为负」，它可能就不拦；你没说「店长不能看别的店」，演示账号就会什么都看。看起来聪明，是因为它在补全，不是因为它做过你的业务。
业余使用者最常遇到的五类问题
第一类是接口幻觉。工具会调用一个并不存在的函数，或按照过时的写法连接服务，本地偶然能跑，换一台机器就失败。第二类是密钥进了页面。示例代码里的口令被原样留下。第三类是只做了成功路径，一点失败就把数据写成一半。第四类是无法解释。出了错只能再问一句「帮我修修」，越修越偏，没有人知道现在哪几行是故意的。第五类是无法交接。作者自己也说不清字段含义，下一个人只能推倒重来。
这五类不是道德问题，是缺少约束时的正常结果。NIST 的人工智能风险管理框架把「测量」放在使用之前（NIST AI RMF）。没有测量的生成，只能叫草稿。
可以用的解法，按成本从低到高
最低成本的解法，是把用途说小。只生成一个只读查询，或一张需要人工确认才提交的草稿，不生成自动改账、自动退款、自动发通知。范围小，幻觉的伤害也小。
第二步，写一张失败清单再继续对话。清单上至少有十条：空数据、重复点击、无权限、断网、金额为负、日期颠倒、找不到记录、两人同时改、超长文本、超时。让工具按清单改，改完由你逐条点一遍。点的人即使不懂代码，也能发现「这一条它说做了，其实没有」。
第三步，找一个懂工程的人做一次短评审，只看四件事：密钥在不在前端、权限是否按人分开、数据能不能退回、版本能不能回滚。评审不负责帮你加功能。四件事有一件不通过，就不要接到正式环境。
什么时候该停下来找人接手
出现下面任何一条，就不要再靠「再问一句」往下走：要处理他人的个人信息或资金；要和现有 ERP、支付、会员打通；已经有人在用，而你不敢改怕改坏。这时候继续对话，节省的是编码时间，增加的是事故时间。交给能读变更、能写回滚的人，草稿仍然有用，它是需求说明，不是最终系统。
Vibe Coding 不是骗局。它把「从零到看得见」缩短了。幻觉在于把「看得见」当成「可以负责」。负责仍然需要规则、清单和一个人的名字。
下周就可以做的最小动作
如果你已经有一个对话生成的页面，不要再追加功能。打印失败清单，自己点十条，把没拦住的记下来，拿着记录去找能看变更的人做那四件事的短评审。评审通过之前，链接只发给一起试点的人，不发给客户，不写进合同。通过之后，把版本号和回滚人写在页面说明的同一行。
如果你还没开始，第一句提示词也别写「帮我做个系统」。先写你要完成的一个动作、三张表的字段，以及「不许自动扣款、不许把口令写进页面」。约束写在前面，生成结果才从幻觉变成草稿。草稿可以很快，上线仍然要慢半拍。
