企业官网建设流程全解析

使用 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 C：CI构建 Task D：Docker镜像

每个任务都有：

目标 允许修改目录 禁止修改目录 当前状态 验证命令

这样即使多个Codex任务并行，也不会互相污染背景。

对于大型仓库，这比“一个聊天处理整个项目”更加稳定。

九、把“已确认事实”和“猜测”分开

Codex分析问题时，经常会产生候选原因。

例如：

可能原因A：Token失效 可能原因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编程中的上下文污染、重复分析和无关修改。