AI 生成代码很快，但读懂它才是真正的成本
最近看到一篇文章《写代码很简单，读懂它才是难事》，深有共鸣。
文章的核心观点是：写代码是件容易事，但真正的难点在于读。你需要花时间在脑海里构建起对整个系统的认知地图，这才是所有成本的真正所在。
但 AI 时代的到来，让这个矛盾变得更加尖锐。
AI 让"写"变得更容易，但"读"的成本没有降低
AI 确实让写代码变得前所未有的快。以前需要几小时才能实现的功能，现在几分钟就能生成出来。让大语言模型帮你写出整个函数？那就更容易了。
但问题是，读代码的成本没有降低，反而增加了。
为什么？因为 AI 生成的代码缺少"思考过程"。
当你自己写代码时，你经历了完整的思考过程：
- 为什么要这样设计？
- 为什么选择这个算法？
- 为什么这样处理边界情况？
- 为什么这样命名变量？
但 AI 生成的代码，你看到的是结果，不是过程。就像继承别人的游戏存档，结果一上来就直接被扔进 Boss 战的战场中央，你不知道前面经历了什么。
心智模型的构建成本
《写代码很简单，读懂它才是难事》中提到了"心智模型"的概念：它是你对系统如何工作的内部地图，上面标注着哪些地方是雷区，哪些东西依赖于另一些东西。
AI 生成的代码同样需要构建心智模型，但这个过程更加困难。
缺少上下文
AI 只看到你给的提示，不了解整个系统的架构。它可能：
- 选择了不合适的库
- 使用了与现有代码风格不符的写法
- 引入了你不需要的依赖
- 忽略了系统的性能要求
风格不一致
不同时间生成的代码可能风格迥异。今天生成的函数用 async/await，明天生成的用 Promise.then()。这种不一致性让代码更难理解。
隐藏依赖
AI 可能引入你不知道的库或模式。你看到一个简单的函数，但要理解它，你需要：
- 追溯这个函数在哪里定义
- 理解它返回什么数据结构
- 知道它如何与数据库交互
- 了解它有没有副作用
- 搞清楚还有谁在调用它
为了理解一个 AI 生成的函数，你常常需要查看其他五个文件。
真正的成本在哪里
让我们看看 AI 时代软件开发的成本分布：
写代码：从几小时缩短到几分钟
这是 AI 的贡献。以前需要学习语法、查找文档、调试错误的时间，现在几乎为零。
读代码：依然需要几小时甚至更久
AI 没有解决这个问题。你仍然需要：
- 理解代码的意图
- 分析代码的结构
- 追踪代码的依赖关系
- 理解代码的副作用
调试：更难了
因为你不知道 AI 的"思路"，调试变得更加困难。当代码出错时，你不知道：
- AI 为什么这样写？
- 这个边界情况 AI 考虑了吗？
- 这个性能问题 AI 知道吗？
维护：更难了
因为你没有经历构建过程，维护变得更加困难。当需要修改时，你不知道：
- 这个修改会影响哪些地方？
- 这个设计决策可以改变吗？
- 这个依赖关系可以优化吗？
软件开发的瓶颈从"写"转移到了"理解"。
如何更好地使用 AI
既然理解成本无法避免，我们如何更好地使用 AI？
让 AI 帮助理解，而不只是生成
与其让 AI 生成大段大段的代码，不如让它帮助我们理解现有的代码：
- 让 AI 解释现有代码：把复杂的函数丢给 AI，让它解释逻辑
- 让 AI 生成文档和注释：让 AI 为现有代码添加说明
- 让 AI 分析代码结构：让 AI 分析代码的依赖关系和调用链
控制生成规模
- 小块生成，逐步验证：不要一次性生成整个模块
- 避免让 AI 生成整个模块：保持对代码结构的控制
- 理解后再使用：不要直接复制粘贴
保持参与感
- 不要直接复制粘贴：理解后再使用
- 必要时手动重构：把 AI 生成的代码改造成你理解的样子
- 保持代码风格一致：建立团队的代码规范
对未来的思考
我们需要的不是"更快的代码生成器"，而是"更好的理解工具"。
AI 的下一个突破应该在"帮助理解"而非"帮助生成"。
想象一下，如果 AI 能够：
- 瞬间分析整个代码库的结构
- 自动生成代码的依赖关系图
- 智能识别代码中的设计模式
- 自动检测代码中的潜在问题
那才是真正的革命。
编程的未来，可能不在于更快地生成更多代码，而在于更快地生成"理解"。
写在最后
AI 改变了写代码的方式，但没有改变软件开发的本质。
理解和维护依然是核心成本。我们解决了"打字速度"的问题，现在我们能生成的代码，远比我们能读懂的要多得多。
但除非我们解决了"理解"的问题，否则软件开发的成本依旧没变：它还是取决于一个人需要花多长时间才能搞懂这一切。
明智地使用 AI：让它加速理解，而不只是加速生成。
这才是 AI 时代程序员的正确姿势。
如果你也在使用 AI 编程工具，欢迎分享你的经验和困惑。我们可以一起讨论如何在快速生成和深度理解之间找到平衡。