1天前
|
|
|
**摘要：** AI 编程的挑战不在于技术债务，而是“理解债务”。当 AI 生成大量代码时，人类开发者理解和审查代码的难度会急剧增加，这可能导致日后维护和调试的巨大困难。本文探讨了 AI 如何加剧理解债务，以及如何通过前置规划和协作来规避这一风险，从而实现真正的工程效率提升。
---
AI 编程到底有什么坑？很多人觉得 AI 编程最大的问题是“技术债”，但作者 Paul Sangle-Ferriere 在他的文章里提出了一个更深刻的观点——真正的难题是“理解债”。
### 什么是“理解债”？
简单来说，就是我们（人类）越来越难理解 AI 生成的代码了。想想看，以前我们自己写代码，一行一行敲下去，脑子里对逻辑、权衡、各种可能性都门儿清。写完一段代码，我们知道为什么这么写，也知道为什么没选别的方案。
但现在呢？AI 一下子就能给你生成几百行代码。我们拿到手，表面上能看懂它在做什么，但那种深入骨髓的理解，那种“我就是这么想的”的感觉，就没那么强了。这就像你直接看一本微积分教材，和自己动手解题，感觉是完全不一样的，对吧？
更要命的是，AI 生成的代码量特别大。以前可能需要工程师花几个小时琢磨的代码，现在 AI 几秒钟就搞定了。这一下子就把我们“反向工程”的难度放大了无数倍。我们不是在理解一个函数，而是在理解整个系统，而且是别人（AI）的“思维”。
### “理解债”什么时候会爆发？
想象一下，几个月后，生产环境出了个 bug。你尝试用 AI 去修复，结果 AI 自己也懵了，陷入“死亡循环”。你只能硬着头皮去调试那些你从未真正理解过的代码。
作者举了个例子，有个团队本来一个小时就能搞定的问题，因为之前用了 AI 生成代码，结果花了整整三天去理解代码，最后损失了 70 个小时！这就是“理解债”的利息，你前期省下的时间，后面会连本带利地还回来。
### 那些“聪明”的团队是怎么做的？
别担心，总有办法解决的！那些最聪明的团队，他们在写代码之前，就已经把这个问题考虑进去了。
他们怎么做呢？不是简单地给 AI 下个指令然后就等着结果。他们会花大量时间跟 AI 一起做“前期规划”。一起讨论高层设计，一起考虑各种边界情况，在 AI 开始“敲代码”之前，就一起把代码的“样子”给定了。
这样做的好处是双重的：
1. **AI 写出更好的代码：** 因为你给了 AI 更多的上下文，帮它想清楚了各种细节，它自然就能写出更干净、更符合架构的代码。
2. **人真正理解代码：** 这点更重要！因为是你主导了设计，是你做了关键决策，AI 只是帮你把想法实现了。这样一来，代码在你手里，你就心里有数。
在代码审查阶段，像 cubic 这样的工具就能帮你抓抓语法错误、安全问题什么的，让你能把精力集中在真正重要的——验证逻辑和架构理解上。
### 工程效率的新瓶颈
随着代码生成越来越便宜、越来越容易，软件工程的瓶颈也悄悄地转移了。
以前我们担心的是“能不能写出代码？”现在，几乎所有团队都能每天生成成千上万行代码，这已经不是限制了。
真正的限制变成了：“我们能不能足够快地理解我们写的代码，以便继续前进？”
你能不能在不埋下维护噩梦的前提下，发布 AI 生成的代码？它出错了，你能不能修？需求变了，你能不能改？新来的同事，能不能快速上手一个他们没写过、AI 也只解释了个大概的代码库？
很多团队还没意识到这个转变，他们还在拼命优化代码生成速度，却不知道“理解债”正在悄悄累积。
### 谁会是最后的赢家？
那些始终把“理解”放在首位的团队，才能在加速的同时，规避风险。
他们会用 AI 加速写代码，但同时也会投入精力去理解写出来的东西。他们会把代码审查看作是“理解验证”，而不是单纯的“抓 bug”。他们会优先和 AI 讨论架构，而不是直接让 AI 去实现。他们会构建可维护的系统，而不仅仅是快速发布。
至于其他人嘛……他们可能会越跑越快，直到最后被自己堆积如山的、难以理解的代码淹没。
2010 年代的技术债危机，跟我们即将面临的“理解债”危机比起来，可能都显得“小巫见大巫”了。至少那时候，代码出了问题，团队里总有人是理解它的。而现在，很多代码，可能真的没人完全理解了。
大家对这个“理解债”有什么看法？你有没有遇到过类似的情况？欢迎在评论区聊聊你的经验和想法！
🫵 来啊，说点有用的废话!
▲
