最近看到一个观点：AI 来了，人类反而更要多读书。
这个观点乍一看有点反直觉。因为现在很多事情确实可以直接问 AI，比如一本书讲了什么、某个概念怎么理解、甚至可以让它直接给出总结、观点和行动建议。
如果只是为了获取一个答案，AI 的效率确实比自己翻书高很多。
但用 AI 用得越多，我越觉得问题不在于 AI 能不能给答案，而在于我还能不能判断这个答案是否靠谱。
从惊艳到反复横跳
我从网页版本的 ChatGPT 一路用到现在的 Cursor、Claude Code、Codex，对 AI 编程的态度其实反转过好几次。
一开始肯定是惊艳的。
以前写一个功能，要自己找组件、接接口、处理状态、处理错误边界。现在把需求丢给 Agent，它可以自己读项目、改文件、跑命令，甚至还能把测试也补上。
这种体验很容易让人产生一种错觉：以后是不是只要会提需求就行了？
但用了一段时间之后，又会发现没有这么简单。
AI 很擅长从 0 到 1 生成一段代码，但在已有项目里做修改时，经常会有一些奇怪的问题：
- 多加一层没必要的抽象
- 忽略项目里已有的工具函数
- 为了通过类型检查写出很绕的兼容逻辑
- 把一个很小的改动扩散到很多文件
- 写出来的代码看起来很完整，但不符合项目习惯
最麻烦的是，代码不是我自己一步一步写出来的，所以 review 它的 diff 时，我还要先理解它为什么这么写。
有时候一个需求我自己写可能十几分钟，交给 AI 写完之后，我花半小时看它的改动，最后还得删掉一半。这个时候就会觉得，AI 不是让我少干活，而是把“写代码”变成了“审核一坨我不熟悉的代码”。
这就是我对 AI 编程第一次比较明显的反转：它很强，但不能无脑交给它。
AI 更适合做什么
后来我开始调整使用方式，不再什么都让 AI 一把梭。
我觉得 AI 现在比较适合做几类事情。
Debug
这个是我觉得最实用的场景之一。
我把报错信息、日志、相关背景告诉它，让它沿着这个方向去读代码。因为搜索和整理上下文本来就是 AI 擅长的事情，它可以很快帮我定位到可疑文件、可疑函数、甚至某个库的用法变更。
Debug 还有一个好处：大多数时候它是只读的。AI 不会一上来就改一堆代码，而是先帮我把问题范围缩小。
定位到问题之后，真正的 fix 可能只有几行。
Review
我不太擅长 review 其他人的代码，因为需要重新梳理其他人的逻辑。而现在经常需要我 review AI 生成的代码，这会导致我很累，但反过来，让 AI review 我写的代码就舒服很多。
因为我对自己的实现有上下文，我知道为什么要这么写，也知道哪些地方是我刻意取舍的。AI 提出的建议，我可以很快判断有没有道理。
它有时会指出一些我忽略的边界，比如空值、异步竞态、类型收窄、重复逻辑。即使它说错了，也不会有太大成本。
这个场景里，AI 更像是一个不会累的代码审阅助手。
验证想法
还有一种场景是写一些临时代码，用来验证某个想法是否可行。
比如我想试试某个 API 能不能拿到需要的数据，某个方案能不能解决某种问题，某个库的某个能力是否符合预期，快速验证这条路线是否可行。
这种代码最后大概率不会进仓库，对质量要求没那么高，让 AI 快速生成一版就很合适。
矛盾的地方
但这里就出现了一个矛盾。
如果我不懂代码，我怎么知道 AI 写得好不好？
如果我没有工程经验，我怎么知道它是不是过度设计？
如果我不知道项目里原本的模式，我怎么告诉它不要改哪些边界？
所以所谓的 Vibe Coding，并不是完全不懂也能做出好东西。更准确地说，是你可以不亲手敲每一行代码，但你必须知道自己要什么，也要知道什么东西不能接受。
AI 能把我想象中的东西更快做出来，但它很难帮我想象一个我完全理解不了的东西。
我的认知、经验和品味，仍然是这个 Agent 的上限。
这也是我现在越来越觉得需要读书的原因。
AI 使人变得懒惰
《思考，快与慢》里面有个很经典的说法：人的思考可以粗略分成两套系统。
一套是快的、直觉的、几乎不费力的；另一套是慢的、需要集中注意力、需要推理的。
AI 很像是在不断放大第一套系统。
它太快了。
快到我遇到问题时，第一反应不是自己想一下，而是直接问 AI。快到我看到一篇长文时，会想先让 AI 总结一下。快到我看到一个复杂需求时，会想先让 Agent 跑起来再说。
这不是 AI 的问题，这是人天然就喜欢省力。
短视频看多了，很难再看长视频；电影解说看多了，很难再完整看完一部电影；读书总结看多了，也很难再真正翻完一本书。
AI 也是一样。它把答案送到眼前，我们就很容易跳过中间的思考过程。
但软件开发里，很多价值恰好就在中间过程。
比如为什么这个方案不行，为什么这个抽象会泄漏，为什么这个需求不应该做成通用能力，为什么这段代码看起来没问题但以后会很难维护。
这些东西不是一个“最终答案”，而是一种判断能力。
为什么还是要读书
读书不是为了和 AI 比谁知道得更多。
这件事肯定比不过，AI 记住的公共知识比个人多太多了。
读书更重要的地方，是训练自己进入慢思考。
一本好书不会只给结论，它会把作者的思考过程摊开给你看。你会看到一个观点是怎么来的，一个问题是怎么被拆开的，一个坑是怎么一步一步变成坑的。
比如读软件工程相关的书，真正有用的往往不是那几句原则，而是原则背后的案例：
- 为什么不要过早抽象
- 为什么简单代码有时比优雅代码更好
- 为什么测试不是为了覆盖率，而是为了让修改更有信心
- 为什么边界比技巧更重要
这些东西如果让 AI 总结，它也能说出来。但只看总结，很难获得那种“原来问题是这样发生的”的体感。
我觉得读书对程序员最大的帮助之一，就是建立判断力。
当 AI 给出一个看起来很完整的方案时，我得知道它哪里不对；当它生成一段看起来很漂亮的代码时，我得知道它以后会不会难维护；当它用很确定的语气解释一个概念时，我得知道要不要去查官方文档。
这就是自己的基本盘。
没有这个基本盘，人很容易被 AI 带着走。
我现在怎么用 AI 和读书
我不觉得 AI 和读书是对立的。
相反，AI 很适合当读书辅助工具。
比如读一本陌生领域的书之前，我会先让 AI 帮我建立一个大概的地图：
这本书主要解决什么问题？阅读前需要了解哪些背景？哪些章节适合重点看？读的时候遇到不理解的概念，也可以让它解释一下，但我尽量不让它直接替我总结整本书。因为一旦直接看总结，就又回到了系统一：快速、轻松、看起来懂了。
更好的方式是读完之后，让 AI 反过来问我问题：
根据这些笔记，帮我设计几个问题，用来检查我是否真的理解了这本书的核心观点。如果答不上来，就说明只是看过，并没有真的理解。
现在这个快节奏的时代，人们变得越来越焦虑、浮躁、追求速度，很难静下心来去做一些事。 而读书可以帮你把节奏放慢，可以跟随作者的心理历程去慢慢了解其中的事情，读书重要的是过程，而不是最后的结果。
最后
AI 会让信息越来越便宜，也会让很多工作变得越来越自动化。
但越是这样，人的判断力、审美、表达、抽象和长期思考能力就越重要。
读书不能保证一个人不被淘汰，也不能让人立刻变得厉害。它更像是一个很慢的初始化过程，让脑子里有更多材料可以调用。
我现在也会大量使用 AI，但我不希望自己变成一个只会等 AI 给答案的人。
AI 来了，反而更要读书。不是为了和 AI 比谁记得多，而是为了在使用 AI 的时候，自己还能做判断。