我们见过太多这样的场景一个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 分钟写下计划与验收标准你会发现返工率下降的幅度远超预期。