如果你正在搜「Codex 最佳实践」，大概率已经过了「怎么装、怎么跑第一条命令」这一关。你能让 Codex 改一个函数、修一个 bug、跑一段脚本，但越用越有种说不清的别扭：同样一句话，有时候它一击命中，有时候它绕了一大圈还把不该动的文件改了；上下文一长就开始降智、重复、答非所问；让它写测试，它顺手把测试改成「永远通过」；明明只想改后端，它连数据库迁移一起动了。
这篇不讲安装和基础命令——那是入门文的范围，如果你还没跑通，先去补这篇基础：Codex CLI 完整入门：安装、工作流、故障排查与 Claude Code 协同。本文的定位是装好能跑之后，怎么用得更好：把 Codex 从「碰运气的智能补全」升级成「可复现的工程流程」。如果你想要一份更偏全流程的实操，也可以对照这篇全方位 Codex 实战教程一起看，本文则聚焦进阶心法与编排。
TL;DR：六条进阶心法
先把结论摆出来，下面每一节都是对这六条的展开：
- 任务拆解颗粒度决定一切：一句话说不清、必须用「然后」「并且」连起来的任务，就是太大了，拆。
- 上下文是有限预算，AGENTS.md 是你的杠杆：把项目的「怎么构建、怎么测试、什么不能碰」写进 AGENTS.md，而不是每次对话临时口述。
- 审批模式和沙箱要主动选，而不是默认全放开：低风险任务给自由度，高风险操作设门禁。
- 代码审查必须闭环：用
/review生成评审，再让另一个回合修，人做终审，不要让同一个上下文「边写边夸自己」。 - 测试驱动让 Codex 自我纠错：给它一个能跑的验证回路（测试 / lint / 类型检查），它才知道「对」长什么样。
- Agent 工作流要编排，不要堆 prompt：profiles、MCP、subagents、skills 各司其职，复杂度沉淀到配置和文件里，而不是困在一次性对话里。
一句话总览：入门解决「能不能让 AI 写代码」，进阶解决「怎么让 AI 写出你敢合并的代码」。 这两件事之间的距离，几乎全在工程方法，而不在你输入框里那句 prompt 写得多花哨。
一、任务拆解：颗粒度才是第一生产力
进阶用户和入门用户最大的差距，不是 prompt 写得多漂亮，而是会不会把一个大目标切成 Codex 能稳定吃下的小块。
一句话原则
社区里流传一条很好用的判据：如果你没法用一句不含「并且 / 然后」的话描述这次改动，这个任务就太大，必须继续拆。 比如：
- ❌「把用户模块重构一下，顺便加上分页，然后把接口文档也更新了」——三件事，三个上下文，三种验证标准，揉在一起必崩。
- ✅「把
UserRepository.findAll改成支持limit/offset分页，保持现有调用方签名不变」——单一目标、有明确边界、可验证。
当任务横跨多个层（比如后端逻辑 + 数据库迁移），更要拆成串行的独立回合，每一步之间插入人工检查点。让 Codex 先改 schema 迁移并跑通，确认无误，再让它改业务代码。把它们塞进一个 goal 里，最典型的结果就是迁移和代码各对一半、互相不匹配。
不确定就先让它出计划
遇到范围模糊、自己也说不清边界的任务，先别给写权限。让 Codex 进入 plan（计划）模式：它会先读上下文、提澄清问题、产出一份「分几步、动哪些文件、每步怎么验证」的计划。你审完计划再放它去写。这一步看似慢，实际省下的是「写错半天再推倒重来」的时间。
关于什么时候该让它自由发挥（vibe coding）、什么时候该先写规格（spec coding），这篇讲得很清楚：vibe coding 与 spec coding 何时切换。简单说：探索性的、可丢弃的原型用 vibe；要合并进主干、有回归风险的改动用 spec。
拆解颗粒度自检清单
每次下指令前，过一遍：
- [ ] 这次改动能用一句话说清吗？（不能就拆）
- [ ] 有没有明确的「完成」判据？（没有就先定义）
- [ ] 跨层了吗？（跨了就拆成串行回合 + 检查点）
- [ ] 我能在 30 秒内 review 它产出的 diff 吗？（不能说明颗粒度太粗）
一位京东后端实习生结合《人月神话》复盘了一个月用 AI 编程的体会，核心结论也是「拆解和验证比生成更重要」，值得一读：用 Claude Code 做 Vibe Coding 的软件工程思考。
二、上下文管理与 AGENTS.md
Codex 的能力上限，很大程度上由「它每一回合能看到什么」决定。进阶用户的核心功夫，就是主动管理上下文预算——既要喂够它干活需要的信息，又不能让无关内容把窗口撑爆导致降智。
AGENTS.md：把规矩写下来，而不是每次口述
Codex 在开始干活前会读 AGENTS.md。这是你给 AI 队友的「入职手册」，放在仓库根目录；放在 ~/.codex/AGENTS.md 则是对所有项目生效的全局规则。Codex 会从仓库根一路走到当前工作目录，沿途的 AGENTS.md 依次叠加，越靠近当前目录的优先级越高，可以局部覆盖更宽泛的规则。
写 AGENTS.md 的几条公认要点：
- 命令优先，解释其次：开头先放「怎么装依赖、怎么跑测试、怎么 lint、怎么构建」的确切命令，而不是大段项目背景介绍。Codex 最需要的是「可执行的事实」。
- 保持精简：AGENTS.md 会被注入会话上下文，废话越多越浪费 token、越容易干扰结果。官方建议单文件控制在
project_doc_max_bytes（默认约 32 KiB）以内，太大就拆到子目录的嵌套 AGENTS.md 里。 - 写明红线：「不要修改
migrations/下已有文件」「改完必须跑pnpm test」「不许改动现有测试断言」这类约束，写进去比每次对话重复管用。 - 不要写的东西：密钥、token、密码绝不能进 AGENTS.md；应该靠沙箱 / 审批强制的东西（比如「不许删库」）别指望用自然语言约束——它没有强制力，真正的硬约束要靠 config.toml 和沙箱。
一句重要提醒：AGENTS.md 里的指令是自然语言，没有 100% 被遵守的保证。 它是「强烈建议」，不是「硬规则」。需要硬保证的，走配置和权限层。
如果你的项目历史包袱重、业务逻辑全在老程序员脑子里，可以考虑给 Codex 注入持久的业务上下文记忆，比如这类开源方案：为 Claude/Codex 注入业务上下文记忆的 Project Brain。
长会话的上下文预算管理
Codex 会在上下文逼近上限时自动做压缩（compaction）：把前面的对话摘要化，腾出空间继续干。但自动压缩是「兜底」，不是「最佳」。进阶用法是主动管理：
- 用
/status随时看当前 token 占用，心里有数。 - 上下文涨得快时，在级联崩溃之前主动
/compact，在自然断点（一个子任务做完）手动压缩，质量远好于撑到最后一刻被动触发。 - 大任务别开一个无尽的会话硬怼。拆成有明确完成判据的多个阶段，每阶段
/new开新会话、必要时/resume续接。 - 收紧单次工具输出：跑大测试套件、
cat巨型文件这类操作是 token 杀手，用tool_output_token_limit之类的配置限制单次注入量，别让一次npm test的满屏输出把窗口塞满。
关于「上下文到底能塞多大、该不该把整个仓库一股脑喂进去」，这篇有更系统的讨论：1M 上下文已经可用：Claude、Gemini 与编程 Agent 怎么选。结论很反直觉：窗口大不等于该塞满，信噪比比绝对容量更重要。大型项目里如何跨会话无缝接续对话，也有专门的讨论：在大型项目中实现对话的无缝接续。
三、审批模式与沙箱：自由度要主动选
很多人把 Codex 一上来就开 --full-auto 或 -a never（永不询问），图个省事，结果某天它「好心」清理项目，把核心配置目录一起删了——这种事故真实发生过：AI 编程工具误删核心配置目录实录。
Codex 的安全控制是两层，理解清楚才能拿捏自由度：
- 沙箱模式（Sandbox）——技术上它能做什么
read-only：只读，最保守，适合让它先调研、出方案。workspace-write：可读写当前工作区、跑工作区内的常规命令，默认没有网络访问。这是本地开发的低摩擦默认档。-
danger-full-access：彻底放开文件系统和网络。只在你明确需要、且清楚后果时用。 -
审批策略（Approval）——什么时候必须问你
- 典型的 Auto 预设 =
workspace-write+on-request：工作区内的读写和命令自动执行，但要改工作区外的文件、或需要联网时，停下来问你。 on-failure：只在命令失败时才问。never：从不问（高危，仅限完全可控的沙箱环境）。
进阶用法不是「全放开」也不是「事事都问」，而是按风险分档：
- 探索 / 读代码 / 出方案 →
read-only，零风险。 - 日常改代码、有版本控制兜底 →
workspace-write+on-request。 - 批量重构、跑长流程、且你已 review 过计划 → 临时调高自由度，跑完调回来。
会话中用 /permissions 随时切换模式；想每次都用同一套行为，写进 ~/.codex/config.toml 持久化。最近社区还热议过怎么有效阻止 AI Agent 读取敏感文件（.env、私钥等），这也属于沙箱边界该管的事：如何阻止 AI Agent 读取敏感文件。
一条铁律：永远在有版本控制（git）的目录里让 Codex 干活。commit 是你最便宜的回滚点——它写崩了，git checkout . 一秒还原，比任何审批都靠谱。
四、代码审查闭环：别让它边写边夸自己
入门用户让 Codex 写完代码，自己扫一眼「看起来对」就合并了。进阶用户知道：Codex 能产出自信但微妙错误的代码，所以审查必须是独立闭环，不能让写代码的同一个上下文自我评价——它有强烈的「确认偏误」，会倾向于说自己写得很好。
用 /review 做独立评审
Codex CLI 内置 /review 命令：它会启动一个专门的评审 agent 检查 diff，按优先级报告问题，而且不会动你的代码。这相当于给你配了个不带感情的代码审查员。对于一个 PR 上的多个关注点，还可以让它每个点派一个子 agent 并行评审，最后汇总。
一个可复现的审查闭环大致四步：
- 限定范围：用 plan 或 AGENTS 约束好这次改动的边界。
- 预埋验收标准：在生成之前就把通过 / 失败的判据写进 prompt——这相当于「给人类意图写单元测试」，diff 必须满足这份契约。
- 独立评审：写完跑
/review，拿到带优先级的问题列表。 - 修复 + 终审：让 Codex 针对评审意见修，最后一道由人拍板。
人的角色：质量守门人，不是流水线工人
这里有个关键认知：你不该当串行执行器，而该当目标定义者和质量守门人。 Codex 负责生成和初步自查，/review 负责独立挑刺，你负责定方向、定验收、做终审。把人从「逐行敲代码」里解放出来，去做机器做不了的判断——这才是 AI 编程真正提效的地方。
社区里有人把这套思路系统化成「Harness Engineering」——给 AI 编程搭治理框架而不是放任自流，值得了解这股工程化趋势：开发者热议构建 Harness Engineering 治理 AI 编程。
五、测试驱动：给 Codex 一面照妖镜
测试驱动（TDD）被公认为 2026 年最可靠的自主编程范式，原因很简单：模型能跑测试、读失败信息、自我纠错，红-绿-重构的循环天然适合 agent。 Codex 写完代码自己跑测试，红了就读报错改，绿了再继续——你要做的是给它一个能跑起来的验证回路。
关键实践
- 先定义「对」长什么样：Codex 只有知道验收标准，才能自己跑这个回路。把测试命令、lint、类型检查写进 AGENTS.md，让它改完自动跑。
- 保护既有测试：在 AGENTS.md 里写死一条——「除非明确要求，否则绝不修改现有测试」。官方把这条列为高风险工作的「非可选」铁律。否则 Codex 为了让测试变绿，会顺手把断言改宽松，制造出「测试全过但功能是坏的」假象。
- 测试、lint、类型检查不是可选项：因为 Codex 会产出「自信但微妙错误」的代码，这三道关是接住它的网。
- 自己跑一遍验证再合并：哪怕 Codex 说「全部通过」，合并前你也亲手跑一次完整验证回路。信任，但要核验。
把验证回路写进 AGENTS.md（示意）
## 提交前必做
- 改完任何 .ts 文件后运行：pnpm test && pnpm lint && pnpm typecheck
- 三项全绿才算完成；任一红了，读报错、修，再重跑
- 绝不修改 tests/ 下已有断言，除非我明确要求
- 新功能必须带对应测试
这样写之后，Codex 每次改完都会自动走一遍验证，把「碰运气」变成「有门禁」。
注意：Codex 的命令、配置键、斜杠命令在不同版本间迭代很快。本文涉及的
--full-auto、/review、/compact、model_reasoning_effort、[mcp_servers]等以社区与官方文档为准，落地前用codex --help核对你本地版本的确切写法。
六、Agent 工作流编排：复杂度沉淀到配置，不困在对话里
到这一层，你已经不是「在跟一个聊天框对话」，而是在编排一套 agent 系统。进阶的标志，是把复杂度从「一次性 prompt」搬到「可复用的配置和文件」里。
Profiles：为不同场景预设档位
config.toml 支持命名 profile，一条命令切换整套配置。比如配一个「快档」用小模型低推理强度跑琐碎改动，配一个「重档」用强模型高推理强度啃硬骨头：
[profiles.fast]
model_reasoning_effort = "low"
[profiles.thorough]
model_reasoning_effort = "xhigh"
用 --profile fast / --profile thorough 切换。model_reasoning_effort 支持 minimal | low | medium | high | xhigh——xhigh 烧 token，留给 plan 模式里最难啃的问题，日常改动用 low/medium 足够。别用大炮打蚊子，也别用步枪轰碉堡，按任务难度匹配推理强度，是省钱又提速的关键。额度怎么算、和 Cursor 怎么比，可参考：Codex vs Cursor 额度对比；想省着用还有人写了工具管理 API 重置次数：高效管理 Codex API 重置次数。
MCP：给 Codex 接外部能力
MCP（Model Context Protocol）让 Codex 连上外部工具——查文档、读数据库、调内部系统。在 config.toml 里用 [mcp_servers.<名字>] 表配置：
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
也可以把 MCP 限定到单个项目（.codex/config.toml，仅限受信项目）。MCP 用多了偶尔会遇到登录态 / 会话问题，这篇有现成的排查：Codex MCP logout 与 session 修复。
Subagents 与 Skills：并行与复用
- Subagents（子代理）：高度可并行的任务——比如同时探索代码库的多个模块、并行实现一份多步计划——可以让 Codex 派多个子 agent 并行干、再汇总。注意：它只在你明确要求并行 / 子代理时才启动，不会自作主张。
- Skills（技能）：把一套可复用的工作流（怎么提交、怎么发布、怎么写某类组件）固化成
SKILL.md，放进技能目录，Codex 在任务匹配时自动加载。这正是「薄 harness、厚 skill」——把反复要解释的流程蒸馏成文件，而不是每次对话重新口述。
如果你同时在用 Codex、Claude Code 等多个 agent 工具，skill 还能跨工具复用，避免每套各写一遍：Agent Skill 跨工具复用：目录结构、版本管理与团队共享。
工具选型：Codex 不是唯一答案
编排的前提是选对工具。Codex 擅长什么、和 Claude Code 等怎么分工，这篇四方对比可以帮你定位：Claude Code vs Codex 四方对比。进阶团队往往不是「只用一个」，而是按场景路由——探索用一个、长链路重构用另一个。
七、常见反模式与避坑清单
把社区踩过的坑集中列一遍，每条都对应一个「别这么干」：
- 反模式 1：一句话甩一个巨大目标。 「帮我把整个项目优化一下」——没有边界、没有验收，等于让它瞎猜。对策：拆到一句话能说清。
- 反模式 2：上下文从不清理，硬怼到降智。 表现是输出开始重复、答非所问、忘记前面说过的约束。社区甚至总结过「一句话指令让 Codex 智商回升」的玄学（实测降智概率从 80% 降到 20%）——但根因还是上下文管理：让 Codex「智商回升」的实测。对策：
/status盯 token，/compact主动压缩，大任务拆会话。 - 反模式 3：默认全自动 + 无版本控制。 它一旦误删 / 误改，你连回滚点都没有。对策：永远在 git 仓库里干活，高危操作设审批。
- 反模式 4：让写代码的上下文自己评审。 它会自我表扬。对策：用独立
/review，人做终审。 - 反模式 5：放任它改测试凑绿。 制造「全过但是坏」的假象。对策：AGENTS.md 写死「不许改既有测试」。
- 反模式 6：用最高推理强度跑所有任务。 烧 token 还慢。对策：profiles 分档，按难度匹配。
- 反模式 7：把规矩每次口述，不沉淀。 同样的解释说一百遍。对策：写进 AGENTS.md / skill。
- 反模式 8：忽略本地资源异常。 Codex 跑久了可能磁盘占用异常膨胀，影响稳定性，发现不对劲先排查：Codex 磁盘占用异常。
一句话收口：这些坑的共性，都是「把 AI 当魔法，而不是当一个需要被工程约束的系统」。 给它边界、给它验证、给它回滚点，它就是个好用的高级工程师；不给，它就是个随机数发生器。
相关阅读
把本文用到的内链集中放一遍，方便按需深挖：
- 还没跑通基础？先看Codex CLI 完整入门：安装、工作流、故障排查与 Claude Code 协同
- 想要全流程实操：全方位 Codex 实战教程
- 何时该切换写法：vibe coding 与 spec coding 何时切换
- 工具选型对照：Claude Code vs Codex 四方对比 与 Codex vs Cursor 额度对比
- 工程化方法论：Harness Engineering 治理 AI 编程 与 用 Claude Code 做 Vibe Coding 的软件工程思考
- 上下文与记忆：1M 上下文已经可用怎么选 与 大型项目对话无缝接续
- 排障专题：Codex MCP logout 修复 与 Codex 磁盘占用异常
FAQ
Q1：我已经看过入门文了，这篇和它最大的区别是什么？
入门解决「装好、能跑、命令是什么、报错怎么修」；本文解决「跑通之后怎么用得好」——任务怎么拆、上下文怎么管、审查怎么闭环、测试怎么驱动、多 agent 怎么编排。一个是「能不能用」，一个是「用得专不专业」。两篇配合看效果最好。
Q2：AGENTS.md 和直接在 prompt 里说，到底有啥区别？
AGENTS.md 是持久且自动注入的——每次会话开始 Codex 都会读，不用你重复口述项目规矩。prompt 适合放「这次任务的具体目标」，AGENTS.md 适合放「这个项目永远成立的约定」（构建命令、测试命令、红线）。把稳定的东西沉淀进 AGENTS.md，对话里只说变化的部分，是省 token 又稳定的关键。
Q3：审批模式到底该怎么设才不会出事？
按风险分档，不要一刀切。调研出方案用 read-only；日常改代码用 workspace-write + on-request（工作区外操作和联网才问你）；只有在你已 review 过计划、且全程在 git 仓库里时，才临时调高自由度，跑完调回来。前提永远是有版本控制兜底——commit 是最便宜的回滚点。
Q4：怎么避免 Codex 把测试改成「永远通过」来骗我？
在 AGENTS.md 里写死「除非明确要求，否则绝不修改现有测试」，这是官方都强调的非可选铁律。同时坚持「写完跑独立 /review、合并前自己亲手跑一遍完整验证」。让测试成为契约，而不是让模型有动机去篡改契约。
Q5：长会话越用越笨，是模型变差了吗？
通常不是模型变差，是上下文被无关内容撑爆导致的降智。对策三连：/status 盯 token 占用，自然断点 /compact 主动压缩，大任务拆成多个有完成判据的会话用 /new 开新局。同时收紧单次工具输出，别让一次大测试的满屏日志吃掉半个窗口。
结语
把这篇浓缩成一句话：进阶 Codex 用户和入门用户的差距，不在 prompt，而在工程纪律。
颗粒度、上下文、审批、审查、测试、编排——这六件事没有一件是「AI 黑魔法」，全是把软件工程的老规矩搬到 AI 协作里。Codex 不会替你思考「这个改动对不对」，它只会高速地把你定义的目标变成代码。所以你的价值不在打字速度，而在定义清楚什么是对的、搭好一个能自动检验对错的回路、守住最后一道终审。
人扶方向盘，不站流水线——这才是进阶。先从今天起：给你最常用的那个项目写一份认真的 AGENTS.md，把构建、测试、红线写进去。这一个动作，就能让你的 Codex 体验上一个台阶。
