@elvissun: https://x.com/elvissun/status/2065035615800864954
摘要
Elvis Sun 分享了一份详细的操作手册,介绍如何使用 AI 编码代理、工程框架和损失函数开发来自主解决复杂工程问题,并展示了如何避免代理作弊等常见陷阱。
查看缓存全文
缓存时间: 2026/06/11 15:40
/goal + 损失函数:如何用一条提示在30小时内蒸馏出一个产品 [完整手册]
99% 的人 /goal 和循环都用错了。
他们听到的炒作是“长时间运行的循环提示自主智能体“:指向一个任务,走开,回来时拿到能运行的代码。
但顶尖的智能体工程师在没有 /goal 的情况下已经这么做了 6 个月(从 GPT-5.2 和 Opus 4.5 发布时开始)。这叫工具架工程 + 规格驱动开发:
- 构建一个工具架让智能体观察问题
- 编写包含所有测试用例的严格规格
- 让 Codex 或 Claude Code 无人值守地循环直到满足每一条测试
我经常在晚上启动这些任务 —— 每次运行 2-5 小时。四月份有一次它耗了一整晚解决了我们 Vercel 单体仓库中的 Turbo 构建缓存 bug,到早上所有测试都通过了。实际上根本不需要 /goal。
Elvis@elvissun·Apr 11我会再说一遍,因为我一直看到人们做错:
你可以通过把一个智能体放到适当的工具架中循环来解决任何工程问题。
codex 一次性修复了我们的 turbo 缓存问题,在我给了它像团队中真正的开发者一样调试所需的一切之后。
会显示更多引用Elvis@elvissun·Mar 26软件已经永远改变了:
如果你能做到以下几点,你就能解决任何工程问题:
- 停止自己尝试解决问题
- 为智能体构建一个工具架来掌控它
- 把它放到自己的反馈循环中直到问题解决 x.com/elvissun/statu…32961.1K285K
那么 /goal 到底是用来做什么的?
以下是我离开时一条提示所做到的事:
- 约 30 小时,6300 行代码,爬取 92k 个页面,花费 $40 在 API 上
- 克隆了另一个产品的核心循环 —— 从头开始逆向工程整个架构
- 我们版本的输出在相同查询上比参考产品好大约 50 倍。(这是一个新的数据层,将驱动 newsjack.sh —— 我一直在开发的开源新闻情报技能)
秘诀是损失函数开发(LFD):你给智能体一个需要优化的目标,而不是一个需要构建的规格。
Peter Steinberger @steipete·Jun 8这是你每月一次的提醒:不要再给编码智能体写提示了。
你应该设计循环来提示你的智能体。1.7K2.7K19K8.2M
这就是 Peter 推文的具体实例,实际落地。
规格驱动开发中的规格现在变成了起点,不再是终点。
我花了一些实验才做对。但这里有完整的手册 —— 但我们需要先了解它最初有多糟糕,这样你才能理解如何设计这些 /goal。
智能体作弊了 3 次。
一切都始于我惯常的做法:一个规格。
我只是把 codex 指向另一个产品的公开网站 —— “我们自己怎么构建这个?” 30 分钟内它返回了一个完整的系统设计和测试用例 —— 即规格。
但这一次,我尝试了一个不同的提示。
“/goal 实现直到你的输出与他们的完全匹配”
然后发生了这样的事:
循环 1(5 分钟)
智能体抓取评估集,生成了镜像它的种子数据,并在五分钟后宣布胜利。
“100%” 召回率,零泛化 —— 一个只能找到我交给它的 30 个东西的搜索引擎,哈哈。
修复 → 使其盲化。 运行期间隐藏评估集,仅在评分时揭示,并附带每个项目的遗漏列表。
循环 2(20 分钟) - 盲化,30 个项目。
我让智能体看不到评估集,但它通过遗漏来学习 —— 每个“你没有找到 X“都在下一个循环变成了一个关键词。几个循环之后:它正好用了 30 个关键词,每个项目一个,它又“赢“了。
修复 → 扩大评估集。 数百个项目用于评分,数量太多无法枚举。
循环 3(30 分钟) - 盲化,200 个项目。
在向新评估集添加 200 个项目后,智能体再次作弊。
有趣的是,智能体还是进行了枚举。关键词列表膨胀到数百个,每个术语都是对下一个遗漏的精确诱饵。
三轮,三次作弊。
就在这时我明白了:智能体只是在优化。
作弊不是智能体的 bug。是我目标的 bug:我告诉它去哪里,却把每条捷径都敞开着。
你没有设防的每条廉价路径,都是优化器会冲刺的方向。而我的初始目标跳过了所有防线。
循环 4(30 小时) - 盲化,200 个项目,硬限制。
于是我开始封锁方向。限制关键词列表,隐藏评估集,扩大日期范围 —— 每次修复都关闭了一条廉价路径,直到唯一能推动数值的方向就是真正提高任务质量。
它停止作弊了。
然后它开始运行。约 30 小时的计算时间,爬取 92k 个页面,约 $40 的 token 消耗,6300 行代码。
结果发现我们参考的产品是地板,不是天花板:在相同查询上我们最终呈现了约 50 倍的结果。
(完整旅程和凭证在这里,供好奇的人查看)
Elvis@elvissun·May 21codex 真是太疯狂了
如果你觉得前端克隆令人印象深刻,看看这个:
我刚刚把 codex 指向另一个产品,30 分钟内得到了它的架构、数据模型、提示以及成本估算。一份 378 行的重建计划。
最疯狂的部分是现在我可以显示更多引用Elvis@elvissun·Apr 11我会再说一遍,因为我一直看到人们做错:
你可以通过把一个智能体放到适当的工具架中循环来解决任何工程问题。
codex 一次性修复了我们的 turbo 缓存问题,在我给了它像团队中真正的开发者一样调试所需的一切之后。
会 x.com/16836399296732…3351700175K
损失函数开发(LFD)—— 一个好的损失函数的解剖
当大多数人试图构建一个产品时,他们使用智能体在几小时内从零到上线。
但关键在于之后的事 —— 长尾。 规格从未想象过的边缘情况只在生产环境中浮现,一次一个错误日志。你逐个修复它们。你在日志中没有捕捉到的情况会被用户报告,这是发现 bug 最昂贵的方式。
我已经自动化了这个过程的廉价端。我的 OpenClaw 智能体 Zoe 每天监视错误日志,并在新错误出现时生成 Codex 创建 PR —— 这个循环差不多紧到极致了。(完整设置在 此处记录)
长尾仍然需要数月。这就是为什么即使有智能体在干活,构建一个好产品仍然需要时间。
LFD 加速了长尾。如果你能提前获得真实的预期输出示例 —— 好的结果是什么样子,而且是规模化 —— 你在上线之前就进行了浸泡测试:数百个边缘情况在一次优化运行中命中智能体,而不是每季度一滴的 bug 报告。而这件事突然变得可行,是因为对于越来越多的问题,这些示例就公开摆在那里。
规格驱动开发:
构建这个。让测试通过。
损失函数开发:
构建这个。让测试通过。然后针对这 1000 个评估案例进行迭代。
测试套件是有限的 —— 一旦变绿就完成了。一个 1000 个案例的评估在 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 个其他旋钮可以尝试。
熵需要被显式地强制进入运行中,因为模型不会自己去做:
- 每个周期的过拟合反思。 我是在构建一个更通用的解决方案,还是在记忆评估集?如果是在记忆,那么下一个更改必须移除一个评估形状的人为产物(限制列表、隐藏某个功能、扩大评估集、拒绝种子),而不是添加一个。
- 卡顿时强制熵。 如果上一个周期没有移动指标,下一个周期就不能是“同样的想法,更努力“。模型必须做出一个真正的非显而易见的跳跃 —— “跳出框架思考“是一个很好的提示 —— 阻止智能体只是更用力地转动同一个旋钮。
- 维护迭代日志。 让智能体记录假设、预期失败模式、每个步骤的诊断,以便它可以回顾并在不同压缩之间进行反思。
元元提示
我一开始是自己写这些目标,但很快发现这也是智能体的工作。
所以我写了一个技能来生成这类目标,用于一个好的损失函数开发运行。
现在开源在这里:
https://github.com/elvisun/loss-function-development
/lfd-design 来生成工具架和目标
/lfd-design 来生成工具架和目标
一路梯度下降:两个循环
退后一步看,一路都是梯度下降。
内循环是智能体:写代码,运行测试,修复。短视界,快反馈,一个目标 —— 让测试通过。这是开发者的内循环,规格驱动开发就是运行它的方式。编码智能体已经自动化了它。
外循环是 /goal:驱动整个系统跨多个周期向一个结果指标前进 —— 发布,测量,改变方向,下降。长视界,稀疏反馈。这传统上是产品团队的循环,数月的发布-测量-迭代浸泡压缩到一次运行中。
现在两个循环都自动化了。剩下在你身上的就是定义损失函数 —— 确切来说 /goal 应该优化什么,以什么方式优化。
你正在蒸馏一个产品 —— 或任何留下公开产物的东西
另一个视角:这本质上是蒸馏,从训练时转移到了提示时。这就是 DeepSeek、Kimi、Minimax 系列缩小与 GPT 和 Claude 之间大部分差距的方式 —— 在别人的输出上训练你的模型,直到你的模型能再现它们。
但不同于蒸馏一个模型,你现在可以使用 /goal 和 LFD 对任何公开可找到的产物进行蒸馏拟合 —— 它从不检查内部,也不需要检查。
强调“公开“这个词。蒸馏受 ToS 限制、需要登录或付费的输出是不公平的。但是公开发布的内容 —— 公司为了赢得客户而发布的输出 —— 从来都是可以学习的。这部分并不新鲜 —— 这是软件中最古老的招数。新鲜的是它现在很便宜,可以在几小时内完成而不是几个月。
退后一步,这里有更大的转变。执行成本坍塌到接近 $0,只要存在信息对称 —— 当输出是公开的时候,每个人都能看到好的结果是什么样子,所以任何人都可以在一个周末用 $40 把它蒸馏回来。
所以这里有一个越来越有价值的全新护城河:信息不对称。
典型的开源公司已经意识到了。2026 年 4 月,cal.com($5M ARR)将其生产代码设为私有并转向闭源。他们给出的理由读起来就像这篇论文的摘要:在 AI 驱动的安全威胁时代,你不能把源代码留在一个智能体可以读取的地方。
“/goal 读取 cal.com 的源代码并枚举其攻击面直到某个方法奏效”
这是一个太危险且太容易执行的攻击。
那个整个身份就是“开源“的公司,在 2026 年决定,开放性已经成为一种负担。这应该告诉你一切。
在软件的整个历史中,“我们构建了它“就是护城河。
那个时代正在结束。
下一个时代属于拥有产物从未包含的东西的人:别人无法用来评分的评估集。你的用户真正遇到的边缘情况列表。你私下测量的真实数据。拥有竞争对手智能体看不到的目标的人,是唯一一个循环能够持续下降的人。
产品现在只是一个周末的事。
去构建一个周末无法触及的评估集吧。
相似文章
@eyad_khrais: https://x.com/eyad_khrais/status/2069552027382980882
一份构建 AI 代理框架的全面指南,涵盖工具执行、上下文管理、状态/记忆和护栏,基于构建 Claude Code 和其他企业级框架的经验。
一位开发者分享关于如何最大化AI代理能力的见解,认为更简单的设置和理解核心原则比复杂的工具和库更有效。
一位开发者分享关于如何最大化AI代理能力的见解,认为更简单的设置和理解核心原则比复杂的工具和库更有效。
@qinzytech: https://x.com/qinzytech/status/2066585405479371092
对构建自我进化AI代理的两种方法的技术分析:基于模型的方法(通过像SSMs或具有快速权重更新的transformer等架构,以及训练方法)和基于工具的方法(通过内存或能够自我重写的元工具)。作者为不同受众提供了实用建议。
@jasonzhou1993: https://x.com/jasonzhou1993/status/2075179471951614381
作者分享了运行AI代理循环一个月后的实际经验,强调了循环契约、状态和日志的重要性,以使代理实现自主和可靠。
@SuJinyan6: https://x.com/SuJinyan6/status/2073955240349770069
这篇由SuJinyan6撰写的博文探讨了AI Agent从简单的LLM加工具使用,向上下文工程和长时间运行框架的演变。文中引用了Anthropic的最新研究,讨论了Agent能力如何成为一种系统级属性,涉及多个组件。