使用 Codex 处理小项目时通常只需要告诉它“修改哪个文件、解决什么问题”任务很快就能完成。但当项目进入几十个目录、上百个文件以后很多开发者会发现一个明显问题前几轮分析很准确后面开始修改无关代码明明已经说明过限制过几轮又忘记一个新问题把之前的重要要求覆盖掉同一个文件被重复读取任务越长输出越来越偏离最初目标修复A问题时把B模块的旧上下文带进来对话很长却很难继续稳定推进。这种现象可以理解为上下文污染。Codex并不是读取的信息越多越好。真正有效的做法是让当前任务只保留真正需要的信息。一、什么是上下文污染假设一个项目包含src/ auth/ order/ payment/ user/ report/ admin/当前只需要解决用户刷新页面后登录状态丢失。理论上主要涉及auth user router store但如果一开始就让Codex扫描整个仓库它还可能读取订单、支付、报表等大量信息。这些内容暂时没有用却会进入当前任务背景。后面继续对话时Codex需要同时判断大量信息之间的关系反而更容易扩大修改范围。所以大型项目使用Codex的第一个原则是不要把“完整仓库”当成默认上下文。二、先建立三层上下文可以把项目信息分成三层。第一层长期项目规则这部分长期不变可以放进AGENTS.md# 项目规则 技术栈 - Vue 3 - TypeScript - Pinia - Node.js 全局限制 - 不修改数据库字段 - 不新增第三方依赖 - 不删除已有测试 - 公共组件修改前必须说明影响 - 完成后必须运行类型检查这些规则不需要每次重新输入。第二层模块上下文例如当前处理用户登录可以准备模块用户认证 相关目录 src/auth src/store/user src/api/auth src/router 当前机制 Token保存在localStorage 应用启动后恢复用户状态 401时统一清理登录信息这部分只在当前模块任务中使用。第三层本轮任务这是最短的一层问题 刷新页面后偶尔跳回登录页。 本轮只检查 src/store/user.ts src/api/auth.ts 目标 确认初始化顺序是否存在竞态。 本轮不要修改代码先分析原因。这样Codex不需要每次重新理解完整仓库。三、不要一次同时“分析重构测试”大型项目最容易失控的指令是检查整个登录系统 修复所有问题 顺便重构代码 增加测试 再优化性能。这实际上包含了多个独立目标。更稳定的方式是拆成阶段。阶段1定位只分析问题原因。 不要修改任何文件。 输出可能相关的3—5个文件。阶段2制定计划根据上一步结果 列出最小修改方案。 说明 - 修改哪些文件 - 为什么改 - 有什么风险阶段3执行只执行已经确认的修改。 不要扩大范围。阶段4验证运行相关测试 检查Git Diff 列出仍未覆盖的情况。每个阶段目标单一Codex更容易保持方向。四、让Codex先缩小文件范围面对大型仓库不建议直接说找出这个问题在哪里。可以先让它输出候选文件当前问题是用户刷新后状态丢失。 请根据目录和调用关系 最多列出5个最可能相关的文件。 暂时不要读取其他模块。然后再进入第二轮只分析刚才列出的5个文件。 找出 1. 初始化入口 2. Token读取位置 3. 用户状态恢复逻辑 4. 路由判断时机。这种方法类似人工排查问题先缩小范围再深入。五、每完成一个阶段就生成“上下文摘要”长任务中不建议一直依赖完整聊天记录。每完成一个阶段可以让Codex生成当前任务摘要 问题 刷新后偶尔退出登录。 已经确认 - Token读取正常 - API请求正常 - 路由守卫执行早于用户状态恢复 已排除 - Token过期 - 后端401 - localStorage写入失败 准备修改 src/router/index.ts src/store/user.ts 暂不处理 订单模块 权限重构 性能优化下一轮只需要基于这份摘要继续。这相当于把大量历史对话压缩成一个稳定的“检查点”。六、为什么摘要比完整聊天更适合长任务完整聊天中通常包含大量已经失效的信息早期猜测被否定的方案临时日志已经修复的错误多次重复说明与当前目标无关的讨论。如果全部保留Codex仍然需要判断哪些信息已经过期。而摘要只保留当前事实 当前目标 当前限制 当前进度 下一步信息密度更高也更不容易跑偏。七、一个任务结束后不要继续塞新任务例如登录问题已经修复开发者紧接着说对了再帮我看下订单性能问题。从使用体验看很方便但从工程上下文看这两个任务几乎没有关系。更好的方式是结束当前任务输出本轮最终摘要 - 修改文件 - 修改原因 - 测试结果 - 未解决风险然后新的订单问题重新建立任务范围。不要让一个长期对话逐渐变成登录 订单 数据库 Docker CI 缓存最终所有内容混在一起。八、为不同任务建立独立工作区如果同时维护多个功能可以采用Task A登录状态 Task B订单接口 Task CCI构建 Task DDocker镜像每个任务都有目标 允许修改目录 禁止修改目录 当前状态 验证命令这样即使多个Codex任务并行也不会互相污染背景。对于大型仓库这比“一个聊天处理整个项目”更加稳定。九、把“已确认事实”和“猜测”分开Codex分析问题时经常会产生候选原因。例如可能原因AToken失效 可能原因B初始化顺序 可能原因C接口401排查后发现真正原因是B。此时摘要里不要继续保留Token可能失效应该更新为已排除 Token失效 接口401 已确认 用户状态初始化晚于路由守卫。如果旧猜测一直留在上下文中后续Codex仍可能重复检查已经排除的问题。十、限制每轮输出长度大型项目中输出越长并不一定越有价值。例如让Codex详细分析整个项目架构。可能得到数千字内容但真正与当前Bug有关的只有几段。可以限定输出格式 问题原因最多3条 涉及文件最多5个 修改建议最多3步 风险最多3项这样能减少无效信息持续进入下一轮。十一、修改前设置“禁止扩展任务”一个非常实用的规则是如果你发现其他潜在问题 只记录到“额外发现”中 不要在本轮修改。例如当前任务 修复登录状态。 额外发现 订单模块存在重复请求。 处理方式 只记录不修改。这样可以防止Codex在执行一个Bug修复时顺便开始重构整个项目。十二、把上下文管理写进AGENTS.md可以增加# Codex任务规则 - 一个任务只处理一个明确目标 - 首轮优先缩小文件范围 - 未明确要求时不要扫描完整仓库 - 已排除的问题不要重复分析 - 新发现的问题只记录不自动修改 - 每个阶段结束后输出任务摘要 - 修改范围扩大前必须说明原因 - 不在同一任务中混入无关模块 - 完成后输出最终交接记录这类规则对大型项目特别有效。十三、一个推荐的Codex大型项目流程可以固定成1. 读取AGENTS.md 2. 明确当前问题 3. 列出候选文件 4. 缩小分析范围 5. 输出原因 6. 生成最小修改计划 7. 执行修改 8. 运行测试 9. 检查Git Diff 10. 生成任务摘要下一次继续时读取项目规则 读取上一轮摘要 执行下一步而不是重新扫描完整项目。十四、什么时候Plus已经够用如果主要是单模块修改明确Bug修复中小型仓库一次涉及少量文件任务可以按阶段拆分Plus通常已经可以完成大部分Codex开发任务。上下文管理做得好往往比单纯增加使用空间更有效。十五、什么时候可以评估Pro如果长期需要分析大型仓库一次涉及大量文件多个模块持续联动长时间运行测试和修复同时维护多个项目Codex已经成为主要开发流程可以再根据任务连续性评估Pro。对于这类工作真正需要的不是“多问几个问题”而是保持较长工程任务的连续分析与验证。但即使使用Pro也仍然建议做上下文分层。使用空间更大不代表应该一次塞入更多无关信息。总结Codex处理大型项目越聊越跑偏很多时候不是模型突然变差而是当前任务中混入了太多已经失效或无关的信息。通过长期规则、模块背景和本轮目标三层上下文可以让Codex只关注当前真正需要处理的内容。再结合文件范围控制、阶段化执行、任务摘要和独立工作区可以显著减少重复扫描、无关修改和任务偏移。真正高效的大型项目AI开发不是让Codex一次记住整个仓库而是让它在每一个阶段都只拿到完成当前任务所需要的最小上下文。CSDN文章描述本文介绍Codex处理大型代码仓库时的上下文管理方法通过AGENTS.md、任务分层、文件范围控制、阶段摘要和独立工作区减少AI编程中的上下文污染、重复分析和无关修改。