@akshay_pachaar: 像写验收标准一样写 /goals。/goal 现已无处不在。Claude Code、Codex、Hermes 以及更多智能体正在采用……

像写验收标准一样写 /goals。/goal 现已无处不在。Claude Code、Codex、Hermes 以及更多智能体正在采用相同的模式：你设定一个完成条件，智能体自主工作，直到一个快速评估模型确认条件达成。功能很简单。但写好目标并不简单。模糊的目标在两方面失败：智能体循环往复试图满足模糊的条件，或者评估者因没有具体内容可检查而幻觉成功。两者都白白浪费 token。以下是有效目标与无效目标之间的区别：𝗴𝗼𝗼𝗱 𝗴𝗼𝗮𝗹𝘀 𝗱𝗲𝘀𝗰𝗿𝗶𝗯𝗲 𝗮𝗻 𝗼𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗹𝗲 𝗲𝗻𝗱 𝘀𝘁𝗮𝘁𝗲。"test/auth 中的所有测试通过且 lint 干净" 有效，因为智能体可以运行测试、打印输出，评估者可以从转录中确认。"所有旧 API 调用点已迁移且构建成功" 有效，因为存在可验证的工件：构建输出。"CHANGELOG.md 包含本周合并的每个 PR 的条目" 有效，因为它指向一个具体的文件与具体的内容。𝗯𝗮𝗱 𝗴𝗼𝗮𝗹𝘀 𝗵𝗮𝘃𝗲 𝗻𝗼 𝗳𝗶𝗻𝗶𝘀𝗵 𝗹𝗶𝗻𝗲。"改进代码库" 失败，因为改进的依据是什么指标？"重构一切" 失败，因为没有退出条件。"修复 bug" 失败，因为哪些 bug？如何验证？有帮助的心智模型：如果一个人类无法判断任务何时完成，评估者同样无法判断。将每个 /goal 视为一个分配给非常字面的、永不知疲倦的初级开发人员的工单。写出你将在该工单中写的确切验收标准。还有一件事：复杂的多步骤目标会压垮它。"重新设计身份验证、添加 OAuth、编写测试、更新文档" 是四个目标伪装成一个。将它们分解为顺序的 /goal 调用，每个调用都有一个可验证的终点。我写了一篇关于 /goal 的详细解析（下面的文章），涵盖了完整的机制。