夜雨聆风前两篇我们已经把 Codex App 装好，也跑通了本地项目工作流。
这篇聊一个更容易被忽略的东西：
Codex App 里的 Commands。
也就是你在输入框里敲 / 后看到的那些命令。
我一开始对它们没太在意。
反正直接用自然语言说“帮我看一下状态”“先给我计划”“帮我 review 一下”也能用。
后来发现，Commands 的价值不在于炫技。
它们像几个固定入口。
你不用每次都重新解释自己要进入哪种工作状态。
输入 /plan，就是先规划。
输入 /review，就是看当前改动。
输入 /status，就是确认当前线程状态。
这篇文章只解决一件事：
新手怎么把 Codex App 里的 Commands 用起来。
一、Commands 到底是什么
Commands 可以理解成 Codex App 里的快捷动作。
它们不是另一套高级语法，也不是必须背下来的命令表。
更实际一点说：
你在输入框里敲 /，Codex App 会列出当前环境可用的命令。
选中一个命令后，再补上你的任务说明。
比如：
/plan请先阅读项目结构，给出重构登录模块的方案。先不要修改文件。
或者：
/review重点看这次改动有没有误改范围外文件，是否缺少测试。
它和直接聊天的区别在这里：
命令先帮你切到一个明确的工作入口。
你后面写的文字，再补充范围、约束和验收方式。
二、第一步不是背，而是输入 /
Codex App 的命令会随着版本、权限、插件、账号和当前环境变化。
所以我不建议一上来背一张“完整命令表”。
更靠谱的方式是：
打开一个项目线程->在输入框输入/->看当前弹出的命令列表->再决定用哪个
这一步很重要。
别人电脑上有的命令，你这台机器未必有。
某篇教程里出现的命令，也不代表你当前版本一定支持。
如果你不确定某个命令能干什么，可以直接问 Codex：
解释一下当前可用的 slash commands。只解释，不要修改文件。
这个习惯比记命令更有用。
三、新手先掌握这几个
官方当前列出的 App slash commands 里，新手可以先看这些：
/status/plan/review/mcp/goal/init/feedback
不用一次全学完。
我建议先从 /status、 /plan、 /review 开始。
这三个已经能覆盖大多数日常场景。
四、 /status：先确认你现在在哪
很多问题，其实不是 Codex 不会做。
而是你没看清当前线程处在什么状态。
比如：
当前有没有打开项目？
上下文还剩多少？
线程 ID 是什么？
当前有没有接近限制？
这时候可以先输入：
/status
然后继续问：
解释当前线程状态。重点说明：当前工作区、上下文使用情况、限制情况。不要修改文件。
这个命令适合放在任务开始前。
尤其是你准备让 Codex 做一个比较大的任务时，先看状态，心里会稳一点。
五、 /plan：别急着让它改
我建议新手先学 /plan。
因为它能帮你把“直接开改”的冲动按住。
适合用 /plan 的场景：
多文件改动不熟悉的项目影响面不确定的 bug重构、迁移、升级依赖
可以这样写：
/plan目标：修复登录页在移动端按钮溢出的问题。范围：先只阅读登录页组件、相关样式和测试文件。约束：不要修改文件。不要安装依赖。交付：列出可能原因、修改方案、风险和验证命令。
注意最后两句。
不要修改文件。不要安装依赖。
这不是废话。
它能让 Codex 先进入分析状态，而不是一上来就动手。
等你看完计划，觉得方向没问题，再让它执行。
六、 /review：改完不要只听总结
Codex 改完文件后，人很容易偷懒：
只看它的总结。
总结可以看，但不能只看总结。
要看 diff。
这时候可以用：
/review
如果任务比较敏感，把检查重点写清楚：
/review重点检查：1.是否改了任务范围外的文件2.是否缺少必要测试3.是否引入新的网络请求、权限变化或外部服务调用4.是否有过度抽象
/review 不是让 Codex 替你拍板。
它是在帮你做第一轮审查。
最后要不要保留这些改动，还是你决定。
七、 /mcp：看外部工具有没有接上
如果你装了浏览器、数据库、文档、内部 API 这类外部工具，通常会涉及 MCP。
这时候 /mcp 可以帮你看当前连接状态。
比如：
/mcp
你可以接着问：
列出当前可用的 MCP 工具。说明每个工具适合做什么。不要调用工具。
这一步适合在“工具好像不能用”的时候先跑。
先看工具是否存在，再谈怎么用。
不要一上来就怀疑 prompt 写错了。
有时候只是工具没接上。
八、 /goal：适合有终点的长任务
/goal 适合更长一点的目标。
比如迁移、重构、持续修复测试，或者需要多轮推进的任务。
但我不建议新手一上来就用它。
原因很简单：
长任务如果目标写得模糊，Codex 会在模糊里跑很久。
不要这样写：
/goal优化整个项目
这个目标太大。
更好的写法是：
/goal把旧的 auth helper 迁移到新的 auth client。范围：只允许修改 src/auth 和 tests/auth。验证：持续推进，直到 npm test -- auth 通过。停止条件：如果需要修改范围外文件，或遇到需要人工确认的设计选择，先停下来问我。限制：不要提交 commit，不要推送远程分支。
这里的重点不是 /goal 本身。
重点是你写清楚了范围、验证方式和停止条件。
如果你的 App 里没有看到 /goal，不要硬找。
先用 /plan 加普通任务提示，也能把大部分工作拆开做。
九、 /init：让项目先有一份 AGENTS.md
/init 的作用，是为当前项目生成 AGENTS.md 脚手架。
AGENTS.md 可以放项目约定。
比如：
项目启动命令测试命令代码风格不要碰哪些目录提交前要跑什么检查
如果你经常让 Codex 处理同一个项目， AGENTS.md 很有用。
它相当于把重复说很多遍的项目规则写下来。
用法可以很简单：
/init根据当前项目生成 AGENTS.md 草稿。先不要覆盖已有文件，如果已有 AGENTS.md，请先展示差异。
如果项目已经有规则文件，不要让它直接覆盖。
先看草稿，再合并。
十、 /feedback：真遇到问题就反馈
/feedback 用来打开反馈入口。
它适合反馈 App 或命令本身的问题。
比如：
某个命令不显示某个命令行为和说明不一致界面卡住插件或工具状态异常
这不是日常高频命令。
但遇到产品问题时，比在普通 thread 里反复描述更直接。
十一、Commands、Skills、Automations 别混在一起
很多人容易把这几个概念混掉。
简单分：
Command 是当前线程里的快捷入口。
Skill 是可复用的方法和规则。
Automation 是定时或后台重复任务。
举个例子。
你只是想看当前改动：
/review
这适合 Command。
你想每次写公众号文章都按同一套发布检查来做：
wechat-md-publisherhumanizer-zhmarkdown-to-html
这更适合 Skill。
你想每天早上自动检查一个仓库的测试状态：
每天9点检查测试结果
这属于 Automation。
不要把所有东西都想成 command。
入口不同，适合的事情也不同。
十二、我的日常用法
如果只给新手一套顺手流程，我会这样用：
/status先确认当前线程状态。
然后：
/plan先读项目，给方案，不要改文件。
确认计划后，让 Codex 执行小范围改动。
改完以后：
/review重点看范围、测试和风险。
如果这个任务比较长，再考虑 /goal。
如果涉及外部工具，再看 /mcp。
这套流程很朴素，但够用。
它的好处是让你一直知道 Codex 现在在干什么。
十三、几个不要做的事
不要把 CLI 命令表直接搬到 App 教程里。
CLI 和 App 不保证完全一样。
不要把别人机器上的命令当成你当前版本一定有。
先输入 / 看列表。
不要给 /goal 这种长任务入口一个模糊目标。
范围、验证、停止条件必须写清楚。
不要把 /review 当成人工 review 的替代品。
它是辅助，不是最终裁判。
总结
Codex App 的 Commands，不是让你背命令。
它们是几个工作入口。
你真正要学会的是：
用/发现当前可用命令用/status 看状态用/plan 先想清楚用/review 检查改动用/mcp 看工具连接用/goal 处理有明确终点的长任务
先把这几个用顺，Codex App 就会从“一个会聊天的代码助手”，变成更可控的本地项目工作台。