实用的 Codex 提示词不需要很长。它需要消除会改变结果的歧义：你希望得到什么结果、哪些证据重要、哪些内容必须保持不变，以及你如何判断工作已经完成。
OpenAI 当前的提示词文档围绕四个有用要素——目标、上下文、输出和边界——来组织较大任务，并建议告诉 Codex 如何验证代码变更。本指南将这条建议转化为一个紧凑的工作流，你可以复用于缺陷修复、小型功能、测试、文档和只读排查。
从结果出发，而不是从脚本出发
告诉 Codex 最终应当达成什么状态。除非确切流程本身是必需项，否则不要逐步规定每一次搜索、文件读取或编辑。
不够好：
打开 components 文件夹，检查每个按钮，编辑一些文件，并改进可访问性。
更好：
为仅含图标的账户菜单按钮添加无障碍名称。保留其视觉外观和现有点击行为。运行范围最小的相关无障碍和组件测试，然后报告已更改的文件以及你无法运行的任何检查。
更好的版本明确了一个可观察的结果。它还能防止一个窄范围的任务悄悄扩大为全站审计。
只添加可能改变答案的上下文
有用的上下文能将 Codex 引向权威依据。根据任务不同，这些上下文可能包括：
- 确切的错误信息和可靠的复现步骤；
- 当前范围内的路由、组件、函数或测试；
- 必须遵循的项目规则或设计系统；
- 应作为模式参考的现有实现；
- 能证明成功的命令或用户流程。
不要将整个仓库粘贴到消息中。在 IDE 中，打开或附加最相关的文件。在 CLI 中，当路径重要时请明确写出路径。如果不知道正确的文件，请描述行为，并让 Codex 在编辑前先定位实现。
对于不熟悉的代码库，安全的首条消息是只读的：
定位渲染账单空状态的代码。不要修改文件。
说明请求流程，列出你检查过的文件，并指出
最小的可能改动点。将假设与仓库中发现的事实
分开标注。定义范围和边界
当某个看似合理的操作可能带来风险或额外工作时，边界很重要。将边界用于真实约束，而不是堆砌重复的警告。
常见边界包括：
- 保持公共 API 和已存储数据的结构不变；
- 保留用户已有的更改，不要重写无关文件；
- 不要添加依赖、迁移数据、部署或发送消息；
- 不要暴露机密、个人记录或生产数据；
- 在执行具有破坏性或对外可见的操作之前，先停下来询问。
要精确。“不要更改任何其他内容”在测试夹具或语言环境必须随实现一起更改时可能不现实。“将更改范围限制在账户菜单组件及其现有测试之内”为 Codex 提供了一个可以实际执行的边界。
让完成可验证
“修复它”并不能定义完成。一个强提示词应明确指出可观察的行为以及相关证据。
使用以下模式：
完成标准：
- 所报告的行为不再复现；
- 仅必要的实现和测试文件发生变更；
- 回归测试在修复前失败，并在修复后通过；
- 相关的 lint、类型检查和测试命令已实际运行；
- 最终报告将已通过、未通过和未运行的检查分开列出。要求采用项目实际提供的检查。Codex 应从 AGENTS.md、README.md、package 脚本、CI 配置或其他项目文件中发现命令，而不是自行编造。未运行的检查可以如实说明为局限；不得将其描述为已通过。
使用五部分提示词模板
对于大多数编程任务，以下结构已经足够：
结果：[描述可观察的结果。]
背景：[说明相关行为、文件、事实来源或复现步骤。]
范围：[说明哪些内容可以变更，哪些应保持在任务之外。]
约束：[保持兼容性、用户更改、安全性或设计规则。]
验证：[列出可提供证据的行为和项目检查。]对于单行改动，你不需要填写每个标题。保留仍能让工作可审查的最小版本即可。
根据任务调整模板
缺陷修复提示词
修复设置问题：保存时提示成功，但刷新后通知开关又回到之前的值。
在编辑前使用现有本地环境复现该问题。保持 API 结构和持久化格式不变。如果当前测试结构支持，添加一个针对性的回归测试。重新运行复现步骤和最小相关测试套件，然后报告原因、变更文件以及精确的检查结果。小型功能提示词
添加一个键盘快捷键，用于打开现有的搜索对话框。
复用当前的对话框和快捷键约定。不要添加第二个搜索实现或新的依赖。保持表单字段内的输入行为不变。更新相关帮助文本和测试。验证键盘可访问性、焦点位置以及现有的关闭行为。只读审查提示词
审查未提交的更改，检查正确性、回归、安全问题和缺失测试。不要编辑文件。按影响程度为发现的问题排序，注明受影响的文件和行号，解释失败场景，并在差异不支持任何问题时明确说明。当你需要的是分析而不是又一轮修改时，只读语言很重要。
一次性改进低质量提示词
在发送任务之前，先问五个问题：
- 我能否用一句话说明预期行为？
- 我是否找出了可能改变答案的证据或文件？
- 允许的范围是否足够清晰，以便发现不相关的工作？
- 重要的兼容性、安全性或审批边界是否明确？
- 我能否在不只依赖摘要的情况下验证完成情况？
如果其中任何一个答案是“否”，就补充那个缺失的细节。如果五个问题都清楚了，更多的文字可能只会增加噪音。
Codex 回复后，用具体的纠正来引导，而不是用一个更长的提示词重新开始。例如：“保留现有翻译键，移除不相关的重构，只重新运行组件测试。”这样可以在缩小结果范围的同时保留有用的上下文。
避免常见的提示词错误
- 成功标准模糊：“让它更好”没有指出应该改进什么。
- **缺少单一事实来源：**模型可能选择与项目规则相冲突的模式。
- 范围不加限制：“修复所有相关问题”会让评审和回滚变得困难。
- **流程过载：**规定每个琐碎步骤可能掩盖真正需求。
- **虚构验证：**指定不存在的命令会造成虚假信心。
- **指令冲突：**同时要求最小化补丁和大范围重构，会让优先级不明确。
- **轻信最终总结：**证据来自 diff、命令输出和观察到的行为，而不是自信的措辞。
若要了解完整的初学者工作流程，请继续阅读 Codex 入门指南。若要将验证变成可重复执行的评审流程，请参阅 Codex 变更评审指南。仓库级约定应维护在 AGENTS.md 文件中，而不是写在每个任务提示里。
常见问题
每个 Codex 提示词都需要完整模板吗？
不需要。一个微小的、易于理解的改动可能只需要一个结果和一条约束。当模糊性、风险、范围或验证变得重要时，再使用更多结构。
我应该明确告诉 Codex 要编辑哪些文件吗？
当文件具有权威性，或者范围已经明确时，可以指定文件。如果不确定，请描述所需行为，并让 Codex 先定位实现。错误的文件指示可能比一次简短的探索步骤更糟。
我应该让 Codex 先制定计划吗？
对于不熟悉、涉及多个文件或影响较大的工作，制定计划很有用。对于简单的文案修改，通常没有必要。当方案本身存在风险时，应在编辑前审查计划。
我可以在每个仓库中重复使用同一个提示词吗？
可以复用结构，但不要盲目照搬约束。命令、架构、权限和完成定义都应来自当前项目。