当一切都可以用 AI 写出来之后，我们正在制造什么？

最近一段时间，我在团队里观察到一个明显的变化。

几乎所有人都在用 AI 写代码。

需求来了，先问 AI；接口不会写，丢给 AI；报错了，把日志贴进去，让 AI 修；甚至连系统设计、脚本、工具，也越来越多地由 AI 直接生成。

短期来看，这是一种极高效的生产方式。
代码可以快速跑起来，功能可以迅速上线，很多原本需要查文档、翻源码、反复调试的工作，被压缩成了几次对话。

但也正因为如此，一些问题开始慢慢浮现。

而这些问题，大多数并不会在当下爆发。

---

一、代码在“可运行”之外，几乎没有任何约束

现在的一个常见状态是：

• 代码只要能跑通，就算完成
• 很少有人主动做结构优化
• 几乎没有统一的风格约束
• 代码的“为什么这样写”，没有人关心

AI 可以给出“正确答案”，但不会对“长期维护成本”负责。

于是我们逐渐得到的是：

• 重复实现的逻辑
• 风格混乱的模块
• 命名随意的函数
• 边界不清晰的职责划分

这些代码在今天是“高效产出”，但在未来，很可能变成“不可理解的遗留系统”。

---

二、工具和 Agent 正在野蛮生长

另一个更隐蔽的问题，是工具层面的失控。

每个人都在搭自己的 Agent：

• 有人做报表自动化
• 有人写数据同步工具
• 有人搞一套自己的分析系统
• 有人封装了一堆内部脚本

这些东西本身没有问题，问题在于：

它们彼此之间没有任何统一规划。

没有统一入口，没有统一权限模型，没有统一数据规范，甚至连“是否重复造轮子”都没人知道。

短时间内，这种方式极大提升了个人效率。

但长期来看，它会带来几个非常现实的问题：

• 功能重复，但没人敢删
• 工具依赖个人，一旦离职直接失效
• 数据口径混乱，多个系统结果不一致
• 出问题时，没有人知道从哪里查起

这不是技术问题，这是“系统失控”。

---

三、知识没有沉淀，只有堆积

过去我们会写文档，是因为代码难懂。

现在代码是 AI 写的，看起来“好像很清晰”，于是文档反而被忽略了。

但问题是：

AI 写的代码，你真的理解吗？

很多时候，我们只是“用得动”，而不是“看得懂”。

于是出现了一种很微妙的状态：

• 代码越来越多
• 工具越来越多
• 但真正被理解的内容越来越少

知识没有沉淀，只是在堆积。

当某一天需要系统性修改、重构、迁移时，就会发现：

没有人敢动。

---

四、维护成本不会消失，只是被延后了

AI 并没有减少复杂度。

它只是把“写代码的成本”，转移成了“未来维护的成本”。

今天省下来的时间，未来可能以更高的代价偿还：

• 一个看似简单的改动，引发连锁问题
• 一个工具无人维护，只能重写
• 一个系统没人理解，被迫推倒重来

更关键的是，这些问题往往是在“系统已经很大之后”才出现。

那时候，代价已经不是优化，而是灾难恢复。

---

五、我们可能正在制造“高科技垃圾”

如果用一个不太好听但很真实的词来形容当前的趋势：

我们正在制造一批“高科技垃圾”。

它们具备：

• 完整的功能
• 看起来合理的代码
• 可以运行的系统

但缺少：

• 设计约束
• 统一规范
• 可持续维护能力

这些东西不会立刻崩溃，但会逐渐变得难以使用、难以修改、难以信任。

最终，它们会被遗弃，然后再被新的一批 AI 生成物替代。

循环往复。

---

六、问题不在 AI，而在使用方式

需要明确的一点是：

问题不在 AI。

AI 本质上只是一个放大器。

• 好的工程习惯，会被放大
• 坏的工程习惯，也会被放大

如果团队本身缺乏规范，AI 会让这种无序以更快的速度扩散。

如果团队有清晰的工程体系，AI 则会成为非常强大的生产力工具。

---

七、也许我们需要一些“减速机制”

在当前这种高速增长的阶段，也许真正需要的不是更快，而是一些“刹车”。

例如：

• 最基础的代码规范和 review 机制
• 工具和 Agent 的统一登记与管理
• 明确哪些系统是“正式资产”，哪些只是“个人实验”
• 对核心模块建立 ownership，而不是“谁都能改一点”

这些东西听起来很传统，但在 AI 时代反而变得更重要。

因为生产已经不是瓶颈，失控才是。

---

结尾

AI 让“创造软件”这件事变得前所未有的容易。

但也正因为如此，我们更容易忽视软件工程本身的约束和边界。

如果没有这些约束，规模一旦上来，问题不会消失，只会被放大。

也许现在一切都还运行良好。

但真正的问题，从来都不是“现在能不能跑”，而是：

当系统变成现在的十倍、百倍时，我们是否还掌控它。