Appearance
Codex CLI 常用命令详解：从 /status、/model 到 /review
第一次进入 Codex 后，会发现除了直接输入自然语言之外，还可以输入很多：
text
/status
/model
/review
/init
...这样的命令。
它们通常被称为：
text
Slash Commands
斜杠命令如果说自然语言 Prompt 是：
text
告诉 Codex 要完成什么任务那么 Slash Command 更像：
text
控制 Codex 当前怎么工作可以简单理解成：
text
Prompt
→ 控制任务
Slash Command
→ 控制 Codex这一篇就专门介绍 Codex CLI 中最值得掌握的常用命令，以及它们在实际开发中应该怎么使用。
1. Slash Command 是什么？
启动 Codex：
bash
codex进入交互界面以后，可以直接输入：
text
/status或者：
text
/model这类以：
text
/开头的命令。
它们并不是发送给模型的普通 Prompt。
例如：
text
帮我分析 UserService这是：
text
Prompt而：
text
/status则是：
text
Codex CLI Command两者负责的事情不同。
可以理解成：
text
┌──────────────────────────────┐
│ Codex CLI │
├──────────────────────────────┤
│ │
│ Prompt │
│ │
│ 帮我分析 UserService │
│ │
│ → 给 Coding Agent 的任务 │
│ │
├──────────────────────────────┤
│ │
│ Slash Command │
│ │
│ /status │
│ /model │
│ /review │
│ │
│ → 控制 Codex CLI │
│ │
└──────────────────────────────┘所以使用 Codex 时，实际上存在两套交互方式：
text
自然语言
+
Slash Commands2. 先学会 /help
如果刚开始使用 Codex，第一个应该知道的命令不是：
text
/model也不是：
text
/review而是：
text
/help它的作用非常简单：
查看当前 Codex CLI 版本支持哪些命令和功能。
为什么这个命令很重要？
因为 Codex CLI 还在快速迭代。
你在网上看到：
text
某篇博客
某个 GitHub Issue
某个视频教程
某篇官方文档里面出现的命令，不一定与你当前安装的版本完全一致。
可能出现：
text
旧版本存在
新版本改名
或者
新版本新增
旧版本没有所以最可靠的方法永远是：
text
/help查看：
text
当前版本真正支持什么。
可以把它理解成：
text
不知道命令
↓
先 /help这也是使用 Codex CLI 最值得养成的第一个习惯。
3. /status：查看当前 Codex 状态
第二个非常重要的命令是：
text
/status它用于查看：
当前 Codex Session 的运行状态。
例如可能看到类似：
text
Model: gpt-5.6-sol
Directory: ~/IdeaProjects/xxx
Permissions: Workspace
Agents.md: AGENTS.md
Account: xxx@example.com
Collaboration mode: Default不同 Codex CLI 版本显示内容可能有所不同，但一般值得关注：
text
Model
Directory
Permissions
Agents.md
Account
Collaboration mode
Usage其中最重要的是：
text
Directory
Permissions
Agents.md
Model4. /status 为什么这么重要？
假设你准备让 Codex 修改：
text
~/IdeaProjects/payment-server结果执行：
text
/status发现：
text
Directory: ~那就应该警惕了。
因为这意味着：
text
Codex 当前工作目录可能不是你的项目目录。
正确状态应该更接近：
text
Directory: ~/IdeaProjects/payment-server再比如：
text
Agents.md: <none>说明当前 Session 没有识别到对应的：
text
AGENTS.md如果你本来已经给项目写好了开发规范，就需要检查：
text
是不是启动目录不对？
AGENTS.md 是否放在正确目录？
当前 Session 是否识别到了？所以：
text
/status不仅仅是“看看信息”。
它实际上是一个：
text
环境检查命令5. 每次进入陌生项目，先执行 /status
我比较推荐一个习惯。
启动：
bash
cd xxx-server
codex之后不要马上输入任务。
先：
text
/status确认：
text
① Directory 对不对
② Model 对不对
③ Permissions 对不对
④ AGENTS.md 有没有加载
⑤ 当前模式是否符合预期可以把这个动作理解成：
text
使用 Codex 前的 pre-flight check类似开发之前先看：
bash
git status使用 Codex 时先看：
text
/status两个习惯都很有价值。
6. /model：选择当前使用的模型
Codex 的核心仍然是模型。
不同模型可能在：
text
推理能力
代码能力
速度
Token 消耗
上下文能力
Agent 能力方面有所区别。
因此 Codex 通常提供模型选择能力。
可以通过对应的 Model 命令或交互入口查看当前可以使用的模型。
例如：
text
/model然后选择当前 Session 使用的模型。
具体可选模型取决于：
text
Codex CLI 版本
账户类型
当前产品策略
模型开放情况因此不要把某个具体模型列表写死。
最可靠的方式是：
text
/model查看当前真正可以使用的模型。
7. 模型应该怎么选？
新手很容易陷入一个误区：
text
永远选择最强模型但实际开发并不一定需要这样。
可以粗略按照任务复杂度理解。
简单任务：
text
查找某个类
解释一段代码
修改变量名
增加简单字段
写简单测试更关注：
text
速度复杂任务：
text
跨模块重构
架构分析
复杂 Bug
并发问题
数据库一致性
大型 Code Review更关注：
text
推理能力可以简单理解成：
text
简单任务
→ 快速模型
复杂任务
→ 强推理模型但不要脱离实际模型讨论“哪个最好”。
最重要的还是：
text
任务复杂度
+
模型实际表现
+
Token / Usage 成本8. Reasoning Effort 是什么？
除了选择模型之外，一些 Codex 模型还可能提供：
text
Reasoning Effort可以理解成：
允许模型在回答之前投入多少推理资源。
常见概念可能类似：
text
Low
Medium
High可以粗略理解：
text
Low
→ 思考少
→ 响应快
Medium
→ 平衡
High
→ 思考更多
→ 更适合复杂问题例如：
text
把 UserService 的变量 userInfo 改成 user通常没必要：
text
High Reasoning但如果任务是：
text
分析为什么高并发下偶尔出现余额重复扣减，
涉及 MySQL 事务、Redis 锁和 MQ 重试。就更值得使用较高的推理强度。
9. 不要所有任务都使用 High Reasoning
这是另一个常见误区。
很多人觉得：
text
High
=
更聪明
=
任何时候都应该 High实际上不一定。
如果只是：
text
增加一个 DTO
修改一个枚举
查找一个方法
增加一个 null 判断模型根本不需要进行复杂推理。
反而可能导致：
text
响应更慢
消耗更多
简单问题复杂化所以更合理的方式是：
text
简单任务
→ Low
一般开发
→ Medium
复杂架构 / Bug / Review
→ High当然这仍然只是：
text
调试起点不是固定标准。
10. Permissions：Codex 到底可以做什么？
Coding Agent 和普通聊天 AI 最大的区别是：
text
Codex 可以执行操作例如：
text
读取文件
修改文件
运行 shell
执行 Maven
执行 npm
查看 Git
运行测试因此必须存在：
text
Permission也就是权限控制。
在：
text
/status中可能看到：
text
Permissions: Workspace它表示当前 Codex 被允许操作到什么程度。
不同版本的 Codex CLI 可能提供不同权限模式，所以具体名称应该以：
text
/help
/status显示为准。
11. 为什么 Coding Agent 必须有权限控制？
假设 Codex 只能：
text
读代码风险其实比较低。
但如果它可以：
bash
rm -rf
git reset --hard
git push
kubectl delete
mysql
ssh
curl情况就完全不同了。
Coding Agent 本质上拥有：
text
AI 推理能力
+
Shell 能力
+
文件修改能力所以权限越高：
text
能力越强同时：
text
风险越高这就是 Permission 存在的意义。
12. Workspace 权限怎么理解？
如果 /status 中看到：
text
Permissions: Workspace可以简单理解成：
Codex 主要在当前工作区范围内执行操作。
这类模式通常比较适合日常开发。
例如允许：
text
读取项目代码
修改项目文件
运行测试
查看 Git Diff但对于超出工作区或具有明显风险的操作，可能需要进一步确认。
对于刚开始使用 Codex 的开发者：
text
Workspace通常比一上来给非常宽松的权限更容易控制风险。
13. 什么操作应该特别谨慎？
尤其是下面这些命令：
bash
rm
git reset --hard
git clean
git push
docker rm
kubectl delete
kubectl apply
mysql
psql
ssh
scp以及：
text
修改生产配置
访问生产数据库
调用生产写接口
删除 Migration
修改 CI/CD
发布线上服务最好不要让 Agent 在没有明确确认的情况下自动执行。
可以直接写入：
text
AGENTS.md例如：
markdown
## Safety
未经明确授权：
- 不允许执行 git push
- 不允许执行 git reset --hard
- 不允许删除数据库 migration
- 不允许访问生产数据库
- 不允许执行 kubectl 修改命令
- 不允许修改生产环境配置这样：
text
Permission
+
AGENTS.md共同构成 Agent 的安全边界。
14. /init：初始化 AGENTS.md
上一篇已经介绍过：
text
AGENTS.md它可以理解成：
text
给 Coding Agent 的项目开发规范Codex 提供：
text
/init这样的初始化工作流。
它的主要用途就是：
text
分析当前项目
↓
生成 AGENTS.md 初始内容第一次进入一个没有 Agent 配置的项目时，可以尝试：
text
/init然后再人工修改。
15. 为什么 /init 生成以后还要人工修改？
因为 Codex 能从代码中推断的主要是：
text
技术栈
目录结构
构建方式
测试框架
代码风格例如它可能发现：
text
Java 17
Spring Boot
Maven
MyBatis-Plus
JUnit但是它很难知道：
text
某张表不能直接修改
某个接口必须兼容旧 App
某个字段已经废弃但不能删除
生产环境禁止执行某些操作
团队要求 Controller 不能直接返回 Entity这些属于：
text
隐含业务知识必须由开发者补充。
因此：
text
/init更应该理解为：
text
生成 AGENTS.md 草稿而不是：
text
自动生成最终开发规范16. /review：让 Codex 帮你做 Code Review
这是 Codex 非常值得使用的一项能力。
我们平时写完代码通常会：
bash
git diff自己检查修改。
但现在还可以增加一层：
text
Codex Review例如通过当前版本提供的 Review 能力，对代码变更进行审查。
Review 的核心目的不是：
text
继续修改代码而是：
text
寻找问题例如：
text
空指针
边界条件
并发问题
事务问题
数据一致性
性能问题
安全问题
向后兼容问题17. Code Review 和“帮我看看代码”有什么区别？
下面这种 Prompt：
text
帮我看看代码有没有问题太模糊。
更推荐：
text
Review 当前修改。
重点检查：
1. 空指针
2. 并发问题
3. MySQL 事务
4. BigDecimal 精度
5. Redis 一致性
6. SQL 性能
7. 向后兼容
不要修改代码，只输出问题。这样模型知道：
text
当前角色
=
Reviewer而不是：
text
Implementer这是一个很重要的区别。
18. 推荐的 Code Review 工作流
例如 Codex 完成一个需求：
text
实现用户余额冻结功能。修改完成以后：
text
Implement
↓
Test
↓
Review
↓
Developer Review可以进一步让 Codex：
text
Review 当前 Git Diff。
重点检查：
1. 是否存在余额重复冻结
2. 是否存在并发问题
3. 是否存在事务不一致
4. 解冻操作是否幂等
5. 异常情况下是否会产生脏数据
6. 是否影响旧接口
不要修改代码。这相当于让同一个 Coding Agent：
text
第一轮
→ 开发者
第二轮
→ Reviewer不过需要注意：
AI Review 不能替代人工 Review。
因为：
text
写代码的模型
+
Review 代码的模型仍然可能拥有相同的理解盲区。
所以最终最好仍然：
bash
git diff人工确认。
19. /compact：上下文太长怎么办？
使用 Codex 时间长了以后，会话会越来越长。
例如：
text
分析项目
↓
讨论方案
↓
修改代码
↓
运行测试
↓
修 Bug
↓
继续讨论
↓
再次修改上下文中可能已经包含大量：
text
代码
日志
命令输出
历史讨论
测试结果这时候就涉及：
text
Context问题。
一些 Codex CLI 版本提供类似：
text
/compact的能力，用于压缩当前会话上下文。
可以简单理解：
text
完整历史
↓
提炼重要信息
↓
压缩上下文
↓
继续工作它的目的不是：
text
清空记忆而更接近：
text
把长上下文总结以后继续使用20. 为什么需要 Compact？
假设一个 Session 已经工作很久。
里面包含：
text
几百次文件读取
大量 Maven 日志
多个 Git Diff
多轮 Prompt
测试输出实际上很多内容已经没有必要继续完整保留。
例如：
text
第一次 mvn test 的失败日志问题已经修复以后，就不一定还需要完整保留。
因此可以：
text
原始上下文
100%
↓
Compact
↓
保留关键状态
继续工作这样可以减少无关历史对后续任务的干扰。
21. 什么时候应该考虑 Compact？
比较典型的情况：
text
Session 已经非常长
Codex 开始遗忘早期重点
历史日志很多
已经完成一个阶段
准备进入下一阶段例如：
text
阶段一：分析支付系统
↓
阶段二：完成重构
↓
阶段三：准备补测试在：
text
阶段二 → 阶段三之间就可以考虑压缩上下文。
22. /new：什么时候应该开新 Session？
有时候：
text
Compact还不够。
因为你准备做的已经是：
text
完全不同的任务例如当前 Session 一直在处理：
text
充值模块现在突然要：
text
重构直播 IM 模块两个任务几乎没有关系。
这时候继续使用原来的 Context 反而可能产生干扰。
更合理的是：
text
New Session也就是开启一个新的任务上下文。
具体命令名称可能随版本变化，可以通过：
text
/help查看当前版本是否提供：
text
/new或对应的新会话能力。
23. Compact 和 New 有什么区别？
可以这样理解：
text
Compact
→ 还是同一个任务
→ 只是上下文太长了
New
→ 已经是另一个任务
→ 不需要继承旧上下文例如：
text
分析支付
↓
修改支付
↓
测试支付
↓
继续优化支付适合：
text
Compact而：
text
支付模块完成
↓
开始研究直播模块更适合：
text
New24. Plan 不一定等于 /plan
上一篇我们介绍了：
text
Plan First很多人会自然地寻找：
text
/plan但这里需要区分：
text
Plan这个概念和：
text
/plan这个具体命令。
Codex 的具体 Slash Command 和 Collaboration Mode 会随着版本变化。
所以不要形成：
text
没有 /plan
=
Codex 不能 Plan这样的误解。
即使当前版本没有某个固定的 /plan 命令，也可以直接告诉 Codex：
text
先分析这个需求。
不要修改代码。
请：
1. 分析当前实现
2. 找出涉及文件
3. 给出修改方案
4. 分析风险
5. 给出测试方案
完成以后停止，不要开始修改。本质上仍然是在：
text
Plan25. Plan 什么时候最有价值？
如果只是：
text
增加一个字段
修改一个变量
增加一个 null 判断
修复简单拼写没必要进行复杂规划。
但如果任务涉及：
text
数据库结构修改
支付逻辑
钱包逻辑
并发控制
事务
接口兼容
跨模块重构
认证系统
复杂 Bug
架构调整就非常值得：
text
先 Plan
再 Implement可以把任务分成：
text
Understand
↓
Plan
↓
Implement
↓
Test
↓
Review而不是：
text
Prompt
↓
直接开始改26. Plan Prompt 怎么写？
可以直接使用下面这种模板：
text
分析这个需求，先不要修改代码。
目标：
实现用户余额冻结功能。
请先完成：
1. 找到当前余额数据结构
2. 找到所有余额扣减入口
3. 找到提现逻辑
4. 找到充值逻辑
5. 分析事务边界
6. 分析并发控制
7. 给出实现方案
8. 列出需要修改的文件
9. 给出测试方案
10. 分析向后兼容风险
完成以后停止，不要修改文件。等方案确认以后，再告诉它：
text
按刚才的方案实施。
要求：
1. 不修改现有 API
2. 不改变旧业务行为
3. 不提交 Git
4. 完成后运行相关测试
5. 最后检查 git diff这就是很典型的：
text
Plan
→ Implement工作流。
27. /status、/model、/review 应该怎么组合？
假设现在要修复一个复杂 Bug。
首先进入项目：
bash
cd xxx-server
codex先执行：
text
/status确认：
text
目录
模型
权限
AGENTS.md然后根据任务复杂度选择合适模型：
text
/model接下来先分析：
text
分析用户余额偶尔重复扣减的问题。
先不要修改代码。
重点检查：
1. MySQL 事务
2. Redis 锁
3. MQ 重试
4. 接口重复请求
5. 幂等机制方案确认以后：
text
按方案修复。
完成后运行相关测试。修改完成以后：
text
/review或者使用 Review Prompt：
text
Review 当前 Git Diff。
重点检查：
1. 是否真的解决重复扣减
2. 是否引入死锁
3. 是否存在锁失效问题
4. 是否破坏原有业务
5. 是否存在新的并发风险
不要修改代码。最终再人工：
bash
git diff
git status整个流程就是：
text
/status
↓
/model
↓
Plan
↓
Implement
↓
Test
↓
/review
↓
Developer Review28. Codex CLI 常用命令可以怎么分类？
不需要死记每一个命令。
更容易理解的方式是按照用途分类。
text
Codex CLI
│
├── 状态
│ ├── /help
│ └── /status
│
├── 模型
│ └── /model
│
├── 项目
│ └── /init
│
├── 工作流
│ ├── Plan
│ └── /review
│
├── 上下文
│ ├── /compact
│ └── /new
│
└── 权限
└── Permissions不同版本可能存在：
text
增加
删除
改名
调整入口所以分类思想比背命令更重要。
29. 新手真正需要记住哪些命令？
如果刚开始使用，其实没有必要记很多。
第一阶段只需要掌握：
text
/help
/status
/model
/init
/review再理解：
text
Plan
Permissions
AGENTS.md就已经可以完成大多数基础开发任务。
可以简单记：
| 命令 / 概念 | 作用 |
|---|---|
/help | 查看当前版本有什么能力 |
/status | 查看当前 Session 状态 |
/model | 查看或调整当前模型 |
/init | 初始化项目 Agent 指令 |
/review | 对当前代码修改进行 Review |
/compact | 压缩较长的上下文 |
/new | 开启新的任务上下文 |
Plan | 复杂任务先规划再执行 |
Permissions | 控制 Codex 可以执行什么 |
AGENTS.md | 告诉 Codex 项目规则 |
30. 一个推荐的 Codex CLI 日常流程
实际开发中，我更推荐固定成下面这套流程：
text
① cd 项目
↓
② codex
↓
③ /status
↓
④ 确认 AGENTS.md
↓
⑤ 选择合适模型
↓
⑥ 描述任务
↓
⑦ 复杂任务先 Plan
↓
⑧ Implement
↓
⑨ Test
↓
⑩ Review
↓
⑪ git diff
↓
⑫ 人工确认注意：
text
Codex Review和：
text
人工 Review并不是二选一。
更合理的是：
text
Codex Review
+
Developer ReviewAI 先帮助我们发现一部分问题。
最终仍然由开发者负责代码质量。
31. 不要把 Slash Command 当成 Codex 的核心
学习 Codex CLI 时很容易变成：
text
今天学 /status
明天学 /review
后天学 /compact最后背了一堆命令，却仍然不会很好地使用 Coding Agent。
真正重要的其实是：
text
如何定义任务
如何控制范围
如何让 Agent 理解项目
如何规划复杂需求
如何验证修改
如何控制权限
如何 ReviewSlash Commands 只是：
text
工具而真正的核心是：
text
Agent Workflow32. 最后怎么记？
如果只记几个命令：
text
/help
→ 我现在能用什么？
/status
→ 我现在是什么状态？
/model
→ 我现在用什么模型？
/init
→ 这个项目怎么让 Agent 快速理解规则？
/review
→ 当前修改有没有问题？
/compact
→ 上下文太长怎么办？
/new
→ 我要开始另一个任务怎么办？然后再记三个核心概念：
text
AGENTS.md
→ 项目规则
Plan
→ 先想清楚
Permissions
→ 控制执行边界最后记住一条真正重要的 Codex 工作流：
text
Status
↓
Understand
↓
Plan
↓
Implement
↓
Test
↓
Review也就是：
text
先确认环境
再理解问题
复杂任务先规划
然后修改代码
自动运行测试
最后进行 ReviewCodex CLI 真正提高效率的地方，并不是：
text
少敲几个命令而是把过去需要开发者手动完成的大量工作：
text
查代码
找调用链
分析影响范围
改多个文件
执行测试
检查 Diff
Code Review逐渐组合成一个完整的：
text
Agent Workflow当你开始习惯这种工作方式以后，Codex 就不再只是：
text
终端里的 ChatGPT而会真正变成：
text
能够参与整个软件开发流程的 Coding Agent