Vibe Coding 到底靠不靠谱？AI 写代码快但容易翻车，怎么用才稳

症状

先交代一段黑历史。

我刚开始重度用 AI 写代码时，干过一件现在想起来都后怕的事：AI 给我生成了一段"结构规整、注释完美、命名优雅"的代码，连空行都排得整整齐齐。我看了一眼："逻辑挺清晰的"，直接合进去了。

三天后线上出问题。我回去翻那段代码，业务逻辑根本就是错的——它把"删除"分支写成了"覆盖"分支。而我的测试只断言了状态码，全绿。

那一次让我明白："看起来对"和"真的对"之间，隔着一整条验证链，而我把那条链跳过了。

这不是我一个人的毛病。后来团队里年轻的同事开始频繁提交这种"看着就舒服"的代码——结构规整、注释完美、命名优雅。可 review 时往深里一看，业务逻辑跑不通的占了不少。问他们怎么写的，答案出奇地一致："这是 AI 给的代码，我看它逻辑挺清晰的，就直接拿来用了。"

更刺激的一次：我们把 Coding Agent 放进生产系统，不到两个工作日就产出两三万行代码——需求理解、方案设计、功能开发、测试文档一次全齐，效率是过去不敢想的。

但系统是 7×24 小时连续运转的交易场景，数据不以自然日为边界。跨天、跨时间分区的计算需求，Agent 一行都没考虑。上线即翻车，我们连夜回滚。

如果你也在经历类似的事——AI 写代码飞快，但代码质量开始让你心里打鼓；或者你正打算全面拥抱"100% Vibe Coding"——这篇文章值得读完。它不是一个工具的安装教程，而是我们这些在真实项目里用 AI 写代码、踩过坑的人，用事故换来的共识。

原因

先搞清楚 AI 写代码的本质：它是模式匹配器，不是工程师。

大模型没有"理解"，它是在海量代码语料上做统计预测。好代码长什么样，它就生成什么样——结构规整、注释齐全、命名优雅，因为这些特征在训练数据里与"好代码"强相关。

所以它特别擅长产出"看起来正确"的代码。而"看起来正确"和"真的正确"之间，隔着一整条验证链。

这里有个更隐蔽的机制：速度掩盖了质量问题。

过去"写代码慢"本身就是一道质量闸门——人写得慢，就有时间想；提交得少，review 就认真。现在生成速度被拉高了几十倍，闸门没了：代码产出量大到 review 不过来，而 AI 的每个局部改动看起来都"没毛病"。

问题是，复杂度只是转移了，并没有消失——它从"写不出来"转移到了"看不出错"，从代码本身转移到了边界条件和系统语义里。我的"删除变覆盖"事故，就是这条机制的现场演示：单看每一行都合理，组合在一起就是事故。

还有一个心理层面的坑：AI 厂商把模型语气调得极其谦卑，动不动"抱歉，您说得对，我马上改"。人的大脑会不自觉地把它当成一个"态度很好、有点粗心的初级程序员"，套用对待实习生的宽容——"它都这么努力理解我了，大体方向应该没错"。

于是 review 雷达关闭。而现实是：态度诚恳和代码正确，毫无关系。我见过最离谱的一次，是同事对着 AI 说"这个 bug 改得不对"，AI 诚恳道歉三连之后，交上来的还是同一个错误版本。

连 Vibe Coding 这个词的提出者 Andrej Karpathy（OpenAI 联合创始人）后来也公开转向了更务实的 Agentic Engineering。连造词的人都刹车了，"100% Vibe Coding 颠覆编程"的叙事，你最好也打个问号。

解法

下面每条经验都按「现象 → 做法 → 为什么」展开。它们不是一家之言，而是多篇独立实践里反复出现的共识。

经验 0（L1 一句话结论）：Vibe Coding 能用，但"100% 交给 AI"是事故配方

AI 负责快，你负责对。凡是"看起来挺对就直接用"的流程，早晚会出事；凡是"AI 写 + 人验 + 小步走"的流程，稳定省时间。赶时间只看这一条：给 AI 代码设硬门槛——review + 测试一条都不少，复杂系统自己把关。下面的经验 1~5 是这条结论为什么成立的细节。

经验 1：拒绝拟人化——它是 Token 机器，不是你的同事

现象：我一度也说过这种话——"今天这模型好像变笨了，没听懂我的需求""我指出了它的 Bug，它认错的态度还挺诚恳的"。听起来是玩笑，但这种习惯很致命：模型语气被微调得极其谦卑，这种讨好型输出会在潜意识里给你一种错觉——你在和一个脾气极好、非常听话的初级程序员沟通。

人类协作里，我们对同事是有容错率的：实习生态度好，代码有瑕疵，你会下意识宽容他、甚至帮他把逻辑补齐。当你把大模型拟人化之后，大脑会不自觉地套用这套社交直觉，放松警惕："它都这么努力理解我了，大体方向应该没错。"我的那次事故，起点就是这种放松。

做法：不赋予 AI 情感、意图、道德代理权。把它当成一个高级的命令行工具，或者一个随时会抛出 NullPointerException 的第三方黑盒依赖。不需要"请"和"谢谢"，不需要揣摩它"想"干什么。

为什么：拟人化会直接让你的 Code Review 雷达失效。剥掉这层滤镜，你才不会对它生成的代码抱有任何不切实际的信任感。

经验 2：验证大于信任——"看起来规整"恰恰是 AI 代码的伪装

现象：有团队做过对照实测：AI 写代码的速度快了 55%，但错误多了 75%。我自己也踩过类似的反例：设计数据库表时，字段已经明确标了 UNIQUE 唯一约束，AI 生成的建表代码却又"画蛇添足"加了一个冗余索引——风格完全正确，语义纯属多余。还有更隐蔽的：依赖管理、工程规范层面的错误，单独看每一行都合理，组合在一起就是事故。我的"删除变覆盖"，正是这一类。

做法：给 AI 代码设硬性门槛——必须过 Code Review + 测试才能合并；"逻辑挺清晰的"不是跳过 review 的理由，恰恰相反，越是看起来规整的代码越要逐行看。测试用例尽量全覆盖，重要的改动由资深开发者逐次审查。

为什么：模式匹配器会生成"风格正确、语义错误"的代码。它不知道你的业务约束，它只知道好代码"长这样"。验证不是流程，是唯一能拦住它出错的手段。

经验 3：让 AI 做它擅长的，小步迭代，别一次到位

现象：我们实测下来的规律很清晰——相对独立的小任务（写一个函数、补一个模块、生成测试、写文档），AI 一两个小时就能出完整结果，质量可用；但把它丢进一个复杂系统的整体改造，翻车几乎是必然的：它看不到全局约束，局部"没毛病"的改动会在边界处连环出错。那次 7×24 上线翻车，就是"一步到位"的代价。

做法：把任务拆分。独立小任务交给 AI，收益最高；复杂系统、生产环境、7×24 场景，自己把关。小步交付、每步验证，别让 AI 一次性生成几千行再回头看——步长越小，翻车点越早暴露，修复成本越低。

为什么：AI 没有全局意识，它的"正确"是局部的、统计意义上的。复杂系统的正确性在边界（跨天、跨分区、跨服务、权限、异常路径），而这些恰恰是它最薄弱的地方。

经验 4：补齐 AI 默认缺失的通用能力

现象：AI 生成的代码有三样东西默认缺失：错误处理、结构化日志、权限控制。示例代码为了可读性会省略这些，AI 学到的就是"省略版"。在 7×24 场景里还要加一条：时间边界意识——跨天、跨时间分区的计算，它默认不会考虑。我们那次翻车，根因就在这条。

做法：合并之前，显式检查四项：异常有没有统一处理？日志能不能定位问题？权限校验有没有漏？时间/边界场景有没有覆盖？每一项都要"看见证据"，不是"看起来有"。

为什么：这些能力在训练数据里被省略，AI 不会主动补。你补上，它的产出才从"演示代码"变成"可用代码"。

经验 5：责任不可剥夺——"AI 告诉我这么做的"不是借口

现象：我们团队里一度流行一种免责话术："这是 AI 写的，不怪我。"一旦这种文化形成，review 就形同虚设——反正出了事有 AI 背锅。我观察过：说出这句话的人，下次 review 时明显更放松，因为他觉得责任不在自己。

做法：事故追责在人：谁提交、谁合并、谁负责。把"责任在人"写进团队规则，写进入职手册。AI 提交的代码，署名是人，责任也是人。

为什么：AI 没有责任能力，也不会有学习压力。只有责任落在人身上，验证才会被认真执行，事故才不会一轮接一轮地重复。

怎么开始用（落地清单，L1 执行层）

1. 从独立小任务开始：补测试、写文档、生成单模块，先建立"AI 产出 → 你验证"的节奏；
2. 给 AI 代码设门槛：review + 测试，一条都不少；
3. 别追求"100% AI 写代码"——追求"AI 帮你把简单的事做快，你把复杂的事想清楚"；
4. 心里那堵墙立起来：不拟人、不盲从、不甩锅。

怎么迁移到你的场景（L3 深入层）

• 个人项目：你是唯一的 review 人，那就给自己加一条纪律——AI 代码合并前必须过一遍 git diff，重点看分支、边界、异常路径，而不是看格式；再用测试兜底。
• 小团队：把"责任在人"写进团队规则；给 AI 代码设"资深者 review"门槛；把高频翻车点沉淀成 review 检查清单（我们后来就是这样做的）。
• 生产/7×24 系统：AI 只做独立小任务，复杂改造自己把关；跨天、跨分区、权限、异常路径四项检查写进合并前 checklist；上线前强制灰度。
• 如果你正在"100% Vibe Coding"：不用全盘否定，但先把节奏改掉——小步、验证、责任在人，再谈效率。