用 AI 读懂老代码，关键是把“解释整个仓库”拆成一条条可以验证的小问题：先让项目跑起来，再从入口出发追踪一条真实的请求，边读边建术语表和调用链，每个 AI 给出的结论都用日志、断点或测试去验证。 目标不是马上改代码，而是在动手之前建立一张可靠的“地图”。

如果你已经读懂代码、准备重构，可以直接看 用 AI 给遗留代码做小步重构计划。本文只讲“读懂”这一步。

第 1 步：先让它跑起来

能运行的代码比只能阅读的代码容易理解得多。把构建脚本、依赖文件、README（如果有）和报错信息交给 AI：

这是一个我刚接手的老项目，下面是目录结构、依赖文件和构建脚本，以及我本地运行时的报错。
请告诉我：
1. 这个项目可能使用的语言版本和运行方式；
2. 报错最可能的原因和修复步骤，按可能性排序；
3. 哪些判断是你从文件中直接看到的，哪些是推测。
【粘贴目录树、依赖文件、构建脚本、报错】

要求它区分“看到的”和“推测的”，是读老代码时最重要的习惯。

第 2 步：找到入口

无论是 Web 服务、命令行工具还是定时任务，都有入口：路由定义、main 函数、任务调度配置。让 AI 列出所有入口及其对应的文件和函数，然后你自己打开这些文件确认。

第 3 步：追踪一条真实请求

选一个最常用、最简单的功能，从入口一路追下去：

我想理解“【功能，例如：用户提交订单】”这条路径。入口是 【文件:函数】。
请按调用顺序列出它经过的函数，每一步说明：
- 这个函数做了什么（一句话）；
- 读写了哪些数据（数据库表、文件、缓存、外部接口）；
- 有哪些分支或异常处理值得注意。
遇到你看不到实现的函数，标注“未提供代码”，不要猜测其行为。
【粘贴相关文件】

拿到结果后，在关键函数上加日志或打断点，实际触发一次这个功能，看执行顺序是否与 AI 描述一致。不一致的地方往往就是老代码里最“有故事”的部分。

第 4 步：建一份术语表

老项目里常有缩写变量名和业务黑话，比如某个状态码代表什么、某个字段为什么叫这个名字。每遇到一个，就记进术语表：名称、含义、出处文件、是否已验证。可以让 AI 根据代码猜测含义，但要标注“待确认”，最好找老同事或历史提交记录核实。

第 5 步：画出调用链和模块关系

追踪过两三条路径后，让 AI 帮你汇总成图：

根据我们前面梳理的三条调用路径，用 Mermaid 语法画一张模块关系图：
节点是模块或关键文件，箭头表示调用方向，箭头上标注主要传递的数据。
只画我们已经确认过的调用关系，不确定的用虚线表示。

图不用画全，覆盖核心路径即可。它会成为你和团队讨论的共同语言。

第 6 步：写交接笔记

把运行方法、入口列表、已追踪的路径、术语表、调用图和“还没搞懂的地方”整理成一份笔记放进仓库。下一个接手的人——包括三个月后的你自己——会感谢这份文档。也可以让 AI 根据你的笔记生成新人问答清单，检验笔记是否足够清楚。

需要注意的几件事

  • 注意代码保密：把公司代码交给 AI 工具前，确认团队允许使用哪些工具、是否可以上传源码；
  • 不要一次贴整个仓库：上下文太长时，模型容易遗漏或混淆细节，按路径分批更可靠；
  • AI 的解释是假设，不是事实：注释和命名可能早已过时，以实际运行结果为准；
  • 读的过程中先不要改：发现可疑代码先记下来，读懂之后再决定是否修改。

延伸阅读

用 AI 理解和重构遗留代码的实用方法 介绍了建立行为基线和安全重构的整体思路。读懂代码之后，日常审查可以参考 程序员用 AI 做代码评审 的示例。