大仓库，别让 Codex「一口吞」
真实项目的代码库可能很大——几百个文件、几十万行。如果让 Codex 一次性全看，上下文瞬间爆炸，又慢又乱。这一节学处理大型代码库的技巧。
核心思路一句话：别让 Codex 一口吞，带着它分层、定位着看。
file-lib 目前只有几个模块还称不上「大仓库」，但它会长大：模块会越来越多、测试越来越密、还有人往里面加 API 客户端、CLI 入口。这一节我们把「处理大仓库」的思维提前练起来——从现在就让 Codex 学会「先理结构、分层深入」，等 file-lib 真长大了，你才不会被它的规模吓到。今天的练习是：让 Codex 先「摸」一遍 file-lib 的结构，再动手加一个「CLI 入口」。技巧 1：先理清结构，再动手
别让它一上来就改。先让它摸清项目结构：
先别改。帮我梳理项目结构：
- 分几个模块、各模块职责是什么
- 关键入口文件在哪
- 数据怎么流动
结构清楚了，它才知道「该在哪下手」，而不是满仓库乱撞。对 file-lib 可以这么问：
先别改。帮我梳理 file-lib 的结构：
- lib/ 下有哪些模块，各自导出什么
- index.js 是怎么汇总导出的
- 测试文件怎么组织、怎么跑
- 有没有约定俗成的模块命名风格
让 Codex 给你一份「结构地图」，你自己心里也有数，后面每个任务都能「照着地图指路」。
技巧 2：自顶向下，逐层深入
别一次性给全部，分层喂：
第 1 层：只看目录结构（知道有哪些模块）
第 2 层：进入目标模块，看它的文件
第 3 层：才看要改的具体文件 + 相关引用
每层的信息量控制住，上下文不爆炸，方向也清晰。给 file-lib 加 CLI 入口，就可以这么分层：
【第 1 层】先只列目录结构，说说 file-lib 现在有哪些入口和模块。
【第 2 层】我要加一个 bin/cli.js 命令行入口。看看 index.js 怎么导出、
lib 下有哪些函数可以给 CLI 用。
【第 3 层】确定用 path 和 io 两个模块的函数。现在写 cli.js，并注册到 package.json 的 bin 字段。
三层走下来，每一步 Codex 手里的资料都不多，方向还特别清楚——它不会在第 1 层就把 test/ 里几十个用例全读了。
技巧 3：精准定位，别全局搜索
大仓库里，「让它搜整个项目」又慢又乱。告诉它去哪找：
❌ 「看看项目里有没有处理支付的代码」 ✅ 「支付逻辑应该在 src/payment/ 下，去看那边的文件」
你有方向，它就有方向。在 file-lib 里，如果你忘了某个函数在哪，与其让它全库搜，不如给个候选范围：
帮我找 file-lib 里处理「日期格式化」的代码。
应该在 lib/date.js 或 lib/utils/ 下，先去那儿找，别全仓库扫。
给 Codex 一两个「候选位置」，它就省下全局扫描的力气，直接把窗口留给有用的信息。
技巧 4：用「问题驱动」缩小范围
让 Codex 带着具体问题看代码，比「随便看看」高效：
帮我定位：订单提交时，前端把数据发到哪个接口、后端怎么处理。
只需要看相关的请求和接口文件。
带着问题 + 限定范围，它才精准。放到 file-lib，与其说「看看我的 CLI 怎么写的」，不如带着问题去：
CLI 里调用 formatDate 时传的格式参数是硬编码的吗？
只查 bin/cli.js 和它 import 的 lib/date.js，别的不用看。
问题越具体，它越知道要翻哪几页，越不会漫无目的地扫荡。
技巧 5：局部改动，别整体重构
大仓库里，优先局部改动，别动不动整体重构：
- 小步改、小步验证
- 改动范围控制在模块内
- 跨模块改动先出计划
大仓库最怕「一把梭重构」，改了几个月都合不回去。file-lib 要加 CLI，正确的做法是新增一个 bin/cli.js，尽量不动已有的 lib/ 模块；而不是为了「代码更优雅」把每个模块都重写一遍。改得越少，风险越小、越好回滚。
处理大仓库的心法
| 别做 | 要做 |
|---|---|
| 让它一口吞整个仓库 | 分层喂、定位着看 |
| 全局乱搜 | 给方向、给具体位置 |
| 没理解就乱改 | 先理结构，再动手 |
| 一把梭重构 | 局部改动、小步验证 |
控制上下文、保持方向，是驾驭大仓库的关键。
index.js 和会用到的 lib/ 模块 → 最后写 cli.js 并注册到 package.json 的 bin 字段）；最后只改新增文件，不动已有模块。②怎么判断做对了：Codex 在第 1、2 层没有一次性读全部文件、改动集中在新增的 cli.js、命令行跑起来能调用已有的工具函数且已有模块测试全绿。③卡住了怎么办：如果它一上来就全库扫，让它「先只列目录结构」；如果它忍不住想重构旧模块，明确说「旧模块一行都不许改，只新增」。常见坑：小库阶段养成的「一口吞」坏习惯
file-lib 现在文件少，你随口一句「看看吧」Codex 读光所有文件也没啥事，于是你养成了让它随便读的习惯。等库长大了、文件几百个，这个习惯还在，Codex 每句话都全库扫，上下文永远爆，又慢又贵。
避坑办法：从现在的小库就强制用「分层」套路，别等大了才改。每次哪怕只有三个文件，也走一遍「先目录 → 再相关模块 → 最后动手」的流程。把好习惯刻进肌肉记忆，大仓库来了才不慌。可以这样给自己立规矩：每次任务，先写一句「这次只读这些文件」，再让 Codex 动手。 这个前缀写习惯了，库越大你越稳。
小结
- 别让 Codex 一口吞大仓库，分层、定位着看
- 先理结构 → 自顶向下 → 精准定位 → 问题驱动
- 局部改动优先，别整体重构
- 心法：控制上下文、保持方向
下一模块进入「代码审查」。