Appearance
用好 Codex 的实用技巧
本文整理自 OpenAI 官方文档：Best practices，适合刚开始用 Codex 的同学。不管你是用 CLI、VSCode 插件还是 Codex App，这些习惯能帮你更快拿到更好的结果。
核心思路：把 Codex 当成一个可以配置和持续改进的队友，而不是偶尔用一下的工具。
一、写清楚你要什么
Codex 不需要完美的提示词也能给出不错的结果，但交代清楚，结果会更稳——尤其是大型项目或重要任务。
一个好的提示词包含四件事：
- 目标：你想改什么，或者想做什么？
- 上下文：哪些文件、文件夹、报错信息和这个任务有关？可以用
@文件名的方式带入上下文。 - 约束：有什么规范、架构要求、或者不能碰的地方？
- 完成标准：什么情况下算做好了？比如测试通过、某个 bug 不再复现？
推理强度怎么选？
- 低：任务简单、范围清晰时
- 中 / 高：逻辑复杂、需要调试时
- 超高：长流程、多步骤、高推理量的任务
二、复杂任务先规划，再动手
任务模糊、步骤多的时候，先让 Codex 规划，比直接让它写代码效果好很多。
三种方式：
方式一：Plan 模式（最推荐）
用 /plan 命令或 Shift + Tab 切换到 Plan 模式。Codex 会先收集上下文、问几个关键问题，再开始实现，而不是直接动手乱改。
方式二：让 Codex 先问你问题
如果你自己思路还不清晰，直接告诉它："先问我问题，把我的想法梳理清楚，再开始写代码。" 它会帮你把模糊的想法变成具体的实现方向。
方式三：PLANS.md 执行计划（进阶）
对于超长流程任务，可以配合 PLANS.md 执行计划模板，让 Codex 跑几个小时的连续任务。详见官方 执行计划指南。
三、用 AGENTS.md 存下你的规则
每次都在提示词里重复同样的要求很麻烦。AGENTS.md 就是解决这个问题的——把你的规范写进去，Codex 每次启动都会自动读取。
把这些内容写进 AGENTS.md：
- 项目结构和重要目录说明
- 怎么运行项目
- 构建、测试、Lint 命令
- 代码规范和 PR 要求
- 哪些地方不能改、不能碰
- 什么算"做完了"，怎么验收
快速创建：在 CLI 里运行 /init，它会自动生成一个起始版本，你再按实际情况修改。
文件放在哪里：
~/.codex/AGENTS.md：个人全局默认设置- 项目根目录：团队共享规范
- 子目录里：只针对这个模块的特殊规则（越靠近当前目录的规则优先级越高）
实用建议：
- 宁可短而准，也不要长而空。简洁准确的 AGENTS.md 比洋洋洒洒的大文件有用。
- Codex 犯了同样的错误两次？让它做个复盘，然后把结论加进 AGENTS.md。
- 内容越来越多时，可以把详细内容拆成独立的
code_review.md、architecture.md等文件，在主文件里引用。
四、做完不算完，让它验证自己的工作
让 Codex 改完代码之后，顺手让它跑测试、检查规范、确认结果。这套流程它都能帮你做，但前提是你告诉它"什么叫做好了"。
可以要求它做的事：
- 给这次改动写或更新测试
- 跑相关测试套件
- 检查 Lint、格式化、类型检查
- 确认实际行为和需求一致
- Review diff，找潜在 bug 和回归风险
用 /review 命令来做代码审查：
- 对比 base 分支做 PR 式审查
- 审查未提交的改动
- 审查某个 commit
- 自定义审查指令
如果你有
code_review.md文件，在 AGENTS.md 里引用它，Codex 就会用里面的标准来做审查——对团队来说非常实用，保证每次审查风格一致。
五、用 MCP 接入外部信息
有时候 Codex 需要的信息不在代码库里，比如数据库里的数据、Jira 里的任务、实时日志。用 MCP 接入外部系统，比每次手动粘贴信息省事得多。
什么时候用 MCP？
- 需要的信息在代码库之外
- 数据会频繁变化
- 想让 Codex 直接调用某个工具，而不是靠你粘贴信息
怎么添加 MCP：在 Codex App 里进入 设置 → MCP servers；或者 CLI 里用 codex mcp add 命令。
建议：不要一口气接入所有工具。先从一两个能真正减少手动步骤的工具开始，稳定之后再扩展。
六、把重复的工作变成 Skill
同一类工作反复做、每次都要写很长的提示词？把它封装成一个 Skill，下次直接调用。
Skill 适合做什么：
- 日志归因分析
- 起草发布说明
- 按 checklist 做 PR 审查
- 制定迁移计划
- 标准化的 Debug 流程
- Incident 总结报告
怎么创建：用 $skill-creator skill 来生成第一版，再用 $skill-installer 安装到本地。
写 Skill 的关键：Skill 描述一定要说清楚"这个 Skill 做什么、什么时候用它"。每个 Skill 只做一件事，先把一个典型用例跑通，再考虑覆盖其他情况。
规则很简单：同样的提示词反复用超过两三次，就该变成 Skill 了。
七、稳定的流程可以设置自动化
某个工作流已经稳定可靠之后，可以设置定时自动运行，不需要手动触发。
自动化适合做什么：
- 定期总结最近的 commit
- 扫描代码中的潜在 bug
- 起草版本更新说明
- 检查 CI 失败情况
- 生成每日站会摘要
操作方法：在 Codex App 的 Automations 标签页里，选择项目、提示词、执行频率即可。
流程还不稳定就别急着自动化——先把它做成 Skill，反复跑通之后再设定自动化计划。
八、新手最容易踩的坑
| 常见错误 | 正确做法 |
|---|---|
| 每次提示词里都写同样的规则 | 把规则放进 AGENTS.md |
| 没告诉 Codex 怎么跑测试 | 在 AGENTS.md 里写清楚测试命令 |
| 多步骤任务不规划直接开始 | 用 Plan 模式先规划 |
| 一上来就给 Codex 最高权限 | 从默认权限开始，熟悉之后再放开 |
| 一个项目只开一个会话 | 一个任务开一个线程，避免上下文混乱 |
| 流程还不稳定就设成自动化 | 先手动跑通，变成 Skill 后再自动化 |
| 盯着每一步看 | 让 Codex 跑着，去做自己的工作 |