Codex 要同时看多个仓库怎么办？

真实项目里，需求很少只落在一个目录：前端页面要改，后端接口要对齐，文档和部署脚本也可能受影响。让 Codex 同时看多个仓库前，先把任务边界写清楚，比一上来让它自由搜索更重要。

适用场景：一个需求牵到多个仓库

这篇适合前端、后端、管理后台、自动化脚本、文档站和部署配置分仓维护的团队。典型问题是：Codex 在 A 仓看到字段名，在 B 仓修改接口，又顺手改了无关文档；或者只看前端，不知道后端真实返回结构。如果你面对的是单个大仓库，可先看 大项目里怎么让 Codex 只改该改的文件；第一次任务预检可参考 第一次让 Codex 改项目之前要检查什么。

先分角色：主仓、参考仓和禁止仓

多仓任务最怕所有仓库都变成“可修改”。建议在任务开头列出主仓、只读参考仓、禁止触碰仓库和远程环境边界。主仓可以修改，参考仓只能读取接口定义、文档或示例，禁止仓只允许用户手动提供片段。这样 Codex 可以理解全局，但不会把每个发现都变成改动。

操作步骤：把跨仓协作拆成可验收任务

1. 写清本次只交付什么

不要把“理解系统、修功能、补测试、改部署、写文档、上线”塞进同一条指令。先确定本次交付物，例如只改前端适配新字段，只补后端返回字段，或只写迁移说明。若要交给同事 Review，可参考 Codex 改完代码后怎么交给同事 Review。

2. 给每个仓库标注权限

任务说明里直接写：前端仓允许修改哪些目录，后端仓只读哪些接口文件，脚本仓禁止写入。涉及 AI API 接入、CCSwitch 配置或模型调用管理时，Key、环境变量和生产配置默认只读，不让 Codex 猜值或重写敏感配置。命令风险分级可参考 让 Codex 执行命令前怎么确认风险。

3. 先只读扫描，再决定是否修改

第一轮让 Codex 只读列出相关文件、接口、字段、测试命令和风险点。你确认后再进入修改。跨仓信息不一致时，优先让它指出冲突，不要直接选一个版本覆盖。比如前端类型写了 modelName，后端返回 model_id，文档又写 model，这时应该先定契约。

4. 验收命令按仓库分别跑

每个仓库的验证命令可能不同：前端跑构建和页面检查，后端跑接口测试，脚本仓跑 dry-run。不要用一个“没报错”替代全部验收。若改的是 AI 自动化办公流程，还要准备样例输入和人工复核表，避免只证明代码能运行，却不能证明结果可用。

常见问题/避坑：跨仓不是越自动越好

第一个坑是让 Codex 自己决定所有仓库的修改范围。第二个坑是参考仓被误改，导致本来只是查接口定义，最后出现无关 diff。第三个坑是跨仓测试没有跑全，只在一个仓库通过。第四个坑是把线上配置和本地示例混在一起，造成测试 Key、正式 Key 或 API 地址误用。

如果多仓任务涉及模型接口，建议先建立一份字段契约，写清请求字段、响应字段、错误码、限流提示和日志字段。错误码排查可以结合 AI API 返回 401、429、500 怎么分工排查。这样 Codex 修改任何一端时，都有契约可对照。

实际合作时，我会要求 Codex 在动手前列三张表：需要读取的文件、计划修改的文件、不会触碰的文件。这个动作看似慢，能提前发现它是否把参考仓当成主仓。任务结束后，再让它给出变更范围、验证命令和剩余风险，方便人工接手。

还有一种常见情况是文档仓记录了旧接口，后端仓已经改了字段，前端仓又有临时兼容逻辑。遇到这种不一致，不要让 Codex 直接把三边改成同一个名字，而是先输出差异清单：哪个仓库是当前真实入口，哪个仓库只是历史说明，哪个兼容逻辑还在被线上用户使用。确认之后再决定改代码、改文档，还是只补测试。

如果任务需要拆成多个提交，也要在交接说明里写清顺序。例如先更新后端契约和测试，再更新前端适配，最后补文档和发布说明。这样 Review 人能按顺序看，也能在某一步发现风险时暂停，而不是面对一大包跨仓改动才开始倒推原因。

检查清单：跨仓任务开始前确认

• 是否明确主仓、只读参考仓和禁止触碰仓库。
• 是否写清本次交付物，不把上线和重构混进同一任务。
• 是否限制允许修改目录、敏感配置和远程操作。
• 是否先只读扫描并列出影响文件。
• 是否为每个仓库准备独立验收命令或人工检查动作。
• 是否有 Review 说明和回滚点。

验收标准：读全局，改局部，证据分仓

好的多仓 Codex 流程，不是让它一次改遍所有仓库，而是让它利用全局上下文做局部、可验收的改动。永沃云枢建议把这类任务模板和 Codex 安装专题、AI API 接入专题 一起沉淀，后续在 https://ai.jn83.com 做开发者 AI 调用或 AI 自动化办公时，也能保持边界清晰。