AI 怎么读懂别人的代码？接手祖传项目实战（2026）

接手一个别人写的项目，最痛的从来不是写代码，而是「我到底该改哪一行」。几十万行的祖传代码、离职同事留下的没有文档的服务、想学但看不懂的开源项目——2026 年这些事已经可以交给 AI 了，但不是简单地把代码丢给它就完事。让 AI 读懂别人的代码，和让 AI 帮你写代码，是两套完全不同的方法。这篇文章讲清楚三条主流路线（网页速读、打包投喂、agent 就地探索）分别适合什么场景，并给出可以直接抄的命令和提问模板。

为什么「让 AI 读代码」比「让 AI 写代码」难

写代码时上下文是你给的，你知道要什么；读代码时上下文在仓库里，而仓库通常远超模型的上下文窗口。一个中型 Next.js 项目动辄十几万 token，大型单体仓库上百万 token 是常态。直接把全部内容塞进去，要么超限，要么模型被无关文件（依赖目录、构建产物、锁文件、测试快照）淹没，回答开始一本正经地胡说。所以读代码的核心问题不是「模型够不够聪明」，而是「怎么把对的那 5% 代码送到它面前」。

三条路线：先选对工具，再谈技巧

简单说：只想看懂用第一条，要整体分析用第二条，要接手并动手改用第三条。三条路线可以叠加——先用 DeepWiki 建立整体印象，再用 agent 深挖具体模块，效率最高。

路线一：DeepWiki——把 github 换成 deepwiki

DeepWiki 是 Devin 团队做的开源仓库阅读工具，用法离谱地简单：把任意公开 GitHub 仓库网址里的 github.com 改成 deepwiki.com 就行。

# 原地址
https://github.com/vercel/next.js

# 改成
https://deepwiki.com/vercel/next.js

它会给这个仓库生成一份维基式文档：项目目标、核心模块拆解、依赖关系、交互式架构图，还带一个针对这个仓库的问答框，你可以直接问「这个项目的路由是怎么解析的」。公开仓库免费使用，私有仓库需要关联 Devin 账户。缺点也明显：只覆盖公开仓库，热门项目是预生成的、冷门项目可能要等，而且它给的是「二手理解」，细节层面还是得自己核。

路线二：Repomix——把整个仓库压成一个文件

如果你想把一个仓库整体丢进 ChatGPT / DeepSeek / Claude 的网页对话框，需要先把它「压扁」成一个文件。Repomix 是目前最顺手的打包器，有 Node 环境的话一条命令搞定，不用预先安装。

# 打包当前目录（默认输出 repomix-output.xml）
npx repomix

# 直接打包远程仓库，不用先 clone
npx repomix --remote yamadashy/repomix

# 开启压缩，大幅削减 token
npx repomix --remote user/repo --compress

# 只要你关心的目录
npx repomix --remote user/repo --include "src/**,docs/**"

# 输出 markdown（人也要读的时候更友好）
npx repomix --style markdown

它默认输出 XML（对模型的结构化解析最友好），会自动跳过 .gitignore 里的内容、统计每个文件和整个仓库的 token 数、并做敏感信息检测。--compress 会把函数体裁掉、只保留签名和结构，token 可以砍到原来的三成左右，适合「先看骨架再深挖」的两轮打法：第一轮压缩版摸清架构，第二轮只打包你锁定的那几个目录。

路线三：让 agent 在仓库里就地探索

真要接手一个项目并动手改，前两条路线就不够了——你需要的是一个能在仓库里反复搜索、跳转、读文件、跑命令的 agent。Claude Code、Codex CLI、Cline 这类工具都能做，思路是通用的。以 Claude Code 为例，有四件事决定成败。

1. 1先生成项目记忆：在仓库里跑 /init，让它扫一遍代码库并生成 CLAUDE.md，把技术栈、目录结构、构建和测试命令写进去。以后每次开新会话它都会自动读这个文件。
2. 2在子目录初始化，而不是只在根目录：agent 会沿目录树往上找并加载沿途所有 CLAUDE.md，所以在 apps/web/、services/api/ 各放一份局部约定，比在根目录堆一个巨型文件有效得多——根目录只放全局指针和关键的坑。
3. 3把噪音挡在外面：构建产物、生成代码、第三方目录用 .claude/settings.json 的 permissions.deny 规则排除掉。配置写进仓库后全组共享同一份降噪规则，不用每人配一遍。
4. 4用只读子智能体做勘探：让一个子智能体专门去把某个子系统摸清楚、把结论写进一个 markdown 文件，主会话再基于这份结论动手改。好处是勘探过程消耗的大量上下文不会污染主会话。

如果项目的目录结构比较反直觉（目录名和实际职责对不上），还可以在仓库根目录手写一份轻量的「代码地图」markdown：每个顶层目录一行，说明里面装的是什么。这份文件对 AI 和对新同事同样有用，属于一次投入长期回本。

分层提问法：别一上来就问「这段代码什么意思」

工具配好只是一半，提问方式决定你能问出什么。接手项目时按这四层由粗到细地问，比东一榔头西一棒子高效得多。

1. 1第一层·地形：「这个项目是干什么的？请按数据流向描述从用户请求到数据库的完整链路，并列出每一层对应哪个目录。」
2. 2第二层·入口：「如果我要改『用户登录』这个功能，需要碰哪些文件？请按调用顺序列出来，并标注哪些是核心逻辑、哪些只是转发。」
3. 3第三层·契约：「这个模块对外暴露了哪些接口/事件？谁在调用它？改动它会影响哪些地方？请给出具体文件路径和行号。」
4. 4第四层·陷阱：「这段代码里有哪些看起来可以简化、但其实是为了兼容某种边界情况才这么写的？帮我找出没有注释解释的反直觉写法。」

四个把人坑惨的常见错误

• 只问不验：AI 说「这个函数在 X 处被调用」，你要顺手让它给出文件路径和行号，然后自己点进去看一眼。跨文件引用是幻觉高发区。
• 让它一次性「总结整个项目」：范围越大结论越水。分模块问，每次只让它读一个子系统。
• 忽略 Git 历史：git log 和 git blame 是理解「为什么写成这样」的一手资料。很多 agent 可以直接跑这些命令，记得让它去查，而不是对着代码猜。
• 拿到理解就直接大改：先补测试、再改。接手的项目通常测试覆盖很差，没有安全网的重构等于赌博。

一个可以照抄的接手流程

• 用 DeepWiki 或打包器建立整体印象（约 30 分钟）
• 跑 /init 生成项目记忆文件，再手工补上业务背景和已知的坑
• 配好忽略规则，把构建产物和第三方代码挡在上下文之外
• 按四层提问法摸清你要负责的那一个模块
• 让 AI 跑一遍 git log，找出近半年改动最频繁的文件——那通常就是核心，也是雷区
• 动手改之前，先让它给关键路径补上测试
• 把这一轮学到的东西写回 CLAUDE.md / AGENTS.md，下次会话直接复用

读懂别人的代码，是 AI 编程里最被低估、也最能拉开差距的能力——写代码 AI 已经很强了，但「判断该改哪里、改了会不会炸」依然是人的活。把上面这套流程跑熟，接手陌生项目的周期能从两周压到两天。想系统学会用 AI 工具真正参与工程（而不只是生成一堆跑不起来的代码），可以来 IMAI 看看我们的体系化实战课程。