AI 都这么强大了，还需要去阅读理解源码吗？

在上篇文章谷歌出品，必属精品，又一源码阅读利器来了中，我介绍了一款谷歌出品的辅助阅读开源代码的 AI 工具。可能很多人会想：AI 都这么厉害了，还有必要去读源码吗？直接让 AI 去理解、修 BUG，不就行了吗？

听起来很美好，但现实可没那么简单。

我们团队在今年做了一次尝试，使用AI扫描Wine项目的源码，试图借助AI找出程序中隐藏的bug。AI倒是挺卖力，找出了很多“bug”。问题是扫描出的“bug”大多数是C语言中一些不安全的写法，比如要用snprintf替代不安全的sprintf。当然使用安全的替代函数最好，但是这样的代码太多，而且很多时候程序员在使用sprintf这样的函数前，已经确保缓冲区不会溢出。因为这类的问题太多，又需要人工去筛选，以确定是不是真的值得修改，这也会是很大的工作量。

其实这个问题在开源届也碰到了，有人借助AI提了很多issue，要分辨这些issue是不是真的问题，耗费了项目维护者大量的时间，导致真正干活的开发者不堪重负。

不久前，CURL开源项目就公开diss了谷歌公司。抱怨谷歌公司用AI提了issue，又不肯投入人力去修复。

那使用AI来修复问题呢？目前照样不可行。比如wine项目中存在大量FIXME的地方，通常是某个Windows API还没在wine中实现。我们就想，AI对Windows API的理解肯定比我们深，那让AI来补充这些实现如何？结果惨不忍睹。

AI 看代码的速度比人快得多，它可以瞬间定位 BUG，甚至帮你写出修改方案。但有些跨模块、跨库的隐性依赖，它可能根本看不出来。特别是一些Windows API的行为，文档描述得不清楚。我们需要写一些测试代码，在Windows上跑一跑，才能猜测出该如何正确模拟，这种AI就特别难处理。

某种意义上，AI 就像一个超厉害的“自动修车机器人”，它能迅速换掉坏掉的零件，但如果整车的设计有问题，它可能帮你修好了一个零件，整车还是容易出故障。

还有，我们都是在有限资源条件下去解决问题。就拿使用AI来说，可能不断加大上下文，更长时间的推理，写出的代码质量更高，能解决更多的问题。可现实情况是，即使使用最高级的AI套餐，对上下文长度都有限制，对深度思考也有次数和时间限制。如果能够无限算力、无限时间，可能AI能做的事情更多，可如果这样付的成本都超过人力成本，那估计也没人愿意使用AI。

当然，目前AI能取代初级程序员。随着AI越来越强大，从趋势上看，AI取代程序员上迟早的事情，但不是现在。

之前写过一篇文章：

用上 AI 之后，感觉自己越来越像老板了

以后，程序员的角色将转化成决策者。也就是说AI给出方案，甚至实现，由开发者判断方案是否靠谱。如果AI提供了多种方案，决定使用哪一种方案。

对程序员来说，读源码不仅是解决问题的手段，更是成长的阶梯。你在阅读中会发现不同的设计模式、编码风格和工程思路，这些都是 AI 无法替代的。完全依赖 AI，就像只会跟着导航走的司机，永远学不到开车的本事。

不可否认，AI 是个超级助手。它可以帮你画调用关系图、生成函数注释、分析依赖，节省大量重复劳动。

所以以后程序员工作的方式，可能是：AI 做重复劳动，你专注理解核心逻辑。AI 就像你的贴身秘书，帮你整理资料、算账、查信息，但最后决策和理解，还得靠你自己。

你会担心AI取代自己吗？欢迎留言谈谈你的看法。