AI面试系列15：Vibe Coding 的常见陷阱有那些？

Vibe Coding 的“感觉/氛围驱动”模式虽然在快速原型和创意探索时很爽，但如果不加控制，很容易掉进几个典型陷阱。下面从代码质量、维护性、安全性、需求演变、团队协作五个维度总结

一、代码质量陷阱

因为 Vibe Coding 依赖对话式迭代，用户每次提出模糊修改需求（如“让这个按钮更有科技感”），AI 会倾向于叠加新代码而不是重构原有逻辑。它不知道哪些旧代码已经失效，也不敢轻易删除，导致冗余、死代码不断累积。同时，AI 没有统一的“代码风格记忆”，每次生成可能遵循不同的命名习惯（取决于训练样本的随机性），加上用户很少给出明确的规范约束，最终代码变得杂乱且难以预测。总结下来为：

冗余与死代码：多次修补后，AI 会留下旧的实现、注释掉的代码块、未使用的导入，因为删除风险高，它选择保留。
不一致的命名与风格：AI 在不同轮次中随机从训练数据中抽取风格，用户不强制规范就会混用驼峰、下划线、空格。
隐藏的逻辑错误：AI 倾向于生成“常见路径”正确的代码，但边界条件（空值、极值、并发）往往被忽略，因为训练数据中这类样例较少。

二、可维护性陷阱

Vibe Coding 的迭代速度极快，用户和 AI 都聚焦于“当前功能是否可用”，几乎没有时间写文档、注释或重构。AI 缺乏长期记忆，不会主动为函数添加 docstring，也不会考虑下一个接手的开发者。另外，AI 倾向于“搞定眼前需求”，要么过度设计一个通用框架（以为用户以后会需要），要么复制粘贴快速实现，导致抽象层次混乱。总结下来为：

缺乏文档与注释：AI 默认输出“自解释”代码，但实际复杂的正则或算法很难理解；用户没有要求，它就不会写文档。
过度抽象或抽象不足：AI 有时套用常见的设计模式（如工厂、策略），即便问题很简单；有时又因为懒得提取公共函数，直接复制代码块。

三、安全陷阱

AI 的训练数据包含大量开源代码，其中不乏历史漏洞（如 SQL 拼接、硬编码密钥）。在 Vibe Coding 中，用户很少主动要求“使用参数化查询”或“从环境变量读取密钥”，AI 就会采用最常见（也往往是不安全）的模式。此外，AI 没有“威胁模型”意识，不会主动检查输入过滤、权限最小化，因为它只关心功能实现。总结下来为：

注入漏洞：AI 默认使用字符串拼接构造 SQL/命令，因为这种方式在简单教程中最常见。
敏感信息硬编码：训练样本中的示例常写死 API Key，AI 会模仿这种模式。
过度权限：AI 为了方便，经常用 sudo 或 w+ 模式打开文件，而不考虑最小必要权限。

四、需求演变陷阱

Vibe Coding 没有明确的边界。用户一句“再加个功能”，AI 会尽力满足，但它不知道什么是“范围之外”。AI 也没有优先级概念，可能会同时实现三个附加特性，导致核心功能被淹没。同时，每次修改新 bug 时，AI 不会回顾旧功能，经常出现修好 A、弄坏 B 的回归问题。总结下来为：

范围蔓延：AI 为了“让用户满意”，会主动添加看似相关但非必需的功能（如计算器加历史记录）。
功能退化：AI 在修复某个 bug 时，因为不了解全局逻辑，修改了一处公共函数，导致其他依赖它的功能异常。

五、团队协作陷阱

Vibe Coding 的对话过程是个人与 AI 的私有交互，没有留下可传递的规格文档或设计决策记录。不同的团队成员分别与 AI 对话，得到的是各自风格的代码，合并时冲突百出。此外，AI 不会自动生成 commit message 或变更日志，代码演化的理由丢失，后期维护人员只能靠猜。总结下来为：

不可重现的构建：不同人、不同时间使用相同 prompt，AI 会输出不同实现（因为采样随机性）。
缺乏变更追踪：没有设计文档、没有 commit message 解释“为什么这么改”，代码变成黑箱。