许多人第一次用 Codex，很容易把它当成一个“更会写代码的终端助手”。

遇到 bug，就让它修 bug；想加功能，就让它直接改文件；报错看不懂，就把日志丢进去让它分析。这样用当然没有问题，Codex 本来就擅长读代码、改代码、跑命令、看 diff，也能把许多原本很耗人的琐碎开发工作接过去。

但真正用久后来，你会发现 Codex 的效率差距，并不只在“它能不能写出代码”，而在于你有没有把它管起来。

它目前知道项目规矩吗？它目前能改哪些文件？它当前是不是在正确的工作区？它准备大改之前有没有先给你路线图？它改完后来有没有帮你做一次交付前检查？

这些问题如果不管，Codex 再能干，也容易变成一个动作很快但边界不清的助手。它可能会认真完成任务，但顺手改了不该改的文件；它可能会跑许多命令，但你不知道它当前权限到底有多大；它可能会给出一大堆改动，但最后 review 的压力又回到你身上。

所以 Codex 的提效，不只是让它多写几行代码，更关键的是先把规则、权限、计划和交付检查管住。

这篇就讲 5 个容易被忽略的小命令。它们看起来都不复杂，但真正用起来，会明显改变 Codex 的工作方式。

/init：先给 Codex 一份项目规矩

许多人一进项目就让 Codex 开始修 bug，这种用法短平快，但一旦项目稍微复杂一点，Codex 就要先花时间猜项目结构。它要判断这个项目用的是 npm、pnpm 还是 yarn，要看测试命令是什么，要确认前后端目录怎么分，要猜哪些配置文件可以动、哪些文件最好不要碰。

这些信息如果每次都靠你临时补充，Codex 的使用体验就会很不稳定。今天你想起来提醒它“别碰 .env”，它就不碰；明天你忘了提醒，它可能就把配置文件也纳入修改范围。更稳的做法，是一开始就把项目规矩写下来。

在 Codex 里，可以先用这个命令：

/init

这个命令会在当前项目里生成一份 `AGENTS.md` 脚手架。你可以把它理解成 Codex 在这个仓库里的工作说明书。后来它进入这个项目，先看这份说明，就知道自己应该怎么工作。

`AGENTS.md` 里最值得写的，不是长篇大论，而是那些你不想每次重复解释的规则。列如这个项目用什么包管理器，测试命令怎么跑，哪些目录是核心业务，哪些文件不能乱改，改完后来需要执行什么检查。

列如可以写成这样：

本项目使用 pnpm，不要使用 npm。

修改前端组件后，必须运行 pnpm lint。

不要直接修改 .env、.env.local、生产配置文件。

数据库迁移文件只允许新增，不要修改历史迁移。

提交前先展示 diff，再等待我确认。

这些规则看起来很普通，但它们能明显减少 Codex 的试错。尤其是一些老项目，目录结构可能并不规整，历史包袱也比较多。如果没有明确的项目说明，Codex 只能靠读文件和猜上下文来判断，效率和安全性都会打折。

我的提议是，只要你准备在某个仓库里长期用 Codex，第一步就先跑 `/init`。不要等它改错文件后来，再回头补规则。先把边界写清楚，后面的协作会顺许多。

/status：动手前先看清当前状态

Codex 和普通聊天工具最大的区别在于，它不是只负责回答问题。它一般会直接介入你的本地项目，读取文件、修改代码、运行命令，甚至在合适的权限下执行一系列连续操作。

这就带来一个现实问题：你必须知道它当前处在什么状态。

列如当前使用的是哪个模型，当前 sandbox 是什么模式，approval 策略是不是你想要的，Codex 当前能写哪些目录，工作区是不是正确的项目目录，上下文容量还剩多少。这些信息如果不确认，就容易发生“我以为它不能做，但它实则能做”或者“我以为它会问我，结果它直接做了”的情况。

这时候可以用：

/status

这个命令本身不会替你写代码，也不会直接改项目，但它是一个很实用的开工前检查。你可以把它理解成 Codex 的仪表盘。

我提议在三种场景下养成看 `/status` 的习惯。第一种，是刚进入一个新项目时。你要确认当前目录是不是你想操作的仓库，尤其是同时打开多个终端窗口时，这一步很容易救命。第二种，是改过权限或审批策略之后。许多人调完配置就直接继续工作，结果过了几天已经忘了自己给 Codex 开了多大的权限。第三种，是准备让 Codex 执行跨文件大任务之前。大任务往往会涉及多个目录、多个命令和多轮修改，开工前先确认状态，比事后排查要省时间。

Codex 提效的一个基础习惯，就是不要在“状态不明”的情况下让它动手。先看 `/status`，确认模型、权限、工作区和上下文都符合预期，再继续给任务。

/permissions：别一上来就给满权限

许多人用 Codex，最容易被审批提示烦到。它改一个文件问你一次，跑一个命令问你一次，访问一些资源也要问你。刚开始还觉得安全，时间一长就觉得麻烦，于是干脆把权限放大，最好什么都不用问。

这样的确 省事，但也很危险。

Codex 的权限管理，核心要看两个东西：sandbox 和 approval。sandbox 决定它能在哪个范围内工作，approval 决定它什么时候必须停下来问你。一个管边界，一个管确认。

在交互过程中，可以用：

/permissions

这个命令用来调整 Codex 当前能做什么、哪些动作需要审批。它比自然语言提醒更可靠，由于你对 Codex 说“不要乱改”，本质上还是一种提示；但你用权限限制住它，它实际能做的动作就会被约束。

更稳的思路是：让低风险动作尽量顺畅，让高风险动作必须确认。列如让 Codex 在当前 workspace 里读取文件、修改普通代码、运行测试命令，这一般是合理的。如果它要访问网络、安装依赖、越出工作区、修改环境配置、执行删除操作，就应该停下来问你。

尤其是下面几类文件，不提议随意让 Codex 自动改：

.env
.env.local
生产配置文件
密钥文件
历史数据库迁移
部署脚本
权限策略文件

这些文件不是绝对不能改，而是不能在你不知情的情况下改。

所以 `/permissions` 真正解决的不是“让 Codex 少问你”，而是“让它在该问的时候必定问，不该问的时候别打断”。这个平衡点找到了，Codex 才会既高效又不吓人。

对于刚接触 Codex 的朋友，我不提议一开始就追求全自动。先把权限收紧一点，等你熟悉它的行为，再逐步放开常用低风险操作。真正熟练的人，不是权限开得最大，而是知道哪些权限可以开，哪些权限必须留给自己确认。

/plan：大改动前先让它写路线图

Codex 的强项是动手快，但动手太快也会带来问题。你让它重构支付模块，它可能很快就开始改服务层、接口层、类型定义和测试文件。你让它拆一个复杂页面，它可能一口气新建组件、移动样式、调整状态管理。最后代码的确 改了许多，但你很难马上判断每一步是不是必要，也不知道出了问题该从哪里回滚。

这种时候，最稳的做法不是让它立刻改，而是先让它计划。

命令是：

/plan

也可以直接把任务写在后面：

/plan 重构支付模块，先列出改动范围、风险点、测试方案，不要直接修改文件

这个命令的价值，是把 Codex 从“执行者”先切换成“规划者”。它会先分析需求、梳理涉及文件、说明可能影响、给出测试方案，再等你确认是否继续。

大改动前，最怕的不是慢，而是看不清。你看不清它准备改哪里，它一动手，你就只能被动 review。相反，如果它先把路线图写出来，你就可以在真正改文件之前发现问题。列如它计划里提到要修改一个历史迁移文件，你可以马上拦住；它遗漏了测试命令，你可以提前补充；它把不相关模块也纳入改动范围，你可以要求缩小边界。

我提议下面这些任务都先用 `/plan`：

跨多个文件的重构
登录、支付、权限、订单等核心模块修改
数据库结构调整
前后端联动改造
框架迁移
依赖升级
测试不完整的老项目改造

一个比较好用的提示方式是：

/plan 把用户设置页拆成 3 个组件：基础信息、账号安全、通知偏好。先列出文件清单、组件边界、风险点和测试命令，不要直接改代码。

这里最关键的是最后一句：不要直接改代码。Codex 能执行，但你要先让它说清楚怎么执行。计划阶段花几分钟，一般能省掉后面大量返工时间。

/review：改完别急着交，让它先自查

许多人用 Codex，只让它写代码，不让它检查代码。它完成任务后来，你看一眼结果，觉得差不多，就准备提交。这个流程很快，但风险也很明显。AI 写代码容易犯的错误，往往不是那种一眼能看出来的大错，而是一些细小但后续很麻烦的问题。

列如类型改了，调用处没有改全；新增文件没有被 Git 跟踪；某个异常分支没有处理；测试命令没有跑；旧逻辑删了，文档没有同步；接口行为发生变化，但调用方还按老逻辑在用。

这时候可以用：

/review

这个命令会审查当前 working tree，适合放在交付前。它不是替你最终拍板，而是先让 Codex 用另一个角度检查自己刚才的改动。

如果你想先看清楚它到底改了什么，可以先用：

/diff

再用：

/review

我的提议是，把这一套动作固定下来：Codex 实现功能后来，先跑测试，再看 `/diff`，最后用 `/review` 做一次交付前检查。

不过 `/review` 不要问得太泛。如果你只说“review 一下”，它可能给你一些很普通的提议。更好的方式，是告知它重点查什么。

列如：

/review 重点检查空值处理、类型变化、测试覆盖、未跟踪文件和可能的回归风险

或者：

/review 只检查这次改动有没有破坏现有 API，不要提出无关风格提议

这样 review 的质量会高许多。

Codex 改完代码后来，不要急着信任它。让它自己换个角度再审一遍，常常能拦住一些小但关键的问题。尤其是你准备把代码提交到真实项目时，这一步超级值得保留。

这 5 个命令怎么连起来用

单独看这几个命令，都不难。真正能提升效率的，是把它们变成一套固定流程。

第一次进入项目时，先用：

/init

把项目规则写进 `AGENTS.md`，让 Codex 知道这个仓库的基本规矩。

开工前，用：

/status

确认当前模型、工作区、权限、审批策略和上下文状态，避免在状态不清的情况下直接开干。

如果发现权限太松、审批太频繁，或者你准备做一个风险更高的任务，就用：

/permissions

把 Codex 能做什么、什么时候必须问你调整到合适档位。

遇到跨文件重构、核心模块修改、数据库变更这类任务，先用：

/plan

让它把路线图写出来，确认范围和风险后再执行。

改完之后，不要只看结果。先看：

/diff

再让它做交付前检查：

/review

这套流程的好处是，Codex 每一步都在你能理解、能控制、能复查的范围内工作。你不需要一直盯着它每一个动作，但关键节点不能放掉：开工前有规则，执行前有状态，动手前有计划，交付前有 review。

最后提炼

这 5 个命令，可以这样记：

Codex 真正提效的关键，不是让它马上动手，而是先把规则、状态、权限、计划和交付检查管起来。

`/init` 让它知道项目规矩，`/status` 让你看清当前状态，`/permissions` 让权限不失控，`/plan` 让大改动不盲目，`/review` 让交付前多一层检查。

许多人觉得 Codex 有时不稳定，实则问题往往出在使用方式上。你把它当成一个随叫随到的代码生成器，它就容易越改越散；你把它放进一套清楚的工作流程里，它才更像一个能长期协作的开发搭档。

一个没有边界的 Codex，会让人紧张。

一个被规则、权限和 review 管住的 Codex，才适合放进真实项目里长期使用。