这是一篇面向终端开发者的 Codex CLI 中文实战教程，补充了 /model、/status、/diff、/review 以及自定义快捷命令（如 /btw）的说明。

Codex CLI 详细使用教程：从安装、登录到实战自动改代码

如果你想把 OpenAI 的编码代理真正放进终端里用起来，那么 Codex CLI 是目前非常值得上手的一种方式。它不是单纯的“问答式 AI”，而是一个可以在本地目录中读取文件、修改代码、执行命令、协助调试、生成补丁的命令行编码助手。

这篇文章我会从 Codex CLI 是什么、如何安装、如何登录、常用命令、交互式 Slash Commands、典型工作流、配置方法、MCP 扩展、实战技巧、风险控制 等多个方面，系统讲清楚它的使用方式。你看完后，基本就可以把它真正用于日常开发。

适合谁看？ 如果你平时就用终端、Git、测试命令和远程服务器做开发，这篇文章会非常实用。

先说结论： Codex CLI 最有价值的地方，不是“能不能写代码”，而是它能直接进入真实工作目录，帮你读仓库、改文件、跑命令、配合 Git 做完整开发闭环。

一、Codex CLI 是什么？

Codex CLI 是 OpenAI 提供的一个 本地终端编码代理（coding agent）。它运行在你的电脑或服务器终端中，可以在你指定的项目目录里：

读取代码
分析项目结构
修改文件
执行命令
辅助修复 Bug
协助重构
帮你补测试
给出实现方案

和普通聊天机器人相比，Codex CLI 更像一个“在终端里工作的 AI 工程助手”。

它的核心价值不只是会写代码，而是能在真实项目目录里协助你完成一整段开发流程。

适合的场景包括：

快速理解陌生项目
实现中小型功能
修复报错与调试问题
重构已有模块
补测试、补文档、补脚本
做原型验证和自动化实验

二、Codex CLI 和网页版 / IDE 插件版有什么区别？

很多人第一次接触 Codex，会混淆几种形态：

1. 网页版 Codex

这是 OpenAI 提供的云端形态，偏“远程代理”。

2. IDE 里的 Codex

比如 VS Code、Cursor、Windsurf 等编辑器集成形态，更偏编辑器内协作。

3. Codex CLI

也就是本文讲的重点：在终端直接运行的本地编码代理。

Codex CLI 的优势主要在于：

离代码仓库更近
离命令行工作流更近
更适合 Linux / macOS / 远程服务器 / SSH 开发环境
很适合配合 git、测试命令、构建脚本一起使用

如果你本身就习惯：

git
npm / pnpm / yarn
pytest / uv / cargo / go test
docker
tmux

那么 Codex CLI 会非常顺手。

三、安装 Codex CLI

根据官方说明，Codex CLI 支持以下常见安装方式。

方式 1：使用 npm 全局安装

npm install -g @openai/codex

这是最常见的安装方式。

安装完成后，执行：

codex

如果能正常启动，说明安装成功。

方式 2：使用 Homebrew 安装（macOS 常见）

brew install --cask codex

如果你是 macOS 用户，并且平时大量使用 Homebrew，这种方式也很方便。

方式 3：从 GitHub Release 下载二进制包

官方仓库提供了不同平台的可执行文件，例如：

macOS arm64
macOS x86_64
Linux x86_64
Linux arm64

下载后解压，通常需要把二进制文件重命名为 codex，再放到 PATH 中可执行目录，例如：

chmod +x codex
sudo mv codex /usr/local/bin/codex

适合：

不想依赖 npm
在精简服务器环境部署
想固定版本

四、如何登录 Codex CLI

Codex CLI 支持两种主流认证方式。

1. 使用 ChatGPT 账号登录

官方推荐直接运行：

codex

然后在界面中选择：

Sign in with ChatGPT

如果你的账号属于这些计划之一，通常可以直接使用：

Plus
Pro
Business
Edu
Enterprise

这种方式的优点是：

不需要手动管理 API Key
对个人用户更方便
更适合日常使用

2. 使用 OpenAI API Key

如果你更偏向 API 工作流，也可以使用 API Key。

这种方式更适合：

自动化环境
脚本化调用
团队统一接入
与其他 OpenAI 工具链共用凭证

但相对来说，初学者更建议先用 ChatGPT 登录方式上手。

五、第一次启动后，它能做什么？

Codex CLI 启动后，本质上会进入一个终端交互式编码代理环境。

你可以直接给它任务，例如：

帮我阅读这个项目，并总结目录结构

或者：

为这个 FastAPI 项目增加 JWT 登录功能

或者：

运行测试，定位失败原因，并修复

Codex 会结合当前目录内容进行分析，并尝试：

读取项目文件
提出实现方案
修改代码
执行命令
给出结果说明

这也是它和“普通聊天”最大的区别：它工作的对象不是抽象代码片段，而是你当前真实项目目录。

六、最常见的使用方式

Codex CLI 主要可以分成两类使用方式：

交互式模式
一次性执行模式（exec）

七、交互式模式

直接运行：

codex

进入后，你可以像和一个终端工程师对话一样给它连续下任务。

例如：

先帮我看一下这个仓库是做什么的

然后再继续：

找出认证逻辑在哪个目录

再继续：

把登录流程改成支持 refresh token

这种方式适合：

你要连续完成一串相关开发任务
你希望它先理解项目，再逐步修改
你想让它边分析边执行

交互式模式的优点

上下文连续
更适合复杂任务
方便追问与细化

适用场景

重构一个模块
修一个复杂 Bug
先分析后编码
边测试边修复

八、一次性执行模式：`codex exec`

如果你不想进入完整交互界面，也可以直接一条命令完成任务。

codex exec "为当前项目补充 README 使用说明"

或者：

codex exec "运行测试并修复失败用例"

这种方式的特点是：

执行完就退出
适合单次任务
很适合脚本化、批量化工作流

适合的例子

1. 让它快速读项目

codex exec "总结当前仓库结构与技术栈"

2. 让它补文档

codex exec "根据当前代码结构，为项目生成一份中文 README"

3. 让它修测试

codex exec "运行 pytest，修复失败测试，最后总结改动"

4. 让它做小型功能

codex exec "给这个 Node.js 项目增加一个 /health 路由，并补测试"

九、自动化模式：`--full-auto`

如果你希望 Codex 更像“自动执行代理”，可以使用：

codex exec --full-auto "重构当前仓库中的日志模块，并保持测试通过"

--full-auto 的含义可以理解为：

在受控范围内自动批准工作区内改动
减少频繁确认
更适合让它完整完成一项实现任务

适合使用 `--full-auto` 的场景

你已经在测试分支里
需求边界清晰
只是让它做项目内修改
你后续还会自己 review 一遍

不建议乱开的场景

生产目录
你不了解项目时
涉及迁移、删除、大规模重构
目录里有敏感文件或高风险脚本

十、激进模式：`--yolo`

还有一个更激进的选项：

codex exec --yolo "修复当前仓库所有 lint 问题并提交修改"

--yolo 顾名思义，就是更少限制、更少保护。

它适合什么？

临时实验仓库
沙盒环境
可随时回滚的分支
你非常清楚自己在做什么

为什么不建议新手一上来就用？

因为你是在给一个有执行能力的代理更大的权限。虽然效率更高，但风险也同步上升。

我的建议是：

先用普通模式熟悉
再用 --full-auto
最后再考虑 --yolo

一组很实用的 Codex 终端快捷命令

如果你平时经常在终端里切换不同任务，下面这组命令可以直接收藏：

# 启动交互式会话
codex

# 让 Codex 一次性执行一个任务
codex exec "总结当前仓库结构与技术栈"

# 自动批准工作区内改动，适合边界清晰的小任务
codex exec --full-auto "修复当前项目中的 lint 问题并保持测试通过"

# 更激进的自动执行模式，只建议在可回滚环境使用
codex exec --yolo "批量整理当前目录中的示例代码"

# 查看帮助
codex --help

# 查看 exec 子命令帮助
codex exec --help

怎么理解这 6 条？

codex：进入交互式模式，适合连续对话、连续改代码

codex exec "..."：一次性执行单个任务，适合脚本化调用

codex exec --full-auto "..."：减少审批步骤，适合边界清晰的仓库内修改

codex exec --yolo "..."：更高权限、更高风险，只适合实验环境

codex --help：查看顶层命令说明

codex exec --help：查看一次性执行模式的详细参数

如果你是第一次上手，建议先把上面 6 条命令跑一遍，你会更快建立对 Codex CLI 的使用感觉。

交互式会话里更好用的 Slash Commands

很多人第一次用 Codex CLI，只会输入自然语言任务，但其实在交互式界面里，Slash Commands 才是提效关键。

你可以在输入框里直接输入 /，然后选择命令；也可以手动敲完整命令名。

下面是几个最值得优先掌握的内建命令：

命令	作用	什么时候用
`/model`	切换当前模型，部分情况下还能调整推理强度	想在速度和深度之间切换时
`/status`	查看当前会话配置、token 使用、上下文容量	想确认当前线程状态时
`/diff`	直接查看当前 Git diff，包括未跟踪文件	改完代码后做 review 时
`/review`	让 Codex 审查当前工作区改动	改完一轮后做自查时
`/plan`	先进入规划模式，再决定是否动手改代码	需求复杂、不想一上来就盲改时
`/permissions`	调整当前会话的批准/权限策略	想放宽或收紧自动执行权限时
`/mcp`	查看当前可用的 MCP 工具	想确认 Codex 还能调用哪些外部能力时
`/clear`	清空当前界面并开启新对话	当前上下文太乱、想重开时
`/compact`	压缩当前对话，节省上下文	长会话跑久了以后
`/init`	在当前目录生成 `AGENTS.md` 模板	想给仓库补长期说明时

我最建议你先记住的 4 个

/model
/status
/diff
/review

这 4 个命令基本覆盖了：切模型、看状态、看改动、做复查 四个高频动作。

`/model` 怎么用？

/model 是很实用的命令之一。

它的作用不是“让你背模型名字”，而是让你在不同任务阶段切换策略：

需要快速扫仓库、快速问答时，可以偏向更轻、更快的模型
需要复杂分析、规划、重构、定位隐蔽 Bug 时，可以切到更强的推理模型

也就是说，/model 更像是一个任务档位切换开关。

`/btw` 是什么？它是不是内建命令？

这里要特别说明一下：/btw 不是官方内建的 Codex CLI slash command。

我查了官方的 Codex CLI slash commands 文档，内建命令里有 /model、/status、/diff、/review、/permissions、/mcp、/clear、/compact 等，但没有把 /btw 列为官方内建命令。

那为什么你会看到有人提 /btw？

因为 Codex 支持把自定义提示词（custom prompts）做成可显式调用的快捷命令。也就是说：

/model 这类通常是官方内建命令
/btw 这类更可能是用户自己定义的快捷提示词名称

举个例子，如果你在本地 Codex 提示词目录里放一个 btw.md，就可以把它当成一个自定义快捷入口来用。

自定义快捷命令的典型思路

比如你可以自己约定：

/btw：帮我补齐背景说明、隐含约束、边界条件
/fix-test：先运行测试，再做最小修复
/shipit：检查 diff、运行测试、输出提交建议

这类命令的价值在于：

把高频提示词模板化
减少重复打字
让团队协作时更统一

一个很实用的理解方式

你可以把 Codex CLI 里的快捷入口分成两层：

第一层：官方内建 Slash Commands

负责控制会话本身，例如：

/model
/status
/diff
/review
/permissions
/compact

第二层：你自己定义的 Prompt 快捷命令

负责沉淀你的工作流，例如：

/btw
/fix-test
/read-repo
/write-readme

前者更像“控制台按钮”，后者更像“个人工作流宏命令”。

十一、Codex 快捷命令（Slash Commands）

除了 codex exec 这种命令行参数形式，Codex CLI 在交互式会话里还有一组非常实用的快捷命令，也就是输入 / 触发的 slash commands。

它们的价值在于：

不用退出当前会话
不用重新敲一长串命令
可以快速切换模型、查看 diff、清理上下文、附加文件
很适合高频开发操作

如果你已经在 codex 交互界面里，直接输入 /，通常就能看到可选命令列表。

常见快捷命令

1. `/help`

查看可用命令与帮助信息。

适合场景：
- 刚开始接触 Codex CLI
- 忘了某个命令怎么写
- 想快速浏览当前版本支持哪些交互能力

2. `/status`

查看当前会话状态。

通常适合用来确认：
- 当前模型
- 当前上下文状态
- 会话的一些运行信息

3. `/model`

切换当前使用的模型。

这个命令很适合在不同任务之间切换策略：
- 轻量任务用更快的模型
- 复杂分析或重构用推理更强的模型

4. `/diff`

查看当前工作区里的 Git diff，包括尚未跟踪的新文件。

这是非常实用的一个命令，因为你可以在 不离开 Codex 会话 的情况下快速检查它刚刚做了哪些修改。

5. `/review`

让 Codex 对当前工作树做一次审查。

适合：
- 你已经让它改完一轮代码
- 想让它再做一次自检
- 让它从 review 视角看看潜在问题、遗漏和风险

6. `/mention`

把文件或目录附加到当前对话里。

这在大型项目里很有用。比如你可以明确把某几个关键文件“点名”给它看，避免它在整个仓库里乱找。

7. `/clear`

清空终端显示并开始一段新的对话。

如果你觉得当前屏幕太乱、上下文已经跑偏，或者只是想重新开始，这个命令很顺手。

8. `/compact`

压缩当前可见对话，生成摘要来节省上下文。

如果你已经连续聊了很多轮、任务很长，这个命令能帮助 Codex 在保留关键结论的同时，减少上下文压力。

9. `/new`

在同一个 CLI 会话里开启一个新对话。

和直接退出再重进相比，它更适合你在同一仓库里快速切换到一个全新任务。

10. `/fork`

把当前对话分叉成一个新线程。

这很适合下面这种场景：
- 你正在做 A 方案
- 又想试试 B 方案
- 但不想把当前已有上下文弄乱

11. `/init`

在当前目录生成 AGENTS.md 脚手架。

如果你想给 Codex 提供长期有效的仓库级说明，比如：
- 代码风格
- 测试要求
- 提交流程
- 项目约束

那么这个命令就很有价值。

12. `/mcp`

列出当前可用的 MCP 工具。

如果你已经给 Codex 接入 MCP server，这个命令可以帮助你快速确认：
- 接了哪些工具
- 当前工具是否可见
- 后续能不能直接调用

13. `/approval`

调整审批模式。

根据官方说明，旧的 /approvals 仍然可以作为别名使用，但在快捷命令列表里主要以 /approval 为主。

这个命令适合在以下场景快速切换：
- 想更保守，所有动作都多确认
- 想提高效率，减少重复批准
- 在不同仓库之间切换不同风险等级

快捷命令的实际意义

如果你把 Codex CLI 当成“终端里的 AI 工程助手”，那这些 slash commands 就像它的工作台按钮。

它们不是可有可无的小功能，而是会明显影响使用流畅度的高频入口。尤其是下面几个，我非常建议重点记住：

/diff
/review
/model
/mention
/compact
/approval

一个很实用的组合用法

比如你在交互模式里完成一轮开发后，可以这样衔接：

先用 /diff 看改了什么
再用 /review 让它自检一轮
如有需要用 /model 切到更强模型继续分析
对关键文件用 /mention 精确补充上下文
会话太长时再用 /compact 压缩上下文

这套组合在真实项目里非常高频，也比单纯反复重启 Codex 更顺手。

十二、典型工作流一：先理解项目，再做改动

这是我最推荐的新手工作流。

第一步：进入项目目录

cd your-project

第二步：启动 Codex

codex

第三步：先让它理解项目

请先阅读这个项目，告诉我：
1. 技术栈
2. 核心目录结构
3. 启动方式
4. 测试方式
5. 你认为最关键的 3 个模块

第四步：再让它实施任务

现在请为这个项目新增一个用户资料接口，并保持现有风格一致

第五步：要求它验证

请运行相关测试、修复问题，并总结你改了哪些文件

这个流程的好处是：

不会一上来就盲改
能先建立项目认知
更适合真实仓库

十三、典型工作流二：让它修 Bug

假设你有一个项目测试失败。

可以这样做：

codex exec "运行测试，定位失败原因，修复后再次验证，并说明根因"

如果你想更稳一些，可以把要求写得更细：

codex exec "
1. 运行 pytest
2. 找出失败测试
3. 分析根因
4. 仅做最小必要修改
5. 再次运行测试
6. 输出改动说明
"

这种写法的优势是：

任务边界更清晰
减少不必要的大改
更适合生产代码仓

十四、典型工作流三：用于小功能开发

例如你要在 FastAPI 项目中增加一个健康检查接口：

codex exec "在当前 FastAPI 项目中新增 /health 接口，返回 {status: 'ok'}，并补一个最基本测试"

或者在前端项目中：

codex exec "为当前 React 项目增加暗色模式切换按钮，并尽量复用现有样式系统"

这里有个关键经验：

提示词不要只说“帮我写个功能”，而要把约束写清楚。

比如最好补上：

使用什么技术栈
尽量复用现有代码风格
是否要补测试
是否要保持向后兼容
是否只做最小改动

十五、怎么写更好的 Codex 提示词？

很多人用不好 Codex CLI，不是因为模型不行，而是因为提示太模糊。

一个不够好的例子

帮我优化一下代码

问题在于：
- 不知道优化什么
- 不知道边界在哪
- 不知道是重构、提速、减重复，还是补测试

一个更好的例子

请分析当前项目的用户认证模块，目标是：
1. 减少重复逻辑
2. 保持对外 API 不变
3. 不修改数据库结构
4. 补充缺失测试
5. 最终给出修改说明

这类提示更容易得到稳定输出。

十六、Codex CLI 很适合配合 Git 使用

Codex CLI 最适合在 git 仓库 中工作。

这是因为真实开发里你总要：

看 diff
新建分支
回滚修改
做提交
发 PR

为什么一定要养成这个习惯？

因为 AI 代理再强，也可能：

理解偏题
改动过大
引入副作用
误删注释或边界逻辑

Git 是你最后一道安全带。

十七、Codex CLI 配置文件与高级配置

根据官方资料，Codex 支持通过：

~/.codex/config.toml

进行高级配置。

这个配置文件可以用于：

MCP server 配置
工具审批策略
通知 hook
SQLite 状态目录
自定义证书
Plan mode 推理强度
部分实验特性

如果你是普通用户，刚开始不一定要手改配置；但如果你希望把 Codex 融入团队工具链，config.toml 很值得研究。

十八、MCP 支持：让 Codex 接入更多工具

Codex 可以连接 MCP（Model Context Protocol）服务器。

这意味着什么？

你可以把更多能力接给它，比如：

文档检索
内部知识库查询
专用代码分析工具
企业内部服务
自定义脚本接口

例如在 ~/.codex/config.toml 中可以配置一个 MCP server：

[mcp_servers.docs]
command = "docs-server"
supports_parallel_tool_calls = true

如果要控制审批，还可以做更细粒度配置：

[mcp_servers.docs]
command = "docs-server"
default_tools_approval_mode = "approve"

[mcp_servers.docs.tools.search]
approval_mode = "prompt"

这意味着什么？

你可以让某些工具默认放行，而某些高风险工具仍然要求人工确认。

这对团队环境尤其重要。

十九、通知能力与状态存储

Codex 还能在一个回合结束时触发通知 hook。

这对下面这些场景有用：

长任务完成提醒
远程 SSH 开发时通知你回来查看
批量执行后做自动记录

另外，Codex 也会用 SQLite 维护状态数据。官方文档提到，它的 SQLite 状态目录可通过配置项或环境变量控制。

如果你在多项目环境、容器环境或企业环境里使用，这部分配置也值得关注。

二十、企业环境注意事项：自定义 CA 证书

如果你所在的公司网络、代理网关或安全设备会拦截 HTTPS 流量，那么可能需要给 Codex 配置自定义 CA 证书。

官方支持通过以下环境变量设置：

CODEX_CA_CERTIFICATE
SSL_CERT_FILE

其中 CODEX_CA_CERTIFICATE 优先级更高。

这对以下环境特别重要：

企业内网代理
安全审计网关
需要自建证书链的环境

否则你可能会遇到登录或外部连接失败问题。

二十一、适合 Codex CLI 的任务清单

下面这些任务，通常很适合交给 Codex CLI：

1. 项目理解类

总结目录结构
说明技术栈
分析入口文件
找出关键模块

2. 编码类

增加接口
补管理脚本
增加配置项
写小型工具函数

3. 维护类

修 lint
修测试
升级依赖后处理兼容问题
批量替换旧 API

4. 文档类

生成 README
补安装说明
总结项目架构
输出变更说明

5. 重构类

抽公共函数
拆分大文件
整理重复逻辑
优化模块边界

二十二、不太适合一上来就交给 Codex 的任务

虽然 Codex CLI 很强，但不是所有任务都应该直接“全权交给它”。

慎用场景

高风险数据库迁移
涉及支付、权限、鉴权核心链路的大改
生产运维脚本直接自动执行
对外兼容要求极高的公共 SDK 改动
你自己都没搞清楚需求边界的复杂任务

这类任务更适合：

先让它分析方案
再人工 review
再逐步执行

而不是一步到位放权。

二十三、提高 Codex CLI 效率的实战建议

1. 永远先在分支里做

不要在主分支直接大改。

2. 提示词写清边界

尤其要写：
- 最小修改
- 不改数据库
- 保持 API 不变
- 先跑测试再改

3. 让它“先分析，后修改”

你可以明确要求：

先分析，不要急着改，先告诉我准备怎么做

4. 改完一定看 diff

这是最重要的工程习惯之一。

5. 让它自己验证

例如：

改完请运行测试，并把失败原因和修复结果一起汇报

6. 把大任务拆小

不要直接说：

把整个系统优化一下

而是拆成：

先分析瓶颈
先处理认证模块
再处理日志模块
最后补文档

这样稳定性高很多。

二十四、一个完整示例：从零开始让 Codex 改项目

假设你有一个 Python Web 项目。

第一步：进入目录

cd my-fastapi-project

第二步：创建新分支

git checkout -b feat/add-health-endpoint

第三步：启动 Codex

codex

第四步：给它清晰任务

请先阅读当前项目结构，然后完成以下任务：
1. 为 FastAPI 增加 /health 接口
2. 返回 JSON：{"status": "ok"}
3. 尽量复用现有路由组织方式
4. 如果项目已有测试框架，补一个最小测试
5. 改完后运行测试并总结变更

第五步：检查 diff

git diff

第六步：运行你自己的验证

pytest

第七步：提交代码

git add .
git commit -m "feat: add health endpoint"

这就是一个非常实用、非常稳妥的 AI 辅助开发闭环。

二十五、常见问题答疑

Q1：Codex CLI 适合新手吗？

适合，但前提是你至少会基本命令行和 git。

Q2：它能完全替代程序员吗？

不能。它更像高效率执行助手，而不是能独立承担所有技术判断的“全自动工程师”。

Q3：它最适合什么人？

经常在终端开发的人
有代码仓库管理习惯的人
希望加快实现、修复、重构速度的人

Q4：我应该优先用普通模式还是自动模式？

建议顺序是：
1. 普通交互模式
2. exec
3. --full-auto
4. --yolo

Q5：它会不会改乱我的代码？

会有这种风险，所以你一定要：
- 在分支里使用
- 先看 diff
- 跑测试
- 再提交

二十六、我对 Codex CLI 的使用建议

如果你准备真正把 Codex CLI 用起来，我建议你按下面这个节奏上手：

第 1 阶段：熟悉交互

目标：学会在当前项目里让它读代码、讲结构、找入口。

第 2 阶段：做小功能

目标：让它增加小接口、小工具、小测试。

第 3 阶段：修 Bug

目标：让它跑测试、定位报错、做最小修复。

第 4 阶段：做重构

目标：在分支中让它处理重复逻辑、拆文件、补文档。

第 5 阶段：接入 MCP / 团队工作流

目标：让它不仅会改代码，还能接入知识库、文档、团队工具。

这样上手，效率和稳定性都会高很多。

二十七、结语

Codex CLI 真正有价值的地方，不是“它能写几行代码”，而是：

它把 AI 从聊天窗口拉进了真实开发终端。

你可以把它理解成一个在本地工作目录里协助你的“命令行工程搭子”：

会看代码
会改代码
会跑命令
会配合 git 工作流
还能通过配置继续扩展能力

如果你平时就喜欢在终端里做开发，那么 Codex CLI 是非常值得认真掌握的一类工具。

它不会替代你做所有技术判断，但它可以非常明显地放大你的开发效率。

尤其是在：

新项目上手
小功能实现
Bug 修复
文档补全
测试完善
自动化改造

这些场景里，Codex CLI 的实用价值非常高。

参考资料

OpenAI Codex CLI 官方文档：https://developers.openai.com/codex/cli
Codex CLI 命令参考：https://developers.openai.com/codex/cli/reference
Codex CLI 功能页：https://developers.openai.com/codex/cli/features
OpenAI Codex GitHub 仓库：https://github.com/openai/codex

如果你后续还想看，我也可以继续写两篇姊妹篇：

《Codex CLI 提示词模板大全》
《Codex CLI、Claude Code、Hermes Agent 三者怎么选》

Codex CLI 详细使用教程：从安装、登录到实战自动改代码

一、Codex CLI 是什么？

二、Codex CLI 和网页版 / IDE 插件版有什么区别？

1. 网页版 Codex

2. IDE 里的 Codex

3. Codex CLI

三、安装 Codex CLI

方式 1：使用 npm 全局安装

方式 2：使用 Homebrew 安装（macOS 常见）

方式 3：从 GitHub Release 下载二进制包

四、如何登录 Codex CLI

1. 使用 ChatGPT 账号登录

2. 使用 OpenAI API Key

五、第一次启动后，它能做什么？

六、最常见的使用方式

七、交互式模式

交互式模式的优点

适用场景

八、一次性执行模式：codex exec

适合的例子

1. 让它快速读项目

2. 让它补文档

3. 让它修测试

4. 让它做小型功能

九、自动化模式：--full-auto

适合使用 --full-auto 的场景

不建议乱开的场景

十、激进模式：--yolo

它适合什么？

为什么不建议新手一上来就用？

一组很实用的 Codex 终端快捷命令

交互式会话里更好用的 Slash Commands

我最建议你先记住的 4 个

/model 怎么用？

/btw 是什么？它是不是内建命令？

自定义快捷命令的典型思路

一个很实用的理解方式

第一层：官方内建 Slash Commands

第二层：你自己定义的 Prompt 快捷命令

十一、Codex 快捷命令（Slash Commands）

常见快捷命令

1. /help

2. /status

3. /model

4. /diff

5. /review

6. /mention

7. /clear

8. /compact

9. /new

10. /fork

11. /init

12. /mcp

13. /approval

快捷命令的实际意义

一个很实用的组合用法

十二、典型工作流一：先理解项目，再做改动

第一步：进入项目目录

第二步：启动 Codex

第三步：先让它理解项目

第四步：再让它实施任务

第五步：要求它验证

十三、典型工作流二：让它修 Bug

十四、典型工作流三：用于小功能开发

十五、怎么写更好的 Codex 提示词？

一个不够好的例子

一个更好的例子

推荐提示结构

十六、Codex CLI 很适合配合 Git 使用

推荐做法

1. 开新分支再让 Codex 改

2. 改完先看 diff

3. 通过后再提交

为什么一定要养成这个习惯？

十七、Codex CLI 配置文件与高级配置

十八、MCP 支持：让 Codex 接入更多工具

这意味着什么？

十九、通知能力与状态存储

二十、企业环境注意事项：自定义 CA 证书

二十一、适合 Codex CLI 的任务清单

八、一次性执行模式：`codex exec`

九、自动化模式：`--full-auto`

适合使用 `--full-auto` 的场景

十、激进模式：`--yolo`

`/model` 怎么用？

`/btw` 是什么？它是不是内建命令？

1. `/help`

2. `/status`

3. `/model`

4. `/diff`

5. `/review`

6. `/mention`

7. `/clear`

8. `/compact`

9. `/new`

10. `/fork`

11. `/init`

12. `/mcp`

13. `/approval`