很多人用 Codex，只会一句话派活：
帮我改一下这个功能。
帮我修一下这个 bug。
帮我重构一下这个页面。
这样当然能用，但不够稳。
Codex 真正提效的地方，不只是“让它写代码”，而是你能用命令把它纳入开发流程：先看状态、定权限、给上下文、规划任务、检查改动、做审查、必要时分叉探索。
这篇文章就把我认为最值得掌握的 Codex 常用命令重新捋一遍。
不过在列命令之前，先说一个很重要的前提：Codex 里有会话命令，也有 CLI 命令，还有启动参数。 这三类东西长得都像“命令”，但使用位置不一样。如果混着记，照抄的时候就容易翻车。
本文写作时核对的本机版本是 codex-cli 0.142.0-alpha.6，时间是 2026 年 6 月 28 日。Codex 更新非常快，CLI、Codex App、IDE 扩展、Cloud/Web 入口的命令也可能不同。文章里的命令不要盲背，最终以你当前界面输入 / 后弹出的命令列表、codex --help 和官方文档为准。
先分清三种入口
很多混乱都来自一个误会：我们把所有“能控制 Codex 的东西”，都叫成了斜杠命令。
其实至少要分三类：
| 类型 | 长什么样 | 什么时候用 |
|---|---|---|
| 会话内 slash 命令 | /model、/status、/diff | 已经进入 Codex 对话后，用来控制当前会话 |
| CLI 顶层命令 | codex doctor、codex review、codex fork | 在终端里执行，用来诊断、审查、恢复、分叉任务 |
| 启动参数 | codex -C、codex -s、codex -a、codex --search | 启动 Codex 前先设好目录、权限、模型和搜索能力 |
这三类东西不能混着写。
codex fork 是顶层命令，不等于你在会话里一定能敲 /fork。codex review 是终端命令，也不等于你的当前界面一定有 /review。反过来，/mention 在官方 CLI 文档里是 slash command，但如果你当前使用的是另一个入口，可能表现为 @ 文件引用、上下文面板、点选文件，而不是直接敲 /mention。
所以命令文章最容易犯的错，不是少写一个命令，而是不说明这个命令属于哪个入口。
常用命令速查表
先把这篇会讲到的常用命令放进一张速查表：
| 写法 | 类型 | 主要用途 |
|---|---|---|
输入 / 查看命令列表 | 会话内能力 | 确认当前入口支持哪些 slash 命令 |
/status | slash 命令 | 查看当前模型、目录、权限和上下文状态 |
/model | slash 命令 | 切换模型和推理档位 |
/permissions | slash 命令 | 调整 Codex 当前能做什么 |
/usage | slash 命令 | 查看额度、限制和重置情况 |
/mention | slash 命令 / 上下文引用能力 | 把关键文件加入上下文，不同入口表现可能不同 |
/plan | slash 命令 / 规划模式 | 复杂任务先规划，再执行 |
/diff | slash 命令 | 查看 Codex 当前改了什么 |
/review | slash 命令 / 审查能力 | 审查当前改动的风险 |
/compact | slash 命令 | 压缩长会话，释放上下文 |
/init | slash 命令 / 项目规则 | 初始化或辅助生成 AGENTS.md |
/goal | slash 命令 / 目标管理 | 给长任务设置目标和完成标准 |
/side | slash 命令 / 旁路会话 | 临时讨论，不污染主线 |
/ps、/stop | slash 命令 | 查看和停止后台任务 |
/mcp、/skills、/ide | slash 命令 | 管理外部工具、技能和 IDE 上下文 |
codex doctor | CLI 顶层命令 | 诊断本地安装、配置、认证和运行时 |
codex review --uncommitted | CLI 顶层命令 | 非交互式审查本地未提交改动 |
codex fork --last | CLI 顶层命令 | 分叉最近会话，试新方案 |
codex -C、-s、-a、-m、--search | 启动参数 | 启动前设好目录、权限、模型和搜索能力 |
下面按真实工作流来讲：开工前看什么，过程中怎么控，改完以后怎么验收。
一、开工前，先看当前命令列表
如果你已经进入 Codex 会话，最稳的动作不是凭文章记忆敲命令，而是先输入 / 看当前界面弹出的命令列表。
不同入口可能不一样：
| 入口 | 命令可能有什么差异 |
|---|---|
| Codex CLI | 更偏终端、仓库、沙盒、审查和本地执行 |
| Codex App | 更偏桌面工作台、插件、连接器和线程 |
| IDE 扩展 | 更贴近编辑器上下文 |
| Cloud / Web | 更偏托管任务和异步执行 |
你在 App 里看到的，不一定能在 CLI 里敲；你在 CLI 顶层能运行的，也不一定是会话里的 /xxx。
所以文章、教程、X 上的截图都只能当参考，最终以当前入口的命令列表为准。
这不是一句客套话，而是使用 Codex 的第一条工程纪律。
二、开工前，先跑 codex doctor
如果会话里的 /status 是仪表盘，那终端里的 codex doctor 就是本机环境体检。
在终端里运行：
codex doctor
它适合检查本地安装、配置、登录、运行时、MCP 等基础状态。很多时候你以为是模型不会干活，其实是环境一开始就不对。
比如：
| 你以为的问题 | 真实可能原因 |
|---|---|
| Codex 不会读某些上下文 | 当前工作目录不对 |
| 某些工具不可用 | MCP 或插件没启动成功 |
| 命令表现和别人不同 | 版本不同、入口不同 |
| 一直请求失败 | 登录或网络状态有问题 |
| 权限很怪 | 沙盒或审批策略没设对 |
写教程、排查问题、给别人复现步骤时，版本号也很重要：
codex --version
当前本机输出是：
codex-cli 0.142.0-alpha.6
Codex 更新快，不写版本就容易变成“你那里能用，我这里不能用”。
三、用 -C 固定项目目录
Codex 改错项目目录，是最容易发生、也最不该发生的问题。
所以启动时建议直接指定目录：
codex -C /你的项目路径
-C 的作用是告诉 Codex 使用哪个目录作为工作根目录。这样它一启动就站在正确项目里，而不是靠你进入会话后再解释。
很多“怎么没改对”的问题，本质不是 AI 不会，而是它一开始就不在那个项目里。
如果你经常在多个项目之间切换，这个参数非常值得养成习惯：
codex -C ~/work/promptbox
codex -C ~/work/company-admin
codex -C ~/work/ai-article
对人来说，打开错文件夹只是小失误；对 Codex 来说，目录错了，后面的搜索、读取、修改、构建都可能错。
四、用 -s、-a 和 /permissions 控制权限
我不建议日常一上来就给 Codex 最大权限。
更稳的启动方式是：
codex -C /你的项目路径 -s workspace-write -a on-request
这里面有两个关键参数。
-s 是沙盒模式，常见取值可以这样理解：
| 参数 | 适合场景 |
|---|---|
read-only | 只读分析、代码审查、理解项目 |
workspace-write | 允许改当前项目，适合日常开发 |
danger-full-access | 高危模式，不建议日常使用 |
-a 是审批策略。比如：
-a on-request
意思是需要关键动作时，让 Codex 按需请求你确认。
如果你已经在会话里，也可以看当前入口是否支持：
/permissions
它适合在会话中调整 Codex 能做什么。
这不是不信任 AI，而是基本工程纪律。你可以把 Codex 理解成一个很能干的开发同事，但再能干，也不能一上来给生产库权限、系统目录权限和无确认执行权限。
五、用 /model 或 -m 控制火力
在会话里切模型，可以用：
/model
启动时指定模型，可以用：
codex -m 你的模型名
我当前 CLI 启动界面里明确显示 /model to change，所以这个属于可以放心写进文章的会话内命令。
模型选择的原则不用复杂：
| 任务 | 建议 |
|---|---|
| 改文案、补小 bug、解释日志 | 不一定上最强模型 |
| 跨文件重构、状态管理、复杂排错 | 用更强推理模型 |
| 涉及架构判断和边界设计 | 不要省推理能力 |
Codex 的提效，不只是让它干活，还包括让它用合适的火力干合适的活。
六、用 /status 和 /usage 看当前状态
进入会话后，建议先看状态：
/status
它适合确认当前模型、目录、权限、上下文和 session 状态。
如果任务比较长，再看一下额度和重置情况：
/usage
我当前 CLI 会话里出现过一条提示：
You have 2 rate-limit resets available. Run /usage to use one.
所以 /usage 在当前环境里是能确认的。
这两个命令都不花哨，但很实用。很多问题不是代码写错了，而是一开始状态就错了。
七、/mention 可以写，但要说明入口差异
这次我专门改了对 /mention 的写法。
更准确地说：/mention 在官方 CLI slash command 文档里是存在的，用于把文件加入上下文。但在不同入口里，它可能不表现为你直接敲 /mention path，而是表现为点选文件、拖入文件、@ 引用、上下文面板或 IDE 当前文件。
所以文章里不能写得像它在任何地方都一定可用，也不能说它完全不是命令。
更稳的写法是：
请重点查看这些文件：
- public/manifest.json
- src/sidepanel/App.tsx
- src/db/index.ts
- src/services/llm.ts
先理解它们之间的关系，不要修改代码。
如果你当前 CLI 的 slash 列表里有 /mention，也可以直接用它指定文件。核心不是命令名字，而是上下文要准。
很多人遇到问题喜欢说：
你看一下整个项目。
这句话听起来很爽，但项目一大，信息就会变杂。Codex 看到的东西越多，不一定越聪明，有时反而更容易跑偏。
更好的方式是告诉它：
| 你要给什么 | 示例 |
|---|---|
| 关键文件 | App.tsx、db/index.ts、manifest.json |
| 当前问题 | “收藏状态切换后列表没有刷新” |
| 不要做什么 | “先不要改代码” |
| 输出要求 | “先说明数据流和风险” |
上下文不是越多越好，而是越准越好。
八、/plan 有就用，没有就用规划提示词
复杂任务不要一上来就让 Codex 改代码。
如果你的当前入口支持 /plan，可以用它先进入规划模式。但为了跨入口更稳，我建议你也记住普通提示词版：
先不要修改文件。
请先分析当前实现，并按下面结构给我方案：
1. 需要查看或修改哪些文件
2. 每个文件为什么要改
3. 可能影响哪些数据流和交互状态
4. 风险点是什么
5. 你建议的验证方式是什么
等我确认方案后再执行。
这比硬背某个命令更可靠。
因为真正重要的不是命令本身，而是让 Codex 从“马上开干”切换到“先想清楚”。
比如你想改一个 PromptBox 插件，直接说：
帮我把词库和收藏合并。
这句话太粗了。Codex 可能马上开始改 UI，但它不一定会先想清楚：
| 关键问题 | 如果没想清楚会怎样 |
|---|---|
| 收藏是不是词库里的一个状态 | 数据结构可能越改越乱 |
| 原收藏页要不要删除 | 页面逻辑可能残留两套 |
| 筛选状态怎么保存 | 切 tab 或刷新后状态丢失 |
| IndexedDB 是否要迁移 | 老数据可能读不出来 |
| 列表刷新机制怎么处理 | UI 变了，数据没同步 |
所以复杂任务一定要先规划。至于你用 /plan，还是用上面这段提示词，取决于当前入口支持什么。
九、用 /diff、git diff 和 codex review 做验收
改完代码以后，不要只看 Codex 的总结。
它说：
我已经完成了修改。
你就信了，这很危险。
在会话里可以看当前入口是否支持：
/diff
在终端里更通用的是：
git diff
你要重点检查：
| 检查点 | 你要警惕什么 |
|---|---|
| 改了哪些文件 | 有没有动到无关模块 |
| 是否新增文件 | 有没有生成临时文件、调试文件 |
| 是否删除逻辑 | 有没有误删老功能 |
| 是否改配置 | 有没有动构建、权限、环境配置 |
| UI 和数据是否一致 | 有没有只改页面没改数据流 |
| 有没有临时代码 | console、mock、TODO、硬编码 |
第二步可以做审查。
如果当前会话支持 /review，可以直接用。终端里更稳的是：
codex review --uncommitted
当前本机 codex help review 里明确能看到这个命令，它用于非交互式代码审查。你也可以加自定义审查要求：
codex review --uncommitted "重点检查状态同步、类型错误、构建风险、边界情况和无关修改"
最后别忘了跑项目自己的验证命令：
npm run build
npm test
Codex 写完，还不算完。看到 diff、审过风险、跑过验证，才算接近完成。
十、长期项目，把规则写进 AGENTS.md
长期项目不要每次都靠口述规则。
如果当前入口支持 /init，可以用它初始化项目规则；如果不支持，也可以手写 AGENTS.md。
重点不是 /init 本身，而是项目里要有一份写给 Codex 的说明书：
# AGENTS.md
## 项目背景
这是一个 Chrome MV3 Side Panel 扩展。
## 技术栈
- Vite
- React
- TypeScript
- Tailwind CSS
- Zustand
- IndexedDB
## 开发规则
- UI 必须适配浏览器侧边栏宽度
- 修改后必须运行 npm run build
- 不要随意改动 manifest 结构
- 生成结果区域不能无限拉长页面
- 复制并保存后，需要跳转到词库并刷新列表
- 收藏/取消收藏后，需要同步本地收藏状态
## 验收标准
- 关键交互需要手动验证
- build 必须通过
- 不要引入无关依赖
这东西特别重要。
因为你不用每次都重新解释项目背景，不用每次都提醒它技术栈，也不用每次都重复“别乱改”。普通人每次口述需求，高手把规则写成文档。
十一、探索新方案，用 /side、/goal 或 codex fork
复杂任务里，容易出现两种情况。
第一种是任务越做越散。你一开始只是想修一个 bug，聊着聊着变成顺手重构组件，再顺手改样式，再顺手换依赖，最后你都忘了这轮到底要完成什么。
如果当前入口支持 /goal，可以给任务设置目标、范围和完成标准。普通提示词版也可以这样写：
本轮目标：修复收藏状态不同步的问题。
范围：只允许修改收藏状态、词库列表刷新和相关测试。
完成标准：收藏/取消收藏后，词库列表、收藏筛选、本地存储三处状态一致，并通过 npm run build。
第二种是中途冒出新想法。
比如你做一个插件 UI，有两个思路：
| 方案 | 做法 |
|---|---|
| A | 保留底部四个 tab |
| B | 把词库和收藏合并成一个 tab，用筛选区分 |
如果当前入口支持 /side，可以开旁路问题，不污染主线。终端里可确认的会话分叉命令是：
codex fork --last
当前本机 codex help fork 里明确能看到这个命令。
注意这里的重点不是“有一个酷命令”，而是一个工作习惯：探索型方案不要污染主线，长任务要有边界。
十二、后台任务用 /ps、/stop，查新资料用 --search
Codex 能做的事情越来越多，长任务也越来越常见。比如跑构建、跑测试、启动 dev server、开浏览器验证、本地生成报告，这些都可能产生后台进程。
如果当前入口支持，可以用：
/ps
/stop
/ps 用来看当前有哪些任务或进程还在跑。/stop 适合在任务明显跑偏、卡住或不该继续时刹车。
如果任务涉及新文档、新 API、新框架写法，可以在启动时启用搜索：
codex --search
比如 Chrome Extension 规范变了、某个库升级了、某个云服务控制台流程更新了，这种就别让模型凭记忆硬猜。
工程里最贵的不是“慢一分钟”，而是“凭旧知识改错一大片”。
我现在更推荐的 Codex 工作流
如果你做的是一个真实项目，我建议按这套流程来。
第一步，确认版本和环境：
codex --version
codex doctor
第二步，从正确目录启动，并设好权限：
codex -C /你的项目路径 -s workspace-write -a on-request
第三步，进入会话后先输入 /，看当前入口到底支持哪些命令。
第四步，必要时切模型：
/model
第五步，给准上下文，不要全项目乱扫：
请重点查看这些文件：
- manifest.json
- App.tsx
- db/index.ts
- llm.ts
先理解结构，不要修改代码。
第六步，先规划再执行：
先不要修改文件。
请说明要改哪些文件、为什么改、风险是什么、验证方式是什么。
等我确认后再执行。
第七步，看真实改动：
git diff
第八步，做代码审查：
codex review --uncommitted
第九步，跑项目验证：
npm run build
npm test
第十步，长期规则沉淀到：
AGENTS.md
这套流程的关键不是命令多，而是每一步都能落地。
最后，真正该记的是这 10 个动作
如果你懒得记太多，我建议记这 10 个动作：
| 控制动作 | 推荐用法 |
|---|---|
| 看当前入口支持什么 | 输入 / 查看命令列表 |
| 看版本 | codex --version |
| 体检环境 | codex doctor |
| 固定项目目录 | codex -C /项目路径 |
| 控制权限 | -s workspace-write -a on-request 或 /permissions |
| 切模型 | /model 或 codex -m |
| 看状态和额度 | /status、/usage |
| 查真实改动 | /diff 或 git diff |
| 审查改动 | /review 或 codex review --uncommitted |
| 分叉探索 | /side、/goal 或 codex fork --last |
你会发现，这里面既有 slash 命令，也有 CLI 命令，还有启动参数和普通提示词。
这才是重点。
Codex 的提效，不是靠背一堆 /xxx。真正提效的是你知道：哪些应该在会话里做，哪些应该在终端里做，哪些应该在启动前设好，哪些应该写进项目规则。
别把 Codex 当许愿池，要把它当工程同事管。
会管理，它才真能干活。
参考资料
- OpenAI Codex CLI Slash Commands
- OpenAI Codex App Commands
- OpenAI Codex IDE Slash Commands
- OpenAI Codex CLI Reference
- OpenAI Codex Best Practices
- OpenAI AGENTS.md Guide
- 本机核对：
codex-cli 0.142.0-alpha.6、codex --help、codex help review、codex help fork、本机 Codex 二进制内置 slash command 文案，时间：2026 年 6 月 28 日