很多人第一次让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修改代码后如果只看到编译通过就可能宣布任务完成。但真正的验收标准可能还包括页面行为、测试结果和修改范围。可以这样写完成条件能稳定复现原问题修改后Token过期只跳转一次相关单元测试通过TypeScript类型检查通过输出根因、修改文件和验证命令不存在无关Diff。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永远不犯错但能够明显缩小它的自由猜测空间让每次修改更容易审查、验证和回退。提示词真正的价值不是写得更像命令而是把一个模糊需求变成一份可以执行和验收的工程任务单。