完成一次陌生代码库导读后，可以交付一张调用地图。它至少写明功能入口、经过的模块、数据在哪里校验、状态在哪里改变、哪些副作用会发生，以及哪组测试能证明这条理解成立。验收时随机挑地图中的一条连线，都能回到具体文件、符号或测试。这样的结果能支持第一次安全改动，也方便同事纠正误读。
开始前先收窄问题
先查入口。准备可读取的仓库、当前分支和能运行的基础检查，再选一个真实功能切口。这个切口可以是一条接口请求、一个页面动作、一条命令或一个后台任务。把输入样例、预期结果和已知入口一并交给 Codex。若仓库有 AGENTS.md、贡献指南或目录内说明，要求先读取，因为这些文件会补充构建命令、目录边界与团队约定。
不要一上来要求解释整个大型仓库。先让 Codex 回答这个功能由谁接收，数据怎样向下流动，结果怎样返回。可见结果是一份待核对的入口清单，其中每项都有文件路径与符号名。入口仍有多个候选时，先通过路由注册、调用方或运行命令排除错误方向。
先别改代码。请它把首轮结论写成三列，分别是判断、证据位置和置信边界。能直接读到的事实放入证据列，需要运行环境才能确认的内容留在边界列。这样第二轮阅读有明确问题，也能阻止一个早期猜测悄悄变成后续步骤的前提。
沿一条请求追到结果
让 Codex 按执行顺序追踪传输层、业务逻辑、持久化或外部服务、返回值组装。每到一个边界，都要回答该模块接收什么、保证什么、返回什么。把直接从代码读到的事实和根据命名推断的部分分开。推断若会影响改动位置，就继续查调用点、类型定义、配置和测试，直到找到证据或明确保留疑问。
接着单独追验证与副作用。参数校验可能在路由、表单、领域对象或数据库约束里重复出现。副作用还可能藏在事件监听、队列、缓存失效、审计日志和通知任务中。可见结果是一张从入口到结果的有向路径，每个节点标注职责，每条跨模块连接标注传递的数据。
动态注册、依赖注入、代码生成和运行时配置会让静态搜索漏掉真实路径。遇到这类结构，让 Codex 指出装配位置，并说明当前结论依赖哪个环境或配置。查不到就写入未知项。疑问要留下。一条形式完整的线不能替代真实分支。
用测试反查这张地图
地图成形后，从相反方向核对。测试也会过期。搜索覆盖入口、核心规则和失败分支的测试，阅读夹具怎样构造状态、断言盯住什么。运行最接近目标功能的检查，记录命令与结果。测试名称相符但没有经过地图中的关键模块时，不能拿来当证据，应继续找集成测试或补一次只读的运行观察。
还可以选一个失败输入做纸面演练。沿地图逐步写出它在哪个节点被拒绝、错误怎样转换、调用方最终看到什么，再用测试或本地请求核对。成功路径很容易漏掉异常分支，这次反向演练会暴露错误被吞掉、状态已经写入或清理动作没有执行等问题。
再让 Codex 回答三个问题。哪项输入会在最早位置被拒绝，哪次状态变化会触发外部动作，哪处改动最容易漏掉调用方。要求答案引用代码与测试。如果答案互相矛盾，就回到那条边界重查。可见结果是一份已核验事实、仍待确认事项和高风险触点清单。
排出第一次阅读与改动顺序
最后把文件按理解依赖排序。通常先读入口与类型，再读核心规则、状态边界、外部适配器和测试。顺序旁写明每个文件解决什么问题，避免得到一长串没有用途的路径。若准备继续修改，让 Codex 先给出最小改动面、需要补的测试和不应顺手碰的区域。到这里才动手。
工作树应保持独立，特别是同时探索多个功能时。代码审查可以在形成改动后检查遗漏调用点，无法替代前面的系统理解。长任务中也要定期收束地图，删除已经证伪的猜测，免得旧判断继续影响后续步骤。
风险与限制
这套方法依赖仓库中可见的代码、配置和测试。生产流量规则、外部平台设置、私有密钥与历史数据不会自动出现在地图里。需要这些信息才能确定行为时，应该停在条件说明，等待有权限的人补充。生成代码与第三方依赖也应标成外部边界，不要为填满地图而展开无关源码。
交付清单
- 功能切口、输入样例与当前分支已经记录
- 调用链每个节点都能回查到文件或符号
- 验证、状态变化与副作用分别标出
- 相关测试命令和实际结果已经保存
- 未知项、环境依赖与高风险触点没有被省略
- 下一批阅读文件与第一次改动范围已经排好