这个标题想表达的东西我特别有共鸣。说实话我见过太多同学拿到一个陌生代码库第一反应就是把整个文件往对话窗口里一贴让它“解释一下这段代码”。AI 确实能解释得头头是道但过两天你再问他“这个订单状态机到底怎么流转的”他可能还记得你自己却脑子一片空白。我自己的经验是AI 时代读代码正确的姿势不是“让 AI 替我把代码读懂”而是“让 AI 当导游带我在代码里走一遍”。导游帮你订票、指路、讲解背景但路是你自己走的风景是你自己看的。这篇文章我整理了近半年来用这个思路读各种项目包括一些老掉牙的遗留系统的具体方法、踩过的坑、还有我一整套可以照抄的提问模板希望对你有用。1. 把代码丢给 AI 要个“解释”为什么读了个寂寞1.1 先坦白我们都有过“甩手掌柜式”读代码的经历最早我用 AI 读代码方法极其粗暴复制一个五千行的文件进去输入“详细解释这段代码”。AI 会在几秒内给出一个结构清晰、条例分明的回答并且每条都带注释。第一次看到这个效果我是很震撼的——这感觉就像雇了一个资深工程师坐在旁边给我逐行讲代码还随叫随到。但问题很快就来了。有一次我需要修改一个定时任务的模块我回想起 AI 曾经“讲过”那个模块的逻辑却发现自己只记得大概方向和几个碎片化的函数名完全没能力动手改。没办法我只能重新打开那个文件再复制进去一段再问一遍。那一刻我突然意识到我之前所谓的“读懂”其实是 AI 懂了我没懂。后来我想通了把代码丢给 AI 要解释本质上是让 AI 替我做“阅读理解”但我交的学费是自己的理解能力。读代码的过程像一个“心智模型建立”的过程你对一个系统的理解是由“文件之间的关系”“数据在函数之间的流动”“哪个状态在什么条件下被改变”这些东西拼起来的。AI 能告诉你它的理解但没法替你建立你的理解。1.2 读代码的真正产物一份能带走的心智模型我在给团队做技术分享的时候经常说一句话“代码阅读的产出不是注释是你脑子里的那张图。”什么叫“脑子里的图”举个例子给你一个用户积分系统优秀的读者读完代码之后如果我问你“用户退款之后积分怎么处理”你应该能答出哪个 Controller 接收退款请求 → 调用了哪个 Service 方法 → 在哪个事务里扣减积分 → 扣减失败的话会不会回滚 → 有没有发消息通知下游。这一整条因果链就是心智模型。如果你只是看 AI 给出的“这段代码处理退款时同步调整积分并记录审计日志”你得到的是结论不是因果链。平时看看无所谓可一旦线上出问题、日志打不出来、数据对不上账你需要的恰恰是因果链AI 能给你的只有线头。所以我后来的原则变成了凡是 AI 替我概括过的代码我必须亲手在源码里找到它对应的位置把这条因果链自己走一遍。AI 当导游永远不等于 AI 替我到达。1.3 “替身心态”的三个典型信号中了就赶紧停下来聊到这里我干脆总结一下“替身心态”长什么样。如果你在看代码的过程中出现了下面这三种情况建议立刻停下手头的复制粘贴回到源码里去只求答案不求脉络拿着某个函数问 AI“这个函数是干什么的”得到回答就心满意足地关掉却不知道这个函数被谁调用、什么时候会被调用、调用的前置条件是什么。AI 说的都信从不怀疑AI 给出的解释跟你看到的代码有一点点出入你选择相信 AI而不是去定位到那一个分支看看到底谁对。在这个场景下AI 是导游但源代码才是地图本身地图上画的是什么就是什么。读完复述不出来看完 AI 的讲解让你用自己的话对你同事介绍一下这个模块的流程你发现你只能说“挺复杂的大概就那样”。这说明你没有把知识变成自己的读了个寂寞。出现这三个信号任何一个我的建议很直接关闭 AI 对话窗口切到项目里靠自己的眼睛从入口开始往下走。走到哪卡住再把 AI 叫出来当问路的——而不是当轿夫。2. 把 AI 从“替身”调教成“导游”先定目标再提问2.1 打开项目前先想清楚这趟阅读你要“去哪”很多人使用 AI 读代码效果不好其实第一个坑根本不在 AI而在于他自己都没想明白这次要搞清楚什么。你只丢一个文件进去让人家解释AI 只能给你流水账你得先有目的地AI 才能帮你规划路线。我的习惯是在打开任何代码文件之前先手写下三个问题比如这个模块的入口在哪里Http 接口消息队列的 consumer定时任务这条链路涉及哪些核心表/核心状态它们分别在什么阶段被改变我今天最可能改动的位置在哪里它依赖了哪些外部条件配置、下游接口、环境变量这三个问题的作用是帮我把“读代码”这件事从“浏览”变成“侦查”。等你带着这三个明确的问题去问 AI 时你会发现 AI 的回答质量完全不一样。它不再是泛泛给你列一堆函数而是会顺着你的问题去组织答案。提示这三个问题本身就是你在读代码过程中的“行程清单”一份好的行程清单应该具体到哪怕你转向别的任务一个月后再回来依然知道当时自己要查什么。2.2 提问粒度要从大到小地图 → 路线 → 景点很多人让 AI 读代码有个老毛病一上来就问最细的问题。拿着一个 if 分支里三行代码问“这个条件为什么这么写”。这样问不是不行而是很容易让 AI 陷入局部解释不能帮你建立整体感。你把整个城市的某个路灯研究了半天却不知道自己在哪个街区有什么用我总结了一套提问的粒度顺序屡试不爽第一层问地图——“这个模块整体分几层各层的主要文件有哪些入口和出口是什么”第二层问路线——“一个订单从创建到完成调用链上依次经过了哪些关键函数哪些分支是主流程哪些是异常处理”第三层问景点——“这个函数里最核心的一个判断/循环/状态流转它的断点是啥前置条件和后置结果分别是什么”顺序一定是地图到路线再到景点。如果先看景点你很容易迷失在细节里就像跟着导游直接逛了最热门的一座寺庙却完全不知道这座城市的整体布局。2.3 几个我调整后的“导游式”提问模板可以直接抄既然讲到提问我把我最常用的一组 Prompt 给你。这些 Prompt 的设计原则都是一样的要求 AI 给出位置定位、调用关系、边界条件并要求它用提问来确认我的理解而不是单向输出结论。第一个用于刚接触一个模块时我现在要阅读某个项目的支付模块代码路径可以贴进来。 请先像一个导游一样给我画一张这个模块的地图 1. 入口在哪里Controller、MQ消费、定时任务等 2. 主干路径上有哪几个核心 Service 方法和对应的文件行号 3. 这个模块依赖了哪些外部系统或配置项 4. 哪些文件是这次阅读最需要重点关注的。 请不要泛泛介绍每个点都给出具体文件路径和行号。第二个用于瞄准某一条链路聚焦在“用户发起退款到退款完成”这条链路。 请带我沿着这条路径走一遍 - 每经过一个关键函数告诉我它的名字和行号并用一句人话说明它在这个环节做了什么 - 遇到分支逻辑时指出哪些是常规路径、哪些是异常/边界路径 - 最后请总结这条链路上有哪些数据状态被改变分别在哪一行。第三个用于验证自己理解是否靠谱我根据刚才的阅读画了一条调用链理解请你帮我纠错 我的理解是用户点退款 - AController.refund() - RefundService.process() ... 请你对照源码指出我理解偏差的地方并解释为什么。这几个模板的核心逻辑是让 AI 始终带上“路线定位”文件行号同时把“理解验证”这个环节还给我自己。AI 在给你定位之后你再自己点开那个文件看几行上下文很快就能建立起真实的连接感。这种感觉是 AI 直接给你一段总结说破天也给不了的。3. 一次完整的 AI 伴随式读代码流程读到能动手改代码为止3.1 第一回合让 AI 画一张模块地图拿我最近读的一个内部积分系统举例虚构项目代称积分系统X。这个项目是别人写的文档几乎没有代码风格还很飘逸。我刚接手时是一头雾水。我没有直接从某个 .java 文件开始看而是先整理出它的几个功能点用户签到、积分变更、积分过期、兑换记录然后丢给 AI 一个指令请把这个系统的整体模块地图和入口点画出来标注文件路径。AI 的回答速度很快它告诉我签到入口在 UserCheckinController、内部有个 AccumulateService 负责积分计算、积分变更记录会进入流水表还有一个定时任务去处理过期积分对应的类在 ExpireJob 里。这算是我读这个项目的第一份“城市地图”。拿到地图之后我做的第一件事不是继续追问而是按照它给的路径一个一个打开源码目录去核实这些类是否真实存在、行号是否对得上。这一步虽然枯燥但是值得的。因为 AI 画地图时有 20% 的概率会“地图开疆”——编造一个看起来合理但实际不存在的类或方法。我后面专门有一部分讲这个坑这里先说结论AI 给的所有定位永远要在源码里去点一下。3.2 第二回合核心路径的逐句翻译加批注地图有了接下来就是挑一条最关键的业务链路深入走一遍。比如积分系统里最重要的场景是“签到获取积分”我让 AI 带我走这条路。这个环节我会要求 AI 以“逐句讲解 批注意图”的方式输出而不是直接给我一个总结。你可能会问“这两者差别很大吗”差别还挺大的。直接给总结AI 容易把代码里那些没兑现的分支、注释里标明 TODO 的坑、还有诡异的 workaround 全都忽略掉给你一个漂亮的理想化说明。逐句讲解则能让你看到代码的真实肌理。那次 AI 带着我走到 AccumulateService.addPoints 的时候它突然停住告诉我“这个方法里有一个很奇怪的判断lookupUserLevel 返回负数时不加积分你注意一下这里可能是历史遗留的防羊毛逻辑。”说实话如果我是让它直接总结这句话大概率会被吞掉。这类“不对劲”的节点恰恰是以后你会踩到的地雷。3.3 第三回合专挑“不对劲”的地方问把水搅浑再澄清一个值得注意的细节是AI 的讲解默认是“乐观模式”倾向于把代码说得合理、规整、符合逻辑。但真实代码往往有一些奇怪的味道不该有的 Thread.sleep、裸 catch、重复得离谱的代码块、注释自相矛盾的地方。这些如果你不提AI 基本上不会主动告诉你。所以我在 AI 讲解完主链路后会专门做一轮骚操作把源码里所有让我皱眉的片段单独拎出来挨个丢给 AI 问同样的话“请你看这段代码告诉我它有没有可能存在什么问题现实一点别帮它圆场。”我记得有次在积分系统的 ExchangeService 里我看到一个变量名非常像 userPoints但赋值来源却是一个完全无关的服务我的直觉告诉我应该是个复制粘贴错误。我把它丢给 AIAI 识别后回答“这个变量确实与命名意图不一致看起来像复制粘贴造成的隐性 Bug线上表现可能是用户兑换时积分显示正确但扣减来源错误。”后来我翻了 Git 记录确认就是一次错误的自动重构导致的。这种地方就是你读代码“超出 AI 的价值”的地方也是把 AI 当导游而不是当替身最典型的场景AI 会帮你兜住“识别异常”的过程但“察觉到不对劲”的直觉必须来自你自己。3.4 第四回合用一次“模拟改动”验证你理解透了到这里我会做一个终极测试在不动代码的前提下在脑子里假设一个需求然后要求 AI 陪我推演要改哪些文件。比如我对积分系统 AI 说“现在有个新需求如果用户连续签到 7 天第 7 天的积分翻三倍。请你不要直接写代码而是告诉我应该改动哪些方法、哪个顺序、哪个地方需要加判断条件以及影响面在哪里。”这个提问的设计意图特别明确它逼着你在动手改之前先把整个变更链路走一遍。AI 会给你一个改动清单而你要做的是打开每个它提到的文件看看它说得对不对。当你能对着 AI 列出的改动清单一边点头一边在源码里把位置指出来的时候这个模块你基本上才算真正“读懂”了。如果你发现连 AI 给出的改动清单你都看不太懂那说明前面三步仍然没有做好回路去重新读。这套流程我走下来每次大概会花掉一个下午但效果非常稳固过几个月再改那个模块我还是有印象在。4. AI 读代码最容易翻车的三个瞬间幻觉、断片、太丝滑4.1 幻觉重灾区同名变量、历史遗留代码、魔法值我前面提到过 AI 会一本正经地编造不存在的类和方法这其实是最常见的“幻觉”现象。在 AI 读代码的过程中你还会遇到更多不那么明显的幻觉变体。同名变量混淆一个项目里可能存在几十个名为 data 的变量、名为 handle 的方法。AI 很容易把它们张冠李戴把 A 方法里的 data 解释成 B 方法里的 data推导出一套根本不成立的结论。我在积分系统里就碰到过它把“RegisterRequest”和“LoginRequest”两个内部字段高度相似的类混为一谈直接导致整段解释都错了。历史遗留代码的过度合理化有些代码因为历史原因逻辑是拧巴的比如一个判断条件从老系统迁移过来后已经失去意义但没人敢删。AI 出于“模型偏好”会很自然地给这些代码安排一个正当理由什么“这里是为了兼容老数据所以故意这样写”之类的话。这些话有时蒙对了有时完全是鬼扯需要你用上下文去验证。魔法值的“合理发挥”代码里出现一个裸的 86400AI 第一反应是“这是 24 小时换算的秒数”但它可能实际上是另一个时区的偏移量。这种状况下对魔法值的错误解读会把整个业务逻辑的解释都带偏。应对的方式没有捷径只有一条把 AI 的话当成“待验证的线索”而不是事实。只要涉及关键结论请务必在源码里找到对应的位置亲自确认。4.2 上下文断裂一个项目塞不进对话窗口时的对策第二个翻车点是上下文窗口的物理限制。现在很多项目的工程规模已经大到把一个核心模块完整贴进去都会爆上下文。你把十几个文件全部塞进去AI 到后面会逐渐“失去记忆”开始出现前言不搭后语的情况。我总结了一套应对大项目的“横向切片法”每次只让 AI 看一个完整链路而不是整个系统。比如读支付模块时就是Controller 层一个切片 → Service 层一个切片 → MQ/任务处理一个切片。每个切片里只包含必要的方法和调用关系并且我要求它在回复时带上来源路径下一次我带着它前一次的输出和分析继续追问保持对话路线的延续。通过这种方法对话不会一次性吃太多内容每次都能保证回答质量。还有一个更笨但很管用的办法给 AI 喂代码时进行“减脂”预处理——把注释删掉、把空行压缩、把跟本次链路无关的私有方法摘除。这些噪声少了AI 的幻觉率也会明显下降。这就跟你带导游逛一条街街边杂物摊太多导游也容易指错方向。4.3 “太丝滑”往往是在编故事教你几招识破话术第三个翻车点比较隐蔽我把它叫做“太丝滑的谎言”。正常情况下一个 AI 读了一段真实代码尤其是有复杂分支的代码后它的语气会带一点犹豫它会说“这个分支看起来像……但我需要再看一下XX才能确认”“这里存在两种可能性需要看调用方怎么传参”。这种不确定语气其实反而说明它是在看着代码回答问题。相反当 AI 的输出过于丝滑、过于流畅所有结论都那么理所当然甚至不用任何“可能”“是否”这类限定词你要小心了——它可能是在给你编一个看似合理的故事。因为它太擅长生成流畅的文本了流畅并不等于正确。我识破“丝滑谎言”的一个办法是故意挑一个细节追着问“你刚才说这个分支在 null 时直接返回那是不是意味着 entry 为空时不会记流水你确定”你一追问细节AI 有两种表现要么自己去查代码给出更深层的解释要么开始顺着你的问法继续圆场。这两种表现你自己观察一下就知道它的可信度有多高了。凡是那种为了圆场开始讲出“其实这里可能做了隐式转换”之类的话八成属于胡编。4.4 回到源码逐行走的纠错实操我记得有一次在某个旧项目里AI 告诉我某个类的方法会在 Spring 启动时被注册为一个定时任务我扫了一眼没细看就信了。等到后面排查一个定时任务重复执行的问题时才发现实际去做注册的逻辑在另一个工厂类里而这个类只是间接被引用了。也就是说AI 把“这个类的方法被一个定时任务调用”偷换成了“这个类本身是定时任务”两种表述的排查方向完全不一样。这件事之后我养成了一个笨习惯AI 每次说“某个类做什么”时我至少要去看它引用的那个类的类名和方法签名一眼AI 每次说“某个调用链经过这里”时我要沿着调用栈往下跳两层再回来。这个过程看起来很笨、很原始但它是对抗幻觉最有效的手段没有之一。这个习惯跟我把 AI 叫“导游”的比喻完全一致导游可以带你去景点但当你真正需要对这个地方了如指掌时你还是要自己走到墙根底下摸一摸那些砖头。5. 越到关键时刻越要关掉 AI 自己读5.1 线上排障时AI 只给“看起来合理的因果链”把 AI 当导游还是当替身最严峻的考验发生在线上故障。那时候时间紧、压力大人最容易本能地把错误日志贴给 AI让它直接给诊断结论。我并不是说这种操作完全没用事实上 AI 在帮忙快速定位异常栈、联想可能遗漏的依赖关系上还真能帮上忙但有一个致命问题AI 给出的因果链往往是“看起来最合理的那一条”而不是“真实存在的那一条”。线上的问题尤其是数据库锁、内存溢出、分布式事务一类的疑难杂症很多时候根本不存在“看起来合理”的答案它可能是某个被忽略的边界条件、一次异常重启的残留状态、或者上下游配置不一致导致的。AI 会根据它的训练数据给出一堆“曾经在别的系统里发生过的原因”让你顺着错误的方向查了半小时。我吃过这个亏有次线上消息积压AI 断定是消费逻辑死循环查了半天才发现是 DBA 手动锁了表导致消费线程阻塞。AI 给出的逻辑完全自洽但跟现场数据完全对不上。所以我的原则是线上排障时AI 只能用来整理日志和梳理思路绝不能用它直接给根因结论。任何根因必须由你自己顺着实际日志和监控一条条抠出来。5.2 改核心逻辑前亲手把调用关系写下来另一个“务必关掉 AI”的场景是当你准备去修改一个你并不完全熟悉的核心逻辑之前。我知道很多人的工作流是让 AI 给出修改建议 → 照着建议改 → 编译通过 → 提测。这么干有时候确实很快但如果这个模块涉及核心资金流转、状态机迁移、并发控制我在动手前会强制自己先“画一遍调用图”不用画得很精美纸上的箭头和框就行。从入口到出口谁先执行、谁后被调、异常怎么往外抛、哪个信息存在 ThreadLocal 里。这个过程我要确保自己不看 AI 能写出来。为什么这么较真因为改代码是个“产生新状态”的行为你改完之后代码就变了AI 给你讲解时基于的是改之前的代码。如果你对原始调用关系没有一手理解AI 给的建议一旦隐含某种前提假设你照着改就可能把前提给改没了Bug 就埋下了。亲手写过一遍的调用关系是你对这片代码最硬的理解底座谁也替代不了。5.3 面试和晋升考核前你的能力没法外包第三个场景比较现实也是很多人容易忽略的面试准备期和晋升答辩前。这几年我身边已经出现了“AI 辅助刷题、AI 辅助做方案设计”的小朋友。说实话我很替他们担心。面试题可以靠 AI 练但面试官追问你项目细节时AI 是不能陪你进考场的。尤其在系统设计题上面试官问到你的项目的具体实现、为什么这么设计、有没有考虑过别的方案AI 平时给你讲的答案就会变成一种“悬浮的理解”你没办法用自己的话讲到面试官点头。我自己在准备答辩时发现真正能给面试官留下印象的永远是你对代码细节的把握、你踩过的坑、你权衡过的取舍。这些恰恰是“自己读代码、亲手印证代码”才能得到的东西。在面试和晋升的节骨眼上短期补课最有效的动作不是刷多少面经而是把一个最能代表你能力的模块用我前面说的那套“导游式”方法自己踏踏实实读透。5.4 我的日常“戒断练习”和节奏安排最后说一说我自己的日常节奏。现在的我读代码时AI 使用比例大概控制在三成左右其余七成还是靠自己在源码里走跳。每次要深入一个模块之前我会主动设计一次“戒断练习”不开任何 AI 工具先给自己 30 分钟强迫自己从入口文件开始沿调用链往下跳能走到哪算哪。先把能读懂的读懂把卡住的地方记录成问题清单。30 分钟之后我再打开 AI带着这些明确的问题去问。这 30 分钟的价值特别大。因为它逼着你在没有任何辅助的状态下启动你的“代码雷达”你会注意到很多平时被 AI 解释遮盖掉的细节——比如一个多余的分号、一个被注释掉的断点、一个不自然的空判断。这些细节才是你在关键时刻真正的底气来源。等你带问题去问 AI 时你的问题质量会明显提升AI 的回答也自然会更准。说白了你越是一开始肯自己走几段路后面 AI 导游带你走的路线就越对路。这个习惯坚持了大半年后我最大的感受是读代码的速度反而变快了。以前靠 AI 全量解释每个文件都要花很长时间且过目就忘现在三分靠 AI、七分靠自己虽然看似慢但整个项目的结构和边界在我脑子里是越来越稳固的。你不需要二次反工一次读透之后的改动和排查才会进入正向循环。这也算是我在“AI 时代怎么读代码”这件事上最想分享的一点私人体会了。