别再把Codex当许愿池了——10个动作让它从”能写代码”变成”真能干活”

我们组新来的实习生，第一天用Codex差点删了生产库

事情是这样的。实习生小刘入职第一天，被安排熟悉一个Spring Boot项目。他把项目路径配好，打开Codex，直接输入：

“帮我重构一下这个项目的用户模块，把代码写得更优雅一点。”

Codex很听话，真的开始重构了。改了UserService、重命名了UserEntity、删了几个它觉得”多余”的工具类。小刘美滋滋地看着代码变干净了，直到构建报错——他才发现Codex删掉的工具类被订单模块引用着。

更要命的是，他启动Codex的时候没设权限限制，也没有指定工作目录。Codex不只改了他当前项目里的文件，还”顺手”碰了一下他电脑上另一个项目——由于两个项目在同一个父目录下。

我花了半天帮他回滚代码、排查影响。

这件事之后我定了一条规矩：用Codex之前，必须先做好三件事——固定目录、设好权限、定好规则。 不是不信任AI，是基本工程纪律。

大多数人用Codex的方式，错在哪？

我看过太多人用Codex的方式了。总结一下最常见的三种”翻车模式”：

翻车模式一：一句话派活。

“帮我改一下这个功能。”“帮我修一下这个bug。”这种指令太粗了。Codex不知道你的项目结构、不知道哪些文件有关联、不知道哪些动不得。结果就是：改对了是运气，改砸了是常态。

翻车模式二：不设权限就开干。

Codex默认能做什么，取决于你启动时的参数设置。你不设权限，它可能误删文件、改配置、碰跟当前任务无关的代码。

翻车模式三：改完不看diff就提交。

Codex说”我改好了”，你就信了？我踩过这个坑。有一次它”修bug”的时候顺手改了一个配置文件的注释格式，导致部署的时候环境变量没加载上。

核心问题就一个：大多数人把Codex当许愿池，许个愿就等着收货。但实际上它是一个需要管理的工程同事。

Codex最容易被忽略的一个前提

许多人不知道，Codex里有三种不同类型的”命令”，使用场景完全不一样：

这三种东西不能混着用。codex doctor是终端命令，你不能在Codex对话里敲它。/model是会话命令，你不能在终端里直接敲它。

我见过有人在会话里敲codex review，然后一脸困惑地问”怎么没反应”。你把终端命令打进聊天框里，当然没反应。

我用Codex的10个步骤，每一步都踩过坑

下面是我自己用了半年Codex之后沉淀下来的工作流。不是从文档里抄的，是从血泪教训里总结的。

第一步：确认版本。

codex --version

Codex更新极快。我在公司用的版本和家里用的版本差了两个小版本，命令列表都不一样。网上抄来的命令在你那里跑不通，第一个排查的就是版本。

第二步：体检环境。

codex doctor

这条命令帮你检查安装、配置、登录状态、MCP连接。许多人”Codex不好用”，实则不是Codex的问题，是环境一开始就不对——MCP没启动、登录过期、工作目录不对。

第三步：固定项目目录。

codex -C /你的项目路径

这步我反反复复说了无数遍了。小刘那次的事故，根因就是没指定项目目录。Codex站在了父目录上，以为两个项目是一体的。

你改一个项目，Codex就老老实实改这一个。别让它有机会碰到别的。

第四步：设好权限。

codex -C /项目路径 -s workspace-write -a on-request

-s workspace-write表明只允许改当前项目文件。-a on-request表明关键操作要问你。

我一般不会给Codex”danger-full-access”权限。你不会给一个新来的实习生生产库的root权限吧？同理。

第五步：切合适的模型。

/model

简单任务用小模型就行了，省token省时间。跨文件重构、复杂排错、架构设计，用推理能力强的模型。别什么活都用最强的模型跑——杀鸡不用牛刀。

第六步：给准上下文，别让它全项目乱扫。

我最怕别人跟我说”你看一下整个项目”。

项目一大，信息就杂。Codex看到的东西越多，不必定越机智。我的做法是明确告知它看哪几个文件、当前问题是什么、不要做什么、输出要求是什么。

举个例子，上周我让Codex修一个Chrome插件的收藏状态同步问题。我没有说”帮我修收藏”，而是：

请重点查看这三个文件：
- src/db/index.ts（IndexedDB操作）
- src/services/favorites.ts（收藏逻辑）
- src/App.tsx（UI状态管理）

当前问题：收藏/撤销收藏后，词库列表没有实时刷新。
先理解数据流，不要修改代码。

先理解，再动手。 这四个字能避免一半的翻车。

第七步：先规划再执行。

复杂任务我从来不直接说”帮我改”。

我的习惯是让Codex先出方案：要改哪些文件、每个文件为什么改、可能影响什么、风险在哪里、怎么验证。我确认方案之后才让它动手。

可以用/plan命令（如果当前入口支持），也可以直接用普通提示词：

先不要修改文件。
请分析当前实现，告知我：
1. 要改哪些文件，为什么
2. 可能影响哪些数据流
3. 风险点是什么
4. 验证方式是什么
等我确认后再执行。

第八步：改完必须看diff。

Codex说”我改好了”，你说”谢谢”。这是最危险的时刻。

我会做三件事：

1. git diff——看它到底改了什么，有没有动无关文件
2. 重点检查有没有临时代码（console.log、mock数据、TODO注释）
3. 看有没有误删逻辑、改配置、动manifest文件

在终端里还可以跑codex review --uncommitted，让AI自己审一遍改动，加一句重点审查要求：

codex review --uncommitted "重点检查状态同步、类型错误、构建风险和无关修改"

第九步：跑项目自己的验证。

npm run build
npm test

Codex写完不算完。构建通过、测试通过，才算完。

第十步：长期规则写到AGENTS.md里。

如果你长期用一个Codex管一个项目，别每次都口述规则。在项目根目录放一个AGENTS.md，把项目背景、技术栈、开发规则、验收标准全写进去。

我给每个长期项目都写了一份。内容包括：这个项目是什么技术栈、修改后必须做什么验证、哪些文件不能动、哪些依赖不能随意升级。

普通人每次口述需求，高手把规则写成文档。

三个被低估的命令

除了上面10步，还有三个命令我用下来觉得很香。

codex fork --last：探索新方案用。你在一个复杂任务里突然想到另一种实现思路，但又不想污染当前会话。用这个命令分叉一条新线，试完不行就丢掉，不影响主线。

我上个月做插件UI重构的时候，纠结是用四个tab还是合并成两个tab。分叉了两条线各试了一遍，最后选了合并方案。主线干干净净，没有被探索过程弄乱。

/compact：长会话压缩用。跟Codex聊久了，上下文会越来越长，token消耗越来越快。/compact可以压缩历史对话，释放上下文空间。相当于给会话做一次”内存回收”。

codex --search：涉及新文档、新API、新框架写法的时候，在启动时加这个参数。让Codex能联网搜索最新信息，而不是凭训练数据硬猜。

工程里最贵的不是”慢一分钟”，是”凭旧知识改错一大片”。

一张图总结我的工作流

我把上面10步浓缩成一张流程图，你存下来每次照着走就行：

启动阶段：确认版本 → 体检环境 → 固定目录 → 设权限

开发阶段：切模型 → 给准上下文 → 先规划再执行

验收阶段：看diff → 审查代码 → 跑验证 → 沉淀规则

每一步都有它存在的理由。跳过任何一步，都是给后面埋雷。

最后一句

Codex是个好工具，但它不是许愿池。你给它的上下文越准、权限越合理、验收越严格，它干得越好。

反过来，你一句话”帮我改一下”然后就等着收货，翻车只是时间问题。

别把Codex当许愿池。当工程同事管——会管，它才真能干活。

版本说明：本文基于 codex-cli 0.142.0-alpha.6 版本验证。Codex更新频繁，命令可能因版本和入口（CLI/App/IDE扩展/Cloud）不同而有差异。提议使用时先输入 / 查看当前入口支持的命令列表，或执行 codex --help 确认可用命令。