我用AI工作提效，赢麻了（三）：读源码像开挂，AI当我的私人导师

说明：本篇不讲故事，只讲一套能落地的"用 AI 读源码"的思路 + 现成工具怎么选。看完你能直接照着用，而不是听我吹一个"我上次如何如何"的爽文。

一、先定义问题：你为什么会卡在"读源码"

真实场景大概率是这几种，不需要编：

• 接手老项目 / 开源库
  ：文档要么没有，要么是两年前的；原作者早走了，问谁谁不知道。
• 要改一个 bug 或加个功能
  ：知道大概在哪块，但找不到入口，不敢动。
• 时间紧
  ：领导给你半天，不可能把十万行从头通读一遍。

传统两条路都不爽： - 硬读：从 main 往下顺，读到第 800 行忘了前 200 行，一天过去还在打转； - 搜博客：文章讲的是旧版本，你手里代码早就改了，对着抄全是坑。

关键认知：读源码的本质不是"读"，是"建立心智模型"——搞清楚"数据从哪进、经过哪些函数、在哪分支、最后到哪出"。这一步最费人，也最该让 AI 帮你加速。

二、先想清楚：AI 在这里到底帮你什么（思考过程）

这是最关键的一步，想歪了后面全白费。

错误心智模型：把整个仓库丢给 AI，说"讲讲这个项目"——结果得到一份泛泛而谈、还夹杂幻觉的摘要，对你理解毫无帮助。

正确心智模型：把 AI 当成一个"随时在线、不嫌烦、只基于你贴给它的上下文回答"的高级工程师。它不比你知道得多，但它能立刻针对你给的那 50 行，告诉你这 50 行在干嘛。

这里有个必须想通的反直觉点：读源码是你的事，AI 只是把信息密度压低、把路径指给你。AI 不能替你"理解"，因为理解 = 在你脑子里搭起结构。所以用法不是"让 AI 读给我听"，而是"我和 AI 对话着把结构搭起来"。

把这个想清楚后，三条原则自然就出来了：

1. 上下文要你自己给（grounding）：AI 的回答必须基于你贴的真实代码，而不是它训练时记的版本。否则必幻觉。 

2. 问题要具体：问到函数、问到行，不要问"这个项目怎么工作的"。 

3. 答案要校验：要求它给 文件:行号 引用，你顺手 grep/跳转验证一下。AI 说"这个函数做了 X"，你点进去看一眼，30 秒的事，能挡掉 80% 的错。

三、核心思路：把"读源码"变成"对话式探索"

把上面三条原则落成四步工作流：

1. 定位（你自己做）：先用 grep、IDE 全局搜索、或"找引用"，把范围从"整个仓库"缩小到"目标函数 / 目标类"。 

2. 喂上下文（给真的，别给多的）：把目标片段带行号贴给 AI，而不是整仓。一段 30~200 行最有效。 

3. 逐层提问（像导师带徒）：从"这块干嘛"→"它调了谁"→"那条分支什么场景触发"→"如果我要加个参数会改哪几处"。一层层往下，别一次要答案。 

4. 校验 + 沉淀：要求 file:line 引用，跑一下或跳转确认；把结论记进你自己的"代码地图"（一个 markdown 就够），下次不用重来。

一句话：你当导航，AI 当讲解；你定方向，它给细节；你做校验，它省时间。

四、详细拆解：几种高频用法

1) "这个函数到底干了啥"——最常用

贴一段函数，问：

用 3 条要点讲清这个函数的控制流；列出它直接调用的 3 个函数，各用一句话说明作用；最后说哪条分支最容易出 bug。

这是"开挂感"最强的用法：AI 把几百行浓缩成你能消化的结构。

2) "相关代码到底在哪"——从现象找入口

你只有报错信息或业务现象，不知道代码在哪：

这个报错 / 这个行为，最可能由哪几个文件 / 函数引起？给出 file:line 和判断依据。

再用 1) 的问法逐层下钻。

3) "帮我画调用链 / 数据流"——文字版调用图

从 handleRequest 到最终写库，列出完整调用链（函数 A → B → C），标注每一步的输入输出是什么。

对理解"一个请求怎么走完"特别有用。

4) 跨文件理解一个 feature

一个功能往往横跨多个文件。正确做法：把相关的几个片段分别贴出（标注"文件A的 X 类""文件B 的 Y 函数"），再问它们怎么协作。别指望 AI 自己"知道"你仓库的结构。

5) 对比两个版本 / 两种实现

这是旧实现，这是新实现，列出 3 个关键行为差异，以及哪个更可能引入 bug。

适合做 code review 或升级评估。

五、深度模块（企业落地才会遇到的坑）

• 上下文怎么切
  ：大文件不要按"前 2000 行"硬切，要按"符号"切——一次给一个函数 / 一个类，AI 才讲得清。用 Trae / Cursor 这类 IDE 工具，选中函数它就自动只带这一块；用 Codex / Aider 这类 Agent，它会自己按符号读，不用人肉切。
• 幻觉治理（最重要）
  ：AI 会一本正经地编出不存在的函数名。强制要求 file:line 引用 + 你侧 grep 验证，是唯一可靠的护栏。
• 模型版本 ≠ 你的代码
  ：公网模型训练数据有截止日期，你手里的代码可能早改了。一切以你贴的代码为准，不要信它"我记得这个库是……"。
• 私有代码合规
  ：把公司核心代码贴给公网大模型 = 泄露风险。正确姿势是：用本地模型（Ollama / vLLM 起的 OpenAI 兼容接口）或企业版 IDE 工具（Cursor / Copilot 企业版 / 通义灵码等已签保密的）。
• 多轮对话会"失忆"
  ：聊到第 20 轮，纯聊天 AI 可能忘了你最早贴的上下文。长任务改用专业 Agent 工具（Codex / Aider / Cline），它们自己维护仓库上下文，比纯聊天稳。
• 别只要答案，要"为什么"
  ：只问"怎么改"你学不会；问"为什么这么设计、前提假设是什么"，才能把别人的代码变成自己的知识。

六、用什么工具：别自己造轮子，用成熟方案

前面讲的"定位 → 喂上下文 → 逐层问 → 校验"是方法论。落到工具上，绝大多数人不需要写一行代码——成熟的 AI 编码工具已经把"自动带上下文"这件最麻烦的事做掉了。你只要把方法论往上一套。

1) 交互式读码（日常最常用）

你开着 IDE，选中一个函数，直接在侧边对话框问"讲讲这段控制流"——工具会自动把当前文件 / 选中片段作为上下文喂给模型，不用复制粘贴。

• Trae（字节跳动出品的 AI IDE）
  ：原生把当前文件、选中代码作为上下文，对话即问即答，读源码体验顺滑。
• Cursor / GitHub Copilot Chat / 通义灵码
  ：同类思路，选中函数 → 提问，IDE 自动带上下文。
• WorkBuddy（本工具）
  ：能直接读你本地文件、跑 grep/命令、调技能；把文件或片段交给它，让它解释并顺手帮你 grep 验证引用。适合不想换 IDE、在当前环境里一次搞定。

2) 代理式读码（给任务，它自己探索）

如果要跨很多文件追一个 feature，或者懒得自己一段段贴，就用"编码 Agent"——你把仓库或需求交给它，它自己在沙箱里读代码、grep、跳转到引用，最后给你结论 + file:line。

• OpenAI Codex（云端 / CLI）
  ：给指令"定位 X 的实现并解释调用链"，它在隔离环境里自行探索仓库、执行命令，产出带引用的解释。
• Aider / Cline
  ：终端或 IDE 里的 coding agent，擅长跨文件理解与改动。

3) 怎么选（一张表看明白）

4) 选型口诀

• 只读一个函数 / 类
   → Trae / Cursor / Copilot，选中即问，零成本；
• 跨多个文件追一个 feature
   → Codex / Aider 这种能自己翻仓库的 Agent；
• 就在当前环境、不想开新软件
   → WorkBuddy 读文件 + 跑命令验证。

一句话：方法论是你的，工具用现成的。先把"对话式探索"的习惯养起来，比纠结自研脚本值钱得多。

七、真实会踩的坑（提前知道少走弯路）

• 模型比你代码旧
  ：它说"这个库用 X 写法"，你一看代码是 Y——以代码为准。
• 贴太多反而乱
  ：一次塞 2000 行，AI 抓不住重点；按符号给，30~200 行最佳。
• 它编函数名
  ：回答里出现你代码里搜不到的函数 → 立刻 grep 验证，别照抄。
• 只读不练
  ：看懂了但没动手，过两天又忘；改一行、加个日志跑一下，理解才牢。
• 公网泄露
  ：核心业务代码别丢公网模型；用本地 / 企业版。
• 把 AI 当答案机
  ：只问"怎么改"学不会；问"为什么这么设计"才能长本事。

八、小结 & 下篇预告

转变只有一句话：别让 AI 替你读，让 AI 陪你读。你当导航、它当讲解；你定方向、它给细节；你做校验、它省时间。把"通读十万行"变成"对话式下钻"，读源码就从苦力活变成开挂。

下一篇（四）：《让AI替我写周报，每周白捡2小时》——讲怎么把一周的零散工作，喂给 AI 自动产出像样的周报，还不被领导看出是 AI 写的。