AI 时代，工程师的决策能力会变得越来越重要。许多执行层面的工作已经可以交给 AI 处理，所以人的注意力自然会更多转向设计和决策。真正困难的地方，不一定是把方案做出来，而是先判断什么问题值得解决、什么方案值得选择。

决策的本质是取舍。只有需要舍弃，才需要选择；而要做好选择，就必须理解每个方案背后的优缺点。方向错了，AI 写得再快也没有意义。

另一个越来越重要的能力，是在变化中找到不变的东西。代码生产速度加快之后，人几乎不可能再逐行精读所有实现细节，代码本身不再是唯一重点，如何组织代码、如何抽象边界、如何沉淀设计，反而成了更关键的事情。

尤其是在 AI 软件形态快速变化的今天，很多系统都在端到端地处理复杂问题：意图识别、上下文管理、工具调用、权限控制，每一环都充满设计难点。这些问题即使直接问 AI，也未必总能得到足够高质量的答案；但越来越多的 coding agent 已经能够把任务完成得很好。对我来说，真正值得学习的，恰恰是这些系统背后的设计方式。

所以我想重新讨论一个问题：在 AI 背景下，我们应该如何更高效地阅读源码？

和很多事情一样，读源码之前先要有目标。对我来说，终极目标不是“把代码读懂”，而是提升自己的工程设计能力和决策能力，从而更好地解决真实世界的问题。

所以，读代码不是目的，提炼设计才是目的。

我现在越来越倾向于把源码阅读概括成一句话：不要试图理解所有代码，而是尽量理解设计决策背后的 Why。

建立全局地图，而不是一上来钻细节

为什么要先建立全局地图？因为人天然就擅长“分区”。无论是整理家里的物品、画思维导图，还是设计图书馆和商场的导视系统，我们都会先分类，再定位。

阅读源码也一样。人脑更像一个模式匹配器，而不是解释器。

模式匹配器会快速识别结构、划分模块、跳过非关键细节，直接抓住本质。

解释器则会逐行读取、一步不落地执行。

而源码阅读显然更需要前者。

这个判断其实有不少经典研究可以佐证。

先看一个很经典的象棋实验。让高手和新手同时复盘一盘真实棋局，高手往往能复原更多细节；但如果棋子是随机摆放的，高手和新手的表现差距会显著缩小。这说明高手不是单纯记忆力更强，而是能够把棋局识别成一组熟悉的模式。

阅读也是类似的过程。我们读一篇文章时，经常会出现两种体验：有时逐字都看了，却仍然不知道它在说什么；有时只是扫一遍，就已经抓住了主旨。这恰恰说明，我们并不是靠逐字解释来理解内容，而是在匹配“最可能的意义”。

卡尼曼在《思考，快与慢》中也提出过类似区分：系统 1 更快、更轻、更偏向模式识别；系统 2 更慢、更重、更偏向显式推理。源码阅读如果长期停留在系统 2，不仅会很累，也很难扩展到复杂系统。

所以，第一步不是立刻下钻，而是先建立地图：这个系统有哪些模块，模块之间怎么协作，入口在哪里，关键状态流转在哪里。

聚焦关键路径，找到系统的骨架

建立全局地图之后，下一步不是“继续平均阅读”，而是找到关键路径。

大多数系统都符合类似的规律：真正承载主要价值的，往往只是少数核心流程。也就是说，80% 的理解收益，可能集中在 20% 甚至更少的执行路径上。

如果沿着一条主流程走下去，通常会经过这些环节：

• 输入与序列化
• 参数校验
• 核心业务逻辑
• 状态持久化
• 错误处理与回退

这些地方构成了系统的骨架。很多设计决策，最终都会落在这些环节里。只要先走通一条关键路径，整个系统的运行方式通常就会清晰很多。

带着问题阅读，本质上是在训练设计能力

源码阅读最怕的不是看不懂，而是没有问题意识。

认知心理学里有一个概念叫“生成效应”（Generation Effect）：人们对自己主动思考出来的内容，记忆会更深，理解也会更牢。相比“知道它是怎么做的”，我们往往更容易记住“它为什么这样做”。

所以我更喜欢带着下面几类问题去读代码：

• 扩展性：如果我要加一个功能，应该从哪里切入？
• Trade-off：为什么这里选 A，而不是 B？
• 容错性：如果依赖挂了，或者工具调用失败了，系统会怎样退化？
• 耦合度：如果把某个模块单独拆出去，它还能不能成立？

这几类问题，本质上都不是“程序员怎么读代码”的问题，而是在模拟架构师和设计者的视角。你问的问题越接近设计，最后得到的理解就越有迁移价值。

输出和反馈，才能把理解真正沉淀下来

最后一步是输出。

遗忘曲线是很残酷的。如果读完之后不表达、不整理，理解往往会在很短时间里流失。而表达的过程，本身就是一次重新组织和校验认知的过程。

当你尝试把一个系统讲给别人听时，你会立刻发现自己哪里真的懂了，哪里只是“以为自己懂了”。这种自我辩论，会逼着你把零散印象整理成模块化的知识点。

所以，源码阅读的闭环不是“读完”，而是“读完之后能输出”。只有能复述、能比较、能总结，设计理解才算真正沉淀下来。

总结

在 AI 时代，源码阅读不该再停留在逐行理解实现细节上，而应该更关注系统的结构、关键路径和背后的设计取舍。

真正有价值的，不是把所有代码都看完，而是借由源码理解别人是如何定义问题、组织系统、做出选择的。如果能把这个过程持续训练下去，阅读源码就不只是“学习实现”，而是在训练自己的工程判断力。