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