周二上线前，我在支付服务仓库里读懂陌生代码

周二上午，支付服务的值班同事请你修一个偶发超时。仓库里有几十个目录，提交记录也不熟；直接让 AI“总结整个项目”，通常只会得到一堆听起来合理、却无法验证的概述。更稳妥的做法，是把理解代码库拆成一连串小问题，每一步都让答案指向可检查的文件和证据。

第一步：先划定本次阅读范围

在终端打开仓库，记下任务涉及的接口、错误现象和可能的服务名。先看 README、目录结构、依赖清单，以及最近相关提交，不要一开始就把整个仓库喂给模型。把你已知的信息整理成几句话，例如“支付请求偶发超时，尚不清楚入口和调用下游的方式”。

接着让 AI 只根据你提供的文件回答：哪些目录可能与支付请求有关？它的判断依据是什么？要求列出路径，并标明哪些是推测。这样能把检索范围缩小，同时避免把猜测误当成仓库事实。

第二步：让 AI 画出仓库地图

挑选顶层目录、启动配置和主要依赖，逐批交给模型。请它按“应用入口、业务模块、基础设施、测试和部署”分类，并为每项附上文件路径与一句用途说明。不要追求完整清单；你需要的是能指导下一次搜索的地图。

如果项目很大，先用搜索工具找路由注册、服务启动函数或支付相关关键词，再把命中的少量文件交给模型。读者可以在桌面上同时打开文件和 AI 对话，逐项确认路径确实存在、说明确实符合代码。

第三步：从一个请求追踪调用链

找到最可能的 API 入口后，要求 AI 按执行顺序追踪一次请求：路由在哪里注册，参数如何校验，调用了哪个服务，数据写入何处，响应如何组装。每一步都要求提供函数名和文件路径；遇到分支则分别说明触发条件。

随后亲自打开这些文件，从入口一路跟读。若模型说某函数会重试，检查重试次数、间隔和异常类型；若它说请求经过队列，找到实际的发布与消费代码。代码才是依据，模型的叙述只是导航。

第四步：把关键数据结构单独问清楚

沿调用链遇到请求对象、数据库模型或配置结构时，暂停追踪，先弄清字段从哪里来、在哪里变更、哪些字段可能为空。让 AI 用“字段、产生位置、读取位置、相关校验”整理答案，并要求引用具体定义。

这一步尤其适合发现命名造成的误会：同一个状态值可能在 API、数据库和下游服务里含义不同。把定义和实际使用处并排阅读，比只看模型生成的摘要可靠得多。

第五步：用测试与配置验证解释

请 AI 找出覆盖目标入口的测试、测试夹具和相关配置，再检查它指出的文件。运行最小范围的测试，观察项目是否依赖环境变量、容器或本地服务。测试失败也有价值：它可能揭示默认配置、时间假设或未写进文档的前置条件。

不要把“测试通过”当成完整证明。核对测试实际断言了什么，是否覆盖超时路径、重试分支和异常响应；如果没有覆盖，就把缺口记下来，后续修复时补上。

第六步：主动寻找反例和未知项

让模型指出自己结论中最不确定的两处，并给出能验证它们的文件或命令。再反问：“有哪些代码路径会让这条调用链不成立？”检查缓存、异步任务、功能开关和版本兼容逻辑。主动找反例，能降低 AI 把常见架构模式套到当前项目上的风险。

最后写一份短笔记：入口、关键调用链、重要配置、已确认的行为和仍待验证的问题。保留文件路径，下一位接手的人就能复查，而不用重新从头询问模型。

第七步：把模型接入日常阅读流程

你可以在 Claude Code、Codex、Gemini CLI 或任何 OpenAI 兼容 SDK 中使用模型，并按任务大小选择模型与上下文。RelayVano 是按使用量付费的 AI 模型中转服务，提供 Claude、GPT、Gemini、DeepSeek 等模型，并兼容上述开发工具；其 API base 为 https://api.relayvano.com。需要一个入口来尝试不同模型时，可以考虑 RelayVano。

现在就注册 RelayVano，用一个熟悉的小仓库走完这套流程，再把同样的步骤带到陌生项目中。先限定范围、逐段追踪、用代码和测试核验，AI 才会成为可靠的阅读搭档，而不是替你编写项目说明的黑箱。