Codex 终极使用指南：解锁高效工作新姿势
Codex 终极使用指南：解锁高效工作新姿势
如果你把 Codex 当成一个“能写代码的聊天机器人”，其实只发挥了它一部分能力。更高效的用法是：把 Codex 当作能够理解项目、制定计划、修改代码、运行测试、分析错误并持续迭代的 AI 开发工程师。
结合你日常使用 Codex CLI / IDE、主要开发 React Native、Swift、TypeScript 和 NestJS，而且每天高强度使用 AI 编程的场景，这份指南不只讲提示词，还会覆盖工作流、项目规范、上下文管理、测试验证和成本控制。
一、先建立正确的使用方式
Claude Code: The Next Generation Developer Assistant | Matt Jones Technology
1. 从“给指令写代码”升级到“交付任务”
不要只说“帮我写一个登录页面”，而是描述业务目标、现有架构、交互规则、验收标准和禁止修改的范围。
Set up a context engineering flow in VS Code
2. 从“一次性生成”升级到“先规划再执行”
复杂需求先让 Codex 阅读代码并输出实施计划，确认后再修改。小任务则直接执行，避免每次都进入冗长的规划流程。
Cline CLI and the Rise of the Autonomous Platform Engineer | by Souvik Majumder | Medium
3. 从“代码写完了”升级到“验证通过了”
每个任务都要求检查差异、运行适用的测试、执行类型检查或构建，并明确说明哪些检查实际通过、哪些没有执行。
二、最值得掌握的 8 个技巧
技巧 1：给 Codex 建立长期记忆——AGENTS.md
这是最值得优先做的一件事。不要每次都重新解释项目技术栈、目录结构、代码规范和业务约束。
Codex 能读取项目中的 AGENTS.md 指令文件，并将其作为后续任务的持续上下文。官方提示指南也建议用它保存项目约定。
OpenAI
+1
建议分为两层：
全局规则
~/.codex/AGENTS.md
记录你长期使用的编码偏好、工作方式、测试要求和风险控制原则。
项目规则
项目根目录/AGENTS.md
记录该项目的架构、依赖、命名规范、业务规则、构建命令和禁止事项。
注意：~/.codex/AGENTS.md 并不是所有版本和配置下都自动生效的通用文件名；官方文档还涉及 Codex Home 中的指令文件和项目目录层级。请以当前版本实际加载的指令为准。
可以先让 Codex 执行：
请分析当前项目，并为 Codex 编写一份高质量的 AGENTS.md。
要求：
- 先阅读 package.json、项目目录、核心模块、路由、状态管理、API 封装和测试配置。
- 不要凭空推测项目架构；不确定的信息明确标注。
- 说明技术栈、目录职责、代码规范、错误处理、日志规范和测试命令。
- 写清楚修改现有功能时必须遵循的约束，避免擅自重构无关代码。
- 要求修改后运行适用的 lint、类型检查、测试或构建。
- 对数据库迁移、生产环境、密钥、依赖升级和破坏性操作设置明确的人工确认边界。
- 文件应简洁、具体、可执行，不要堆砌通用口号。
- 先给出拟定内容和依据，经我确认后再写入文件。
进阶技巧： 不要把所有内容塞进一份几百行的规则文件。全局规则负责通用原则，项目规则负责项目事实，复杂子模块再使用对应目录的局部规则。
技巧 2：复杂任务使用“先分析、再实施、最后验收”
对于 CMS 模块、React Native 页面重构、NestJS 权限系统等跨多个文件的任务，建议采用三阶段工作流。
阶段 A：分析
阅读现有实现，定位入口、数据流、依赖和潜在回归风险。只输出实施方案，不修改文件。
阶段 B：实施
按计划逐项修改，尽量保持变更集中，遇到与预期不符的架构时先重新评估。
阶段 C：验收
检查 Git diff、运行测试和构建、核对验收标准，并报告尚未验证的内容。
可直接使用的复杂任务提示词：
请为当前需求执行工程化交付。
第一阶段：分析
- 阅读相关代码，梳理现有架构和调用链。
- 列出涉及的文件、实现步骤、兼容性风险及测试方案。
- 当前阶段禁止修改文件。
第二阶段：实施
- 按确认的方案修改代码。
- 遵循现有架构和项目约定。
- 不修改与本需求无关的模块。
- 遇到重大假设不成立、数据结构需要变更或存在破坏性操作时暂停并询问。
第三阶段：验证
- 运行相关测试、类型检查、lint 或构建。
- 检查 diff，排查遗漏、重复逻辑和潜在回归。
- 不得把未执行的测试描述为通过。
最终输出：修改摘要、关键设计决策、变更文件、验证结果、剩余风险。
需要注意：并非所有任务都需要三阶段。 一行文案、简单 Bug、单个工具函数直接做通常更快。规划模式的价值在于减少方向错误，而不是增加仪式感。
技巧 3：用 Git 和 Worktree 降低 AI 并行开发风险
AI 写代码速度越快，越容易出现多个任务相互覆盖的问题。
推荐每个任务开始前确认工作区状态：
git status --short
git diff为高风险或独立任务创建单独分支，或者使用 Codex 支持的 worktree：
git worktree add ../project-feature -b feature/my-task
cd ../project-feature
codex也可以在支持该参数的 CLI 版本中直接使用：
codex --worktree具体参数以当前版本的 CLI 帮助为准。官方 CLI 文档提供了 worktree 相关选项。
ChatGPT Learn
+1
适用场景：
- 同时开发两个互不依赖的功能。
- 尝试不同的 UI 方案。
- 让一个任务负责实现，另一个独立审查。
- 对较大重构保留可随时回滚的基线。
不要让两个 Agent 同时修改同一个工作区中的同一批文件，然后指望 Git 自动帮你解决所有冲突。
技巧 4：不要用一个模型、一个思考强度处理所有工作
把任务按难度分级，比始终追求最强模型更实用。
| 任务 | 建议策略 |
|---|---|
| 文案、简单样式、明确的小 Bug | 快速执行 |
| 常规页面、API、表单 CRUD | 中等推理，边做边测 |
| 权限体系、数据库设计、复杂重构 | 先规划，再实施 |
| 疑难构建错误、并发问题、跨模块故障 | 加强推理，要求证据和复现步骤 |
| 生产数据迁移、安全敏感操作 | 严格限制权限，人工确认 |
模型名称、推理等级及其可用性会随账号和 CLI 版本变化。不要将网上某个固定模型参数照搬到自己的配置里。
真正应该优化的是：
单位时间内通过验收的任务数，而不是每小时生成的代码行数。
技巧 5：让 Codex 负责验证，而不是只负责实现
开发完成后，不要只问“你写好了吗”，要让它验证可观察的结果。
React Native 项目可以要求：
npx tsc --noEmit前提是项目已经正确配置 TypeScript。
NestJS 项目可以根据现有脚本执行：
npm run lint
npm test
npm run build如果项目没有相应脚本，应先检查 package.json，不要假定这些命令必然存在。
尤其是 iOS 项目，要区分三件事：
- TypeScript 或 Swift 代码检查通过。
- iOS 工程编译成功。
- 真机运行、交互及系统权限行为验证成功。
这三者不能相互替代。对于 UI 任务，还应让 Codex 检查加载、空数据、失败、重复提交、键盘遮挡和安全区域等边界情况。
技巧 6：用截图和实际错误信息代替模糊描述
遇到 UI 或构建问题时，提供可复现证据。
例如：
- UI：目标截图、实际截图、设备尺寸、预期交互。
- iOS：完整报错、Xcode 版本、部署目标、相关 Pod 或 Swift 配置。
- 后端：请求参数、响应、日志、复现步骤。
- 数据库：表结构、索引、约束、样例数据；敏感信息先脱敏。
提示词示例：
请根据我提供的实际错误排查问题。
- 先定位最早出现的根因错误，不要只处理最后一条连锁报错。
- 阅读相关配置与依赖版本，确认错误是否与环境兼容性有关。
- 优先提出最小修复方案，不要直接升级全部依赖或重写模块。
- 修改前说明可能影响的范围。
- 修复后执行能够复现或验证该问题的命令。
- 如果证据不足，明确指出还需要什么信息，不要把猜测当作结论。
技巧 7：重复工作做成 Skills，而不是反复复制提示词
如果你每周都让 Codex 做相似的事情，例如：
- React Native 页面开发与 UI 自检。
- NestJS 接口新增及权限审查。
- iOS 构建错误排查。
- CMS 模块开发前的架构审查。
- PR 差异检查与测试总结。
就值得将稳定流程封装成可复用的 Skill。
一个简单的目录示例：
.codex/
skills/
rn-feature/
SKILL.md
nestjs-api/
SKILL.md
ios-build-debug/
SKILL.md每个 Skill 应明确说明何时使用、需要读取哪些文件、执行哪些步骤，以及什么结果算通过。是否能够自动发现和调用该目录，要按当前 Codex 版本支持的 Skills 机制配置。
Skills 的设计理念是把重复的操作流程和配套资料封装成可复用能力，而不是把所有指令堆到一个超长的系统提示词里。
OpenAI API
技巧 8：自动化可以提高效率，但不要取消所有安全边界
Codex 能在授权范围内读取和修改文件、执行命令；具体能力受沙箱、审批模式、网络权限和当前运行环境限制。
OpenAI Help Center
+1
建议按风险分层：
- 低风险： 读取代码、搜索文件、生成测试、查看 diff，可尽量自动化。
- 中风险： 修改模块、安装依赖、运行构建，应关注变更和副作用。
- 高风险： 删除数据、执行生产迁移、修改线上配置、操作密钥或绕过权限，应设置明确的人工确认点。
不要为了减少点击就默认使用无沙箱、无审批的执行方式。自动化的目标应该是消除重复确认，而不是放弃对高影响操作的控制。
三、适合你的 Codex 高效开发工作流
对于你每天长时间使用 Codex 开发 React Native、Swift、TypeScript/NestJS 的情况，我建议采用下面这套流程。
每日开发闭环
开始前：检查项目状态
查看当前分支、未提交修改、构建状态，避免覆盖已有工作。
拆分任务：明确交付边界
每项任务尽量能独立修改、独立验证，避免一次改动整个模块。
执行任务：先规划高风险工作
简单任务直接执行；跨模块任务先分析依赖和实现方案。
验证结果：先解决根因
执行类型检查、测试、构建或实际页面验证。
结束任务：审查差异并提交
检查意外改动、业务逻辑、敏感信息和测试结果，确认后提交 Git。
沉淀经验：更新项目规则
将反复出现的错误、确定的架构约定和验证命令写入项目文档或 Skill。
四、可以直接使用的提示词库
选择场景，复制对应提示词到 Codex。
需求开发适合新功能、页面与 APIBug 排查适合错误日志、异常行为和构建失败UI 优化适合 React Native 页面和交互改进代码审查适合功能完成后的独立检查重构评估适合模块拆分和架构调整
请先阅读相关代码，理解现有架构和业务约束，然后实现这个需求。保持改动范围最小，不重构无关代码。根据现有项目约定处理加载、错误、空数据和重复提交等状态。完成后运行适用的检查和测试，审查 diff，并报告变更文件、验证结果和剩余风险。
复制提示词
五、哪些做法最容易浪费 Codex 的额度和时间？
| 低效做法 | 更好的做法 |
|---|---|
| 每次重复介绍项目背景 | 使用项目规则文件 |
| 一次要求重构整个项目 | 按模块拆分并逐步验证 |
| 看到报错就升级所有依赖 | 先定位根因，再最小修复 |
| 不检查 diff 就继续下一项 | 每个任务结束后审查变更 |
| 一个会话混合很多无关任务 | 按任务或模块分开上下文 |
| 不断让 AI 重试同一个失败命令 | 补充新证据，改变排查方向 |
| 所有任务都使用最高推理强度 | 根据难度选择模型和推理等级 |
| 让 AI 自己宣布“测试通过” | 要求给出实际执行的命令和结果 |
这里最关键的一点是：不要把 AI 反复犯错的成本转嫁给更多提示词。 如果同一种错误连续出现，应该检查项目规则、任务描述、环境约束和验证流程，而不是单纯增加提示词长度。
六、建议你现在就做的 5 件事
实施清单
0/5 已完成
建立项目 AGENTS.md
沉淀架构、编码规范、业务约束与验证命令。
固定任务验收标准
每项任务都有明确的完成条件和测试要求。
为大任务启用 Git 隔离
利用分支或 worktree 防止并行开发互相干扰。
建立三个高频 Skill
优先覆盖 RN 页面、NestJS API、iOS 构建排错。
形成每日审查习惯
检查 diff、测试结果、风险和未完成事项。
复制清单
七、官方资料建议收藏
- Codex 官方文档：了解 CLI、配置、权限和工作流。
- Codex IDE 使用指南：了解编辑器中的 Codex 工作方式。
- Codex CLI 官方 GitHub：查看最新代码、版本说明和使用方法。
- Codex 官方提示词指南：了解代码任务的指令设计、上下文和 Agent 工作流。
官方功能和命令可能随版本更新，实际使用时以当前安装版本的帮助信息及官方文档为准。
ChatGPT Learn
+2
最后给你的建议： 以你现在的开发强度，最值得投入的不是继续收集几十条所谓的“万能提示词”，而是建立一套可以反复复用的开发体系：项目规则、任务模板、隔离工作区、自动化验证和独立审查。这样才能真正减少返工，并让 Codex 从单次代码生成工具变成稳定的开发工作流。