读懂 AI 生成的代码：给"AI 写、你负责"时代的代码阅读术

AI 编程普及之后，出现了一个吊诡的现象：一个人一天能"写"出过去一个团队一周的代码量，但几乎没人敢说自己读过这些代码。代码是 AI 写的，测试是 AI 跑的，PR 是 AI 开的——人只负责点"合并"。直到某天线上出了问题，打开那个 2000 行的文件，所有人才发现：我们拥有了一座自己没进去过的房子。

这篇文章想讲一个反常识的观点：AI 时代，读代码的能力比写代码的能力更稀缺，也更值钱。写代码正在变成廉价劳动，读懂代码、判断代码能不能上线，正在变成新的核心竞争力。下面是六个实战方法。

1. 先拿地图，再进城

不要一上来就逐行读。先让 AI（对，就是写代码的那个 AI）给你画一张地图。好用的提问模板：

• "用 300 字讲清楚这个项目的模块划分和数据流向"
• "列出 5 个最关键的文件，以及删掉它们分别会发生什么"
• "这次改动涉及哪几个模块？它们之间是什么依赖关系？"

先有地图再读细节，效率差一个数量级。没有地图的阅读叫"逛"，有地图的阅读叫"检查"——你要做的是后者。

2. 从入口和测试读起

读代码永远先找三样东西：入口（main 函数、路由注册、事件监听）、测试（测试用例是"代码应该干什么"的活文档）、数据模型（表结构、类型定义是系统的骨架）。

AI 生成的测试尤其值得读：测试用例暴露了 AI 对需求的理解。如果测试本身就在测错的东西，代码写得再漂亮也是错的。先看测试断言，再看实现——顺序反了，你会被实现带偏。

3. 控制 diff 粒度：一次不超过 300 行

人脑的 review 带宽是有限的。超过 300 行的 diff，你的眼睛会开始"自动驾驶"——扫过去，点通过，什么都没记住。这是 AI 时代最危险的习惯，因为 AI 恰恰最擅长一次甩给你 2000 行"看起来没问题"的代码。

实操规则：让 AI 把大改动拆成多个小 PR，每个 PR 只做一件事；每个 PR 附一段"人类可读"的变更说明（不是 git log 那种，是"为什么这么改"）。拆不开的改动，本身就是坏味道。

4. 建一份"不信任清单"

AI 写代码很少犯语法错误，它犯的是"看起来做完了"的错误。把下面这份清单贴在你的 PR 模板里，每次对照着查：

• 异常处理：catch 块里是真的处理了，还是悄悄吞掉了？（AI 最爱写空 catch）
• 边界条件：空数组、null、超长输入、并发写入，测了吗？
• 权限检查：这个接口真的校验了身份吗？还是"默认可信"？
• 硬编码：魔法数字、写死的 URL、临时密钥，有没有混进去？
• N+1 查询：循环里查数据库，AI 的经典保留节目。
• TODO 注释：AI 留的 TODO，就是没做完的工作，搜一遍。

5. 用 AI 解释 AI 的代码，但要交叉验证

让 AI 解释它自己写的代码是最高效的学习方式，但问法有讲究。不要问"这段代码对吗"（它会说对），要问"这段代码在 XX 边界条件下会发生什么"、"如果我要删掉这个函数，哪里会坏"。前者在求证，后者在求表扬。

更进一步：用另一个模型来 review。A 写的代码让 B 来挑刺，能过滤掉大量"自我认同"偏差。成本是双倍 token，收益是少一次线上事故——这笔账很好算。

6. 每周一次"代码散步"

最后一条最不"高效"，但长期回报最高：每周花 30 分钟，随机打开一个你没写过的模块，从头读到尾，不为改 bug，只为熟悉地形。消防员要熟悉每栋楼的楼梯，不是等着火了才看平面图。

AI 让代码库膨胀的速度，第一次超过了人类熟悉它的速度。"代码散步"是唯一能缩小这个差距的笨办法。

记住这句话：review AI 代码的重点不是找 bug，是找"你以为它做了、但它没做"的事。AI 从不撒谎说"我没做"，它只是安静地跳过，然后用漂亮的格式让你相信一切正常。

读代码不是为了挑刺，是为了在 AI 犯错的那一刻，你能接住。房子是你住的，进去看看，是主人的基本义务。