Vibe Coding 的陷阱:为什么 AI 不能取代软件工程

最近一个尖锐的观察引发共鸣——"如果你只看单块砖头的质量，AI 生成的代码确实规范、工整，甚至比很多赶工期的程序员写得更少出错。但软件工程从来不是'把砖头造出来'这么简单，而是状态管理、边界划分和复杂度控制。"这件事揭示了"Vibe Coding"（即"凭感觉用 AI 写代码"）的三大陷阱——抽象能力退化、上下文遗忘、修复的"拆东墙补西墙"。

"Vibe Coding"是一种"用 AI 写代码"的模式——开发者描述需求，AI 自动生成代码。这种模式在"单块砖头"层面表现优秀——比如写一个独立的正则匹配、一个标准的数据转换函数、照着文档调个接口——AI 生成的代码"规范、工整、出错少"。

这种"单块砖头幻觉"是 Vibe Coding 流行的原因——开发者看到"AI 写单块代码比人好"——就以为"AI 能写整个项目"——但这是"以偏概全"。

软件工程从来不是"把砖头造出来"这么简单——而是"状态管理"、"边界划分"、"复杂度控制"——这些是"架构层面"的问题，不是"单块代码"问题。AI 在"单块代码"上有优势，但在"架构层面"上不一定。

二、抽象能力退化的陷阱

Vibe Coding 的第一个陷阱是"抽象能力退化"。具体来说，第一，"手写代码慢"时的"被迫抽象"——过去手写代码慢，为了省事，程序员会被"被迫"思考"怎么抽离公共模块"、"怎么解耦"——这种"被迫抽象"让代码保持"精炼"和"低耦合"。第二，"AI 生成代码快"时的"懒惰"——现在"敲一下回车三秒出五百行代码"——最"省脑子"的做法变成了"让 AI 再写一套差不多的"——"抽象"被"重复"取代。第三，"项目膨胀与耦合"——"项目体积以十倍速膨胀"——"隐式耦合散落在各个角落"——长期看代码"难以维护"、"难以扩展"。

这是 Vibe Coding 的"长期成本"——短期内"代码生成快"——长期看"代码质量下降"。

三、上下文遗忘的陷阱

Vibe Coding 的第二个陷阱是"上下文遗忘"。具体来说，第一，"上下文窗口有限"——"哪怕现在的模型上下文再长，面对几万行代码的真实业务库，它也无法像人类架构师那样在脑子里维持一张完整的'全局状态图'"。第二，"局部优化与全局失衡"——"每次你只盯着报错信息让它修 Bug，它为了当前测试通过，往往会采取最暴力的打补丁方式"——这种"局部优化"导致"全局失衡"。第三，"架构退步"——长期"局部打补丁"——会让代码"越来越难理解"、"越来越难修改"——形成"技术债务"。

这是 Vibe Coding 的"架构成本"——短期内"修 bug 快"——长期看"架构退步"。

四、修复的"拆东墙补西墙"陷阱

Vibe Coding 的第三个陷阱是"修复的拆东墙补西墙"——即"为了修复一个 bug，引入新的 bug"。

具体来说，第一，"局部修 bug"的副作用——AI 在"修 bug"时只看"局部报错"——没有"全局视角"——可能"修了一个 bug"但"破坏另一个不相关的功能"。第二，"技术债务的指数级增长"——每次"局部修 bug"——"技术债务"都会"指数级增长"——最后代码"完全无法维护"。第三，"重构成本"——长期"拆东墙补西墙"后，"重构"需要"重写整个项目"——成本远超过"从一开始好好设计"。

这是 Vibe Coding 的"维护成本"——短期内"修 bug 快"——长期看"维护成本指数级增长"。

五、对 AI 编程工具的影响

这件事对 AI 编程工具（Cursor、Claude Code、Codex 等）有直接影响。

第一，"AI 编程工具"应"提供全局视角"——不应只关注"局部代码"——应"提供项目全局视角"——帮助开发者"理解"代码的"整体结构"。第二，"AI 编程工具"应"鼓励抽象"——不应"鼓励"重复生成代码——应"鼓励"抽象思维——让代码"精炼"和"低耦合"。第三，"AI 编程工具"应"避免引入新 bug"——修 bug 时应"全面测试"——避免"破坏不相关功能"。

六、对软件工程师的启示

这件事对软件工程师有几个直接启示。

第一，"架构能力"是核心竞争力——AI 能写"单块代码"——但"架构设计"仍是人主导——这是 AI 时代工程师的核心价值。第二，"抽象思维"是必备——AI 时代工程师应"保持抽象思维"——避免"被 AI 工具的便捷'诱惑'——丧失'抽象'的本能。第三，"代码 review"是关键——Vibe Coding 时代"代码 review"比过去更重要——"AI 生成的代码"必须"人工 review"——避免"局部优化破坏全局"。

七、对"AI 替代程序员"论的反思

这件事对"AI 替代程序员"论有重要反思价值。

第一，"AI 替代程序员"是"伪命题"——AI 能"生成代码"——但"软件工程"不只是"写代码"——还包括"架构设计"、"抽象思维"、"状态管理"、"复杂度控制"——这些是"AI 不擅长"的。第二，"AI + 工程师"是"未来"——不是"AI 替代工程师"——而是"AI 放大工程师"——能"用 AI 写代码的工程师"会比"不用 AI 的工程师"更高效。第三，"Vibe Coding 陷阱"是警示——过度依赖"Vibe Coding"会让代码"难以维护"——工程师应"在使用 AI"和"保持工程能力"之间找到平衡。

八、对"软件工程方法论"的启示

这件事对软件工程方法论有启示。

第一，"传统软件工程方法论"仍然重要——"抽象"、"解耦"、"低耦合"等"经典原则"——在 AI 时代仍然适用——不能"因 AI 工具便捷"就"放弃原则"。第二，"新软件工程方法论"需要发展——AI 时代需要"新的工程方法论"——比如"如何与 AI 协作写代码"、"如何评估 AI 生成代码质量"、"如何维护 AI 生成的代码"——这些都是"新方法论"需要回答的问题。第三，"工具不替代方法论"——AI 编程工具是"工具"——不能"替代"软件工程方法论——好的"方法论" + 好的"工具" = 好的"软件工程"。

九、我的评价

"Vibe Coding 陷阱"这个观察最让我认同的是它对"软件工程"本质的深刻理解。软件工程从来不是"写代码"——而是"管理复杂度"——AI 时代反而更需要"架构能力"、"抽象思维"、"全局视角"——这些是"AI 不擅长"、"人擅长"的领域。

这件事的更深意义在于——AI 时代的软件工程师不会被"AI 替代"——但"只会写代码的工程师"可能被"会用 AI 写代码 + 有架构能力的工程师"替代。能"用 AI 工具" + "保持软件工程能力"的工程师，会在 AI 时代获得最大优势。

十、反面观点

不过这件事也面临一些讨论。第一，"Vibe Coding"的进步——"Vibe Coding"正在快速进步——未来的"AI 编程工具"可能"内置全局视角"、"内置抽象检查"、"内置 bug 引入检测"——这些"陷阱"可能被"工具层面"解决。第二，"架构能力的 AI 化"——AI 在"架构能力"上也在进步——AlphaCode、Code Llama 等"专门架构 AI"在发展——未来"AI 架构师"可能成为现实。第三，"实际工作流的灵活性"——在"快速原型"、"短期项目"、"一次性脚本"等场景——"Vibe Coding"的"快捷"价值大于"长期维护成本"——不能"一刀切"反对"Vibe Coding"。