一年之后，重新理解 AI 编程

效率提升的表象之下

我们项目引入 AI 编程已经整整一年了。翻看提交记录，一个直观的感受是：效率确实上去了。功能迭代速度变快，需求排期一再压缩，老板对"用了 AI 应该更快"这件事似乎已经默认成了新的基准线。但当我真正静下心来审视这一年的代码库时，一种隐隐的不安浮现出来——我们提交、合并、发布了大量 AI 生成的代码，可我们真的理解这些代码吗?

没人真正理解的代码

答案并不乐观。很多时候，AI 给出一段能跑通、能通过测试的代码，大家看一眼逻辑大致对得上，就直接合并了。至于这段代码在边界条件下会不会出错，异常处理是否完备，和系统里其他模块的隐性约定是否冲突，很少有人真正逐行推敲过。换句话说，我们把"能跑"当成了"正确"的替代品。这在项目早期，业务逻辑相对简单时，问题还不明显——即便有坑，影响范围也有限，发现了改一改就过去了。

但一年下来，业务复杂度是指数级增长的。模块之间的依赖越来越深，历史遗留的假设越来越多，一个看似无害的改动，可能悄悄破坏了三个月前另一个功能里的隐含约定。这时候，"没有人真正理解代码"这件事的代价开始显现：排查一个线上问题，常常要先花大量时间搞清楚"这段 AI 写的代码到底想干什么"，然后才能着手修复。团队对代码库的整体心智模型，变得越来越模糊、越来越依赖"问 AI"而不是"自己想清楚"。

暴露出来的人性之懒

这里有一个值得诚实面对的现象：程序员为什么会走到这一步?很大程度上，是因为老板催得紧，任务排期不给人留出"理解"的时间。当交付压力足够大，而 AI 又能在几秒钟内给出一段"看起来对"的代码时，选择相信它、跳过审查、直接提交，几乎是一种本能反应。这不是某个人偷懒，而是人性在效率压力下的必然选择——趋易避难，谁都一样。AI 编程工具在这个意义上，像一面镜子，把这种"人性之懒"毫不留情地照了出来。

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

但这不代表 AI 编程本身有问题，问题在于我们使用它的方式。一年的经验让我逐渐明白，AI 编程真正的价值，不在于让人可以不再理解代码，而在于让理解代码这件事变得更快、更轻松。

如果把 AI 当成一个可以完全托付信任的"黑箱工人"，迟早会在复杂系统里踩到无法预料的坑；但如果把 AI 当成一个可以随时追问、随时要求解释、随时一起推演边界情况的"结对伙伴"，它反而能倒逼我们比过去更快地建立起对代码的深层理解。

一种新型技术债：理解债务

如果再往深处想一层，这一年真正积累下来的，其实是一种新型的"技术债"——不妨称之为"理解债务"。传统技术债是"代码写得不够好，以后要还";理解债务则是"代码可能写得还不错，但没人真正懂它，以后一定要还，而且利息更高"。这种债务的可怕之处在于它极具隐蔽性：代码能跑、测试能过、评审也走完了流程，表面上一切正常，债务却在悄悄积累，直到某次线上故障把它连本带利地摆到所有人面前。

生成与理解之间的鸿沟

更值得警惕的是一种结构性的"不对称"。这一年里，写代码的速度提升了数倍，但理解代码、建立心智模型的速度几乎没有变化——人脑理解复杂逻辑的带宽，并不会因为工具进步而扩容。于是"生成"与"理解"之间的鸿沟只会越拉越大：代码库膨胀的速度，远远超过了任何人能够真正吃透它的速度。长此以往，项目会变成一片由无数 AI 生成的补丁拼接而成的"珊瑚礁"，每个人只熟悉自己碰过的那一小块，却没有人拥有整体地图。

责任稀释与能力退化

还有一层容易被忽略的代价，是责任的稀释和能力的退化。过去代码出问题，至少能追溯到"是谁写的、他当时怎么想的";现在很多时候，大家只能说"是 AI 生成的"，却说不清楚是谁在什么场景下批准了它上线。责任变得模糊，追责变得困难，也就更难从错误中真正吸取教训。与此同时，那些原本应该在"写代码、调试代码、和复杂逻辑较劲"的过程中锻炼出来的能力——尤其是对新人而言——正在被悄悄跳过。写出漂亮代码的门槛降低了，但理解复杂系统的肌肉，却没有得到应有的锻炼机会，这是一种更隐蔽、也更长期的能力透支。

被拿走的摩擦力

还有一个更容易被忽视的机制性变化，值得单独拿出来讲：AI 拿走的不只是"打字的时间"，更是"打字过程中顺带发生的思考"。过去写一段复杂逻辑，哪怕水平有限，手指敲键盘的那几分钟里，大脑也在被迫过一遍分支条件、变量含义、异常场景——这是一种"边写边想"的天然摩擦力，慢，但扎实。AI 把这层摩擦力完全抹平了：代码几秒钟生成，思考的强制过程也随之消失。如果不主动把这部分思考找补回来，它就不会自动发生。这也是为什么"理解债务"会积累得如此之快——不是大家变懒了，而是原本免费依附在"写代码"这个动作上的思考，现在需要额外花力气才能获得。

没有记忆的协作者

更深一层的问题在于，AI 本身没有制度记忆。一段两年前写下的"奇怪代码"，背后往往藏着某次线上事故的教训、某个客户的特殊要求、某次团队争论后的妥协——这些原因通常不会写进注释，而是活在写代码的人的记忆里。AI 生成新代码时，并不知道这些历史，它只是在"当下这个上下文"里给出一个看似合理的答案。于是代码库里开始出现一种奇怪的分裂：表面上风格统一、写法工整，因为都出自同一个模型的"手笔"，但这种一致性是假象——它掩盖了背后完全没有被继承的历史教训。团队原本靠人传人积累起来的隐性知识，正在被这种"看起来很像但其实没有记忆"的协作方式悄悄稀释。

评审正在变成仪式

最后一点，或许最刺痛：代码评审这道本该兜底的防线，正在慢慢演变成一种仪式，而非真实的把关。评审人自己也在赶进度、也在用 AI，也没有时间真正读懂每一行逻辑，于是"评审通过"这个动作，渐渐从"我确认理解并认可这段代码"退化成"这段代码格式正确、测试通过、没有明显语法问题"。当"评审通过""测试通过"这些本该是理解程度的代理指标，反过来变成了大家追逐的终点本身，真正的理解就被系统性地挤出了流程之外——这是一种典型的目标替代：我们优化的是"看起来合规"，而不是"真的搞懂了"。

把 AI 当作陌生的外部贡献者

从这个角度看，或许更健康的做法，是不要把 AI 当作"值得信任的同事"，而是把它当作"一个来历不明的外部贡献者"——它的每一次提交，都应当像评审一份陌生人发来的 Pull Request 一样，带着审视而非默认的信任去对待。这种心态上的转变，可能比任何工具和流程上的调整都更重要。

结语

回头看这一年，最大的教训或许是：AI 编程带来的效率提升是真实的，但它同时放大了一个更早就存在的问题——我们对"交付速度"的追逐，一直有意无意地压缩着"深入理解"的空间。AI 只是让这个矛盾变得更加尖锐、更加无处遁形。真正值得我们思考的，不是要不要用 AI 编程，而是如何在使用它的同时，重新为"理解"找回应有的位置。

毕竟，代码可以让机器帮我们写，但代码背后的责任，终究还是要由写代码的人来扛。