很多人只把 Codex 当成代码生成器写页面、改代码、解释报错。真正拉开效率差距的是 Plan、AGENTS.md、Worktree、子 Agent、Review 和 Skills 组成的完整工作流。下面整理 10 个可以直接复用的 Codex 进阶技巧。PS还没安装配置Codex可以借助AI编程助手完成部署。01先开 Plan避免边改边猜 面对陌生项目、复杂需求或跨文件重构不要直接让 Codex 修改代码。先通过/plan或Shift Tab进入 Plan 模式让它读取项目、划定范围、分析风险再决定怎么改。先不要修改任何文件。 请阅读当前项目重点分析 1. 相关模块和调用链 2. 需要修改的文件 3. 可能影响的现有功能 4. 测试和验收方式。 如果需求存在歧义先向我提问。 输出执行计划等我确认后再修改。如果需求本身还不清楚再补一句先向我提出最多 6 个关键问题确认用户流程、异常场景、权限边界和验收标准。复杂任务先 Plan通常比写完再返工更快。02四段式指令锁定范围 提示词不需要写几千字只要说清四件事目标 需要完成什么功能。 上下文 重点查看哪些文件、目录、报错或参考实现。 限制 哪些内容不能改需要遵守什么规范。 完成标准 运行哪些测试、出现什么结果才算完成。例如修复“退出登录后仍能访问个人中心”的问题可以明确重点检查src/auth、中间件和路由守卫不修改现有登录接口不新增第三方依赖退出后访问/profile必须跳转到登录页修复完成后补充回归测试。如果已经知道相关文件可以直接使用指定减少 Codex 在整个仓库里盲目搜索。好用的指令只需要回答四个问题改什么、看哪里、不能碰什么、怎样才算完成。03重复要求写进 AGENTS.md ⚙️如果每次都要提醒 Codex修改后运行测试不要随意增加依赖使用 pnpm 而不是 npm不允许修改生产配置API 返回结构必须统一那就把这些规则写进AGENTS.md。Codex 开始工作前会自动读取该文件。CLI 用户还可以使用/init生成初始版本。# 项目协作规则 ## 开发要求 - 修改前先阅读相关模块 - 不得修改生产环境配置 - 新增依赖前必须说明原因 - 修复 Bug 时必须补充回归测试 - 不得覆盖用户未提交的代码 ## 验收要求 - 运行单元测试 - 运行类型检查 - 汇总修改文件 - 说明仍然存在的风险常用规则可以分成三层~/.codex/AGENTS.md个人通用习惯项目根目录整个项目的公共规范子目录特定模块的单独要求。不需要一开始写几千字。同一个错误出现两次再把对应规则补进去。04截图、日志、源码一次给全 只说“页面有问题”或“运行报错”Codex 很难准确判断。排查问题时最好同时提供截图展示页面现象和错误位置日志提供报错堆栈和执行路径源码帮助定位真正原因。Codex CLI 还有几个容易被忽略的命令命令用途codex --image加入报错截图、设计图或架构图codex --search查询最新文档、版本和外部信息codex resume恢复之前的项目会话排错时不要只发一张截图可以直接告诉 Codex结合截图、控制台日志和相关源码定位原因先判断问题来自页面样式、组件状态、接口数据还是路由权限再修改并实际验证。截图负责展示现象日志负责提供证据源码负责定位原因。05Git Review 双重验收 ✅让 Codex 大范围改代码之前先确认 Git 工作区状态避免覆盖用户尚未提交的修改。完成后不能只看“已经修复”的回复还要检查实际差异和测试结果。先检查当前 Git 状态和未提交修改 不要覆盖已有代码不要修改无关文件。 完成后运行相关测试并检查 Git diff 再使用 /review 审查以下问题 1. 功能回归 2. 异常和边界处理 3. 权限与数据安全 4. 性能退化 5. 测试遗漏。 Review 只输出问题不要直接修改文件。Codex CLI 的/review可以审查当前未提交修改某一次提交当前分支与目标分支的差异自定义文件或审查范围。一套更稳的验收顺序是检查状态 → 实施修改 → 运行测试 → 查看 diff → 独立 Review。06Worktree 隔离并行任务 ChatGPT 桌面端中的 Codex 支持 Git Worktree可以基于同一个仓库创建多个相互隔离的工作副本。例如Worktree A开发登录功能Worktree B修复支付 BugWorktree C补充自动化测试Local继续处理当前工作。不同 Worktree 拥有独立的文件和分支状态不会直接挤在同一个工作区。任务完成后还可以通过 Handoff 转回本地继续检查。它特别适合耗时较长、相互独立的任务。需要注意两点项目必须已经是 Git 仓库多个任务尽量不要修改同一批文件。否则节省的时间可能全部耗在冲突处理上。07子 Agent 并行调查 Worktree 解决“代码修改相互隔离”子 Agent 解决“分析任务并行处理”。面对大型项目可以让 Codex 主动分工请把这次问题排查拆给 3 个子 Agent Agent 1梳理前端登录状态和路由守卫 Agent 2检查后端 Token 生成与失效逻辑 Agent 3分析现有测试覆盖和复现步骤。 三个 Agent 只读取和分析不修改文件。 最后由主 Agent 汇总结论并给出修复计划。子 Agent 更适合这些读取型任务探索不同模块分析日志检查测试覆盖对比多个方案整理大型项目结构。不要让多个 Agent 无边界地修改同一个模块。并行任务必须职责清楚、输入输出独立。子 Agent 也会增加 Token 消耗简单任务不需要强行拆分。08重复流程封装成 Skill 一套提示词重复使用三次就可以考虑做成 Skill。Skill 可以包含SKILL.md执行步骤和规则scripts/辅助脚本references/参考资料assets/模板和固定资源。适合封装成 Skill 的任务包括代码审查Bug 排查发布前检查测试报告整理固定格式的文档生成。例如“发布前检查”可以固定为运行单元测试和类型检查检查 Git 差异、调试代码、临时文件和敏感信息最后输出发布风险清单未经确认不得部署。以后只需调用 Skill不必反复复制整段要求。09仓库外数据交给 MCP Codex 默认擅长处理项目里的文件和代码但很多开发信息存在仓库之外例如GitHub Issue 和 Pull Request项目管理平台团队文档数据库错误监控系统。这类场景可以通过 MCP 或插件连接外部工具减少反复复制粘贴。几个概念可以这样区分能力解决的问题AGENTS.md每次都要遵守什么规则Skill某一类任务应该怎样执行MCP怎样连接外部工具和实时数据插件怎样安装一组 Skills、连接器和工具例如“修改后必须运行测试”写进AGENTS.md“怎样生成上线检查报告”做成 Skill“读取项目管理平台中的任务”交给 MCP 或插件。不要一开始接入十几个工具。先找出最重复、最耗时间的一条工作流再增加对应能力。10稳定流程定时运行 经过多次验证、流程已经稳定的任务可以交给 Codex 定时执行。常见场景包括每天检查失败测试每周整理依赖更新定期扫描过期文档汇总最近代码变化检查项目规则是否与代码现状脱节。Git 项目可以让定时任务运行在独立 Worktree 中避免影响正在开发的代码。为了降低风险定时任务最好遵守三个原则默认只检查和生成报告不自动部署不自动升级依赖或删除文件。项目级任务运行时电脑需要保持开机ChatGPT 桌面端需要保持运行项目目录也必须可以访问。如果需要接入脚本或 CI/CD还可以使用codex exec执行非交互式任务。上面这些进阶用法的前提是 Codex 已经完成安装和基础配置。如果还没有跑通环境可以参考这个 Codex 部署小助手再继续配置AGENTS.md、Worktree、Skills 和自动化任务。总结Codex 的“奇技淫巧”不是冷门命令而是更成熟的工作方式用 Plan 控制方向用 Git 和 Review 控制风险用 Worktree 和子 Agent 并行处理再用AGENTS.md、Skill 和定时任务持续复用。