ChatGPT、Codex实战：提示词怎么写才不会改错文件？四段式任务单教程

很多人第一次让Codex修改项目时，只会输入一句：

帮我修复登录Bug。

这句话对人类开发者来说也许够用，因为人会主动追问需求、确认目录、检查影响范围。但对Agent来说，它可能意味着：搜索整个仓库、修改多个模块、顺便重构相关代码，再运行一组自己认为合适的测试。

最后Bug可能修好了，却多改了十几个文件。

真正的问题不是Codex不会写代码，而是任务没有说明：

到底要完成什么、应该看哪些信息、哪些内容不能改，以及怎样才算完成。

OpenAI给出的Codex最佳实践建议，任务提示中至少包含目标、上下文、约束和完成标准。本文把它整理成一个更适合日常开发的“四段式任务单”。

一、为什么一句话任务容易改错文件？

假设项目中同时存在：

src/pages/login
src/services/auth
src/store/user
server/routes/auth
server/services/token

你只告诉Codex“修复登录失败”，它并不知道问题属于：

• 前端表单；

• 请求封装；

• 状态管理；

• 后端接口；

• Token刷新；

• 环境配置。

为了完成目标，它可能扩大搜索范围，并根据当前看到的信息自行判断应该改哪些文件。

这种主动探索是Agent的优势，但如果任务边界不清，也会变成风险。

所以提示词不能只描述问题，还要给Agent一张可以执行的任务单。

二、第一段：Goal——明确最终目标

Goal负责说明这次任务到底要产生什么结果。

错误写法：

优化一下登录功能。

这句话没有明确问题，也没有明确结果。

更好的写法：

修复用户Token过期后，登录页面反复跳转的问题。修复后，用户应被正常跳转到登录页，并且页面只跳转一次。

目标最好满足三个条件：

• 问题具体；

• 结果可观察；

• 范围不过度开放。

OpenAI在Codex目标任务指南中强调，一个好的目标应该明确要实现什么、不应该改变什么，以及如何验证完成，而不是把整个开放式需求一次交给Agent。

三、第二段：Context——告诉Codex从哪里开始看

Context负责提供任务所需的背景。

例如：

问题发生在前端登录流程。
重点检查src/services/auth.ts、src/store/user.ts和路由守卫。
后端接口已经确认正常，不需要修改服务端代码。
错误通常在Token过期后刷新页面时出现。

这段信息解决三个问题：

• 先看哪里；

• 哪些结论已经确认；

• 哪些方向不用重复排查。

Context并不是越多越好。

不要把整个项目介绍、所有历史Bug和几十页需求文档全部塞进去。真正有价值的是与当前任务直接相关的信息。

可以理解成：

Goal说明终点，Context说明起点。

四、第三段：Constraints——限制允许修改的范围

Constraints是防止Codex改错文件的关键部分。

可以明确写：

只允许修改src/services/auth.ts、src/store/user.ts和相关测试。
不修改后端代码。
不更换状态管理方案。
不新增第三方依赖。
不顺便重构登录页面。
如果判断必须修改其他文件，先说明原因，等待确认。

最后一句尤其重要。

它不是完全禁止Codex发现其他问题，而是要求Agent在扩大修改范围前暂停。

对于复杂项目，还可以加入数量限制：

修改文件尽量不超过4个；如果预计超过4个，先提交修改计划。

这样能防止一个小Bug逐渐变成大规模重构。

五、第四段：Done——定义怎样才算完成

很多任务失控，是因为没有明确完成条件。

Codex修改代码后，如果只看到编译通过，就可能宣布任务完成。但真正的验收标准可能还包括页面行为、测试结果和修改范围。

可以这样写：

完成条件：

Codex支持对当前工作区未提交变更、目标分支差异等内容执行独立Review，因此完成后还可以要求它再检查一次Diff，确认是否存在无关修改。

Done解决的是：

Agent什么时候可以停止？

没有停止标准，Agent容易继续优化；有了停止标准，它才能围绕交付结果工作。

六、可直接复制的四段式模板

日常开发可以直接使用下面这份模板：

Goal：
修复【具体问题】。
修复后应该表现为【可观察结果】。

Context：
问题发生在【模块或页面】。
重点检查【目录、文件或函数】。
已经确认【已知事实】。
暂时不需要检查【排除方向】。

Constraints：
只允许修改【文件或目录】。
禁止修改【明确范围】。
不新增依赖，不进行无关重构。
如果需要扩大修改范围，先说明原因和计划，等待确认。

Done：
能够稳定复现原问题。
修改后重新执行相同流程并通过。
运行【测试、构建或检查命令】。
输出根因、修改文件、验证结果和剩余风险。
确认不存在无关Diff。

这个模板不是为了让提示词变长，而是让任务结构更清楚。

七、实战示例：修复保存按钮无响应

普通提示词：

保存按钮没反应，帮我修一下。

四段式写法：

Goal：
修复用户编辑个人资料后，点击“保存”按钮没有任何反应的问题。
修复后，点击按钮应正常发送请求，并显示成功或失败提示。

Context：
问题发生在前端个人资料页面。
重点检查：
– src/pages/profile/ProfileForm.tsx
– src/services/profile.ts
– 相关表单测试

后端接口已经通过Postman验证，不需要修改服务端。

Constraints：
只修改个人资料页面、请求封装和相关测试。
不修改全局表单组件。
不更换请求库。
不新增依赖。
如果发现问题来自其他模块，先汇报，不直接修改。

Done：
先复现按钮无响应问题。
修复后重新执行保存流程。
检查请求是否发送、状态是否更新、提示是否出现。
运行相关测试和类型检查。
输出根因、修改文件、验证结果和剩余风险。

这份任务单将范围限制在几个明确文件，同时保留了必要的排查空间。

八、修改前先让Codex汇报计划

对于陌生项目或风险较高的修改，可以把任务分成两步。

第一步只分析：

先不要修改代码。请说明问题可能原因、计划检查的文件、预计修改范围和验证方式。

等它给出计划后，再回复：

按这个计划执行，但不要超出已经列出的文件。需要扩大范围时先暂停。

这种方式能提前发现两个问题：

• Codex是否理解了任务；

• 它预计修改的范围是否合理。

对于大型或持续目标，Codex也提供了目标与计划相关的工作方式，但目标仍然应该小于一个开放式任务列表，并具有明确的边界和验证条件。

九、长期规则不要每次写进提示词

四段式任务单适合描述当前任务，但有些规则每次都适用，例如：

• 禁止修改生产配置；

• 不允许删除测试；

• 公共接口变化必须说明兼容性；

• 修改后必须运行特定测试；

• 不新增未经批准的依赖。

这些长期规则更适合写进AGENTS.md。

Codex会在开始任务前读取适用范围内的AGENTS.md，并根据项目目录组合相关指导。官方也建议保持文件简洁，只保存真正需要长期复用的项目规则。

这样可以形成清晰分工：

AGENTS.md保存长期规则；
四段式任务单描述当前任务。

十、常见的四种提示词错误

只写目标，不写范围

重构用户模块。

问题：Codex不知道应该修改多少内容。

只写文件，不写结果

修改auth.ts。

问题：Agent不知道修改后要达到什么行为。

只写禁止事项，不写验证

不要改其他文件。

问题：即使修改范围正确，也无法判断结果是否有效。

一开始就让它自由优化

修Bug，并把相关代码全部优化一下。

问题：修复、重构和优化混成一个任务，Diff很难审查。

更稳妥的方法是先修Bug，再把重构作为独立任务。

结语

Codex改错文件，很多时候不是模型能力问题，而是任务边界没有写清。

一个可靠的开发任务应该包含：

Goal：要实现什么；
Context：从哪里开始；
Constraints：哪些不能动；
Done：怎样才算完成。

对于复杂任务，再增加一步：

修改前先汇报计划。

这套方法不会保证Agent永远不犯错，但能够明显缩小它的自由猜测空间，让每次修改更容易审查、验证和回退。

提示词真正的价值，不是写得更像命令，而是把一个模糊需求变成一份可以执行和验收的工程任务单。