Fable 5 vs GPT-5.6 Sol NP难问题对决：/goal模式效果实测

Fable 5 vs. GPT-5.6 Sol 在 NP 难问题上的对决：/goal 有帮助吗？TL;DR：我给了 Claude Fable 5 和 GPT-5.6 Sol 同一个未发表的 NP 难优化问题，分别测试了启用和禁用原生 /goal 模式的情况。

Fable 5 绝对是一头猛兽；/goal 并非颠覆性功能。背景：这是一个最初提交给黑客马拉松学生的运筹学问题。几年前我花了一周时间用 C++ 解决它，因此拥有一个有用的人类基线。Fable 5 在这个基准测试上表现惊人。

它整体上给出了最佳解决方案，其一致性是我在这个问题上从未见过的。这是纯粹的原始智能，令人难以置信。另一个结果是，/goal 并非一个通用的“再努力一把”开关。它改变了控制循环和搜索路径。有时能找到一个更好的解区域，有时则让一个坏主意有更多时间发酵。

所有代码、提示词、结果表格、排除项和轨迹注释都在 CLIArena 中。这是我关于该基准测试的第一篇文章的后续。问题 KIRO 是我在 2018 年作为工程专业学生研究的一个光纤网络设计问题。

给定格勒诺布尔、尼斯和巴黎的有向距离矩阵，求解器必须使用环路和短链连接分配点和终端，同时满足多个结构约束。目标是总电缆长度，越低越好。一个有效的网络由以分配中心为根的冗余环路组成，这些环路的塔上悬挂着短分支。

每个塔必须恰好出现一次，反转一段电缆可能会改变其成本。搜索空间有多大？没有单一的闭式计数，因为一个解可以使用任意数量的环路、可变环路大小以及不同锚定和排序的分支。但仅巴黎就提供了一个有用的下界。

即使忽略排序和分支，仅将 532 个终端分配给 11 个分配中心，就有 11^532 种可能分配。一个更强的下界来自一个故意受限的有效解族：恰好 19 个环路，每个环路 28 个终端，没有分支。

这覆盖了所有 532 个终端，因为 19 x 28 = 532，同时保持在每个环路 30 个终端的限制以下。对 532 个终端排序，将该排序分成 19 个连续组，除以 19!因为环路集合是无序的，并为每个环路选择一个中心： (532!

/ 19!) x 11^19 ≈ 10^1223。我测试的内容：主要实验故意范围狭窄：结果：在集中重复旗舰对比之前，我为扫描中的每个模型运行了一组匹配的 30 分钟无提示对比。对于 Fable 和 Sol，图表使用了来自重复标题集的 Pair 1；

其他四个模型各有一对。然后我重复旗舰对比，直到 Fable 5 和 Sol 各有三次匹配运行。负值表示 /goal 更好。Goal 在六次试验中赢了四次，因此仅胜率就让该功能看起来有用。

均值则揭示了另一半：两个模型通常获得小幅收益，偶尔遭受大幅回撤。这就是为什么 /goal 赢得了大多数运行却拉低了两个模型的均值。Fable 也明显更强。它的普通均值比 Sol 好 1,875 分，goal 均值比 Sol 好 1,984 分。

更重要的是，Fable 普通模式的结果仅分布在 319 分范围内，而 Sol 普通模式则跨越了 1,958 分。Fable goal 模式产生了最佳清洁分数 31,934；Fable 普通模式是最安全的配置。

深入探讨 goal 命令：同一个命令隐藏了两个不同的系统。Claude Code 和 Codex 都暴露了 /goal，但实现方式根本不同。Claude Code：一个独立的评估器。Claude Code 将 /goal 实现为会话范围的 Stop 钩子。

每次主模型轮次后，一个小型评估器模型（默认是 Haiku）读取条件和对话。它返回是或否并附理由。否则开始另一轮；是则清除 goal。评估器不能使用工具或检查文件，只能判断对话记录中出现的证据。

这可以捕捉过早退出，但无法知道另外一千万次求解器迭代是否值得。Anthropic 的 goal 文档：请记住，Claude Code 不是开源的，所以我们只能依赖 Anthropic 告诉我们的信息。

Codex：持久状态和生命周期工具。我还阅读了基准测试版本 Codex CLI 0.144.4 的源代码。

Codex 将 goal 视为持久化的线程状态：TUI 保存活动线程的目标，SQLite 存储其状态和预算核算。工作模型接收 create_goal、get_goal 和 update_goal 工具。

如果线程在 goal 激活时变为空闲，Codex 会注入一个包含目标和完成审计的延续轮次。Claude 将完成判断委托给另一个模型。Codex 让工作模型声明完成，然后在持久化 goal 保持激活时恢复它。

Claude 的评估器是独立的，但只能看到对话记录；Codex 能看到文件和工具，但实际上是给自己的作业评分。为什么 /goal 能赢得大多数运行却仍然是一个糟糕的默认设置？在普通编码任务中，进度通常是清晰的：多一轮可以修复测试或完成迁移。

优化则不同。一旦智能体选择了求解器，额外的时间既可以放大好的决策，也可以放大坏的决策。这正是这里发生的情况。当 goal 维持了 Fable 快速编译的组合或 Sol 成功的链重分区时，它有帮助；

当 Fable 构建了慢速求解器或 Sol 致力于穷举锚点扫描时，它有害。中位数略微向正确方向移动；坏尾则向错误方向移动得更远。局限性：这是一个未公开的 NP 难任务，而非通用编码排行榜。只有 Fable 和 Sol 有三个干净的匹配对。

其他比较混合了提示词、包装器版本和时间限制，并且试验通过可能已发生漂移的订阅服务顺序执行。尽管任务元数据声明了一个 CPU，但容器暴露了八个 CPU，这有利于 Fable 的并行组合。

每个评分的 Fable 和 Sol 输出都是有效的，部分原因是包装器要求早期检查点和最终验证。该基准测试衡量的是完整系统：模型、CLI、提示词、订阅服务和测试框架。复现方法：基准测试任务、包装器、分析脚本、图表生成器和完整的证据备忘录都在 CLIArena 中。

原始作业目录因其大小而被排除在 Git 之外，但备忘录记录了每个可发布的分数、城市细分、运行时间、策略、排除项和运行 ID。主要命令为：

RUN_ID=article-kiro-YYYYMMDD-clean \ PHASE=nohint-all \ . /scripts/run_subscription_article_matrix.sh \ uv run python scripts/summarize_

subscription_article_results.py RUN_ID ... \ uv run python scripts/analyze_subscription_article_results.py RUN_ID ... 我会放在标题中的结果不是 goal

有帮助或有害，而是一个持久化功能可以赢得大多数单独试验，同时使观察到的平均性能变得更差。在一个困难的优化问题上，循环的质量不如循环持续执行的任务质量重要。