Goal 提示语
面向长任务和自主 Agent 的目标协议：用“目标、指标、边界”定义任务，让模型在可验证范围内自主实验、记录假设并自我纠错。
简介
Goal 提示语是文章《分享8个Claude Fable 5下线前必跑的超实用Prompt》中提炼出的长任务起手式。它不是普通的“请你帮我完成某事”，而是把任务交给 Agent 前必须说清楚的三件事：要达成什么目标、用什么指标判断完成、过程中绝对不能碰什么边界。这与 Karpathy 的表达高度一致：“Here’s an objective, here’s a metric, here’s your boundaries of what you can and cannot do. And go.”
在 Fable 5 这类更适合长期自治和多代理编排的模型上，Goal 提示语的价值尤其明显。模型一旦知道目标和评估标准，就可以不再等待人类逐步指挥，而是在边界内自主提出假设、运行实验、记录预期和实际结果，并在发现数据口径或评估方法错误时当场修正。文章引用 Jesse Vincent 的 Superpowers 6.0 成本优化案例：通过要求至少 25 次不同实验、每次实验前写清假设、失败路线完整记录，最终花 165 美元把构建速度提高 50%、token 开销降低 60%。
Goal 提示语的重点不是“让模型多思考”，而是让模型知道怎么判断自己是否真的做完。没有指标，Agent 容易停在“看起来不错”；没有边界，Agent 容易做过度修改、扩大范围或碰到不可逆操作；没有过程记录，失败经验会在对话结束后消失。一个成熟的 Goal 提示语应把三者合并成可执行协议。
关键信息
- 类型：提示词结构 / Agent 任务协议
- 核心公式：目标（objective） + 指标（metric） + 边界（boundaries）
- 适用场景：成本优化实验、CI 修复、性能调优、提示词测试、长时间研究、多代理任务编排
- 关键机制：假设记录、失败路线记录、中途自纠错、独立验证、停止条件
- 相关概念：Fable 5、Loop Engineering、验证者子代理、自我改进代理系统、提示词工程
核心特性
目标：把“想要什么”变成可执行方向
Goal 提示语第一步是明确最终要什么结果，而不是只描述过程。例如“优化构建成本”仍然太宽，进一步要写成“在不降低测试覆盖和产物正确性的前提下，降低 CI 构建耗时与 token 成本”。目标决定 Agent 搜索空间，如果目标只写“更好”“更快”“更省钱”，模型会不知道何时停下，也难以区分有效优化与表面优化。
指标：把“做完了”变成可判定事实
指标是 Goal 提示语的核心。文章里 Jesse 的实验有构建速度提升、token 开销下降、实验次数、失败路线记录等可检查指标。一个好的指标通常应包含：基线是什么、目标改善幅度是什么、如何测量、同一套口径如何在前后轮次保持一致。如果模型中途发现数据量错了、口径不一致或评估方法有问题，必须先修正测量再继续，否则循环会在错误指标上越跑越远。
边界：把“不能做什么”写在前面
边界决定 Agent 的行动护栏。常见边界包括：不能破坏生产数据，不能跳过测试，不能扩大到未授权模块，不能直接替换线上 prompt，不能把成本优化建立在削减测试质量上。边界不是降低模型能力，而是防止它为了达成指标走捷径。文章中“给测试计划设字数预算导致测试内容削减 62%”就是边界不足的反例：表面上控制了输出，实际破坏了实验质量。
过程记录：让失败也成为资产
Goal 提示语应要求每次实验开始前写清假设，结束后记录预期、实际和失败原因。文章强调，被否定的想法同样要完整记录，因为这些失败实验能避免未来在新项目上重新花钱踩坑。例如“限制思考字数省 token”看似合理，但实际导致轮次从 92 轮增加到 138 轮；“便宜模型先写计划、Fable 执行”看似省钱，但会让任务结构不是 Fable 的思路。失败一旦被记录，就变成下一轮的负面样本和设计边界。
不同素材中的观点
-
2026-07-07-woshipm-fable-5-prompts-before-offline：Goal 提示语的最佳结构是目标、指标、边界。Jesse Vincent 用类似 /goal 的协议让 Fable 5 运行 25 个实验，并要求每个实验都有假设、预期、实际结果和失败路线记录。这个案例说明，长任务 prompt 的价值不在“措辞优美”，而在让模型拥有可验证的任务定义和中途自纠错机制。
-
2026-07-07-blocktempo-fable-loop-library-25-workflows：这篇素材进一步强调
/goal的“完成证明”必须能被裁判读到。由于旁边的小模型裁判通常只能看对话，不能打开文件、跑测试或检查网站，所以“测试通过就算完成”是不合格目标；更好的写法是“当完整绿色测试结果被贴进聊天室才算完成”。这把 Goal 提示语从目标协议升级为证据契约：如果贴不出证明，就必须贴出失败信息并停止。 -
2026-07-08-abmedia-claude-code-four-loop-types：这篇素材给出
/goal的官方式使用场景：/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries。它强调 goal-based loop 最适合“可量化验证”的任务，例如测试通过数、Lighthouse 分数、覆盖率门槛等；开发者不只要写目标，还要写最大回合数，让评估者模型在 Claude 想停下时检查是否真的达成。这个案例补充了 Goal 提示语的实操边界：指标越决策性、越能被裁判读到，越省 token；如果任务成功标准无法量化，应先转成 rubric 或改用 turn-based 协作。
实用信息
推荐模板
背景：我在为 [谁] 做 [什么项目]，他们需要 [这个东西解决什么问题]。
目标：请达成 [具体目标]。
指标：完成必须满足 [可测量标准]，请记录基线、每轮结果和最终对比。
边界：过程中绝对不能 [红线1]、不能 [红线2]，遇到 [高风险情况] 必须暂停。
过程：每次尝试前写清假设；每次尝试后记录预期、实际、失败原因和下一步。
停止条件：当 [指标达标] 或 [轮次/预算上限] 达到时停止，并输出最终报告。适用判断
- 任务是否有可测量目标？如果没有，先反向澄清。
- 失败路线是否值得记录？如果是，Goal 提示语比普通 prompt 更合适。
- 是否可能无人值守运行？如果是，边界和停止条件必须写入。
- 是否需要多轮实验或多代理协作？如果是，必须增加状态文件或验证者。
常见误区
- 只写目标，不写指标，导致模型不知道何时停。
- 只写指标，不写边界，导致模型用不合规方式达成数字。
- 只记录成功路径，不记录失败路线，导致未来重复踩坑。
- 把“限制输出字数”当成成本控制，结果让模型多绕路、更贵。
- 让便宜模型先写完整计划再让重型模型执行，却忽略不同模型的思路和任务结构可能不一致。