给 Codex 写任务的技巧

这篇适合谁

适合已经装好 Codex、想让每次任务都更有效的开发者。读完，你能写出带复现步骤的 Bug 修复提示、一个代码审查提示，以及一个先规划再修改的提示，并知道每种场景该用哪个功能。

好的 Codex 提示包含什么

官方把提示词描述为一个问题、一条指令或一个目标。你可以用自己的话开始，看结果，再用后续消息把它调整到位^[1]。任务较大或较重要时，提示可以包含四部分：目标、上下文、输出和边界。只写有用的部分即可^[1]。

对 Codex 而言，好的提示要做四件事：说明你要的行为；指向相关的代码或复现步骤；保留重要的约束；说明怎样验证修改^[1]。描述结果比列步骤更有用，只有过程本身重要时才描述过程^[1]。

边界是少数几条指令，用来防止额外的工作或意外操作，比如要求保持已批准的数字不变^[1]。

给够上下文

IDE 扩展会把你打开的文件自动当作上下文。在 CLI 里则要自己指明路径：用 @ 触发路径自动补全，或用 /mention 附加某个文件^[1]。在 IDE 里，可以选中关键代码行，然后从命令面板选择「Add to Codex Thread」把它们加进上下文^[1]。

要写测试时，直接指向一个有名字的函数。例如：Add a test for the invert_list function in @transform.ts. Cover the happy path plus edge cases^[1]。

先规划，再设目标

多步骤任务，在应用的输入框里输入 /plan，让 Codex 先调查并提出方案，再开始改代码。Goal 模式可用时，可以在规划之后用 /goal 设置一个持久目标^[1]。

Codex 在沙箱里运行本地命令，沙箱会限制文件和网络访问。如果任务必须越过这个边界，Codex 会先按你的审批策略处理，再继续^[1]。写边界时要留意这一点，别让提示要求审批策略会拦下的操作。

一个 Bug 修复提示

Bug 修复的流程是：在仓库根目录运行 codex，再给出复现步骤和约束。下面是一个示例提示^[1]：

Bug: Clicking "Save" on the settings screen sometimes shows "Saved" but doesn't persist the change.
Repro:
1) Start the app: npm run dev
2) Go to /settings
3) Toggle "Enable alerts"
4) Click Save
5) Refresh the page: the toggle resets
Constraints:
- Do not change the API shape.
- Keep the fix minimal and add a regression test if feasible.
Start by reproducing the bug locally, then propose a patch and run checks.

复现步骤和约束比笼统的描述更重要。Codex 会自己补上命令输出、它发现的调用点，以及运行中出现的堆栈信息^[1]。修复之后，让 Codex 运行 lint 和最小的相关测试集，并报告命令和结果^[1]。

工作途中插话：steer 与 queue

在 CLI 里，Codex 工作时按 Enter，可以把消息插入当前这一轮，用来改方向或补充漏掉的细节。按 Tab 则把消息排到下一轮，适合等当前工作结束再处理的后续请求^[1]。

提交前做代码审查

在 CLI 里运行 /review，就能审查当前工作区的改动。也可以在后面加上关注点，比如边界情况和安全问题^[1]。应用修改之后，再运行一次 /review，确认问题已经解决^[1]。

在 GitHub 上，要先为仓库开启 Codex Code review。之后在 PR 里评论 @codex review 即可，还可以附加关注的方向，比如安全漏洞^[1]。

解释代码与更新文档

要熟悉一个陌生的服务，可以让 Codex 概括每个模块的职责，说明数据在哪里校验，并列出修改时要注意的一两个坑^[1]。改文档时，把范围和要做的检查说清楚，比如验证所有链接有效；然后审阅草稿，继续迭代^[1]。

什么时候用 Codex

当你希望 ChatGPT 处理代码、代码库或开发者工具时，用 Codex。它在 IDE 或 CLI 中运行，并且在沙箱里执行本地命令，所以它的提示要包含能让它找到代码的信息^[1]。

写提示前的检查清单

发出任务之前，可以对照下面几点过一遍：

• 结果说清楚了吗？先写想要什么，再写怎么做。只有过程本身重要时才列步骤^[1]。
• 相关代码指明了吗？CLI 中用 @ 或 /mention 指向文件；IDE 中打开相关文件，或选中关键代码行^[1]。
• Bug 类任务有复现步骤吗？复现步骤和约束比泛泛的描述更有用^[1]。
• 约束写全了吗？比如不改 API 形状、修改尽量小，这些要直接写进提示里^[1]。
• 怎么验证？要求 Codex 运行检查并报告命令和结果，修改后再跑一遍复现步骤或 /review^[1]。

多步任务怎么拆

对于跨多个文件、需要先想清楚的改动，先用 /plan，让 Codex 先调查、提方案，确认方案后再动手。方案稳定后，如果任务还要持续推进，再用 /goal 设定持久目标^[1]。先看方案再进入修改，能更早发现方向偏差。

工作途中要改方向，用 Enter 插入当前这一轮；要补充后续请求，用 Tab 排到下一轮。两种方式的区别在于，前者影响正在进行的工作，后者等它结束再处理^[1]。

遇到问题时怎么办

• 在 GitHub 上 @codex review 没有反应，先确认仓库已经开启 Codex Code review^[1]。
• Codex 跑偏了，不要急着重开。工作途中用 Enter 插入修正，或用 Tab 排到下一轮^[1]。
• 命令在沙箱里被拦住，通常是因为文件或网络访问超出了沙箱边界。越界的操作要走审批流程，而不是绕过它^[1]。
• 改完之后不放心，就让 Codex 按复现步骤重新验证，再运行 lint 和最小的相关测试^[1]。

下一步

官方的 Codex 提示示例还包括截图转原型、云端委派等更多工作流，可以在官方文档中查看^[1]。