如何写好 Codex Goal：结构、模板与反例
很多开发者在使用 Codex 时发现，同样的任务，给出的 Goal 越简单，Codex 跑偏得越严重。真正决定成败的，不是 Goal 写得够不够长，而是写得够不够“结构化”。
一个写得好的 Codex Goal，应该像一份清晰的工程任务单：目标明确、验收标准明确、边界明确、停止条件明确。本文将系统讲解如何写好 Codex Goal，包括推荐的六个核心要素、可直接复制的模板，以及常见的反例，帮助你大幅提升 Codex 的可控性和交付质量。
Codex Goal 到底是什么？
Codex Goal 是从 Codex 0.128.0 版本开始支持的线程级目标状态。它不是全局记忆，也不是项目级配置，更不是让 AI 无限自主运行的后台 Agent。
它的核心价值在于：让 Codex 在多个交互轮次中持续朝着同一个可验证的目标推进，直到满足完成证据、主动停止，或遇到明确阻断条件。
简单来说，Goal 把“继续做”这种模糊指令，变成了可追踪、可验证、可暂停、可恢复的正式目标契约。
写好 Codex Goal 的六个核心要素
一个稳健的 Goal 建议包含以下六个要素，这套结构来自大量工程实践的抽象总结：
| 要素 | 中文含义 | 要回答的核心问题 | 常见写法建议 |
|---|---|---|---|
| Outcome | 目标结果 | 最终要交付什么？ | 修复 bug、完成迁移、P95 下降30% |
| Verification surface | 验证表面 | 用什么证明任务已完成？ | 测试通过、benchmark 数据、日志、产物文件 |
| Constraints | 约束条件 | 哪些事情绝对不能做？ | 不能改公开 API、不引入新依赖 |
| Boundaries | 任务边界 | 本次任务的范围是什么？ | 只处理 /src/api 目录、特定模块 |
| Iteration policy | 迭代策略 | 应该按照什么顺序和方式推进？ | 先复现问题 → 最小修复 → 验证 |
| Blocked stop condition | 停止条件 | 什么时候必须停止并报告？ | 缺少生产数据、权限不足、外部服务不可用 |
这六个要素能帮助 Codex 在推进过程中做出清晰的决策，避免过度探索或盲目乐观。
Codex Goal 实用写作模板
推荐基础模板（最常用）：
/goal
目标：优化 /api/search 接口，使本地 benchmark 的 P95 响应时间从当前基线下降至少 30%。
完成证据：
- 提供优化前后的 benchmark 命令、样本量、完整结果对比
- 列出所有修改的文件及改动理由
- 核心回归测试全部通过
约束：
- 不得改变任何公开接口的返回数据结构
- 不得引入新的外部服务或重型依赖
- 必须保留原有错误处理逻辑
边界：仅限于 /src/api/search/ 及其直接依赖模块，不得修改前端或数据库层代码。
迭代策略：先复现当前性能问题 → 定位主要瓶颈 → 最小化改动验证效果 → 回归测试。
停止条件：如果瓶颈主要来自生产环境特有的数据分布且本地无法复现，则停止并明确列出所需的数据字段和样本要求。
这个模板几乎可以覆盖 80% 的工程任务。你只需要根据具体场景替换对应内容即可。
常见反例与改进对比
反例 1：愿望型 Goal（最常见）
/goal 帮我把这个项目优化一下。
问题：没有具体指标、没有验证方式、没有边界、没有停止条件。Codex 很容易在多个方向上漫无目的地尝试。
改进版：
/goal 将用户登录模块的加载时间从 2.3s 降低到 800ms 以内，完成证据为 Lighthouse Performance 分数达到 95+，仅允许修改登录相关的前端资源，不得改动后端 API。
反例 2：范围过大且模糊
/goal 自动优化整个项目，直到没有任何问题。
问题：什么是“没有任何问题”？如何验证？做到什么程度算完？这类 Goal 几乎必然导致 Codex 过度设计或陷入死循环。
反例 3：缺少停止条件
/goal 根据 PRD 实现多租户功能。
改进建议：在 Goal 中明确增加一句：
PRD 中出现的所有「后续」「未来」「可以考虑」「可扩展」相关描述，均视为非本次目标，除非 SPEC 明确要求实现。
进阶用法：结合 SPEC 与 Checklist
当任务较为复杂时，建议不要直接把 PRD 扔给 Goal。先让 Codex 根据 PRD 生成一份 Implementation Spec，再基于 Spec 开启 Goal：
/goal
按照 docs/PRD.md 和 docs/SPEC.md 完成「多租户权限系统」第一版实现。
执行规则：
- 以 SPEC 为技术实现准绳，PRD 与 SPEC 冲突时以 SPEC 为准并在报告中说明
- PRD 中的未来规划默认不实现
- 每个 Checkpoint 完成后必须运行对应测试
- 涉及页面变更时需通过浏览器验证核心用户流程
同时，可以让 Codex 生成 Checklist 文件，将抽象的“格式正确”“逻辑完整”转化为可逐条勾选的具体验证项，大幅提升完成判断的确定性。
写好 Goal 的核心原则
- 完成必须靠证据说话，而不是靠 Codex 说“我觉得已经好了”。
- 反馈循环越短越好，优先选择能在本地快速验证的指标。
- 明确什么是“不做”，往往比说“要做什么”更重要。
- 永远写清楚停止条件，让 Codex 知道什么时候该停下来报告而不是硬着头皮继续。
一个好的 Codex Goal，最终不是让 AI “更聪明地乱试”，而是把复杂任务变成当前线程内可验证、可控、可解释的目标状态。
掌握了结构化写作方法后，你会发现 Codex 从一个“听话但容易跑偏的助手”，变成一个真正能交付可靠结果的工程搭档。
关键词：Codex Goal、如何写 Goal、/goal 使用指南、Codex 0.128、Goal 模板、Codex 目标管理、AI 工程化、Codex 最佳实践