1. 任务描述要像给工程师写需求

不要只写一句“帮我加个登录功能”，而是给出：

• 背景：这是什么项目、技术栈是什么
• 目标：要做什么
• 约束：不要改什么、遵循什么规范
• 验收标准：测试通过、能运行、输出格式等

示例：

这是一个 Express + TypeScript 项目，使用 Prisma 连接 PostgreSQL。

请帮我实现用户登录接口 POST /auth/login。

要求：
- 使用 bcrypt 校验密码
- 登录成功后返回 JWT，有效期 7 天
- 输入必须校验 email 格式和密码长度
- 不要修改现有的 Prisma schema
- 不要引入新的依赖

先给出修改计划，等我确认后再改代码。

这样 Codex 会更稳，不会乱来。

---

2. 使用 AGENTS.md 统一项目规则

在项目根目录放一个 AGENTS.md，Codex 会自动读取。里面写清楚项目约定，例如：

# 项目规则
- 包管理器使用 npm，不要用 yarn/pnpm
- 测试框架使用 vitest
- API 路由统一放在 src/routes/
- 数据库访问必须通过 Prisma，不要写原生 SQL
- 提交前必须运行 npm run lint 和 npm test

这样每次 Codex 操作都会遵守这些规则，减少出错。

---

3. 先计划，再执行

对于复杂任务，不要让 Codex 直接改代码。可以先让它：

请先阅读 src/auth 相关代码，然后给我一个修改计划，列出要改哪些文件、每个文件改什么。

确认计划没问题后，再说：

可以，按这个计划执行。

Codex CLI 里也可以使用 /plan 命令，让它先生成执行计划。

---

4. 善用交互命令

Codex CLI 有一些内置命令，能帮你控制流程：

• /diff：查看当前改动
• /review：让 Codex 审查当前 diff
• /undo：撤销最后一次修改
• /redo：重做
• /model：切换模型
• /approvals：查看或修改审批策略
• /help：查看所有命令

改完代码后，建议多用 /diff 和 /review，不要盲目信任生成结果。

---

5. 控制安全和审批模式

Codex 可能会修改文件、执行命令，所以建议：

• 默认使用 审批模式：每次写文件或执行命令前需要你确认
• 使用 --sandbox 或配置沙箱模式：只允许读取，不能写文件/网络
• 不要随便使用 --full-auto：全自动模式风险高

例如：

codex --approval
codex --sandbox

或者在使用过程中手动批准关键操作。

---

6. 缩小上下文范围

Codex 上下文有限，大项目不要一次让它读所有文件。可以：

只查看 src/auth/ 目录和 package.json，不要读取其他文件。

也可以让它先搜索相关代码：

先搜索项目中所有涉及 JWT 的代码，再告诉我修改点。

这样可以避免无关信息占用上下文。

---

7. 分阶段处理大任务

不要一次丢一个超长需求。可以拆开：

1. 先让 Codex 阅读代码并总结结构
2. 再让它设计修改方案
3. 确认方案后让它实现
4. 让它运行测试并修复问题
5. 最后让它做代码审查

每一步都可以用自然语言追问：

现在运行 npm test，如果有失败请自动修复。

---

8. 明确验收标准

告诉 Codex 如何验证自己的修改是否成功：

改完后运行 npm test，必须全部通过。
如果测试失败，请根据错误继续修复，直到通过为止。

也可以要求它运行构建：

修改后执行 npm run build，确保没有类型错误。

---

9. 利用图片、文档和错误信息

你可以把截图、报错堆栈、接口文档直接粘贴给它。例如：

这是浏览器控制台报错截图，请根据这个错误修复前端代码。

或者：

下面是第三方支付接口文档片段，请按这个格式实现签名逻辑。

这比抽象描述准确得多。

---

10. 结合 Git 工作流

建议在独立分支上使用 Codex：

git checkout -b feature/codex-login

让 Codex 修改完后，用 git diff 检查改动，确认没问题再合并。Codex 的 /diff 命令也可以直接看差异。

---

11. 非交互式用法

Codex CLI 可以直接在命令行执行一次性任务，适合脚本化：

codex exec "修复 src/utils.js 中第 42 行的 TypeError，并运行测试"

也可以用它批量处理简单任务，但注意审查输出。

---

12. 常见坑

• 生成不存在的 API：要求它先查看现有代码或文档，不要凭空写。
• 修改范围过大：明确“不要修改其他文件”。
• 忽略项目规范：用 AGENTS.md 约束。
• 不运行测试：主动要求它运行测试并修复。
• 上下文超长：大项目分段处理，不要一次读太多。

---

总结

Codex 最好用的姿势是：

清晰需求 + 项目规则 + 先计划后执行 + 审批模式 + 测试验收 + 人工审查 diff

把它当一个能快速执行但需要监督的初级工程师，就能发挥最大价值。