精选推荐

很多人在使用 Codex时，仍然沿用过去与 ChatGPT对话的方式，只输入一句“帮我修改这个项目”或“帮我修复这个 Bug”。Codex通常会开始执行，但结果未必稳定：它可能改动不该修改的文件，只处理表面问题，没有运行测试，甚至在任务尚未真正完成时就停止。

OpenAI最近更新了 Codex相关提示词指南，并给出了一套更适合编程代理的写法。一个完整的 Codex提示词通常包含四个部分：Goal、Context、Constraints和 Done when，也就是目标、上下文、限制条件和完成标准。这套方法不复杂，却非常适合 Codex这类能够读取文件、修改代码、运行命令并验证结果的 AI编程代理。

Goal：先告诉 Codex最终要实现什么

Goal是任务目标，也就是希望 Codex最终完成什么工作。很多提示词只描述了模糊动作，例如“优化一下这个网站”。但对 Codex来说，“优化”可能意味着提升加载速度、调整页面布局、重构代码结构或改善 SEO，范围过大时就容易跑偏。

更好的写法是：“优化网站首页在手机端的显示效果，解决标题溢出、按钮过宽和卡片间距不一致的问题，桌面端布局保持不变。”这句话明确说明了修改对象、现有问题和期望结果，Codex更容易把任务范围控制在正确位置。

描述目标时，可以写清楚要创建什么、要修改什么、要解决什么问题、为什么需要这项修改，以及用户最终应该看到什么变化。例如：“修复用户登录后刷新页面会被退出的问题，并确保登录状态可以在浏览器刷新后继续保留。”这比只说“修复登录 Bug”更容易获得稳定结果。

Context：把相关文件和信息指给 Codex

Context是 Codex完成任务时需要参考的上下文。Codex可以主动搜索代码库，但如果已经知道问题可能出现在哪里，最好直接提供相关文件、目录、错误日志或参考页面。

例如，可以写：“重点检查 src/components/Header.tsx、src/styles/mobile.css和首页布局组件。”也可以补充错误信息：“用户提交表单后出现500错误，终端日志显示 Cannot read properties of undefined。请检查表单提交接口和数据库写入逻辑。”

在 Codex IDE扩展中，还可以直接引用当前打开的文件或选中的代码。对于包含多个模块的大型项目，准确的上下文能够明显减少 Codex搜索无关文件的时间。除了代码文件，上下文还可以包括项目说明文档、数据库结构、API文档、截图、错误日志、设计稿、已有页面、希望模仿的组件，以及 GitHub Issue或需求说明。

Constraints：明确哪些内容不能随便改

Constraints是限制条件，也是使用 Codex时最容易被忽略的一部分。Codex具备较强的自主执行能力，如果没有明确限制，它可能为了完成任务而重构大量代码、安装新依赖，或者修改与当前目标无关的功能。

因此，可以直接写明：“不要修改数据库结构，不要更换现有技术框架，不要删除已有功能，不要引入新的第三方依赖，保持现有 API地址和字段名称不变，只修改与本次问题直接相关的文件。”限制条件并不是越多越好，而是要指出那些一旦被改动，就可能引发额外问题的关键内容。

例如：“修复移动端菜单，但保留当前桌面导航布局，不要修改登录逻辑，也不要安装新的 UI组件库。”如果项目有固定规范，也可以告诉 Codex：“使用项目现有的 TypeScript、Tailwind CSS和组件结构，不要添加内联样式。”这些要求能让 Codex的修改更贴合现有项目，而不是另起一套实现方式。

Done when：告诉 Codex怎样才算真正完成

Done when，也就是完成标准，是这套提示词方法中最关键的部分之一。传统 Prompt往往只告诉 AI要做什么，却没有说明如何判断任务是否已经完成。

对于 Codex来说，完成标准可以包括：指定功能能够正常使用，原来的错误无法再次复现，测试全部通过，页面在指定尺寸下显示正常，没有新增错误或警告，代码通过格式检查，输出了指定文件，并提供修改说明。

例如，可以这样写：

登录后刷新页面不会退出、登录状态过期后会自动跳转到登录页、现有登录测试全部通过、不影响注册和退出登录功能和最后说明修改了哪些文件以及如何验证。

这会让 Codex不只是修改代码，还会主动运行测试、检查相关功能，并确认改动是否真正生效。OpenAI的 Codex指南也反复强调，应在提示词中说明如何验证结果，例如运行哪些测试、检查什么行为，以及怎样确认 Bug已经无法复现。

复杂任务先使用 /plan

对于涉及多个文件、代码重构、系统设计或较大功能开发的任务，可以先使用 /plan，让 Codex先检查项目并提出执行计划，而不是马上修改代码。

例如：

/plan

目标：为网站增加用户收藏文章功能。

上下文：项目使用 Next.js、Prisma 和 PostgreSQL，登录功能已经完成。

限制：不要修改现有用户表字段，不要更换认证方案。

完成标准：用户可以收藏和取消收藏文章，并在个人中心查看收藏列表。相关接口和核心逻辑需要有测试。

Codex会先分析可能涉及的数据表、接口、页面和组件，并给出执行步骤。开发者可以先检查方案，再让它继续操作。这种方式适合新增完整功能、大规模重构、数据库修改、跨多个目录的 Bug，以及涉及部署和环境配置的任务。对于只改按钮文字、调整间距或修复明显语法错误的小任务，则没有必要每次都进入规划模式。

不要把 Codex当成只会回答问题的聊天机器人

普通对话模型更偏向给出答案，而 Codex的特点是能够真正操作项目。它可以搜索文件、阅读代码、修改文件、运行终端命令、执行测试、查看错误、根据结果继续修改，并检查代码差异。

因此，给 Codex写提示词时，最好不要只要求它“告诉我怎么修”，而是直接说明希望它完成什么工作。与其问“这个错误怎么解决”，不如写：“定位并修复这个错误。先检查相关代码和日志，修改后运行测试，确认错误不再出现，最后总结原因和修改内容。”如果只希望得到分析而不希望它修改文件，也要明确说明：“只分析问题并给出修改建议，暂时不要更改任何文件。”

一个可以直接复制的 Codex提示词模板

下面这套模板适合大多数 Codex任务：

目标：
我希望实现或修复【具体目标】。

上下文：
相关文件、目录、错误信息或参考资料包括【相关内容】。

限制条件：
- 保留【不能修改的内容】；
- 不要【禁止操作】；
- 使用项目现有的【框架、规范或组件】；
- 只修改与当前任务相关的内容。

完成标准：
- 【功能或问题得到解决】；
- 【需要运行的测试或检查】通过；
- 不影响【相关已有功能】；
- 最后总结修改文件、实现方式和验证结果。

例如：

目标：
修复文章详情页图片加载失败的问题。

上下文：
重点检查文章内容渲染组件、图片 URL 处理逻辑和 Next.js 图片配置。问题出现在文章更换路径后，旧图片地址无法显示。

限制条件：
- 不修改文章正文；
- 不删除已有图片；
- 不更换当前图片存储方案；
- 不影响其他文章页面。

完成标准：
- 更换路径后的文章图片可以正常显示；
- 原路径文章不受影响；
- 运行项目现有检查；
- 最后说明问题原因、修改文件和验证方法。

提示词不必很长，但必须可验证

OpenAI最新的 Codex实操指南并不要求用户编写复杂的“超级提示词”。对于简单且范围明确的任务，一两句话也可以让 Codex完成工作；项目越大、风险越高，才越需要补充上下文、限制条件和完成标准。

真正关键的不是给 Codex安排一个“资深工程师”角色，也不是要求它反复“一步一步思考”，而是让它清楚知道：你要什么结果、应该参考什么、哪些内容不能动，以及怎样才算完成。

这也是 Codex提示词与普通聊天提示词最大的区别。普通 Prompt的重点是获得一个好答案，而 Codex Prompt的重点，是让 AI在真实项目中可靠地完成一项工作。与其寻找复杂的“万能提示词”，不如把任务写成一份清楚、可执行、可验证的工作要求。