我们都在选择性忽视AI coding房间里面的大象

本文前半部分由人类编写，后半部分由AI辅助语言优化

今天，无论从是资本家，还是到文科生，都沉浸在 vibe coding 、技术平权等宏大的术语当中，高声大喊 "软件工程将不复存在" , 股票再创新高！

代码的脆弱性

但是所有人似乎都在选择性地忽视 Coding Agent 领域里“房间里的大象”，那就是代码劣化。不管是codex 5.4还是Claude Opus 4.6, 随着代码仓库变大，架构变得混乱不堪，大量重复的逻辑，散落在各个角落的bug，终究会更快地堆积成屎山, 这种由于彻底放手，让AI彻底自由发挥，而导致的“屎山”迅速积累，终究会在某一刻爆发。

软件工程没有银弹

有很多人在举例：我的项目已经达到了10万行，全都是拿 AI 写的。其中不乏一些看起来比较资深的程序员。

但是，如果你们仔细看看你们的AI编程的项目，难道就没有发现这个项目其实 5 万行甚至就可以搞定？可以编写得更加健壮，性能更好，架构也更好, 也更加可维护。

AI编程更多的是临摹

这个地方是我最近的另外一个比较大的感受，其实感觉也不一定准确，这个部分轻喷。

• 很多 Coding 模型在发布时都会提供一些样例，比如迅速做出一个贪吃蛇或 Flying Bird。
• 一个产品经理可以拿它快速写出一个网页，TODO APP，甚至更复杂的邮件发送程序。

然后我们都在惊叹，AI 自己居然连这个都能写出来，它把它"创造"了出来这个代码。

但其实有没有一种可能：这个东西在 GitHub 上本来就已经存在了？AI更准确来说，是把它给抄下来了，我们无需惊叹，AI在30分钟就能帮我写一个cloudflare上面发邮件的程序，因为这个在GitHub上早就有了，你要是找到了原仓库，git clone下来只要1s，还不要钱。

你的绝大部分需求，在GitHub上都有人给你实现了，只不过在这数千万的仓库当中你找不到它，它也没写 README，如果你找到了他，压根不需要一声声对话，给claude充钱。

奖励函数的缺陷

我们回到这个 Coding Agent 底层的 AI 来观察一下，它到底是如何进行训练的。

目前的 Coding Agent 训练主要依赖于功能实现率（如通过修补 Bug 或完成单元测试）作为核心奖励信号。这种模式倾向于从海量仓库中学习“补丁式”的解决方案，其本质是一种基于结果的二元反馈：只要代码运行通过，AI 就会获得正向激励。

这种“单一奖励”机制忽略了软件工程中至关重要的非功能性需求。代码的产出过程往往缺乏对以下维度的考量：

• 架构合理性： 是否符合设计模式，是否存在过度耦合？
• 性能边界： 时间与空间复杂度的最优解，而非仅仅是“能跑通”。
• 可维护性与扩展性： 命名规范、注释质量以及对未来功能演进的支撑。

“AI 偷懒”引发的长期技术债

这种只关注“瞬间功能交付”的模式，本质上是 AI 在执行层面的“贪婪搜索”。它利用大规模参数量寻找实现功能的捷径，却剥离了工程美学与系统深度。这种短期主义的效率提升实际上是一种“研发贷款”：虽然初期开发速度惊人，但其产出的低质量代码会迅速转化为沉重的技术债。

你节省的时间终将10倍奉还回去

一个健康的系统应当充分规划，合理设计架构。当我们在前期就让AI草率地完成各个功能，看都不看一眼，后续维护时所需的资源投入，往往会数倍于 AI 节省下来的开发时间。