CX-03 Commands 完整指南：App 里的 slash commands 与工作流入口

本篇以 Codex App 的 slash commands 为主线。CLI slash commands 只作为核对和排查补充。

⠀

本篇于 2026-09-14 对照官方 Slash commands、Developer commands、Import 与 Prompting 文档复核，沿用本系列 Codex App 26.908 / CLI 0.154.0 的版本基线。官方桌面资料现归入 ChatGPT 桌面 App 文档；这里仍以 Codex 工作流为主线，CLI 只作辅助。命令会随环境和账号权限变化，以输入 / 后的实际列表为准。

课程信息

⠀

作者：老金
GitHub：https://github.com/KimYx0207
公众号：老金带你玩AI
X（Twitter）：老金带你玩AI
个人博客：https://aiking.dev
预计学时：2-3小时
难度等级：⭐⭐ 入门级
更新日期：2026年9月14日
信息来源：OpenAI Codex App Commands、CLI Slash Commands、Follow Goals 官方文档
前置要求：已完成 CX-01 安装和 CX-02 桌面工作流

📚 本课学习目标

⠀

完成本课学习后，你将能够：

⠀

本次复核重点：补齐当前命令分组，区分 /status、模型与权限入口；明确 /plan 的切换行为、Goal 的暂停与继续，以及 Skills 也会出现在 slash 列表。/init 生成项目指令；从其他工具导入设置要走 Settings → Import，详见 CX-14。

⠀

理解Commands的本质：掌握slash命令是App的快速工作流入口，不是高级玩具
学会发现命令：在App中输入/查看当前可用命令，不依赖死记硬背
掌握常用内置命令：熟练使用/status、/plan、/review、/mcp、/feedback
理解计划模式：知道什么时候该先规划再执行，用/plan进入
区分命令层级：分清App命令、CLI命令、版本相关命令、Skills各自的位置
理解命令边界：知道 App 内置命令、CLI 命令、实验能力和 Skill 入口各自怎么核对
理解命令的变化性：知道命令会随版本、插件、权限变化，以当前App显示为准
避免常见命令陷阱：不把CLI命令当App主线，不把版本相关命令写成确定功能

🗺️ 学习路径导航（先看这里！）

⠀

💡 根据你的情况选择学习路径：不用全看！

⠀

路径A：快速上手（⏱️ 15分钟）

⠀

适合人群：想快速知道App里有哪些命令可以用

⠀

只看这些章节：

⠀

✅ 第2部分：先学会在App里发现命令（3分钟）
✅ 第3部分：当前 App 命令分组（5分钟）
✅ 第4部分：/plan 先规划（7分钟）

路径B：完整学习（⏱️ 2-3小时）

⠀

适合人群：想系统掌握所有Commands用法

⠀

学习顺序：从头到尾所有章节

路径C：问题排查（⏱️ 5分钟）

⠀

适合人群：某个命令用不了或效果不对

⠀

直接跳到：

⠀

🔧 最后的常见问题FAQ部分

术语表（小白必读）

⠀

Commands 这一章要先分清“入口”和“能力”。很多人学 slash commands 会犯一个错误：以为命令越多，能力越强。实际上，命令只是把某类工作流快速切出来，真正的能力仍然来自 App 当前线程、权限、工具、项目上下文和你的任务描述。

⠀

术语

一句话解释

在 Codex App 里怎么理解

Slash command

在输入框用 / 调出的工作流入口

快速切换状态、计划、审查、工具面板

Composer

你输入任务的地方

/、$skill、自然语言都从这里进入

Plan mode

先规划、暂不执行的模式

大任务先降低风险

Goal mode

持续推进到完成、暂停或需要更多输入

适合长目标，但必须有停止条件

Review mode

让 Codex 审查当前 diff 或分支差异

不是人工 Review 的替代品

MCP status

查看外部工具 server 是否连接

工具可见不等于可以随便用

Skill invocation

用 $skill-name、slash 列表或自然语言触发 Skill

Skill 是可复用流程，列表入口不改变它的类型

CLI slash command

终端 TUI 里的 / 命令

可辅助理解，不等于 App 一定有同名命令

⠀

一句话：Command 是“入口”，Skill 是“方法”，MCP 是“工具”，Automation 是“时间触发”，Review 是“收口”。学清边界，比背完整命令表更重要。

⠀

0. Commands 的心智模型：入口、状态、动作

⠀

我讲 Commands 时不会把命令背诵当目标，真正要学的是什么时候该规划、什么时候该审查、什么时候该看状态。

⠀

Codex App 里的 slash commands 可以分成三层：

⠀

入口层：/status、/mcp、/feedback
  -> 帮你打开状态、工具、反馈等面板或信息

状态层：/plan、/goal
  -> 改变 Codex 接下来怎么推进任务

审查层：/review
  -> 围绕当前 Git diff 或分支差异做检查

⠀

这三层的使用顺序通常是：

⠀

先看状态：用 /status 或当前 App 界面确认线程、权限、上下文。
再定推进方式：任务复杂就 /plan，长期目标才 /goal。
执行后收口：用 /review 和 Review 面板检查结果。
工具问题单独查：外部工具不可见时用 /mcp，插件和连接器去对应入口。

⠀

不要把 command 当成魔法咒语。它只是让你更快进入一种工作模式。模式不对，命令反而会制造混乱。例如，模糊目标直接 /goal，会让 Codex 长时间围绕一个不清楚的目标打转；没有 diff 时 /review，只会得到“当前没有可审查内容”的结果。

⠀

0.1 用不用 Command 的判断树

⠀

你现在想做什么

首选方式

为什么

看当前线程状态

/status

快速确认上下文、限制和配额信息

让 Codex 先别动手

/plan

把执行前移到方案讨论

长时间推进一个清楚目标

/goal

让目标跨多个 turn 持续存在

检查当前改动

/review

直接进入代码审查口径

查 MCP 是否连接

/mcp

看工具 server 和状态

触发团队 SOP

$skill-name 或自然语言

Skill 比 command 更适合复用流程

定期重复检查

Automation

Command 是手动入口，不负责调度

当前 App 没这个命令

自然语言 + 官方文档核对

不要硬套 CLI 命令

⠀

0.2 命令变化为什么正常

⠀

命令列表会随这些因素变化：

⠀

App 版本。
账号或组织权限。
当前功能的开放状态与实验设置。
已安装插件和 Skills。
当前线程类型、项目状态和连接器。
CLI / App / IDE extension 的不同界面。

⠀

所以教程要教你"怎么发现和核对命令"，免去背表的负担。Claude Code 的 Commands 章节之所以厚，是因为它讲命令系统、作用域、开发方式、故障排查和 FAQ；Codex 这里也要用同样的思路：先理解命令背后的工作流。

⠀

1. Commands 在 App 里解决什么问题

⠀

Commands 不是"高级玩具"，而是 App 的快速入口：

⠀

你想做什么

直接说也可以

Command 更适合

查看当前状态

“当前任务的上下文和额度如何？”

/status；模型、推理与权限分别查看对应入口

进入计划模式

“先给计划别执行”

/plan

长目标持续推进

“一直做直到验证通过”

/goal；如果当前 App 没显示，按官方方式启用或改用分阶段提示

审查改动

“review 当前 diff”

/review

管理外部工具

“看看 MCP”

/mcp

反馈问题

“这个 App 行为不符合预期”

/feedback

⠀

学习方式：在 App 输入框输入 /，看当前版本展示什么。不要背死命令表，也不要把别人机器上出现的命令直接当成你这台机器一定有。

⠀

2. 先学会在 App 里发现命令

⠀

每次换版本、换账号、换项目或安装插件后，先做这四步：

⠀

打开 Codex App 的任意项目线程。
在输入框输入 /。
看弹出的命令列表、命令说明和是否有实验标记。
阅读候选项的说明；不确定时用自然语言询问用途，不执行文件修改。找不到某命令时先查当前官方列表，不靠另一个未显示的命令来排查。

⠀

判断一个命令能不能写进教程，按这个顺序：

⠀

来源

教程写法

当前官方 App 文档明确列出

按核查日期说明用途，并保留环境和账号限制

当前 App 弹窗显示但官方页未列出

写成“当前版本可能出现，以你的 App 为准”

只在 CLI 出现

放到 CX-12，不能写成 App 主线

只听别人说过

不写成确定命令

⠀

3. 当前 App 命令：按任务用途选择

⠀

以下按 2026-09-14 读取的官方命令表整理，适用于桌面 App 的 Codex 工作流；具体可用项仍受当前环境与账号权限影响。输入 / 后先看说明，再选命令。

⠀

你要做什么

命令

作用与边界

查看状态

/status

显示任务 ID、上下文用量和额度限制；模型与权限另看对应选择器

选择模型与推理

/model、/reasoning

选择当前任务的模型、推理强度，不保证每个账号都有相同选项

调整响应方式

/fast、/personality

Fast 服务档位或回复风格，需当前模型支持

先规划、再推进

/plan、/goal

Plan 切换计划模式；Goal 设置有范围与结束条件的持续目标

审查改动

/review

审查未提交改动，或与选定基础分支比较

初始化项目指令

/init

为当前项目生成 AGENTS.md 草稿，会产生文件修改，生成后要审阅

查看外部工具

/mcp

打开 MCP 状态查看连接的服务器，不会因此完成账号授权

管理记忆与 IDE 上下文

/memories、/ide-context

配置记忆使用或切换共享 IDE 上下文，需要对应能力可用

整理上下文

/compact

压缩当前任务上下文，重要结论仍应保存到项目文件

选择项目

/project

为新任务选择项目

创建无项目任务

/task

从不绑定项目的任务开始，不等于当前项目的另一个分支

分叉或临时旁问

/fork、/side

Fork 复制本地任务到新任务或 worktree；Side 是不打断主任务的临时旁问

选择本地工作位置

/local、/worktree

使用所选本地项目或新的 Git worktree，先核对路径与基础分支

使用云端环境

/cloud、/cloud-environment

选择云端执行与环境，需具备该能力；本机文件不会因此自动变成云端可用

管理桌面宠物

/pet

唤醒或收起桌面宠物

重试一次自动审查拒绝

/approve

自动审批审查启用时允许对最近的拒绝重试一次，不是全局关闭权限保护

提交产品反馈

/feedback

打开反馈框，可选择附带日志；检查内容后再提交

⠀

Skills 仍可用 $技能名显式选择，也会出现在 slash 列表中。兼容的自定义提示显示为 /prompts:<name>。这几类条目可能出现在同一个列表，但 Skill、提示模板与产品内置命令的来源和作用不同。若列表没有 /help，直接使用 / 的筛选和说明，不把它当成必有命令。

⠀

下面代码框表示 App 输入框里的操作与需求，不是要粘贴进终端的 Shell 命令。选择某个 command 后，再根据界面补充需求；/status、/mcp 等会直接打开状态信息。

⠀

3.1 三个 App 命令工作流配方

⠀

配方一：大任务先计划

⠀

/plan

目标：把登录逻辑从旧 auth helper 迁到新 auth client。
范围：先只读 src/auth、tests/auth 和相关 README。
约束：先不要修改文件，不要安装依赖。
交付：列出方案、风险、要改的文件和验证命令。

⠀

你应该看到计划和待澄清问题，项目文件没有新增修改。/plan 是切换开关；已经显示 Plan 标识时，直接补充需求，不要每轮重新输入一次把它关掉。

⠀

配方二：改完立刻审查

⠀

输入 /review，按界面选择未提交改动或基础分支，再补充：

⠀

重点检查：是否改了范围外文件、是否缺少相关测试、是否引入权限或网络行为变化。
先给审查结果，不直接修改文件。

⠀

你应该看到能对应文件或 diff 的发现。没有发现问题不代表已经运行了测试，测试结果要另外看命令记录。

⠀

配方三：把状态、模型和权限分别看清楚

⠀

/status

⠀

先看任务 ID、上下文和额度，再用 /model、/reasoning 或输入框选择器核对模型与推理强度。权限看当前任务的权限状态和设置；不要求 /status 一张卡片展示所有信息。

⠀

3.2 跟练：从新项目指令到一次审查

⠀

在单独的练习项目中输入 /init，先确认它将生成或调整的 AGENTS.md。已有项目指令要保留原规则，不直接覆盖。
在 Review 面板查看生成的说明，核对安装和测试命令是否来自项目文件，而不是模型猜测。
用 /plan 提出一个仅修改 README 的小任务，确认方案后执行。
用 /review 检查未提交改动，再运行计划里与这次修改相关的检查。
结束时用 /status 看上下文与额度变化，并记录修改文件与实际检查结果。

⠀

这个练习不需要连接外部账号或发布代码。先跑通本地的“生成指令—规划—修改—审查”，再去 CX-05、CX-09、CX-11 学外部工具、定时任务和云端环境。

⠀

4. /plan：先规划，不急着写

⠀

适合：

⠀

多文件改动。
架构调整。
不确定影响面的 bug。
需要先比较方案。

⠀

示例：

⠀

/plan

修复登录页移动端布局问题。先读相关文件，列出可能方案、风险和验证命令，不要改文件。

⠀

好的计划应该包括：

⠀

要读哪些文件。
要改哪些文件。
可能方案和取舍。
验证命令。
不做什么。
什么时候退出计划模式进入执行。

⠀

当前文档使用 /plan。确认输入框显示 Plan 状态后再发送规划需求；需要执行时按界面退出计划模式，不把仅有一句“按计划做”当成模式一定已经切换的证据。

⠀

5. /goal：长目标入口

⠀

/goal 设置持续目标，适合有明确完成条件、一次普通提示不易做完的任务。目标还模糊时先用 /plan，确定范围后再设置 Goal。

⠀

/goal 修复 docs/codex 中的内部链接。只改该目录的 Markdown 链接；所有断链都已修复或记录具体原因时结束。不提交、不推送，不连接外部账号。

⠀

运行时，输入框上方会显示目标进度。使用进度栏按钮暂停、继续、编辑目标或清除目标；过程中也可以用普通消息调整优先级与范围。CLI 中的 /goal pause、/goal resume 等子命令，不要直接当成桌面 App 的操作方式。

⠀

目标应写清对象、允许修改的范围、完成条件与需要停下说明的问题。它不会自动获得新权限，也不是按某个日期定时醒来的调度器。

⠀

若当前环境没有 /goal，先核对版本和可用功能，或用普通提示分阶段继续。当前 App 文档没有要求所有读者先修改 features.goals；不要把旧版本启用步骤当成通用前提。需要每天或每周回来检查时，使用 CX-09 的定时任务。

⠀

6. /review：把审查放进 App 工作流

⠀

/review 用来审查当前工作区改动。App 用户可以把它放在每次合并前：

⠀

/review

⠀

你也可以自然语言补充审查重点：

⠀

/review 重点看：是否改了范围外文件、是否缺测试、是否引入安全问题。

⠀

注意：

⠀

/review 不替代人工确认。
高风险改动仍要读 diff。
安全专项可以另用安全审查提示或专门 skill。

⠀

6.1 /review 不是一句“帮我看看”

⠀

好的 /review 要带检查维度：

⠀

维度

适合提示

范围

是否只改了任务指定文件

正确性

是否有边界条件、空值、异步竞态

安全

是否触碰 secret、权限、网络、外部服务

测试

是否覆盖新增行为，是否只跑了无关测试

可维护

是否引入重复逻辑、过度抽象或隐式依赖

⠀

示例：

⠀

/review 重点检查 auth migration 的边界条件、token 处理、测试覆盖，以及是否误改了非 auth 模块。

⠀

7. 权限命令与安全边界

⠀

权限入口的名称可能随 App 版本变化。你应该通过 / 列表或 Settings 找到当前会话的权限设置，用来理解或调整 Codex 能自动做什么。

⠀

学习阶段建议：

⠀

不要开无限制自动执行。
让 Codex 在写文件和运行危险命令前解释。
对陌生项目使用更保守权限。

⠀

当任务涉及删除、移动、大量写入、联网或外部服务时，先看权限。若当前 App 没有 /permissions，就去 Settings 或当前线程权限提示里看，不要假设命令一定存在。

⠀

8. /mcp、Apps、Plugins

⠀

这三个命令常被混淆：

⠀

命令

管什么

例子

/mcp

外部工具 server 暴露的工具

浏览器、数据库、内部 API

Apps / Connectors 入口

连接器 / 外部服务上下文

GitHub、Drive、Gmail、Slack

Plugins 入口

能力包

携带 skills、MCP、apps、配置

⠀

使用顺序：

⠀

先确认要解决的问题。
看 App 是否已有连接器或插件。
用 /mcp、Apps 入口或 Plugins 入口确认工具是否可见。
再让 Codex 使用它。

⠀

9. CLI slash commands：只作为补充

⠀

在终端里运行 codex 也有 slash commands。CLI 表只能帮助你理解概念，不能反推 App 一定支持同名命令。在 CLI 交互输入框里输入 / 查看支持项；Shell 中的 codex --help 用来查看子命令与参数。

⠀

类型

例子

App 用户怎么用

状态 / 配置

/status、/model、/permissions

理解概念，App 里按 Settings 和 / 列表找对应入口

工作流

/review、计划模式、目标模式

App 优先用 Review 面板和当前命令

工具

/mcp、Apps、Plugins

App 优先看工具/连接器入口

会话管理

/compact、/resume、/new 等

CLI 辅助或当前 App 可见时使用，不写成 App 必备

⠀

如果你需要完整 CLI 命令表，去 CX-12 或直接运行 codex 后在交互输入框输入 /。本篇只保留 App 主线。

⠀

10. Commands、Skills、Automations 的边界

⠀

类型

适合什么

例子

Command

当前会话里的快速动作

/review、/plan、/mcp

Skill

可复用流程或领域规范

代码审查 SOP、发布检查

Automation

定时或后台重复任务

每天检查测试、每周依赖摘要

⠀

不要把所有东西都做成 command。长期流程优先做成 Skill；周期任务用 Automation。

⠀

10.1 App Commands 与 CLI Commands 的差异模型

⠀

App 和 CLI 都有 slash commands，但它们服务的界面不同。

⠀

维度

App commands

CLI commands

主要对象

桌面线程、Review 面板、App 工具入口

终端 TUI、命令行权限、模型、会话

发现方式

App 输入框输入 /

CLI TUI 输入 /；Shell 中运行 codex --help

适合读者

桌面 App 用户

终端用户、CI / 远程环境用户

教程写法

以 App 当前显示和官方 App Commands 为准

放到 CX-12，按本机 --help 核对

风险

把 CLI 命令误写成 App 主线

把 App 面板能力误以为 CLI 自动具备

⠀

如果你正在写课程、团队文档或 onboarding 文档，建议这样表述：

⠀

在 Codex App 中，先输入 `/` 查看当前可用 commands。
如果你在 CLI TUI 中工作，在交互输入框输入 `/` 查看当前可用 commands。
两者不保证完全一致；以当前界面显示为准。

⠀

这句话能避免很多学习者卡在“教程写了，但我的界面没有”的挫败感。

⠀

10.2 命令排障表

⠀

症状

可能原因

排查顺序

输入 /goal 没出现

版本、环境或开放状态不同

先查当前列表和官方说明；无法使用时按明确阶段继续，不盲目修改旧实验开关

/review 没有发现问题

当前没有 Git diff，或 Review 范围不对

先看 Review 面板文件列表，再确认是否有 uncommitted changes

/mcp 看不到工具

MCP 未配置、App 未刷新、server 启动失败、项目未信任

先看 App Settings，再用 CLI codex mcp list 辅助

/plan 后仍想执行

任务描述里让它直接改了，或你后续批准执行

明确写“先只读计划，不修改文件”

命令列表和教程不同

版本、插件、界面、实验开关不同

以当前 App 列表和官方文档为准

CLI 有命令 App 没有

两个界面能力不同

不要强行照搬，用自然语言或 App 对应入口

⠀

排障的原则是：先看当前界面，再查官方文档，再用 CLI 辅助。不要把别人截图里的命令当作你的机器一定应该出现。

⠀

10.3 团队应该怎么教 Commands

⠀

团队培训时，不要从“命令大全”开始，而是用四个场景带着学：

⠀

状态场景：每个人输入 /status，说明当前线程、上下文和限制。
计划场景：给一个两文件改动，让大家用 /plan 只出方案。
审查场景：制造一个小 diff，用 /review 做定向检查。
工具场景：连接一个只读 MCP，用 /mcp 看工具是否可见。

⠀

这样学完，团队真正掌握的是“什么时候切换工作模式”，而不是机械背命令名。

⠀

11. 课堂工坊：三种命令场景连起来练

⠀

案例一：用 /plan 把模糊任务变成可执行计划

⠀

目标：让 Codex 先读证据、出计划，不直接改文件。

⠀

/plan

目标：修复登录页移动端按钮文字溢出。
范围：先只读 src/pages/login.tsx、src/styles/login.css、相关测试文件。
约束：不要修改文件，不要安装依赖。
交付：列出可能方案、影响文件、验证命令和不做事项。

⠀

你应该看到：计划里有要读的文件、要改的文件、验证命令和风险；当前 Review 面板没有新增改动。

⠀

案例二：用 /goal 做有边界的长任务

⠀

目标：学习长目标不是"无限优化"，而是带停止条件的持续任务。

⠀

/goal Fix the docs link drift in docs/codex only. Scope: markdown links inside docs/codex. Stop when every broken local link is either fixed or listed with a reason. Do not commit or push.

⠀

如果当前 App 看不到 /goal，核对当前环境支持情况，或改用普通提示分阶段执行。你应该看到：目标进度出现在 composer 附近；Codex 在完成、暂停或遇到阻塞时能说明状态。

⠀

案例三：用 /review 做定向审查

⠀

目标：让审查指向真实 diff，而不是泛泛评价。

⠀

/review 重点检查：是否改了范围外文件、是否引入错误命令、是否缺少验证步骤、是否触碰密钥或权限配置。

⠀

你应该看到：Review 结果能引用具体文件或 diff 片段；如果没有改动，Codex 会说明当前没有可审查 diff。

⠀

常见问题

⠀

Q1：App 和 CLI 的命令完全一样吗？

⠀

不保证。以当前 App 的 / 列表、命令说明和官方 App Commands 文档为准。CLI 表只能辅助理解。

⠀

Q2：/goal 会不会无限跑？

⠀

目标会持续推进到完成、暂停或需要更多输入。写清范围和完成条件，必要时用输入框上方的目标进度栏暂停或清除；不要用它代替定时任务。

⠀

Q3：我应该背完整命令表吗？

⠀

不用。掌握“输入 / 看当前命令”、/status、/plan、/review、/mcp、/goal，再理解 Apps / Plugins / 权限入口，就足够开始。周期任务去 CX-09 Automations。

⠀

Q4：为什么 Claude Code 的 Commands 能自定义很多文件，Codex 这里没有照搬？

⠀

因为两个工具的命令系统不一样。Claude Code 有自己的命令文件体系；Codex App 的 App commands 是产品内置工作流入口，Codex 的可复用流程主要用 Skills、Plugins、Automations、MCP 和项目指令来组织。不要把 Claude Code 的命令开发方式硬套到 Codex App。

⠀

Q5：我能不能把常用提示做成一个 command？

⠀

在 Codex 里，重复提示优先做成 Skill。Command 负责进入当前界面的工作模式，Skill 负责固化可复用工作流。如果这个流程还要定时跑，再让 Automation 调用 Skill。

⠀

Q6：命令能绕过权限吗？

⠀

不能这样理解。Command 只是入口，真正执行文件写入、命令、MCP 或外部服务动作时，仍受当前 Settings、sandbox、approval、rules、hooks、connector 权限影响。

12. Commands 的分类学习法

⠀

新手不要把 Commands 当成一张需要背诵的命令表。更好的学习法是按“改变什么”来分类。

⠀

类别

改变什么

代表场景

计划类

改变任务推进方式

/plan、长任务拆解

目标类

改变持续执行状态

/goal

审查类

改变当前姿态

/review

能力类

查看或选择外部能力

/mcp、App Plugins 页面、CLI TUI /plugins、Skills mention

权限类

改变能做什么

permissions 相关入口

会话类

改变上下文和线程

resume、status、agent 相关入口

⠀

Commands 的本质是“告诉 Codex 现在进入哪种工作模式”。它不是魔法，也不会绕过项目规则、审批或沙盒。

⠀

12.1 什么时候不用 command

⠀

很多任务普通自然语言就够：

⠀

请只读解释当前项目结构。

⠀

不需要强行写成：

⠀

/plan 请只读解释当前项目结构

⠀

如果任务很小、风险很低、边界清楚，普通 prompt 更自然。

⠀

12.2 什么时候应该用 command

⠀

情况

13. /plan 深入：让 Codex 先站住脚

⠀

/plan 最适合模糊、较大、会改多个文件的任务。它的价值是把执行前的思考显性化。

⠀

13.1 差的 /plan

⠀

/plan 做一个完整优化。

⠀

问题是没有对象和边界。

⠀

13.2 好的 /plan

⠀

/plan
我想把 README 的安装部分改得更适合 Windows 新手。
请先只读分析 README、package.json 和 docs/setup.md。
计划里请说明：
1. 哪些内容可能过期
2. 建议改哪些文件
3. 哪些内容不要碰
4. 是否需要先运行命令
不要直接修改文件。

⠀

13.3 plan 后的确认话术

⠀

按方案 A 执行。
只改 README 和 docs/setup.md。
不要改 package.json。
完成后告诉我 Review 面板里应该检查哪些 diff。

⠀

不要只说“可以”。要把你接受的方案和边界再说一遍。

⠀

14. /goal 深入：长任务也要有边界

⠀

/goal 适合目标持续、步骤较多、需要 Codex 长时间推进的任务。但长任务更需要边界。

⠀

14.1 适合 /goal 的任务

⠀

/goal
把 docs/codex 目录的课程文档补厚到可以作为完整自学课程。
边界：
- 只改 docs/codex
- 不加入空白素材提示
- 不写课程外的内部评审文字
- 不虚构 Codex 功能
每完成一批请做禁词和 diff 检查。

⠀

14.2 不适合 /goal 的任务

⠀

/goal
帮我把公司所有项目都弄好。

⠀

这个目标没有范围，没有结束条件，也没有权限边界。

⠀

14.3 长任务的中途控制

⠀

先暂停扩大范围。
请汇报：
1. 已经改了哪些文件
2. 当前统计变化
3. 还差哪些部分
4. 下一批准备改什么

⠀

长任务不是交出去就不管。你可以随时收窄、改变优先级或要求复盘。

⠀

15. /review 深入：把 Codex 切到审查姿态

⠀

/review 的价值是让 Codex 按 review 方式看改动，而不是继续实现。

⠀

15.1 宽泛 review

⠀

/review
请审查当前 diff。

⠀

适合快速扫一眼，但可能输出泛。

⠀

15.2 定向 review

⠀

/review
请只看以下风险：
1. 行为回归
2. 安全或权限问题
3. 缺失测试
4. 破坏兼容性的改动

不要评论纯格式问题，除非它会造成真实维护风险。

⠀

15.3 Review 后不急着全修

⠀

请把 `/review` findings 分成：
- 需要马上处理
- 可以稍后处理
- 需要我判断

先不要改文件。

⠀

这一步能避免 Codex 把 review 中的每个点都当成同等重要的修复任务。

⠀

16. /mcp 与 Plugins：能力发现入口

⠀

/mcp 是 App slash command；Plugins 在 App 里主要通过 Plugins 页面和插件深链进入，CLI 里才是运行 codex 后输入 /plugins。两者都是能力发现入口，但看的是不同层。

⠀

入口

看什么

/mcp

当前 MCP server 是否可用、工具是否暴露

App Plugins / CLI /plugins

已安装和可发现的插件、marketplace 来源

⠀

16.1 MCP 排查 prompt

⠀

我在 App 里想使用文档查询 MCP，但 Codex 没有调用它。
请先帮我判断：
1. MCP server 是否在当前配置中可见
2. 当前任务是否真的需要 MCP
3. prompt 是否没有明确要求查外部文档
4. 是否应该改用普通 Web search 或本地文件

⠀

16.2 Plugins 排查 prompt

⠀

我安装了一个插件，但当前线程里没有按预期使用。
请帮我判断：
1. 插件是否已安装并启用，当前能力列表是否已刷新
2. 是否需要外部账号授权
3. 是否应该用 @ 显式调用
4. 是否应该用普通 Skill 或 MCP 而不是插件

⠀

17. Commands 与 Skills 的组合

⠀

Command 负责“切换入口”，Skill 负责“执行工作法”。下面的 $docs-drift、$writing-humanizer-zh 等是自建 Skill 名称示例，先确认项目中已经安装并能选到它们；没有对应 Skill 时，用普通提示说明同一项工作，不把示例名称当成内置功能。

⠀

17.1 组合示例：先 plan，再 skill

⠀

/plan
我想用 $docs-drift 检查文档是否过期。
请先分析这个项目是否适合运行该 skill。
不要修改文件。

⠀

确认后：

⠀

$docs-drift
只读检查 README 和 docs/。
输出可能过期的段落、证据和建议更新位置。

⠀

17.2 组合示例：先 review，再 skill

⠀

/review
请审查当前文档改动是否引入事实不一致。

⠀

再用：

⠀

$writing-humanizer-zh
请只润色刚才改动中的课程表达。
不要改变事实和命令。

⠀

18. Commands 与 Automations 的组合

⠀

Automations 里也可以用 Skill，但不应该依赖需要人工交互的 command。你要把“定期醒来要做什么”写清楚。

⠀

$pr-review
每天上午 10 点检查当前项目关联 PR 的新评论。
只读读取评论。
把需要我处理的事项放进 定时任务运行记录（Scheduled）。
不要回复评论，不要推送代码。

⠀

如果任务需要 /review，更好的做法是让自动化生成报告，然后人打开线程手动运行 review。

⠀

19. Commands 排障：命令不存在不等于功能不存在

⠀

Codex 的不同界面和版本中，commands 的入口可能不同。不要把某个命令不存在直接理解为功能不存在。

⠀

症状

判断方式

App 里找不到某命令

看当前 App 命令列表或 command palette

CLI TUI 命令不同

在 CLI 里看帮助或 slash 列表

插件入口没出现

打开 App Plugins 页面；CLI 里进入 codex TUI 后再输入 /plugins

Skill 没被触发

检查 $skill mention 和 description

MCP 工具没出现

用 /mcp 或配置检查

⠀

19.1 通用排查 prompt

⠀

我想使用一个 Codex command，但当前界面里找不到。
请不要猜命令一定存在。
请帮我：
1. 判断这个能力在 App、CLI、Skill、Plugin、MCP 中哪个层面
2. 给出当前界面可用的替代入口
3. 避免使用不存在的命令名称

⠀

20. 团队 Commands 教学脚本

⠀

团队培训时，可以按 4 个 15 分钟模块讲。

⠀

20.1 第一段：不用 command

⠀

练普通 prompt：

⠀

请只读总结当前项目。

⠀

目标：先学会写清任务。

⠀

20.2 第二段：用 /plan

⠀

/plan
请帮我规划如何更新 README 的快速开始部分。
只读分析，不改文件。

⠀

目标：学会执行前拆解。

⠀

20.3 第三段：用 /review

⠀

/review
请审查 README 改动是否和 package.json 一致。

⠀

目标：学会切换到审查姿态。

⠀

20.4 第四段：用能力入口

⠀

/mcp

⠀

App 里打开 Plugins 页面；如果在 CLI 里练习，则先运行：

⠀

codex
/plugins

⠀

目标：知道外部能力在哪里看，不把所有事情都归到 slash command。

⠀

21. Commands 综合工坊：一个任务从 /plan 到 /review

⠀

本工坊用一个文档修复任务串起常用 command。

⠀

21.1 任务背景

⠀

README 里的安装命令和 package.json 不一致。你要先规划，再执行，再 review。

⠀

21.2 第一步：/plan

⠀

/plan
README 的安装命令可能和 package.json 不一致。
请先只读分析 README、package.json 和 docs/setup.md。
输出：
1. 可能不一致的地方
2. 建议修改文件
3. 不应该修改的文件
4. 建议执行顺序
不要改文件。

⠀

21.3 第二步：执行计划

⠀

执行计划中的最小方案。
只改 README。
不要改 docs/setup.md、package.json 或 lockfile。

⠀

21.4 第三步：/review

⠀

/review
请审查刚才的 README 改动是否：
1. 和 package.json 一致
2. 没有扩大范围
3. 没有改变其它说明
4. 没有引入过期命令

⠀

21.5 第四步：修 review findings

⠀

请只处理 review 结果里和 README 命令一致性有关的问题。
其它建议先列出，不要修改。

⠀

这个工坊让学习者理解：Commands 不是孤立用，而是组成任务节奏。

⠀

22. Command prompt 语法库

⠀

22.1 只读规划

⠀

/plan
请先只读分析这个任务。
计划里列出：
- 目标
- 可改文件
- 不改文件
- 需要运行的命令
- 风险
不要修改文件。

⠀

22.2 小范围执行

⠀

按刚才计划执行。
只改以下文件：
- docs/setup.md
- README.md

如果你认为需要改其它文件，先停下来说明原因。

⠀

22.3 长任务目标

⠀

/goal
目标：把 docs/codex 中某一篇课程补成完整自学章节。
边界：
- 只改目标文件
- 不虚构功能
- 不加入课程外内容
- 每批修改后汇报新增章节和检查结果

⠀

22.4 定向 review

⠀

/review
只看：
- 行为是否偏离目标
- 命令是否正确
- 是否有不必要改动
- 是否缺少必要解释

不要评价纯文风。

⠀

22.5 能力发现

⠀

请帮我判断这个任务应该使用 command、Skill、MCP、Plugin、Automation 还是普通 prompt。
先给理由，不要执行。

⠀

23. Commands 与团队规范

⠀

团队里使用 commands，不能只靠个人习惯。建议统一三类模板。

⠀

23.1 规划模板

⠀

/plan
Task:

Scope:

Do not:

Evidence to read:

Expected output:

⠀

23.2 审查模板

⠀

/review
Review lens:
- correctness
- security
- tests
- scope control

Ignore:
- style-only comments
- unrelated refactor ideas

⠀

23.3 长目标模板

⠀

/goal
Outcome:

Allowed files:

Not allowed:

Batch size:

Progress report:

⠀

把这些模板放进团队文档，而不是让每个人临场发挥。

⠀

24. Commands 版本意识

⠀

Codex App、CLI、IDE Extension 的命令入口会随版本变化。课程写法要避免“把当前界面当永恒事实”。

⠀

24.1 课程里应该怎么说

⠀

- 在当前界面查看可用 commands。
- App 和 CLI 的入口可能不同。
- CLI 用 `--help` 和 TUI 内列表确认。
- 插件用 App Plugins 页面；CLI 里用 `codex` TUI 内的 `/plugins`。
- MCP 用 App settings、CLI `codex mcp` 或 TUI `/mcp`。

⠀

24.2 学生遇到命令差异时

⠀

我在当前 Codex 界面找不到教程里的命令入口。
请帮我按能力寻找替代路径：
1. 这个命令想完成什么事
2. 当前 App 有没有对应按钮或 command palette
3. CLI 有没有对应子命令
4. 是否应该用 Skill、Plugin 或普通 prompt

⠀

25. Commands 进阶常见问题

⠀

Q1：Commands 是不是越多越高级？

⠀

不是。高手往往先用普通 prompt 把任务说清楚，只有在需要切换模式、调用能力或管理状态时才用 command。

⠀

Q2：/plan 之后一定要照计划执行吗？

⠀

不用。计划是为了暴露路线。你可以选择其中一部分执行，也可以要求 Codex 改计划。

⠀

Q3：/goal 适合所有长任务吗？

⠀

适合目标明确、边界清楚的长任务。不适合“帮我把一切弄好”这类开放目标。

⠀

Q4：/review 发现的问题都要修吗？

⠀

不一定。Review 是发现风险，不是自动排期。先分级，再决定处理哪些。

⠀

Q5：找不到命令是不是课程错了？

⠀

不一定。可能是界面不同、版本不同、功能入口变了，或者这个能力在当前客户端不可用。按能力寻找替代路径。

⠀

26. 命令选择案例库：同一句需求，入口不同结果不同

⠀

26.1 需求：帮我改 README

⠀

普通 prompt：

⠀

请只改 README 的安装命令，使它和 package.json 一致。

⠀

适合：范围小、风险低、目标明确。

⠀

/plan：

⠀

/plan
README 的安装部分可能过期。
请先只读分析 README、package.json、docs/setup.md。
不要修改文件。

⠀

适合：不确定改哪里。

⠀

/review：

⠀

/review
请审查 README 改动是否和 package.json 一致。

⠀

适合：已经有 diff，需要检查。

⠀

26.2 需求：处理 PR 评论

⠀

普通 prompt：

⠀

请读取当前 PR 评论并分类。
不要修改文件。

⠀

/review：

⠀

/review
请审查当前 diff 是否已经处理 PR 评论中的 bug 和测试问题。

⠀

Skill：

⠀

$pr-risk-review
请按团队 PR review 流程审查当前分支。

⠀

Automation：

⠀

每天 17:00 只读检查当前 PR 新评论，输出到 定时任务运行记录（Scheduled）。
不要回复评论。

⠀

同一个需求从“临时处理”到“周期跟进”，入口会变化。

⠀

26.3 需求：查官方文档

⠀

普通 prompt：

⠀

请根据你知道的信息解释 Codex MCP。

⠀

风险：可能过期。

⠀

MCP：

⠀

请使用官方文档 MCP 核对 Codex MCP 配置字段。
输出来源和需要改写的地方。

⠀

适合：事实可能变化，需要来源。

⠀

26.4 需求：长期补课程

⠀

/goal：

⠀

/goal
把 docs/codex 的课程按 App-first 主线补厚。
边界：
- 只改 docs/codex
- 不虚构功能
- 保持课程内容面向学习者
- 每批修改后运行扫描

⠀

适合：多文件、长时间、需要阶段复盘。

⠀

27. Command 错误恢复

⠀

27.1 /plan 计划太大

⠀

这个计划太大。
请收缩成第一批最小可执行任务：
- 最多 2 个文件
- 不改配置
- 不涉及外部系统

⠀

27.2 /goal 跑偏

⠀

先暂停继续执行。
请只汇报：
1. 当前目标
2. 已经改了什么
3. 哪些动作可能偏离目标
4. 如何回到原边界

⠀

27.3 /review 输出太散

⠀

请重写 review 输出。
只保留：
- confirmed bug
- security risk
- missing test
- scope creep
其它建议放到低优先级。

⠀

27.4 能力入口找不到

⠀

请不要继续假设某个 command 存在。
请按能力目标寻找入口：
- App UI
- CLI subcommand
- slash command
- Skill
- Plugin
- MCP
- ordinary prompt

⠀

28. Commands 教学作业

⠀

作业一：改写模糊任务

⠀

原句：

⠀

帮我优化项目。

⠀

要求：分别改写成普通 prompt、/plan prompt、/review prompt。

⠀

作业二：判断入口

⠀

给出 10 个任务，让学生选择入口：

⠀

1. 看当前 MCP 是否可用。
2. 审查当前 diff。
3. 长期补完整课程。
4. 每周检查 docs 漂移。
5. 把 PR 评论分类。
6. 生成发布说明。
7. 打开插件目录。
8. 修一个明确 bug。
9. 设计项目 AGENTS.md。
10. 查官方最新配置字段。

⠀

参考方向：

⠀

1 `/mcp`
2 `/review`
3 `/goal`
4 Automation + Skill
5普通 prompt 或 GitHub connector
6 Skill
7 App Plugins 或 CLI TUI `/plugins`
8普通 prompt 或 `/plan`
9 `/plan`
10 MCP 或 Web search

⠀

作业三：写团队 command 模板

⠀

# Team Command Templates

## Planning

...

## Review

...

## Long Goal

...

## Capability Discovery

...

⠀

这个作业让团队把个人经验整理成共享语言。

⠀

29. Commands 长案例：同一个需求，入口选错会怎样

⠀

需求：

⠀

帮我把结账页的错误处理做得更好。

⠀

这是一个典型的入口选择题。如果直接普通 prompt：

⠀

帮我优化 checkout 错误处理。

⠀

风险是 Codex 可能立刻改代码，而且“优化”范围很大。更稳的第一步是 /plan：

⠀

/plan
我想改善 checkout 页的错误处理。

请先只读分析：
1. checkout 页当前有哪些错误路径。
2. 哪些错误用户可见。
3. 哪些测试覆盖了错误路径。
4. 哪个最适合做成一个小 PR。

不要修改文件。

⠀

如果已经有 diff，入口就换成 /review：

⠀

/review
请审查当前 checkout 错误处理改动。

重点看：
1. 是否覆盖网络失败、库存不足、支付失败。
2. 是否有未测试路径。
3. 是否引入无关 UI 改动。
4. 是否需要拆 PR。

⠀

如果这是一个范围明确、需要连续处理的目标，可以用 /goal：

⠀

/goal
修复 checkout 已确认的三个错误路径，完成对应检查后结束。

目标：
1. 先建立错误路径清单。
2. 每次只处理一个高价值错误。
3. 每个改动都要有测试或手测路径。
4. 三条路径的相关检查通过，或出现需要我决定的阻塞时停止并说明。

⠀

如果你怀疑需要外部工具或插件：

⠀

/mcp
请帮我确认当前有没有可用工具能读取错误监控、PR 评论或内部文档。
只做能力发现，不修改文件。

⠀

这个案例说明：Commands 不是魔法词，而是任务阶段的入口。阶段不同，入口不同；入口错了，Codex 的行为就容易错。

⠀

30. Commands 反例库：这些命令习惯会拖慢你

⠀

30.1 一上来就 /goal

⠀

坏例子：

⠀

/goal
把整个项目质量提升一下。

⠀

问题：

⠀

- 目标过宽。
- 没有边界。
- 很难判断什么时候完成。
- 容易把多个 PR 混成一个长线程。

⠀

改法：

⠀

/plan
请只读分析项目中最适合先改善的一个质量问题。
限制：必须能在一个小 PR 内完成。

⠀

30.2 用 /review 要求实现

⠀

坏例子：

⠀

/review
帮我审查并修复所有问题。

⠀

问题：

⠀

- review 和 implementation 混在一起。
- finding 还没确认就开始改。
- 容易扩大 diff。

⠀

改法：

⠀

/review
只读审查当前 diff。
输出 findings，不要修改文件。

⠀

等确认后再普通 prompt：

⠀

只修第 1 条 finding。
边界：只改 auth redirect 和对应测试。

⠀

30.3 把 /mcp 当搜索按钮

⠀

坏例子：

⠀

/mcp
帮我查一下最新最佳实践。

⠀

问题：

⠀

- `/mcp` 更适合发现和管理当前可用外部工具。
- 不是所有“查资料”都应该走 MCP。
- 如果资料是官方网页，可能需要 web 或文档来源，而不是项目 MCP。

⠀

改法：

⠀

请先说明当前任务需要哪类外部资料：
1. 项目内部文档。
2. GitHub PR/issue。
3. 官方公开文档。
4. 本地代码即可。

再建议使用 MCP、Plugin、Web 还是普通本地分析。

⠀

30.4 把命令当成课程主线

⠀

坏习惯：

⠀

先教所有 slash command，再教 App。

⠀

更好的顺序：

⠀

1. 先教 App 任务闭环。
2. 在真实任务里插入 `/plan`。
3. 在 diff 出现后插入 `/review`。
4. 需要能力发现时再讲 `/mcp`、App Plugins 和 CLI TUI `/plugins` 的边界。
5. 长任务出现时再讲 `/goal`。

⠀

读者不是因为背会命令而会用 Codex，而是在每个任务阶段知道该用哪个入口。

⠀

31. Commands 与团队语言：把口头习惯变成 prompt 入口

⠀

团队里常见的口头话：

⠀

- 先别写，先看看。
- 这个 PR 太大了，拆一下。
- 先把风险说清楚。
- 别碰支付逻辑。
- 这事儿做成每周检查。

⠀

这些话可以翻译成 Commands 入口。

⠀

“先别写，先看看”
=> `/plan` + 只读分析 + 不修改文件。

“这个 PR 太大了，拆一下”
=> `/review` + scope creep + 拆分建议。

“先把风险说清楚”
=> `/review` 或普通只读风险分析。

“别碰支付逻辑”
=> 当前 prompt 边界 + AGENTS.md 或 Rules。

“这事儿做成每周检查”
=> Automation + Skill。

⠀

团队可以整理一份入口词典：

⠀

# Codex Entry Phrases

## Planning

Use when someone says:
- 先看看
- 先别改
- 帮我拆一下

Prompt:
`/plan ... 不要修改文件`

## Review

Use when someone says:
- 这个 diff 看一下
- 会不会有风险
- 这个 PR 能不能合

Prompt:
`/review ... 只读审查当前 diff`

## Automation

Use when someone says:
- 每周都要检查
- 每次发版前都要看
- 这个提醒能不能自动化

Prompt:
普通线程中描述 schedule、scope、output、archive condition。

⠀

这份词典看起来简单，但很能提升团队协作。大家不需要争论“该用哪个功能”，只要把日常语言映射到稳定入口。

⠀

32. Commands 收口：命令结束后要留下下一步

⠀

很多命令使用失败，不是开始错了，而是结束时没有收口。/plan 给出计划后，用户不知道下一步该执行哪一小块；/review 给出 findings 后，作者不知道先修哪条；/goal 运行一阵后，线程不知道当前阶段是否完成。

⠀

每次命令结束，都可以要求 Codex 输出下一步。

⠀

/plan 收口：

⠀

请把这个 plan 收口成一个最小下一步。

输出：
1. 现在先做哪一件事。
2. 允许修改哪些文件。
3. 不允许碰哪些文件。
4. 完成后跑什么检查。
5. 如果遇到不确定，要停在哪里。

⠀

/review 收口：

⠀

请把 review findings 收口成修复顺序。

分类：
1. blocking
2. should fix
3. follow-up
4. ignore for this PR

然后只推荐第一条要修的问题。

⠀

/goal 收口：

⠀

请总结当前 goal 的阶段状态。

输出：
1. 已完成什么。
2. 当前卡在哪一步。
3. 下一次醒来或继续时应该先看什么。
4. 是否应该拆新线程。
5. 哪些内容已经不再相关。

⠀

命令不是流程的终点。命令的好坏，要看它是否让下一步更窄、更清楚、更容易 Review。

⠀

33. Commands 练习：把一段混乱对话整理成入口序列

⠀

混乱对话：

⠀

用户：帮我优化 checkout。
Codex：我可以开始修改。
用户：等等，先看看哪里问题最大。
Codex：发现测试失败。
用户：那你修一下。
Codex：改了 checkout、payment、toast。
用户：这个 PR 太大了。

⠀

要求学生整理成正确入口序列：

⠀

1. `/plan`：只读分析 checkout 问题。
2. 普通 prompt：只修一个明确失败。
3. `/review`：检查 diff 是否越界。
4. 普通 prompt：只处理 blocking finding。
5. Review 面板：人工决定 stage。

⠀

可用 prompt：

⠀

请把下面这段混乱 Codex 对话整理成正确 Commands 使用顺序。

要求：
1. 标出哪里应该用 `/plan`。
2. 哪里应该用普通 prompt。
3. 哪里应该用 `/review`。
4. 哪一步不应该继续写代码。
5. 给出改写后的 prompt。

⠀

这个练习能让读者看到：Commands 不只是功能入口，还是节奏控制器。会用命令的人，能在任务快要跑偏时把它拉回正确阶段。

⠀

📝 总结与检查清单

⠀

完成本课后，请确认以下所有项：

⠀

全部勾选后即掌握 Codex Commands。

附录

⠀

A. 命令速查

⠀

命令

用途

稳定性

展开并筛选当前命令列表

按实际列表

/status

查看任务 ID、上下文用量与额度

当前官方支持

/plan

切换计划模式（先规划不执行）

当前官方支持

/review

审查当前改动

当前官方支持

/mcp

打开 MCP 连接状态

当前官方支持

/goal

设置持续目标

当前官方支持

/feedback

发送产品反馈

当前官方支持

⠀

B. 推荐学习资源

⠀

App Slash commands：https://learn.chatgpt.com/docs/reference/slash-commands
快捷键与深链：https://learn.chatgpt.com/docs/reference/commands
CLI Developer commands：https://learn.chatgpt.com/docs/developer-commands?surface=cli
Import from another agent：https://learn.chatgpt.com/docs/import
本系列上一篇：CX-02 桌面工作流
本系列下一篇：CX-04 项目指令与权限

课程制作：老金
最后更新：2026年9月14日
许可：本课程采用 MIT License；转载、复制或二次分发时必须保留版权声明与许可声明

下一步

⠀

下一篇：CX-04 项目指令、配置、权限与沙盒。