我们见过太多这样的场景：一个README.md修改或单文件 Bug 修复，Codex 表现得精准而高效，让人惊叹。但一旦切换到包含多个微服务、复杂依赖和古老业务逻辑的项目，情况就会急转直下——频繁的上下文丢失、修改遗漏、测试跑崩，甚至需要人工重写大半代码。这种反复返工并非模型能力退化，而是复杂项目中，Codex 缺乏对“全局约束”和“执行边界”的感知。

要在复杂项目中榨干 Codex 的生产力，核心不在于更换模型，而在于建立一套包含规划、记忆与验收的工作流。以下是我们在实际落地中验证有效的四步法。

1. 强制“计划模式”：先谋后动，避免无效代码

对于超过 5 个文件改动或涉及架构调整的任务，绝不让 Codex 直接输出代码。在提示词开头强制注入：

"进入 Plan 模式。请先不要写代码，分析需求文档和现有项目结构，输出一份包含影响范围、改动文件清单、潜在风险点和数据库变更的英文技术方案。等待我确认后再执行。"

这一步将 Codex 的思维从“写代码”切换到“系统设计”，其生成的方案能提前暴露 80% 的逻辑冲突。当你确认计划时，Codex 会带着这份“地图”进入后续编码，极大降低迷路概率。

2. 建立项目记忆：AGENTS.md是关键锚点

复杂项目的痛点在于上下文窗口被无关日志或第三方库文档污染。我们会在项目根目录维护一个AGENTS.md文件，专门用于存储 Codex 的高优先级上下文。内容精简为：

• 启动与调试：npm run dev、docker-compose up的具体指令。

• 测试规范：运行pytest tests/unit而非全量集成测试的命令。

• 禁止修改清单：标注migrations/下的历史脚本或legacy/auth.js为核心代码，除非明确指令否则禁止重构。

在每一轮对话的 System Prompt 中引用该文件，能确保 Codex 在每次生成代码前自动加载这些硬约束。

3. 原子化拆分与验收标准（AC）

将“重构支付网关”这类宏大需求拆解为“迁移签名算法”、“适配新 API 字段”、“更新单元测试”等子任务。每个子任务的提示词必须包含四要素：

• 目标：具体到函数名或接口路径。

• 上下文：引用AGENTS.md中的相关模块。

• 限制条件：不引入新依赖、保持向下兼容。

• 完成标准：给出明确的Given-When-Then验收用例。

完成后，直接要求 Codex 执行增量测试和 Lint 检查，观察输出日志。如果单测覆盖率未达标或 Lint 报错，要求它在本次会话中修正，而非留给开发者处理。

4. 场景区分与资源策略

我们观察到三类典型场景：

• 单文件任务（如工具函数优化）：上下文简单，几乎零返工，基础套餐的调用量足以覆盖。

• 多模块协作（如前后端联调适配）：需要频繁跨文件读取，此时 Codex 的“任务连续性”比单次输出质量更重要。

• 多项目并行（如同时维护 3 个仓库的热修复）：上下文切换开销极大，频繁中断会导致 Codex 丢失“项目记忆”，重复返工率显著上升。

对于长期处理多模块或多项目的开发者，核心痛点往往是额度耗尽后任务被迫中断。相比单次响应的质量，保持对话历史的连贯性、确保长任务不被切断，才是减少返工的关键。如果你的日常仅限于零星的单文件修改，现有套餐通常已足够；若你频繁处理跨服务重构或连续数小时的密集开发，关注账户的任务连续性和长上下文吞吐量远比纠结模型版本更重要。

稳定的工作流不是靠某个模型的一蹴而就，而是靠 Plan 的严谨、AGENTS.md 的记忆锚点、以及基于场景的合理资源规划。当你下次准备向 Codex 抛出复杂需求时，不妨先花 5 分钟写下计划与验收标准，你会发现返工率下降的幅度远超预期。