| name | better-goal |
| description | 为任意 coding agent 编写高质量任务目标的指南。当用户提到「设定目标」「goal」「任务目标」「持久目标」「完成标准」、或需要为复杂多轮任务（性能优化、调试、迁移、研究复现等）定义可验证的完成条件和约束时触发。 |
| version | 1.2.0 |
| source | https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex |
| metadata | {"hermes":{"tags":["goal","prompt-engineering","agent","中文"],"related_skills":["writing-plans","code-review"]}} |
编写高质量任务目标（better-goal）
Goal 不是 prompt。Goal 是验收契约。
以前我们写 prompt，告诉模型「做什么」就够了。现在 agent 能干活了，要求更高——你得告诉它「做完了怎么验证」「什么情况下停」「边界在哪里」。没有验收标准的 goal 就是猜谜游戏；没有暂停条件的 goal 会让 agent 在死循环里烧 token。
一个好的任务目标让 agent 在多轮探索中持续朝着既定结果工作，证据达标时停止，遇到决策点时暂停等人工判断。
一次性任务 vs 持久目标
| 一次性任务 | 持久目标 |
|---|
| 模式 | 请求 → 工作 → 结果 → 等待 | 工作 → 检查 → 继续或完成 |
| 适用 | 单次明确任务 | 路径不确定的多轮探索任务 |
| 完成 | 任务执行完毕 | 证据验证目标达成 |
何时使用持久目标
应该用： 性能优化、flaky test 排查、依赖迁移、需要复现的 bug 调查、多步重构、基准驱动调优、需要产出最终产物的研究任务。
不要用： 单行修改、简短解释、代码审查、一次性问答。标语式目标（「让代码更好」「重构一下」）也不适合。
适用条件：持久目标 + 可验证的完成线 + 需多轮探索的路径。
七个要素
- Outcome（结果）：工作完成时应该为真的状态
- Verification（验证）：证明结果的测试 / 基准 / 产物 / 命令输出
- Constraints（约束）：工作过程中不能退化的东西
- Boundaries（边界）：允许写哪里、禁止碰哪里、可用的资源范围
- Iteration policy（迭代策略）：每次改多少，改完跑什么检查，如何选择下一步
- Stop when（完成条件）：什么证据出现时宣告目标达成
- Pause if（暂停条件）：什么情况下暂停等人工决策（而非继续盲猜或宣告失败）
编写模板
/goal [期望结果]
Verification: [用什么证明完成了]
Constraints: [不能改什么 / 不能退化什么]
Boundaries: [允许写哪里 / 禁止碰哪里]
Iteration policy: [每次改多少，改完跑什么检查，如何选下一步]
Stop when: [证据证明完成]
Pause if: [什么情况下暂停等人工决策]
Stop when 和 Pause if 的区别：Stop when 是正向的完成信号（测试全绿、benchmark 达标），Pause if 是需要人介入的决策点（发现两种方案各有利弊、需要确认是否接受 trade-off、外部依赖阻塞需人类操作）。不要一遇到困难就宣告完成——该暂停时暂停，该完成时完成，该报告阻塞时报告阻塞。
从弱到强
性能优化
弱：/goal Improve performance
强：
/goal Reduce p95 checkout latency below 120 ms
Verification: checkout benchmark 报告 p95 低于 120ms，且 correctness suite 全绿
Constraints: 不退化 correctness suite 任何测试，不修改公开 API
Boundaries: 仅修改 checkout service、benchmark fixtures 和相关测试
Iteration policy: 每次迭代记录改了什么、benchmark 结果、下一最佳实验方向
Stop when: p95 连续 3 次 benchmark 低于 120ms 且 correctness suite 全绿
Pause if: benchmark 无法运行、或连续 5 次实验无改善、或需要动到公开 API
关键差异：强目标命名了结果（<120ms）、验证方式（benchmark）、约束（correctness suite、API）、完成信号（连续3次达标）和暂停点（5次无改善）。即使延迟从 180ms 降到 135ms，目标仍未完成；延迟达标但测试失败，目标也未完成；连续无改善时暂停而非盲目继续。
研究复现
弱：/goal Reproduce Buehler et al., "Deep Hedging"
强：
/goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging"
Verification: 产出分级报告——confirmed（精确复现）/ approximate（近似结果）/ blocked（阻塞项）/ uncertain（不确定项）四层分类
Constraints: 仅使用论文公开材料和本地资源，不做未经证实的结论宣称
Boundaries: 允许使用论文材料、公开数据集、本地计算资源
Iteration policy: 逐一尝试每个 headline 结果，验证输出，记录证据等级
Stop when: 所有 headline 结果分类完毕，报告覆盖四层分级
Pause if: 关键数据不可获取、计算资源不足跑完整实验、论文方法有歧义需判断
关键差异：强目标定义了证据标准（四层分级），防止「看似可行」的产物变成过度宣称的结论。
核心纪律
- 先定义验收标准，再开始工作。 什么算完成？什么证据能证明？什么信号表示该停？
- 目标要窄到能审计，宽到能探索。 「修好这个测试」可能太窄（问题在上游依赖），「改善整个系统」太宽（没有审计面）。
- 区分三种停止信号，不要混淆。 Stop when 是完成，Pause if 是等人，彻底无路可走才报告阻塞。不要用暂停冒充完成，也不要用完成冒充阻塞。
- 预算耗尽≠目标完成。 达到 token 限制时应总结进展和阻塞，标识下一步，而非标记完成。
反向访谈：让 AI 帮你收敛需求
当你不确定怎么写 goal 时，最有用的技巧是让 AI 反向访谈你——你只知道要做什么，AI 帮你把验收标准、边界条件、暂停规则全部问出来。
Step 1：提交模糊任务，让 AI 反问
/plan Help me turn this vague task into a strong coding agent goal.
Interview me for missing success criteria, verification commands,
constraints, boundaries, iteration policy, stop conditions, and pause
triggers. Then draft a final /goal ... command.
或者中文版：
/plan 帮我把这个模糊任务转成高质量的 coding agent 目标。
请反问我：验收标准是什么、用什么命令验证、有什么约束不能碰、
边界在哪、迭代策略、什么证据算完成、什么情况要暂停等人。
最后生成一份完整的 /goal 命令。
Step 2：回答 AI 的反问
AI 会逐一追问：
- 「你说的『快』具体是多少毫秒？」
- 「用什么测试来验证？」
- 「性能优化过程中有什么不能改？」
- 「如果连续失败几次后要暂停？」
Step 3：审查生成的 goal
检查收紧张力：成功条件是否可测量？暂停条件是否覆盖常见卡点？边界是否清晰？然后复制执行。
这就是 Agent 时代的工程规范——需求不再是「你猜我要什么」，而是「我们一起把验收契约写清楚」。
