它失效的地方

对它的边界要诚实，因为无人监督的 vibe coding 正是在这些地方把人坑惨：

• **深奥而新颖的逻辑。**微妙的算法、并发、任何"对了 95%"就等于"坏了"的东西。模型即便错了也很自信。
• **铺得很开的跨文件改动。**它在大型代码库里会跟丢线索，悄无声息地搞坏它看不见的东西。
• **安全和钱。**认证、支付、权限，任何一个看似合理的 bug 会带来真实后果的地方。审查这些时要像你的饭碗系于此一样，因为它可能真的是。
• **规格说明不足的问题。**如果你都不知道正确长什么样，AI 没法读你的心。规格说明是垃圾进，代码就是垃圾出。

失败的模式几乎总是一样的：代码看起来对，在顺利路径上能跑，却以一种你只要读了就能抓住的方式错了。解药就是审查这一步。它无法被跳过。

两个问题就能把任何任务放到这张地图上——模式是否常见，以及结果是否容易核查:

                   易于验证            难以验证
                ┌──────────────────┬──────────────────┐
   常见         │   纯赚           │   放慢,          │
   模式         │   (脚手架,       │   要求测试       │
                │   样板           │                  │
                ├──────────────────┼──────────────────┤
   罕见 /       │   需读但可行     │   危险区         │
   新颖         │                  │   (新逻辑,       │
                │                  │   鉴权, 金钱     │
                └──────────────────┴──────────────────┘

注意上面那条规则的反面：这些都是罕见、微妙、或验证成本高的情形。模式不常见，所以模型在猜；或者 bug 在顺利路径上不可见，所以快速检查抓不到。这并不意味着在这里就要躲开 AI——它意味着你要放慢、把步子切小、要求测试，并把每一行都当作有敌意的来读。