接手一个不熟悉的代码仓库，可能是除了写文档之外，程序员最头疼的事之一。上个月我临时被拉进一个数据中台项目，原负责人已经转岗了，代码库接近二十万行，文档基本停留在两年前。我需要在一周内理解核心模块的逻辑，然后接手后续迭代。

这个场景下，快速理解陌生代码的能力比写新代码的能力更重要。我用了两周时间，分别借助 Gemini 2.5 Pro 和 Claude 3.5 Sonnet 来辅助阅读理解，两者在代码理解这个维度上的差距比预想的大。

日常处理代码分析和文档阅读我习惯在一个聚合站上切换模型（zijieai.cn），不用来回登录。Gemini 2.5 Pro 的 200 万 token 上下文在处理大规模代码库时确实有优势。

01 为什么这个场景值得单独拿出来对比

代码生成能力是 AI 模型的常规考点，但“理解一段从来没见过的代码”是另一个维度的事。两者的区别在于：

• 生成能力测试的是模型“写得对不对”
• 理解能力测试的是模型“读得懂多少”

在接手老项目的场景里，读的能力往往比写的能力更紧迫。你还没到要写新代码的阶段，迫切需要的是快速建立对现有代码的认知。

这次测试用的不是刻意构造的示例代码，而是那个真实项目中的三个典型任务：

1. 理解一个复杂的递归解析函数
2. 根据错误堆栈反推问题根因
3. 跨文件追踪一条完整的数据调用链路

02 场景一：理解一个复杂递归函数

项目里有一个解析配置表达式的函数，大约 80 行，嵌套了三层条件判断，内部调用了五个辅助方法，还涉及异常捕获和重试逻辑。没有注释，变量名是 expr、parsed、temp 这类通用词。

我先让两个模型分别解释这个函数在做什么。输入是一样的：完整的函数代码 + 五个辅助方法的定义。

Gemini 2.5 Pro 的解读：

它不仅逐行解释了逻辑，还做了一件让我很受用的事——自动绘制了函数的执行流程图。在文本描述中，它把函数分成了三个阶段：预处理（校验输入格式）、核心解析（递归遍历表达式树）、后处理（异常捕获与重试）。每个阶段用箭头标注了输入输出和数据流向。

最关键的是，它从代码里推断出了这个函数的实际用途——把前端传递的字符串表达式转换成后端可执行的查询条件对象。原始的变量名和注释都没有说明这一点，它是通过分析辅助方法里出现的 QueryBuilder 和 FilterCondition 类推断出来的。

Claude 3.5 Sonnet 的解读：

逐行解释同样清晰，它把每一行代码的作用用中文标注出来了，可读性没问题。但在“整体意图”的理解上不如 Gemini——它把函数描述为“一个递归处理表达式的方法”，没有进一步判断这个表达式最终要转换成什么。也就是说，它看得懂每行代码在干什么，但没有推演出整个模块的业务目的。

在这个场景里，Gemini 胜在“从代码反推设计意图”的能力更强。

指标	Gemini 2.5 Pro	Claude 3.5 Sonnet
逐行解释准确性	4.8	4.8
整体意图推断	4.7	3.8
执行流程梳理	4.6	4.2
关键路径标注	4.5	4.0

03 场景二：从错误堆栈反推问题根因

生产环境报了一个偶发的空指针异常，堆栈指向一个我从来没看过的类。我只有堆栈信息和相关类的源代码，需要定位问题原因。

我把堆栈信息和涉及的三个类文件发给两个模型，问题是：“请分析可能的原因，并给出验证思路。”

Gemini 2.5 Pro 的表现：

它先分析了堆栈中每一层的调用关系，然后在代码里找到了一个关键细节——某个缓存工具类在取不到数据时返回了 null，但上层调用方没有做 null 判断，直接调用了 .toString()。它同时指出，这个问题只在特定条件下复现（缓存过期且回源失败时），所以不是必现 bug，解释了为什么之前没有发现。

它还给出了两套验证方案：一是加日志确认缓存失效时的行为，二是直接修改代码增加 null 保护。推荐用前者先确认假设，再改代码。

Claude 3.5 Sonnet 的表现：

它同样定位到了缓存工具类返回 null 的问题，解释也清晰。但在“为什么只在特定条件下复现”这一步上，它没有进一步推演——只是说了“可能存在缓存失效的情况”，没有结合代码中的缓存策略配置（过期时间 60 分钟 + 回源超时 3 秒）来解释为什么回源会偶尔失败。

简言之，两个模型都找到了问题点，但 Gemini 对“根因”的挖掘更深一层，还原了触发条件，让后续修复更有把握。

指标	Gemini 2.5 Pro	Claude 3.5 Sonnet
问题点定位	4.8	4.7
根因推理深度	4.7	4.0
验证方案可行性	4.6	4.3
触发条件还原	4.8	3.8

04 场景三：跨文件追踪调用链路

这是一个相对复杂的场景。我需要理解“用户导出报表”这个功能涉及的完整链路：从前端请求进来，到权限校验、数据查询、报表生成、文件上传 OSS、返回下载链接。

涉及 9 个类、14 个方法，分布在 6 个文件中。我把所有相关文件打包发给两个模型，指令是：“帮我梳理这个功能的完整调用链路，标注每个节点的输入输出、异常处理方式、性能瓶颈点。”

Gemini 2.5 Pro 给出的链路非常清晰：

分了四层：Controller（参数接收）→ Service（权限校验 + 业务编排）→ Repository（多表联查）→ OSS Client（文件上传）。它还给了一个文本版流程图，每个节点标注了输入参数类型、返回类型、可能抛出的异常、以及它判断的潜在性能风险点。

关于性能风险，它特别指出：多表联查的部分没有做分页，如果数据量大可能会撑爆内存。这个我后来确认确实存在——报表数据量超过 5 万行时确实会报 OOM，之前团队是知道但没来得及修的。

Claude 3.5 Sonnet 给出的链路：

同样梳理了四层结构，整体路线图没大问题。差异在于细节——它没有把“异常处理方式”和“性能风险点”作为独立的标注项，而是散落在描述里。我需要从头到尾读一遍才能把风险点找全。Gemini 的结构化输出让信息获取的效率更高。

另一个差别：Claude 在梳理链路时，把 OSS 上传部分标注为“异步执行”，但实际代码里是同步阻塞的。这个信息它推断错了。Gemini 没有犯这个错，它从代码中的 ossClient.putObject() 同步调用和后续的 return downloadUrl 确认了这是同步操作。

指标	Gemini 2.5 Pro	Claude 3.5 Sonnet
链路完整性	4.8	4.6
输入输出标注	4.7	4.2
异常处理梳理	4.6	3.8
风险点识别	4.5	3.5
执行方式判断准确率	4.8	3.5

05 综合对比与使用场景建议

三个场景跑下来，我的感受是：

Gemini 2.5 Pro 在“深度理解”上更胜一筹。 它不满足于“这段代码干了什么”，而是会尝试推断“为什么要这么写”“在什么业务场景下会走到这段逻辑”。对于接手老项目、需要快速建立认知的开发者来说，这种“带意图的理解”能大幅缩短熟悉代码的时间。

Claude 3.5 Sonnet 在“逐行精读”上表现稳定。 如果目标是理解一个具体函数的每一行执行细节，它的输出质量很高，而且中文表达非常自然，适合用来做代码注释的辅助生成。

选型上的个人建议：

• 如果你需要整体理解一个陌生的代码模块，Gemini 2.5 Pro 的宏观视角和结构化输出更适合
• 如果你需要精读某一段复杂算法，Claude 3.5 Sonnet 的逐行解读能力完全不输
• 如果你需要追踪跨文件的复杂调用链路，Gemini 2.5 Pro 的长上下文和结构化输出能力优势明显

06 关于长上下文的一个实测感受

Gemini 2.5 Pro 的 200 万 token 上下文在第三个场景里确实发挥了作用——9 个类 14 个方法全部放在一次对话里，它依然能保持前后一致的分析。我没有遇到“读到后面忘了前面”的问题。

Claude 3.5 Sonnet 的上下文窗口是 200K，在同时处理 9 个文件时其实也够用，但在跨文件追踪时，它对不同文件之间关系的“粘合”能力不如 Gemini。Gemini 似乎更擅长在长上下文中建立和维系跨文件的逻辑关联。

07 一个提醒：AI 的理解不能替代你的验证

最后说一个很重要的体会。AI 给出的理解再怎么详尽，也不能替代自己跑一遍代码验证。特别是当 AI 说“这里可能存在性能风险”或者“这段逻辑看起来是做什么的”时，把它当作线索去追踪，而不是当作最终结论来接受。

我这次的做法是：让 AI 输出分析，然后我自己在 IDE 里对照着代码过一遍，确认 AI 标注的关键路径和风险点是否准确。那些被标注为“需要重点关注”的地方，我会单独写测试用例去验证。这种“AI 出分析 + 人做验证”的组合，是目前我找到的效率最高的方式。

如果你也正在接手一个不熟悉的代码库，可以试试这个方法。花几十分钟让 AI 先帮你读一遍，然后你带着它的分析去看代码，比你一个人从零开始啃要快得多。