AI 编程工具最容易被误用成“高级自动补全”。但 Codex 更适合被当成一个能读代码、改代码、运行命令、参与排查和交付的编程智能体。以 Codex CLI 为例，它可以在本地终端运行，读取、修改并执行当前目录中的代码；官方文档也提到 Codex CLI 可通过 npm 安装，并支持 macOS、Windows、Linux。(OpenAI 开发者)

这篇文章不追求覆盖所有高级配置，而是总结开发者最常用、最容易见效的一套 Codex 使用技巧。

1. 先把 Codex 放进真实开发流，而不是只拿来问答

安装 CLI 后，可以直接在项目目录中运行：

npm i -g @openai/codex
codex

第一次运行会提示登录，可使用 ChatGPT 账户或 API key。官方说明中也提到，Codex 已包含在 ChatGPT Plus、Pro、Business、Edu 和 Enterprise 等方案中。(OpenAI 开发者)

实际使用时，建议从这些任务开始：

阅读这个仓库，告诉我启动项目、运行测试、构建发布分别需要哪些命令。

帮我定位这个测试失败的原因，但先不要改代码，先给我分析路径。

实现这个小功能，并在完成后运行相关测试。

审查我这次改动，重点关注边界条件、并发问题和错误处理。

一开始不要让 Codex 直接“重构整个系统”。先让它处理小而明确的任务，比如修 bug、补测试、解释模块、改一个接口、增加一个验证逻辑。等你熟悉它的行为后，再逐步交给它更复杂的任务。

2. 写提示词时，用“四件套”：目标、上下文、约束、完成标准

Codex 官方最佳实践建议，在复杂代码库中给它足够的任务上下文，并明确说明目标、相关文件、约束和“完成条件”。(OpenAI 开发者)

一个好提示词可以这样写：

目标：
修复用户在提交表单时重复点击导致创建两条订单的问题。

上下文：
- 主要逻辑在 src/pages/Checkout.tsx
- API 调用封装在 src/api/order.ts
- 相关测试在 src/pages/__tests__/Checkout.test.tsx

约束：
- 不要引入新的状态管理库
- 保持现有 UI 不变
- 优先使用已有的 Button loading 逻辑

完成标准：
- 重复点击只会创建一条订单
- 相关测试通过
- 如果缺少测试，请补一个回归测试

这比“帮我修一下 checkout bug”稳定得多。你给的信息越接近真实任务单，Codex 就越像团队成员，而不是猜谜机器。

3. 复杂任务先让它“计划”，不要一上来就改

复杂需求、历史包袱重的模块、跨文件改动，都应该先让 Codex 计划。官方最佳实践也建议复杂或模糊任务可以使用 Plan mode，让 Codex 先收集上下文、提出问题、形成计划，再进入实现。(OpenAI 开发者)

你可以这样说：

先不要修改代码。请先阅读相关文件，给出：
1. 你认为问题发生在哪些路径
2. 准备修改哪些文件
3. 每个修改的风险
4. 准备用什么测试验证
等我确认后再开始实现。

这个习惯很重要。它能避免 Codex 在理解不充分时大范围修改，也方便你在实施前纠偏。

4. 用 AGENTS.md 固化团队规范

很多人反复告诉 Codex：“项目用 pnpm”“改完要跑 npm test”“不要动 generated 文件”“PR 描述要包含测试结果”。这些重复说明应该写进 AGENTS.md。

官方文档说明，Codex 会在工作前读取 AGENTS.md，可以把全局指导和项目级指导叠加起来，让不同仓库拥有一致的工作约定。(OpenAI 开发者) 官方最佳实践也建议把仓库布局、运行方式、构建测试命令、工程规范、禁止事项、完成定义等内容放进 AGENTS.md。(OpenAI 开发者)

一个实用的 AGENTS.md 示例：

# AGENTS.md

## 项目结构
- src/pages：页面组件
- src/components：通用组件
- src/api：接口封装
- src/domain：核心业务逻辑

## 常用命令
- 安装依赖：pnpm install
- 本地开发：pnpm dev
- 类型检查：pnpm typecheck
- 单元测试：pnpm test
- lint：pnpm lint

## 开发约定
- 优先补测试，再修实现
- 不要修改 generated/ 目录
- 不要直接读取 .env 文件
- 新增依赖前必须说明原因
- 修改公共组件时，需要检查至少一个使用方

## 完成标准
- 相关测试通过
- 没有新增 TypeScript 错误
- 输出改动摘要和验证方式

建议每个长期维护的仓库都放一个 AGENTS.md。这相当于给 Codex 写了一份“新同事入职指南”。

5. 小步提交：让 Codex 一次只做一类事

不要把“修 bug、重构、补测试、改 UI、升级依赖”塞进同一个任务。更好的做法是拆成几轮：

第一步：只定位问题，不改代码。
第二步：只加一个失败测试，证明 bug 存在。
第三步：只修复实现，让测试通过。
第四步：审查改动，看看有没有边界问题。

这和人类开发流程一致：先复现，再修复，再验证，再清理。Codex 在这种流程下更容易产出可 review 的 diff。

6. 让 Codex 写测试，但测试意图要由你定义

Codex 很适合补测试，但不要只说“帮我补测试”。更好的写法是：

请为这个函数补充测试，重点覆盖：
- 空数组
- 重复 ID
- 无权限用户
- API 返回 500
- 时区跨天场景

不要为了通过测试而修改业务逻辑。先给出测试用例列表，再写测试。

你也可以让它先生成测试计划：

先列出这个模块最值得补的 8 个测试场景，按风险排序。暂时不要写代码。

这样你保留了测试策略的主导权，Codex 负责把策略落成代码。

7. 用它做代码审查，而不是只做代码生成

Codex 的高价值场景之一是 review。比如：

请审查当前 git diff，重点关注：
1. 是否有破坏兼容性的接口变化
2. 是否缺少错误处理
3. 是否存在竞态条件
4. 是否需要补测试
5. 是否有过度设计
请按严重程度排序，不要直接修改代码。

或者：

请从资深后端工程师视角 review 这次改动，只指出真正可能导致线上问题的点。

这种方式比“帮我看看代码有没有问题”更有效，因为你指定了 review 维度。

8. 让 Codex 解释陌生代码库

接手旧项目时，可以让 Codex 做“代码导览”：

请阅读这个仓库，输出：
1. 项目的主要入口
2. 核心业务模块
3. 数据流从 API 到 UI 的路径
4. 本地启动方式
5. 最值得小心的历史包袱
不要修改代码。

进一步可以问：

如果我要修改支付成功后的跳转逻辑，应该看哪些文件？请给出阅读顺序。

这个技巧适合 onboarding、排查线上问题、接手离职同事代码、理解第三方开源项目。

9. 明确权限边界，尤其是文件和网络访问

Codex 可以运行命令、改文件，所以权限设置很重要。官方权限文档提到，权限 profiles 可以用最小权限原则限制 Codex 运行本地命令时的文件系统和网络访问；内置 profiles 包括 :read-only、:workspace 和 :danger-full-access，其中 full access 应只在你明确需要时使用。(OpenAI 开发者)

实用建议：

探索代码、解释架构、做 review：优先只读模式。
修 bug、补测试：允许写 workspace。
涉及删除文件、迁移脚本、生产配置、密钥、依赖升级：要求 Codex 先计划并等待确认。

尤其不要让 Codex 随意处理 .env、密钥文件、生产数据库脚本和部署凭证。它可以帮你写迁移方案，但是否执行应该由你控制。

10. 让 Codex 跑验证命令，并要求它报告结果

一个常见错误是让 Codex 改完代码就结束。更好的方式是在任务里写清楚验证方式：

完成后请运行：
- pnpm test src/pages/__tests__/Checkout.test.tsx
- pnpm typecheck

如果命令失败，请不要掩盖错误，直接贴出失败原因并尝试修复一次。

也可以要求它总结：

最后请输出：
1. 修改了哪些文件
2. 为什么这样改
3. 跑了哪些验证命令
4. 还有哪些未验证风险

这会让 Codex 的输出更接近 PR 描述，也方便你 review。

11. 不要迷信一次成功，善用“二次提示”

Codex 第一次给出的方案不一定最佳。你可以像 review 同事代码一样继续追问：

这个方案会不会影响已有缓存逻辑？请重新检查。

有没有更小的改动方式？尽量减少 diff。

请不要重构无关文件，只保留修复 bug 所需的最小改动。

现在从测试工程师视角找一下这个实现还缺哪些测试。

很多时候，第二轮、第三轮提示会显著提升质量。

12. 常用提示词模板

修 bug

请帮我修复这个 bug。

现象：
[描述问题]

复现步骤：
[步骤]

期望行为：
[期望]

约束：
- 先定位原因，不要立即修改
- 找到原因后给出修改计划
- 修改后补回归测试
- 最后运行相关测试并总结结果

补测试

请为 [模块/函数] 补测试。

重点覆盖：
- [场景 1]
- [场景 2]
- [场景 3]

要求：
- 先列测试用例清单
- 不要改业务逻辑，除非发现现有逻辑明显有 bug
- 测试风格保持和现有测试一致

重构

请重构 [模块]，目标是提升可读性和可维护性。

约束：
- 不改变外部行为
- 不改公共 API
- 不引入新依赖
- 每一步保持测试可通过
- 先给重构计划，再动手

代码审查

请审查当前 git diff。

重点关注：
- 逻辑漏洞
- 边界条件
- 错误处理
- 性能风险
- 测试缺口
- 破坏兼容性的变化

请按严重程度输出，不要直接修改代码。

解释代码

请解释这个模块的工作原理。

请包含：
1. 入口文件
2. 核心数据结构
3. 主要调用链
4. 关键边界条件
5. 修改这个模块时最容易踩的坑

结语：把 Codex 当作可配置的工程队友

Codex 的关键价值不是“替你写几行代码”，而是把开发流程中的阅读、定位、实现、测试、review、总结都串起来。用好它的核心方法很简单：

先给清楚上下文；复杂任务先计划；把团队规范写进 AGENTS.md；小步修改；每次都验证；对高风险操作设置权限边界。

当你按这种方式使用 Codex，它就不只是聊天框里的代码助手，而会更像一个能参与真实交付流程的工程队友。