我把 Codex 提效命令重新捋了一遍，这篇够全了

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

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

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

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

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

本文写作时核对的本机版本是 codex-cli 0.142.0-alpha.6，时间是 2026 年 7 月 8 日。Codex 更新非常快，CLI、Codex App、IDE 扩展、Cloud/Web 入口的命令也可能不同。文章里的命令不要盲背，最终以你当前界面输入 / 后弹出的命令列表、codex --help 和官方文档为准。

先分清三种入口

很多混乱都来自一个误会：我们把所有“能控制 Codex 的东西”，都叫成了斜杠命令。

其实至少要分三类：

这三类东西不能混着写。

codex fork 是顶层命令，不等于你在会话里一定能敲 /fork。codex review 是终端命令，也不等于你的当前界面一定有 /review。反过来，/mention 在官方 CLI 文档里是 slash command，但如果你当前使用的是另一个入口，可能表现为 @ 文件引用、上下文面板、点选文件，而不是直接敲 /mention。

所以命令文章最容易犯的错，不是少写一个命令，而是不说明这个命令属于哪个入口。

常用命令速查表

先把这篇会讲到的常用命令放进一张速查表：

下面按真实工作流来讲：开工前看什么，过程中怎么控，改完以后怎么验收。

一、开工前，先看当前命令列表

如果你已经进入 Codex 会话，最稳的动作不是凭文章记忆敲命令，而是先输入 / 看当前界面弹出的命令列表。

不同入口可能不一样：

你在 App 里看到的，不一定能在 CLI 里敲；你在 CLI 顶层能运行的，也不一定是会话里的 /xxx。

所以文章、教程、X 上的截图都只能当参考，最终以当前入口的命令列表为准。

这不是一句客套话，而是使用 Codex 的第一条工程纪律。

二、开工前，先跑 codex doctor

如果会话里的 /status 是仪表盘，那终端里的 codex doctor 就是本机环境体检。

在终端里运行：

codex doctor

它适合检查本地安装、配置、登录、运行时、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 是沙盒模式，常见取值可以这样理解：

-a 是审批策略。比如：

-a on-request

意思是需要关键动作时，让 Codex 按需请求你确认。

如果你已经在会话里，也可以看当前入口是否支持：

/permissions

它适合在会话中调整 Codex 能做什么。

这不是不信任 AI，而是基本工程纪律。你可以把 Codex 理解成一个很能干的开发同事，但再能干，也不能一上来给生产库权限、系统目录权限和无确认执行权限。

五、用 /model 或 -m 控制火力

在会话里切模型，可以用：

/model

启动时指定模型，可以用：

codex -m 你的模型名

我当前 CLI 启动界面里明确显示 /model to change，所以这个属于可以放心写进文章的会话内命令。

模型选择的原则不用复杂：

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 看到的东西越多，不一定越聪明，有时反而更容易跑偏。

更好的方式是告诉它：

上下文不是越多越好，而是越准越好。

八、/plan 有就用，没有就用规划提示词

复杂任务不要一上来就让 Codex 改代码。

如果你的当前入口支持 /plan，可以用它先进入规划模式。但为了跨入口更稳，我建议你也记住普通提示词版：

先不要修改文件。

请先分析当前实现，并按下面结构给我方案：
1. 需要查看或修改哪些文件
2. 每个文件为什么要改
3. 可能影响哪些数据流和交互状态
4. 风险点是什么
5. 你建议的验证方式是什么

等我确认方案后再执行。

这比硬背某个命令更可靠。

因为真正重要的不是命令本身，而是让 Codex 从“马上开干”切换到“先想清楚”。

比如你想改一个 PromptBox 插件，直接说：

帮我把词库和收藏合并。

这句话太粗了。Codex 可能马上开始改 UI，但它不一定会先想清楚：

所以复杂任务一定要先规划。至于你用 /plan，还是用上面这段提示词，取决于当前入口支持什么。

九、用 /diff、git diff 和 codex review 做验收

改完代码以后，不要只看 Codex 的总结。

它说：

我已经完成了修改。

你就信了，这很危险。

在会话里可以看当前入口是否支持：

/diff

在终端里更通用的是：

git diff

你要重点检查：

第二步可以做审查。

如果当前会话支持 /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，有两个思路：

如果当前入口支持 /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 个动作：

你会发现，这里面既有 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