AI 时代,程序员还需要读源码吗?

— 当代码不再稀缺，什么才真正值钱

    以前面试程序员，经常会被问到一个问题：

    "你看过哪些优秀的开源项目源码？"

    Spring、Netty、Redis、MyBatis、JVM、Kafka……工作几年以后，多少都应该能说出几个。那个时候，大家普遍相信：真正的程序员，不能只会调用 API，还得知道这些东西底下到底是怎么工作的。

    所以我们读源码。研究线程池、JVM、网络、数据库、分布式。有时候为了搞明白一个问题，盯着几百行代码看一下午。

因为大家都觉得：

底层能力，决定一个程序员能够走多远。

    但 AI 出现以后，这件事情好像突然变得没那么重要了。现在遇到一个问题，可以问 AI。看不懂一个类，可以让 AI 解释。不知道一个框架怎么实现，可以让 AI 帮你梳理源码。甚至整个 GitHub 项目扔进去，让 AI 给你讲架构。

那么问题来了：AI 时代，我们还需要读源码吗？

❋ ❋ ❋

一、以前不会写代码，很多事情真的做不了

以前的软件开发有一个非常明显的门槛。你得会：

            编程语言框架数据库网络LinuxGit部署

哪怕只是做一个简单的网站，也得先跨过这些门槛。所以过去：代码能力，本身就是产品开发能力的重要组成部分。不会代码，很多事情真的做不了。

于是我们会花大量时间学习：

Java 怎么写 → Spring 怎么用 → MySQL 怎么优化 → Redis 为什么快 → JVM 怎么运行 → Netty 为什么性能高

这些东西不仅仅是为了"会用"。更重要的是：建立自己的技术认知。

❋ ❋ ❋

二、但 AI 正在把这个门槛一点点拆掉

AI 正在拆掉编程的门槛

现在情况完全不一样了。你告诉 AI：

"帮我做一个用户注册系统。"

✅ 可以。已生成完整代码。

"增加验证码。""接 MySQL。""增加后台管理。""帮我部署到服务器。"——它也已经可以参与。

于是一个以前很难想象的事情出现了：

一个不懂编程的人，也可以开始生产大量代码。

    我身边就有一个挺典型的例子。一个做运营的朋友，并不是传统意义上的程序员，但最近一直在用 Claude Code 做产品。有一次聊天，他跟我说：

"我已经用 Claude Code 写了几十万行代码，上线十几个产品了。"

    我当时其实挺震撼。因为按照以前的认知，一个非程序员想做十几个产品，至少得找程序员、找外包，或者自己花几年时间学开发。但现在，他只需要不断告诉 AI "我想要这个功能"，然后 "这里不对，改一下"，代码就这么一点点长出来了。而且最关键的是：产品真的上线了。

这件事情让我第一次非常强烈地意识到：

AI 可能真的正在改变"会不会写代码"这件事情的意义。

❋ ❋ ❋

三、当代码变得越来越便宜，问题就来了

以前写 1000 行代码，可能意味着你花了一天、两天，甚至更久。现在呢？AI 几秒钟就能生成出来。

    代码已经不是那么稀缺了。甚至只要 Token 足够，一个不会传统编程的人，也可能让 AI 生成成千上万行代码。所以我越来越觉得：

未来真正稀缺的，可能不是"写代码"

而是：理解代码，以及 判断代码

❋ ❋ ❋

四、这也是为什么我重新想到了"读源码"

以前我们读 Spring 源码，是为了知道 Spring 到底是怎么实现的；读 Netty，是为了知道为什么它能做到这么高的性能；读 Redis，是为了知道它为什么这么快。

那个时候，读源码本身就是一种学习编程的方式。但 AI 出现以后，读源码的意义可能正在发生变化。

以前：你不知道怎么实现 → AI 可以告诉你。你看不懂源码 → AI 可以给你解释。你甚至可以让 AI 帮你画整个调用链。

现在真正重要的问题：为什么要这么写？

"知道代码怎么写出来"这件事情，正在变得没那么稀缺。真正重要的问题变成了：为什么要这么写？

❋ ❋ ❋

五、"怎么写"和"为什么这么写"，是两种完全不同的能力

比如 AI 给你生成一个缓存系统。代码 3000 行，能运行，测试也通过。但你有没有想过：

    ❓ 为什么这里用 Redis？    ❓ 为什么这里设置这个过期时间？    ❓ 为什么这里需要本地缓存？    ❓ 为什么这里用了消息队列？    ❓ 为什么这里需要分布式锁？    ❓ 为什么这个地方不能直接查数据库？

AI 都可以给你一个答案。但真正的问题是：

这个答案到底适不适合你的系统？

    🚨 比如线上突然出现：

    • CPU 100%    • 数据库连接池耗尽    • Redis 命中率下降    • 接口 RT 从 50ms 变成 2s

    你把问题丢给 AI，它可能给你十个解决方案。但最后还是需要有人判断：到底应该改哪个？

❋ ❋ ❋

六、"能跑"和"真正可用"，中间差着一整个软件工程

这可能是我做了十几年开发以后，越来越深的一种感受。能跑的代码，其实很多。真正困难的是：能不能长期跑。

✅ 一个 Demo：能启动 → 能登录 → 能增删改查 → 看起来就已经成功了

⚠️ 但一个真正的生产系统，还要考虑：并发 · 性能 · 稳定性 · 安全 · 数据一致性 · 异常处理 · 监控 · 扩展性 · 容灾 · 成本

这些问题，不是"能不能生成代码"就能解决的。而且系统越大，问题越复杂。

一个小项目，AI 可以帮你从零写出来。但当它变成几十个服务、几百张表、几千万甚至几个亿的数据之后：代码量增加，并不会让系统设计自动变得正确。

代码只是冰山一角，真正的能力藏在水面之下

❋ ❋ ❋

七、所以我反而觉得，AI 会让程序员出现更明显的两极分化

第一类人：

需求 → AI → 代码 → 报错 → 继续问 AI → 继续生成

短期来看，效率可能非常高。一个人真的可以做以前一个小团队才能做的事情。

第二类人：

理解需求 → 设计系统 → 让 AI 生成 → Review → 测试 → 发现问题 → 继续让 AI 修改

这两类人的区别不在于：谁更会用 AI。而在于：谁知道 AI 生成的东西到底对不对。

❋ ❋ ❋

八、这时候，真正的"底层能力"反而可能变得更重要

所以我现在越来越不赞同一种观点："AI 都能写代码了，还学什么计算机基础？" 恰恰相反。我觉得：AI 越强，底层能力越重要。

但这里的"底层能力"，和过去可能有一点区别。

以前的底层能力：数据结构 · 算法 · JVM · 网络 · 操作系统 · 数据库 · 分布式

现在多了一层：系统理解能力

你不一定需要亲手写出一个线程池。但你应该知道线程池解决什么问题。你不一定需要自己实现 Redis。但你应该知道缓存可能带来什么问题。你不一定需要自己写一个 HTTP Server。但你应该知道一次请求到底经历了什么。

AI 可以替你写实现，但很难替你承担最终的判断。

❋ ❋ ❋

九、所以，AI 时代还需要读源码吗？

我的答案还是：需要。

但我不建议再像过去那样："我要把 Spring 源码全部啃完"，然后从第一个类开始，一行一行往下读。这其实没有太大必要。

以后读源码，我觉得反而应该更加"功利"一点：

    ❓ 为什么 Netty 性能这么高？→ 去读。    ❓ Redis 为什么这么快？→ 去读。    ❓ Spring AOP 到底怎么实现？→ 去读。    ❓ 一个 Agent 是怎么工作的？→ 去读。

    带着问题去读，而不是为了证明自己"读过源码"。

❋ ❋ ❋

十、因为真正值得保留的，可能不是"读源码"本身

而是读源码背后的那种能力：面对一个复杂系统，愿意沉下心去理解它。

这件事情，AI 很难完全替代。

✅ AI 可以：搜索 · 总结 · 解释 · 生成 · 重构 · 甚至帮你阅读整个项目

❓ 但最后还是会有一个问题：它说的是真的吗？

你必须有能力判断。而判断从哪里来？来自长期积累的知识，来自大量实践，也来自那些曾经一个人啃过的源码、踩过的坑、排查过的线上事故。

❋ ❋ ❋

十一、我反而觉得，未来程序员最值钱的能力可能变了

以前我们经常讨论：谁写代码最快？以后可能越来越少有人关心这个问题。因为 AI 写得比人快。

未来真正值得比较的是什么？

    💡 谁能提出更好的问题？    💡 谁能设计更合理的系统？    💡 谁能发现 AI 代码里的问题？    💡 谁能判断一个技术方案到底适不适合自己的业务？    💡 谁能在系统出问题的时候找到真正的根因？

以前：想法 → 程序员 → 代码

以后：想法 → 程序员 → AI → 大量代码

代码这一层正在越来越便宜。而：想法、设计、理解、判断、验证——这些东西，反而越来越重要。

❋ ❋ ❋

十二、所以 AI 到底让程序员变强了，还是变弱了？

我觉得两种情况都有。

对于真正懂软件工程的人：

AI 是放大器。以前一天完成一个功能，现在可能一天完成五个。以前一个人只能维护一个项目，现在可能同时推进多个项目。AI 把他的能力放大了。

但对于完全不理解代码的人：

AI 更像一个非常强大的"拐杖"。短期确实可以走得很快。但如果永远不自己走，最终可能连自己为什么摔倒都不知道。

所以我更倾向于认为：AI 会把"能力差距"放大。懂的人，会越来越强。不懂的人，也许可以在短期内看起来很强，但项目越复杂，这个差距越容易暴露出来。

❋ ❋ ❋

十三、代码越来越多，并不等于能力越来越强

这句话可能有点残酷。但我越来越相信：

写了几十万行代码，不等于你拥有了几十万行代码对应的能力。

代码可以由 AI 生成。但系统复杂度不会因此消失。一个人可以在几天之内生成几十万行代码，但他仍然可能不知道：

    ❓ 为什么这么设计？    ❓ 哪里可能出问题？    ❓ 哪个地方是瓶颈？    ❓ 哪个地方不能改？    ❓ 线上为什么会崩？    ❓ 以后怎么扩展？出了问题怎么回滚？

代码生成的速度已经突破了过去的瓶颈。但人的理解能力没有。

━━━━━━━━━

最 后

所以，如果现在再问我："AI 时代，程序员还应该读源码吗？"

我的答案是：应该。

但不是为了成为一个"源码背诵者"。也不是为了面试的时候能够说："我读过 Spring、Netty、Redis。" 而是为了训练一种越来越重要的能力：理解复杂系统。

AI 可以帮你写代码，可以帮你读代码，可以帮你解释代码，甚至可以帮你重构代码。但至少现在：它还不能替你承担最终的判断。

未来真正值钱的程序员，可能不是那个：

写代码最快的人。

而是那个：

知道什么时候应该让 AI 写，什么时候不能让 AI 写；知道 AI 给出的代码哪里值得相信，哪里必须怀疑；更知道一个系统为什么应该这样设计，而不是那样设计。

以前：底层能力 = 你能不能自己把代码写出来

现在：底层能力 = 即使代码不是你写的，你仍然能看懂、能判断、能驾驭它

也许这才是 AI 时代，程序员真正应该留下来的东西。

━━━━━━━━━

最后留一个问题

如果现在重新给你三个月时间。你会选择：

A：花三个月认真读一个优秀开源项目的源码。

B：把这三个月全部交给 AI，直接做十个产品？

我现在也没有标准答案。但我越来越觉得：

    AI 可以替我们节省大量"写代码"的时间。但我们不能把省下来的时间，也一起交给 AI。因为那部分时间，可能正是一个程序员真正建立自己能力的时间。