/goal 现在无处不在。Claude Code、Codex、Hermes 和更多 Agent 都在采用相同模式：你设置完成条件，Agent 自主工作直到快速评估模型确认条件达成。
功能很简单。写好目标不简单。
模糊目标的两种失败方式
模糊目标以两种方式失败：
- Agent 无限循环试图满足 unclear 条件
- Evaluator 幻觉成功因为没有 concrete 东西可检查
两者都白白 burn tokens。
好目标 vs 坏目标
好目标描述可观察的终态：
- "test/auth 中的所有测试通过且 lint 干净" — 有效，因为 Agent 可以运行测试、打印输出，evaluator 可以从 transcript 确认
- "旧 API 的每个调用点都已迁移且构建成功" — 有效，因为有可验证产物：构建输出
- "CHANGELOG.md 有本周合并的每个 PR 的条目" — 有效，因为它指向有具体内容的 concrete 文件
坏目标没有 finish line：
- "让代码库更好" — 失败，因为 better 按什么 metric？
- "重构所有东西" — 失败，因为没有退出条件
- "修复 bug" — 失败，因为哪些 bug，如何验证？
心智模型
如果人类无法判断 ticket 何时完成，evaluator 也无法。
把每个 /goal 当作分配给一个非常 literal 的 junior developer 的 ticket 来写——他从不疲倦，但也不会读心。写你会放在那个 ticket 里的 exact 验收标准。
复杂目标的拆分
复杂多步目标会 overwhelm Agent。
"重新设计 auth，添加 OAuth，写测试，更新文档" 是四个目标假装成一个。拆分为 sequential /goal 调用，每个有单一可验证的 finish line。
关键原则
- 具体 — 指向可验证的 artifact（测试输出、构建结果、文件内容）
- 单一 — 每个 /goal 一个 finish line
- 可观察 — evaluator 能从 transcript 确认成功
- 像 ticket — 写你会给 junior dev 的验收标准
Akshay 写了更详细的 /goal 拆解文章，覆盖完整机制。