适合已经在真实代码库中使用 Codex，但经常遇到“方向大致正确，结果却总差一点”的开发者。核心结论只有一句：好的任务提示词不是把操作步骤写得越细越好，而是说清目标、上下文、边界和验收。
为什么“帮我优化一下”容易返工
「帮我优化这个页面」对人类同事尚且不够清楚，对需要读代码、调工具和执行测试的编程代理更是如此。“优化”可以指性能、样式、可访问性或可维护性；“这个页面”也没有指明入口、状态和不能破坏的行为。
于是 Codex 只能自行补全缺失的决策。它可能修了正确的文件，却改了不应改的交互；也可能交付了代码，却没有证明问题真的解决。这不是“提示词不够长”，而是任务合同不完整。
第一段：用可观察的结果描述目标
先写用户或系统最后应该看到什么，不要一上来就指定某个函数怎么改。例如：
修复订单列表的重复提交问题。用户连续点击“保存”时，客户端只发出一次有效请求，按钮在请求结束前显示加载状态，失败后可以重试。
这种写法给出了可观察行为，同时保留了实现空间。只有当某条技术路径是项目的硬性要求时，才需要把它写进目标。
第二段：只提供会影响决策的上下文
上下文不是把整个项目介绍复制一遍，而是给出能缩小搜索范围的线索：问题入口、已知现象、关联模块、现有测试以及能复现问题的最小条件。
比如可以写：“入口在订单编辑页；问题只在网络延迟较高时出现；服务端已有幂等键，请先确认前端事件链路。”这三句比一大段泛化背景更有用。如果你不确定根因，就把现象写成事实，把推测明确标为假设，不要将猜测包装成结论。
第三段：说清边界和授权
真实开发中，“不做什么”往往与“做什么”同样重要。请指出可以修改的范围，以及哪些动作需要停下来确认。
一个简洁边界可以是：“可修改该页面及其直接依赖，并运行现有前端测试；不改 API 协议、不升级依赖、不删除用户数据。如果必须超出范围，先说明原因和最小扩展方案。”
边界不必反复强调。OpenAI 官方文档建议将授权规则放在一个明确位置，同一条指令只说一次。重复堆叠“先问我”、“不要改”反而会让代理在安全、预期内的动作上频繁停顿。
第四段：把“完成”改写成验收条件
不要只说“改完告诉我”。列出可以独立检查的证据：哪个复现步骤应该消失，哪些测试应通过，哪些既有行为必须保留，最终报告需要包含什么。
例如：“用测试覆盖连续点击和请求失败两条路径；运行该模块现有测试；最终说明根因、改动文件、测试结果和尚未覆盖的风险。”测试通过不等于线上已验证，不要要求 Codex 将未观察的环境说成已确认。
可直接复制的四段式模板
```text 目标： 用可观察的行为描述最终结果，不预设不必要的实现方法。
上下文： 给出入口、复现条件、相关模块和已知证据；将事实与假设分开。
边界： 说明可改范围、必须保留的行为，以及需要先确认的外部或破坏性动作。
验收： 列出必须通过的检查、需要保留的证据和最终报告的内容。 ```
三个容易忽略的注意点
第一，不要把你的初步诊断当成实现指令。如果你只是怀疑缓存有问题，请要求“先验证缓存假设”，而不是“删掉缓存”。
第二，不要用“尽量”、“适当”、“优雅”代替可检查的条件。如果必须保持接口兼容，就直接写“不改变现有请求和响应字段”。
第三，提示词是任务起点，不是一次性真理。当 Codex 在代码中找到与假设冲突的证据时，应允许它调整方案，但不应默默改变目标或扩大范围。
当你把这四段写清楚，Codex 获得的不是一份僵硬的逐行指令，而是一份可执行、可调整、又可验收的任务合同。这才是减少返工的真正杠杆。