接手一个不熟悉的代码仓库，可能是除了写文档之外，程序员最头疼的事之一。上个月我临时被拉进一个数据中台项目，原负责人已经转岗了，代码库接近二十万行，文档基本停留在两年前。我需要在一周内理解核心模块的逻辑，然后接手后续迭代。
这个场景下，快速理解陌生代码的能力比写新代码的能力更重要。我用了两周时间，分别借助 Gemini 2.5 Pro 和 Claude 3.5 Sonnet 来辅助阅读理解，两者在代码理解这个维度上的差距比预想的大。
日常处理代码分析和文档阅读我习惯在一个聚合站上切换模型（zijieai.cn），不用来回登录。Gemini 2.5 Pro 的 200 万 token 上下文在处理大规模代码库时确实有优势。
01 为什么这个场景值得单独拿出来对比
代码生成能力是 AI 模型的常规考点，但“理解一段从来没见过的代码”是另一个维度的事。两者的区别在于：
- 生成能力测试的是模型“写得对不对”
- 理解能力测试的是模型“读得懂多少”
在接手老项目的场景里，读的能力往往比写的能力更紧迫。你还没到要写新代码的阶段，迫切需要的是快速建立对现有代码的认知。
这次测试用的不是刻意构造的示例代码，而是那个真实项目中的三个典型任务：
- 理解一个复杂的递归解析函数
- 根据错误堆栈反推问题根因
- 跨文件追踪一条完整的数据调用链路
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 先帮你读一遍，然后你带着它的分析去看代码，比你一个人从零开始啃要快得多。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
