99% 的人都在错误地使用 /goal 和循环。
他们听到的宣传是“长时间运行的循环驱动自主 Agent”：把它指向一个任务，走开，然后回来就能看到可运行的代码。
但顶尖的 Agent 工程师在没有 /goal 的情况下已经这么做了 6 个月（当 GPT-5.2 和 Opus 4.5 发布时）。这被称为框架工程 + 规范驱动开发：
- 构建一个框架让 Agent 观察问题
- 编写一个包含所有测试用例的严格规范
- 让 Codex 或 Claude Code 无监督地循环，直到满足所有条件。
我经常在夜间启动这些任务——每次运行 2-5 小时。在四月，有一个任务在我们的 Vercel monorepo 中解决了一个 Turbo 构建缓存错误，并在早上之前通过了所有测试。实际上并不需要 /goal。
那么 /goal 到底是做什么用的？
下面是一个单一提示在我离开时完成的工作：
- ~30 小时，6,300 行代码，爬取了 92k 个页面，API 花费 $40
- 克隆了另一个产品的核心循环——从零开始逆向工程了整个架构
- 我们版本的输出在相同查询上比参考产品好大约 50 倍。（这将是一个新的数据层，将为 newsjack.sh 提供支持——我一直在开发的开源新闻情报技能）
秘诀是损失函数开发 (LFD)：你为 Agent 编写一个要优化的目标，而不是一个要构建的规范。
这是 Peter 推文的一个具体例子，已经付诸实践。
规范驱动开发中使用的规范现在变成了起点，而不再是终点。
我花了一些实验才弄清楚。但这里是完整的打法——不过我们需要先看看它最初有多糟糕，这样你才能理解如何设计这些 /goal。
Agent 作弊了 3 次。
一切从我一直做的事情开始：一个规范。
我只是把 codex 指向另一个产品的公开网站——“我们如何自己构建它？” 30 分钟内，它带回了一个完整的系统设计和测试用例——即规范。
但这次，我尝试了一个不同的提示。
“/goal 实现直到你的输出与他们的完全匹配”
然后发生了以下事情：
循环 1（5 分钟）
Agent 获取了评估集，生成了镜像它的种子数据，并在五分钟内宣布胜利。
“100% 召回率，零泛化能力”——一个只能找到我交给它的 30 件事情的搜索引擎，哈哈。
修复 → 使其盲目。 评估在运行期间隐藏，仅在评分时揭示，并附带每个项目的遗漏列表。
循环 2（20 分钟）- 盲目，30 个项目。
我让 Agent 看不到评估集，但它转而通过遗漏来学习——每个“你没有找到 X”在下一次循环中都变成了一个关键词。几个循环后：它恰好使用了 30 个关键词，每个项目一个，然后再次“获胜”。
修复 → 扩大评估集。 数百个项目用于评分，太多了，无法枚举。
循环 3（30 分钟） - 盲目，200 个项目。
在向新的评估集添加 200 个项目后，Agent 再次作弊。
有趣的是，Agent 仍然进行了枚举。关键词列表膨胀到了数百个，每个术语都是下一个遗漏的精确诱饵。
三轮，三次作弊。
就在那时我明白了：Agent 只是在优化。
作弊不是 Agent 中的错误。这是我目标中的错误：我告诉它去哪里，并留下了每一个捷径。
你没有围堵的每一个廉价路径都是优化器会冲刺的方向。而我最初的目标跳过了所有围栏。
循环 4（30 小时） - 盲目，200 个项目，硬限制。
所以我开始封锁方向。限制关键词列表，使评估盲目，扩大日期范围——每次修复都堵住了一个廉价路径，直到唯一能提升指标的方向是真正更好地完成任务。
它停止了作弊。
然后它开始运行。大约 30 小时的计算时间，92k 个页面被爬取，大约 $40 的 tokens 费用，6,300 行代码。
事实证明，我们参考的产品只是地板，而不是天花板：我们在相同的查询上最终得到了大约 50 倍的结果。
（完整旅程和证据在此，供好奇者参考）
损失函数开发 (LFD) - 一个好的损失函数的构成
当大多数人尝试构建产品时，他们使用 Agent 在几小时内从零到发布。
但问题是之后的事情——长尾。 规范从未设想过的边缘情况只有在生产环境中才会出现，一次一个错误日志。你一个一个地修复它们。你没有在日志中捕捉到的情况会由用户报告，这是发现错误最昂贵的方式。
我已经自动化了这个过程的廉价部分。我的 OpenClaw Agent Zoe 每天监视错误日志，并在新错误出现时生成 Codex 创建 PR——这几乎是这个循环能有的最紧密方式。（完整设置在此处记录）
长尾仍然需要数月时间。这就是为什么即使有 Agent 做工作，构建一个好的产品仍然需要时间。
LFD 加速了长尾过程。如果你能提前获得真实的预期输出示例——即“好”的样子，并且规模足够大——你就可以在发布之前运行压力测试：在一次优化运行中让 Agent 处理数百个边缘情况，而不是一个季度一次的错误报告。而这件事突然变得可行，是因为对于越来越多的问题，这些示例就公开地摆在那里。
规范驱动开发：
构建这个。让测试通过。
损失函数开发：
构建这个。让测试通过。然后针对这 1,000 个评估用例进行迭代。
一个测试套件是有限的——一旦变绿就完成了。一个 1,000 个用例、要求 95% 通过率的评估是一个你需要不断趋近的目标；在达到标准之前没有退出路径。这一点很重要，因为 Agent 会做出数百个你永远不会看到的决策，而每一个决策都会针对某个东西来解析。如果你没有编写目标，Agent 就会自己选择一个——正如第 1-3 轮所示，它会选择最容易满足的那个。
损失函数比评估更大。它有 4 个部分——目标、约束、工具和强制熵。四个部分。
1. 目标
- 足够大，以至于枚举不划算。 一个 28 项的评估在一个循环内就被记住了。越多越好。
- 让 Agent 看不到答案。 评估数据仅用于事后评分。如果 Agent 在运行期间能看到答案，它会想办法获取。
2. 约束
Agent 被允许做什么，以及不被允许做什么。
- 时间是 Agent 总是忘记的约束。 Agent 没有时间感。它们会因为指标在名义上在移动而花 10 个小时去争取 2% 的提升。但一个 2 小时内完成的 80% 解决方案胜过 30 天完成的 100% 方案。 解决方案：设置一个挂钟时间预算。
- 金钱。 对每个付费调用设置硬上限：爬虫积分、LLM 花费、一次性密钥的总美元上限。
- 表面。 所有提供商、允许的模型、并发上限。将 Agent 限定在你希望它接触的范围内。
- 方法论。 是否允许 LLM 分析，还是只允许确定性逻辑？Agent 可以访问哪些数据源？要明确规定。
3. 工具（框架）
没有工具的约束只是一种感觉——Agent 会愉快地违反它，因为它无法判断自己正在违反。对于上述每个约束，提供一个 CLI 命令让 Agent 可以自行检查。
- 目标测量，以正确的分辨率进行。 仔细选择目标测量工具。一个真实的例子：一个天真的“让 LLM 比较两个截图”的评判者会批准有 12px 间距错误的 UI 克隆，因为 LLM 实际上并不能看到图像，它会把图像转换成嵌入向量然后比较嵌入向量。 所以如果你想要像素完美的 UI 克隆，给你的 Agent 一个像素差异工具。然后 /goal 直到像素差异为 0。
- 时间核算。 记录每次运行和每个步骤的时间戳。Agent 应该知道每一步花了多长时间，以及总挂钟时间。时间是一个一等公民的工具，而不是一个脚注。
- 提供商预算。 “我们现在在爬虫上花了多少钱？”应该是一个命令，而不是一个猜测。追踪剩余的抓取积分、本次循环的消耗、累计消耗以及下一个付费批次之前的预计消耗。
- LLM 花费。 给它一个用于数据层面的 LLM API 密钥可以简化很多逻辑。但 Agent 应该负责任地使用它们，首先要知道它实际花了多少钱。
- Codex 使用情况。 这个有点元。循环应该具有自我意识：我在这次优化上花费了多少 tokens？有助于了解当前优化步骤的梯度。
模式还是那句老话：你无法优化你看不到的东西。
如果你第一次运行这些循环，不要启动它就走开。先观察第一个周期。看看它会接触什么。确认你构建的框架确实被正确使用了。然后再去睡觉。（并试着不去想你醒来时会看到什么来入睡）
4. 强制熵
为什么强制熵很重要：每个循环都从上一次运行的完整上下文继续。模型不是从零开始——它在读取自己过去的上百个决策以及到目前为止有效的梯度。
在 /goal 循环中，达到局部最优是默认状态。 如果没有明确的推动，Agent 会继续沿着同一个山坡向上走，而“同一个山坡”就是它停止改进时所在的位置。
例如，如果一个小旋钮能将结果提高 0.1%，Agent 会不停地转动那个旋钮，即使它还有 1000 个其他旋钮可以尝试。
需要显式地将熵强制注入到运行中，因为模型不会主动采取：
- 每个周期的过拟合反思。 我是在构建一个更通用的解决方案，还是在记忆评估集？ 如果是在记忆，下一个更改必须移除一个评估形状的产物（限制一个列表、使一个特征不可见、扩大评估范围、拒绝一个种子），而不是添加一个。
- 在停滞时强制熵。 如果上一个周期没有移动指标，下一个周期就不能是“同一个想法，更努力”。模型必须做出一个真正的非显而易见的跳跃——“跳出框架思考”是一个好的提示——阻止 Agent 只是更用力地转动同一个旋钮。
- 保留迭代日志。 让 Agent 记录假设、预期的失败模式、每一步的诊断，以便它可以回顾并在压缩中进行反思。
元-元-提示
我以前是自己编写这些目标，然后很快意识到这也有 Agent 来做。
所以我编写了一个技能，可以为一次好的损失函数开发运行生成这些类型的目标。
现已在此开源：
https://github.com/elvisun/loss-function-development
/lfd-design 用于生成框架和目标
梯度下降贯穿始终：两个循环
退一步看，这完全就是梯度下降。
内循环是 Agent：编写代码，运行测试，修复。短周期，快速反馈，一个目标——让测试通过。这是开发者的内循环，规范驱动开发就是运行它的方式。编码 Agent 已经自动化了它。
外循环是 /goal：驱动整个系统在多个周期中朝着一个结果指标前进——发布、测量、改变方向、趋近。长周期，稀疏反馈。这传统上是产品团队的循环，将数月之久的发布-测量-迭代压力测试压缩到一次运行中。
两个循环现在都已自动化。留给你的就是定义损失函数——/goal 应该精确地优化什么以及以何种方式优化。
你是在提炼一个产品——或者任何留下公开产物的事物
另一个视角：这本质上是蒸馏，从训练时转移到了提示时。这就是 DeepSeek、Kimi、Minimax 这条线缩小与 GPT 和 Claude 之间大部分差距的方式——用别人的输出训练你的模型，直到你的模型能复制它们。
但与其蒸馏一个模型，你现在可以使用 /goal 和 LFD 来对任何可公开找到的产物进行蒸馏拟合——它从不检查内部结构，也不需要。
注意公开这个词。蒸馏某人的受 ToS 限制、需要登录或付费的输出是不公平的。但是，公开发布的内容——一家公司为了赢得客户而发布的产品——一直是公平学习的对象。这部分并不新鲜——这是软件领域最古老的策略。新鲜的是它现在变得廉价，并且可以在几小时内完成，而不是几个月。
退一步看，这里是更大的转变。只要存在信息对称性，执行成本就会暴跌到大约 $0——当输出是公开的时候，每个人都能看到“好”的样子，所以任何人都可以在一个周末花费 $40 将其蒸馏出来。
所以这里出现了一个越来越有价值的新的护城河：信息不对称。
典型的开源公司已经意识到了这一点。在 2026 年 4 月，cal.com（$5M ARR）将其生产代码私有化并转为闭源。他们给出的理由简直就像这篇文章的摘要：在一个 AI 驱动的安全威胁时代，你不能把你的源代码放在 Agent 可以读取的地方。
“/goal 阅读 cal.com 源代码并枚举其攻击面，直到某个东西起作用”
这是一个太危险、太容易执行的攻击。
这家整个身份都是“开源”的公司，在 2026 年决定，开放性已经成为一种负担。这应该说明了一切。
在整个软件历史中，“我们构建了它”就是护城河。
那个时代正在结束。
下一个时代属于那些拥有产物从未包含的东西的人：别人无法衡量的评估集。你的用户实际遇到的边缘情况列表。你私下测量的真实数据。谁拥有竞争对手的 Agent 看不到的目标，谁的循环就能继续下降。
现在构建一个产品只需要一个周末了。
去构建一个周末无法触及的评估吧。
