“优化一下这个页面”或者“修复登录问题”足以开启讨论，却不足以定义一次可靠的工程交付。Codex 可以主动探索仓库，但它无法从代码中推断产品取舍、风险偏好和真正的验收标准。高质量提示词的作用不是规定每一行实现，而是给代理一个清晰的问题边界，以及证明任务已经完成的方法。
用四个部分定义任务
一个稳定的起点是 Goal、Context、Constraints 和 Done when 四段式结构：
- Goal 描述要改变的用户行为或系统结果，而不是指定某个函数必须怎样改；
- Context 指向相关目录、错误信息、复现步骤、设计稿或已有实现；
- Constraints 固定不能破坏的接口、依赖、安全边界和改动范围；
- Done when 列出测试、构建、页面行为或性能指标等可验证结果。
例如，要求 Codex 给 Hugo 博客增加文章，可以这样写：
Goal:
新增三篇可直接发布的中文文章，并让它们出现在首页和分类页。
Context:
站点配置在 hugo.toml，文章放在 content/posts，public 已被 Git 跟踪。
Constraints:
不要修改 PaperMod 子模块；沿用 TOML Front Matter；保留现有改动。
Done when:
hugo --minify 成功，文章页、RSS、标签页和站点地图都包含新 URL。
这份提示没有替 Codex 决定具体模板实现，却明确了探索范围和交付证据。代理仍可以从仓库中发现真实结构，而不是被一份可能过时的文件清单绑住。
复杂任务先规划
当需求涉及多个模块、存在兼容风险，或者验收标准尚不清楚时，先进入规划阶段。支持的 Codex 界面可以使用 /plan；也可以直接要求它先阅读仓库、提出问题并给出实施方案，在确认前不要编辑文件。
规划的核心不是生成一份很长的待办清单，而是消除会改变实现方向的未知项。目录位置、依赖版本和现有测试属于可发现事实，应先从仓库查证；发布策略、兼容范围和产品优先级属于偏好，才需要向人提问。一份可执行计划还应说明数据如何流动、失败时如何表现、哪些接口保持不变，以及每个风险如何验证。
小而明确的改动则不必为了形式强行规划。修正文案、调整单个配置值等任务，在边界和验证都清楚时可以直接执行。判断依据是错误决策的代价，而不是文件数量。
让执行过程保持可审查
开始实现后，可以要求 Codex 遵循一个简单闭环：
- 读取入口、相邻实现、测试和工作区状态，确认没有覆盖他人改动；
- 先复现问题或建立基线，再选择最小的行为改动；
- 按仓库现有模式实现，并补充与风险相称的测试；
- 运行最小相关检查，再扩大到构建、类型检查或集成测试；
- 审阅最终差异，报告命令、结果和仍未覆盖的风险。
这里的“最小”不是追求最少行数，而是避免顺手重构无关模块。上下文不足时，代理应该继续查找；只有无法从环境得到、且答案会实质改变方案的问题，才需要暂停询问。
权限同样属于任务设计。Codex 在沙箱内运行本地命令，越过文件或网络边界时会遵循审批策略。不要为了省一次确认就授予整台机器的宽泛权限。更好的做法是保持工作区干净，给出准确命令，并只批准当前任务确实需要的能力。
常见失败方式
最常见的问题是只有目标，没有完成标准，最终得到“看起来合理”却无法证明的补丁。另一个极端是提前指定所有文件和函数，使代理无法根据真实代码修正假设。把多个互不相关的目标塞进同一会话，也会让上下文膨胀，增加遗漏和无关改动。
交付前应能回答：原问题是否复现过，改动为何足够，哪些检查已经运行，输出是否成功，还有什么没有验证。无法运行测试并不等于可以沉默跳过；应明确说明原因和证据缺口，让评审者决定是否接受风险。