刚开始使用 Codex 时，我总觉得提示词应该写得越详细越好：项目背景多讲一点，技术栈多列一点，步骤再拆细一点，结果应该就会更可靠。真正用过一段时间后，我发现最容易影响结果的往往不是背景不够多，而是任务没有明确的目标和终点。
「帮我优化一下这段代码」「修一下这个 Bug」都能让 Codex 开始工作，但“优化”可以指性能、结构或命名，“修好”也可能只是让报错暂时消失。如果我自己都说不清怎样才算完成，最后就只能凭感觉判断代码改得好不好。
与其反复补充提示词，不如先写清修改后应该出现什么结果，以及怎样证明这个结果已经实现。
问题不一定出在代码，而是任务没有终点
Codex 不只是回答代码问题，它还可以读取项目、修改文件并运行现有工具。执行能力越强，模糊要求带来的影响也越大：它可能选择一条合理但并非我想要的实现路径，也可能顺手扩大修改范围。
OpenAI 的 Codex 最佳实践建议在任务中提供目标、上下文、约束和完成条件。这并不是要求每次都写套一份复杂模板，而是在减少可能让 Codex 猜测的内容。
例如，一个待办应用出现了常见问题：勾选任务后，页面显示“已完成”；刷新页面，状态又恢复成“未完成”。
不能只说 ”修复一下待办事项的状态问题“，这样的话 Codex 还需要自己判断：状态有没有写入存储、页面初始化时有没有正确读取、是否允许修改数据结构、修复后应该检查哪些旧功能。
把「修好」改写成可观察的结果
现在遇到这类问题，可以这样写Prompt：
这段任务的重点不是更长，而是把一个模糊动作拆成了可以检查的一套流程。
明确的目标告诉 Codex 应该改变什么：
- 开始前要求它先确认根因，避免只修表面；
- 约束限制无关改动；
- 完成标准则判断它什么时候可以停止。
这样的话实现方式仍然可以由 Codex 判断，但“做完”的含义不再由它猜。
核心结论：真正有用的是诊断、边界和验收；原因不明确时，先诊断再修改；提前说明不能破坏什么，同时检查结果、回归和工程状态。
更可靠的检查通常有三层：
- 需求结果：原问题不再出现；
- 回归范围：相关旧功能保持正常；
- 工程检查：已有测试、类型检查或构建通过。
如果缺少环境或项目里没有相应测试，就应明确写出哪些部分没有验证。未验证并不可怕，把预期结果写成已经验证才危险。
问题通常不是提示词不够华丽，而是没有定义清楚一套流程。
对我来说，这也是 Codex 从“代码生成工具”变成“开发协作者”的分界线：它不只负责写出修改，我也提前提供一套双方都能使用的完成标准。这样即使第一次结果不理想，后续也能明确判断是根因找错、修改越界，还是验收遗漏，而不是继续盲目补充提示词。