许多人用 Codex，只会一句话派活：

帮我改一下这个功能。
帮我修一下这个 bug。
帮我重构一下这个页面。

这样当然能用，但不够稳。

Codex 真正提效的地方，不只是“让它写代码”，而是你能用命令把它纳入开发流程：先看状态、定权限、给上下文、规划任务、检查改动、做审查、必要时分叉探索。

这篇文章就把我认为最值得掌握的 Codex 常用命令重新捋一遍。

不过在列命令之前，先说一个很重大的前提： Codex 里有会话命令，也有 CLI 命令，还有启动参数。 这三类东西长得都像“命令”，但使用位置不一样。如果混着记，照抄的时候就容易翻车。

Codex 命令提效工作流地图

本文写作时核对的本机版本是 codex-cli 0.142.0-alpha.6 ，时间是 2026 年 7 月 8 日。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

先理解结构，不要修改代码。

第六步，先规划再执行：（关于计划，这里我推荐superpowers）

先不要修改文件。
请说明要改哪些文件、为什么改、风险是什么、验证方式是什么。
等我确认后再执行。

第七步，看真实改动：

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