Fable 5 碾压 GPT-5.6 Sol：/goal 模式真有用？
Fable 5 vs. GPT-5.6 Sol on an NP-Hard Problem: Does /goal help?
我把一个未公开的 NP-Hard 优化问题扔给了 Claude Fable 5 和 GPT-5.6 Sol，分别测试了普通模式和原生 /goal 模式。结果令人震惊：Fable 5 展现了惊人的原始智能，不仅给出了最优解，而且稳定性远超其他模型。更有趣的是，/goal 模式并非通用的“更努力”开关，它虽然赢得了更多单次测试，却拉低了整体平均表现。这揭示了一个残酷真相：在硬核优化问题上，循环的质量远不如循环中持续执行的内容重要。
在艰难的优化问题上，循环的质量远不如循环中持续执行的内容重要。
HN 评论区
125- o10449366
/goal 模式已经取代了 plan 模式，成为我的首选。这是我目前 95% 的 AI 工作流中使用的模式：
1. 阅读 Y 的 X 功能，告诉我你何时完全理解了它（如果摘要中有任何细节缺失，就重复直到上下文被充分激活）
2. 现在几点了？
3. /goal 从 $time 开始，花 X 分钟撰写一份关于 $feature 的技术设计文档。文档中绝不能有任何模糊语言或歧义。请阅读 carry_forward_requirements.md 和 testing_best_practices.md，并将它们明确地整合到你撰写的文档中。文档完成后，应能让一个没有上下文背景的开发者直接执行，并包含具体的代码、文档引用以及所需的变更。请花满 X 分钟来撰写和审查这份文档——不要提前结束并等待。
根据我的经验，哪怕只是强迫 GPT 花 10 分钟写一份设计文档，其生成的计划也比 plan 模式更稳健，而且能节省我原本需要在 plan 模式初稿上反复迭代的时间。
- enraged_camel
自 GPT 5.6 Sol Xhigh 发布以来，我一直在广泛使用它，同时也在使用 Fable 5。
我的印象是，它的智力水平大约相当于 5.5，但他们把“ relentless（ relentless 指不知疲倦、 relentless 的推进力度）”的刻度拨到了十一。这使得它更有可能完成你交给它的任务，我认为这也是它在基准测试中看起来具有竞争力的主要原因。然而，这也意味着它更有可能诉诸……非传统、怪异甚至 outright unsafe（完全不安全）的方法来完成任务。所以我必须像鹰一样盯着它。
前几天，它试图通过 CLI 命令读取生产环境的 env 变量。它当时处理的任务根本不需要这样做。我用于该 CLI 工具的 SSH 密钥绑定在我的 1Password 上。所以当代理失败（因为我从未认证过 SSH 密钥访问）时，它试图接管我的电脑，这时我收到了一个系统提示。那一刻我停止了代理，并问它为什么这么做。它说它想潜入 1Password 本身，看看能不能拿到密钥。我问他为什么需要生产环境的 env 变量，它思考了一会儿，承认其实并不需要。所以从昨天起，我停止了使用“替我批准”模式，现在只用它来做简单的调整和修复 bug。
Fable 不仅更聪明，而且洞察力也强得多。它能更有效地嗅出我的意图，其“现实世界”的知识储备让它能像一位拥有领域专长的资深产品经理一样行事。它还能跳出框框思考，提出一些我……
- tyleo
顶部的图表有点令人困惑。它写着“越低越好”，但 Y 轴却是倒置的！所以在视觉上，图表中位置越高越好，但在数值上却是越低越好。
- theptip
很棒的评估！如果你是在比较搜索策略，ultra 模式可能更胜一筹。很期待看到后续关于这方面的评估。
Ultra 模式可以并行展开多个调查员，在预定义的检查点进行对抗性审查，还能做一堆其他聪明的事情，以避免陷入局部最优解。
一般来说，正如 OP 所指出的，/goal 模式更适合单线程调查或小规模的散点/收集任务。
- Tenoke
Claude 似乎会在非常漫长的工作会话中（那些需要数周开发的任务）忘记你告诉它的东西，无论你告诉它多少次哪些部分特别重要。我不使用 goal 模式（我想我应该用），但推测它能让模型真正记住最重要的指令。我认为这里讨论的是较短的会话，在这种场景下该问题出现得没那么频繁。
- sreekanth850
Anthropic 在代码领域正被 OpenAI 打得落花流水。直到去年三月，我还在使用 Claude Code。我不是企业客户，而是一名负责任的 AI 用户，不过度消费，使用基础计划来管理总共 40 万行代码的仓库。我们向地方政府销售产品，团队只有 3 人。Claude Code 超级慢，从来无法正确修复问题（尽管有完善的测试用例、可观测性、文档和分层架构）。在迁移到 Codex 后，生活变得轻松多了，不再有使用焦虑。现在每个团队成员用两个 Codex Plus 账号就能管理所有事情。Anthropic 是时候停止制造恐慌，转而构建高效的模型了。并不是每个人都需要 Fable。人们需要的是能高效解决问题的模型。
- varispeed
这两个模型在处理复杂问题时都完全没用，因为它们的训练数据存在偏差，导致它们只能部分检测到自己输出中的问题。随着你深入探讨正在工作的主题，答案只会越来越差。我曾以为可以结合 Opus 4.8 和 GPT-5.5 来打磨我手头的一份文档。结果 Fable 5 和 GPT-5.6 把它彻底毁了。不仅文档不再具备人类可读性，而且完全不合逻辑。
- akoboldfrying
如果你好奇巴黎问题的实际最优成本是多少，我建议将该问题建模为整数线性规划（ILP），并提交给 NEOS 上的 Gurobi 求解器 [0]。Gurobi 可能是最强的商业 ILP 求解器；大公司为此支付巨额费用，用于优化排程、工业流程等。我不确定它能否在 NEOS 提供的 8 小时内将该问题求解至最优，但有可能——KIRO 与车辆路径问题（Vehicle Routing Problem）有一些相似之处，而该问题的变体在商业上非常重要。无论如何，Gurobi 是个怪兽，即使得不到精确解，它也会给出一个下界（可能不紧，但依然很有趣）。