别让 AI 替你理解代码

想象一下：你面前是一个完全陌生的代码库------可能是刚入职接手的老系统，可能是内部转岗换了方向，也可能是公司合并后塞过来的项目。几十万行代码，文档要么不存在，要么三年前写的。你在终端里敲了一行 prompt，让 AI 帮你实现第一个需求。

这大概是当下最典型的开局。也是最容易出问题的开局。

问题出在哪？三件事同时撞在一起了。

第一，你对这个系统一无所知------它的代码风格、历史约定、哪里埋过坑，你都不知道。第二，AI 也不了解你的项目------它只会给你通用的写法，而不是这个项目里最安全的写法。第三，你看不出 AI 给的方案靠不靠谱------因为你脑子里没有判断的参照物。

这三个条件凑在一起，结果不是「效率低了一点」。是你越靠 AI 交付得快，你离真正懂这个系统越远。理解力债务从第一天就开始滚雪球了。

这篇文章想讲清楚一件事：在面对不熟悉的代码库时，加速理解和替代理解是两个方向。同一个工具，相反的结果。以及，你应该怎么走第一条路。

理解力债务是什么

在展开之前，先把这个贯穿全文的概念讲清楚。

你用过导航软件吧？跟着导航走，左转右转，顺利到达目的地。但如果关掉导航让你原路返回，你大概率做不到。你到过那个地方，但你不认识路。导航替你认路了。

用 AI 写代码也是同样的道理。AI 帮你读代码、帮你写代码、帮你把测试跑过------你交付了功能，但这个功能是怎么嵌进系统的、为什么选择这种实现方式、改了之后哪些地方可能被波及，你一概不知。你到达了目的地，但你不认识路。这就是理解力债务。

这个类比还能再往下挖一层。有人可能会说：「但我用导航去陌生地方确实很方便啊，没必要每次都硬背路吧？」这话没错。问题在于------你是游客，还是出租车司机？

对游客来说，「到达但不认识路」是完全合理的结果。只去一次的地方，路线知识本来就没有价值。对应到编码，就是原型验证、一次性脚本、探索性任务------这种场景下，「到达即可」是合法策略，AI 导航随便用。

但程序员的日常处境更接近出租车司机。

第一，目的地从不是终点。软件没有「到达」这个概念------每个功能交付都是下一段行程的起点。接下来是维护、排障、下一个需求、下一个接手的人。你交的不是一次性行程，是每天都要重开的路。「只是到达」会复利成「一座你永远不认识的城市」。

第二，路线知识就是职业技能本身。伦敦出租车司机要考 "The Knowledge"------背下全城两万五千条街道------不是没有原因的。导航失灵时、乘客要绕路时、新修路段没进地图时，兑现价值的就是脑子里的路网。一个永远靠导航的司机，和任何一个拿着手机的人没有区别。这就是驾驶界的理解力债务------你握着方向盘，但不是你在开车。

第三，导航会失灵，而且专挑最麻烦的地方失灵。导航在训练数据充沛的主干道上表现很好，在新建区、临时管制、城中村挣扎------和 AI 在 CRUD 上熟练、在怪异长尾上挣扎是同一条分布曲线。而事故和需求恰好偏爱长尾。

所以整个导航类比重述一遍，判据就一句话------

每次「行程」结束时问自己：我现在能不靠导航重开这条路吗？ 能，导航就是你的副驾；不能，你就是导航的司机------车是到了，但下次没有它，你连起点都找不到。

而判断该用哪种模式的，看这趟路的性质：只去一次的地方尽管用导航；你每天营生的城市，必须自己认识。理解力债务（comprehension debt）的本质是：你手里的代码越来越多，但脑子里对它的理解没有跟上。它和技术债听起来像一家人，但性格完全相反。

技术债是个吵闹的邻居------构建慢、依赖乱、改个字段心惊肉跳。它通过制造痛苦来刷存在感，你想忽视都难。好处是，你知道它在那，可以选择什么时候处理。

理解力债是个安静的骗子------代码看起来干干净净，测试全绿，lint 全过，一切都很美好。它不制造摩擦，它制造的是虚假信心。它的清算方式不是在日常开发中提醒你，而是在最糟糕的时刻突然现身：线上出了问题，别人问你从哪开始排查，你脑子一片空白。不是忘了------是你从一开始就没建立过对这段代码的直觉。

为什么 AI 时代这个债务变得特别危险？因为 AI 写代码太快了。快到什么程度？快到你的大脑根本跟不上。以前你写代码的速度受限于打字和思考------你写每一行的时候，大脑在同步构建理解。现在你敲一行 prompt，几十行代码回来了。你的大脑没有参与生成过程，理解自然没有建立。代码产得越多，审得越草率，草率就变成追认------每追认一次，就多一笔理解力贷款。

有一个实验把这个机制揭示得很清楚。研究人员让两组人学一个陌生的 Python 异步库，学完之后做同一套理解测验。

没用 AI 的那组，写代码时中位数踩了 3 个坑------函数没 await、类型对不上、协程没启动。每次踩坑都挺折磨的，但每次折磨都逼着你去搞懂一个核心概念：被一个 bug 卡了二十分钟，你就永远不会忘记那个概念。

用了 AI 的那组，中位数只踩 1 个坑。代码跑得更顺，人也更轻松。全程丝滑。

然后理解测验的成绩出来了：AI 组的得分比没用 AI 的组低了 17 个百分点。踩坑少的那组，反而考得更差。

更要命的是，两组完成编程任务花的时间差不多。AI 并没有让你更快做完------它只是让你在做的时候少动了脑。坑替你绕开了，理解也一起绕开了。

也就是说：你花了同样的时间，交出了同样的代码，但脑子里的东西少了 17%。时间没省下来，理解却丢了。这才是最亏的地方。

AI 从两个方向同时削弱了你的学习：一边在生成时替你做了思考（你不用建心智模型就能拿到代码），一边在运行时替你挡了错误（你没有调试经历，没机会发现自己理解错了）。你以为自己在高效交付，实际上你在高效地绕开所有学习机会。（数据来自 Anthropic 的对照研究《How AI Impacts Skill Formation》，arXiv 2601.20245，下同。）

回到开头那个场景------你对一个代码库一无所知，每接受一个没真正理解的 AI 输出，就是往理解力账户上贷了一笔小款。利息不高，但它是复利。你越高效地交付，你离真正理解越远。

为什么不能替代理解

「让 AI 替我读代码、替我写代码，有问题再说」------这个想法很自然，但它背后有几个结构性裂缝。

AI 的「理解」不是理解

AI 对代码库的「理解」是 token 间的统计关联，不是对「程序是什么、为什么」的直觉性把握。区别在三处。

第一，AI 不知道你的系统为什么长这样。哪个设计是深思熟虑的架构选择，哪个是当年赶进度的妥协，哪里埋着只有老同事知道的雷------AI 全都能回答，且回答得自信流畅。但回答的质量你无法判断，除非你也有理论。一个看起来合理的解释和一个真正正确的解释，在你不懂的领域里，长得一模一样。

第二，AI 的理解不持久。Agent 最大的问题是无法保留理论------每次新会话都是一个从零构建的失忆工程师。你的理论是累积的，每轮评审都在反哺：今天懂了缓存层，明天叠加鉴权层，后天就能直觉判断「这个改动在支付模块会炸」。AI 没有这个累积过程。

第三，AI 不对后果负责。凌晨三点生产事故，被叫起来的是你。「AI 说可以」不是事后复盘的有效论据。

没有理论 = 没有拒绝的能力

有经验的工程师自述，他们日常能拒绝约 80% 的 AI 输出------「不，可以更简单」「我们不是已经做了 X 吗」「这个在我们的系统里不适用」。最终只有约 10% 进入生产。

没有理论的人呢？采纳率接近 100%。不是 AI 输出突然变好了，是你失去了拒绝的依据------AI 给什么你接什么，这其实就是一种投降。「看起来没问题」是你唯一的判断标准，但 AI 的输出就是被训练成看起来没问题的。

更麻烦的是，这种投降有路径依赖：跳过一块不理解的代码后，下一块几乎必然继续跳过------因为它依赖你对上一块的理解。这不是一千个独立的小决定，是方向一旦选错就会加速滚雪球的过程。

六个月后的两条曲线

用同一个 AI 工具，六个月后两个接手不熟悉代码库的人会走向完全不同的方向。

左边这条路，替代理解的人，不是「少懂了一点」------是从一开始就放弃了理论构建。在这里待了多年的同事至少「曾经懂过」（理论随人员流失侵蚀），他连「曾经懂过」的阶段都没有。六个月后，他面前的代码库和第一天一样陌生，只不过这次它已经在跑生产流量了。

右边这条路，加速理解的人，同样用 AI 交付了大量代码，但每轮评审都在给自己的理论加码。六个月后，他对系统的直觉已经能覆盖大部分日常决策------不需要 AI 告诉他「这里小心」，他自己就知道。评审越来越快，因为他脑子里有了真正的判断参照。

上面的三条是根因。它们跟你的项目管得好不好没有关系------即使文档齐全、代码规范，AI 读完所有文档之后依然是统计关联、依然每次会话冷启动、依然不替你接报警电话。完善的文档能帮你更快入门，但就像一张详细的地图------拿着它坐车逛了一圈，不等于你认识了路。导航一关，你还是不知道自己在哪。

一旦你接受了「人必须自己理解」这个前提，AI 就从一个威胁变成了极其好用的工具。接下来讲怎么用。

切入姿势

正确的策略不是「人工读三个月再碰 AI」，也不是「直接让 AI 写」。是用 AI 加速你达到能判断 AI 输出的水平。

第一步：端到端追踪一条流

选最典型的业务流程------比如一个 API 请求从网关到数据库再返回------手动追踪一遍。自己点进去看代码，自己跟着调用链走。目标不是理解每个细节，是建立第一块部分理论：知道大概的模块边界在哪、数据怎么流动、关键的抽象层长什么样。

这一步完成之后，你已经能拒绝 AI 的明显不合理输出。

第二步：逐步扩展，而非一次性覆盖

从这条流向相邻模块扩展。每理解一个新区域，就多一块可以判断 AI 输出的锚点。大系统里没有人持完整理论------人人都是部分理论加上有根据的推测。部分理论已足以拒绝约 80% 的 AI 输出。你不必等全懂了才开始写。

第三步：把 AI 用对方向

同样是跟 AI 交互，做什么事决定了你是在加速理解还是替代理解：

用法	操作	为什么是杠杆
让 AI 做检索	搜索调用链、定位配置项的影响范围、追踪函数引用	替代手动 grep，释放时间给理解
让 AI 解释模块	「这个函数做了什么？为什么这样设计？调用者是谁？」	加速理论构建------你在学，不是 AI 在替你学
跟 AI 做探索	你提假设（「我猜 bug 在缓存层」），AI 验证或推翻	保持主导权，AI 做体力活，你在练诊断能力

概念询问远好于生成委托

前面提到的那个对照实验还给出了另一组数据------同样是完成任务后的理解测验，不同的人用 AI 的方式不同，结果差距极大：

拿 AI 当老师，问「为什么这么设计」「这里还有什么我没注意到的」：65-86% 的测验分数
「帮我实现 X」，拿到代码就交：不到 40%

同一个模型，差一倍多。区别不在努力程度，在认知参与发生在哪一环。前者是你在学，后者是 AI 在替你学。所以你每天跟 AI 的对话里，应该多写「这段代码的设计思路是什么」，少写「帮我重构一下」。

日常节奏

有了部分理论之后，日常开发的循环长这样：

写清楚需求，别凭感觉

给 AI 之前你必须知道要做成什么样。不是「帮我加个用户导出功能」，而是包含七个要素的需求说明：目标 / 背景 / 约束条件 / 不在范围内 / 验收标准 / 接入说明 / 验证计划。战术关键：指向已有实现------「参照 src/services/user/Export.java 里的 CSV 生成方式」这句话，能让 AI 产出命中率提高一个档次。

评审前先构建期望

读 AI 输出之前，先在脑子里过一遍你期望看到什么。如果你读完代码变更才开始想「这对不对」，就已经晚了------你的判断已经被 AI 的输出框住了。这条尤其适用于排查问题的场景：先自己猜一个根因，再看 AI 的诊断。

评审的目的不只是检查代码对错------是为你自己持续积累对系统的理解。每轮评审都在问自己：这个改动和我知道的系统约束一致吗？这个新增的抽象在我刚理解的模块边界里合理吗？答不上来的地方，就是你理解有缺口的地方。

验证先行

prompt 里直接给测试用例，验收标准写进提问而非事后检查。几个硬规则：

Agent 一次只做一个改动。评审单位等于理解单位。一个 2000 行的超大改动你不可能真正理解，只会追认，追认就变成债务。
验证门禁：同 prompt 跑测试 → 停止条件检查（跑不过不继续）→ 确定性校验（lint、类型检查这类不依赖模型的硬规则）→ 独立评审子代理。核心原则：干活的不给自己打分。
盯着测试变更：AI 改行为后可能顺手重写断言来匹配自己的新（坏）行为。200 个改过的测试全绿不等于正确。测试变了的地方，比代码更值得细看。

提交即声明

提交代码合并请求 = 声明你完全理解这些代码在做什么。填写四个字段：做了什么及为什么 + 怎么证明它能用 + 风险点 + 评审重点。填不出来？说明你不够理解自己的变更，没资格请别人批准。AI 写的不能成为逃避责任的借口。

反投降防线

知道该做什么是一回事，在每天的惯性里不滑向替代理解是另一回事。三道具体的防线。

自己讲一遍，才是真懂

可以用 AI，但不要原样转发它的输出。代码评审时、回答同事问题时，「AI 说： $整段粘贴$ 」是零增值------对方自己能用 AI，更快且能控制上下文，不需要你当中转站。

正确做法很简单：读一遍 → 想清楚 → 确认没问题 → 再用自己的话讲出来。如果你无法用自己的话解释一个变更为什么这样写、解决了什么问题，那说明你其实还没理解它。反之，能用自己的话讲清楚，就是你真正理解了这个东西的最好证明。

反合理化表格

AI 是合理化机器------它会为你的每一个跳过思考的冲动提供漂亮借口。在它开口之前写好反驳：

「任务太简单不需要写需求说明」 → 验收标准仍然适用。简单任务的验收标准更简单，但不是零。
「AI 写得差不多」 → 差不多就是你无法解释为什么这样写。说不清代码变更里每处改动的理由，就是没理解。
「测试全绿了」 → 测试只覆盖了已被编码的行为，从未覆盖意图。代码删掉了一个关键逻辑，测试不知道，你也不知道------直到线上炸了。

工具配置防御

几行配置可以替你执行纪律：

CLAUDE.md（Claude Code 的项目指令文件）分层：项目根目录只放指针和关键坑（约 100 行），子目录放局部约定。给 AI 一张地图，不是 1000 页说明书。
AGENTS.md（项目级的 Agent 行为规范文件）五条底线：
- 动手之前把假设说清楚
- 需求冲突时停下问，别猜
- 该拒绝就拒绝------AI 不是应声虫
- 偏好朴素但一眼能看懂的方案
- 只碰叫你碰的东西
关键纪律：绝不让 AI 直接写 AGENTS.md，每条规则能追溯到一次具体的失败教训。
任务间重置上下文。上下文越长，模型对信息的召回越差------这是当前模型普遍存在的现象。

避坑清单

陷阱	表现	解法
跳读代码直接写	AI 生成不符合已有模式，引入新的不一致	至少理解一条端到端流再开始
评审追认	「看起来差不多」就过，不验证约束	评审前先自己写出期望行为
只委托不学习	从不追问「为什么这么设计」	每轮至少问一次 why
原样转发 AI 输出	「AI 说： $整段粘贴$ 」	读→理解→验证→用自己的话
试图一次理解全部	读了几个月还没写第一行	部分理论即可开工，边做边扩展
交给 AI 就不管了	AI 跑得流畅，你从来不读输出	每轮问自己：这一轮我读了什么？
让 AI 写项目规则	LLM 生成的规则文件会损害效果	人写，出过事才加，每条能追溯
把 AI 当权威	AI 说是什么就是什么	AI 输出是原料，不是答案

你的目标不是「让 AI 帮你在不熟悉的代码库里写出代码」，而是用 AI 加速你成为懂这个代码库的那个人。

代码可以是 AI 写的，但系统是你的。出问题时半夜被叫起来的是你，不是模型。理解不是开发之外的修养------是这条流水线上最需要主动防守的资产，也是你作为工程师在这个系统里不可替代的原因。

端到端理解一条流 → 用 AI 加速扩展 → 写设计说明指向已有模式 → 评审前构建期望 → 提交即声明理解。循环往复，理论渐厚。