Meta Muse Wonder Full 实测：与 Opus、Sol 比较编程智能体

Meta 发布了 Muse Wonder Full。提前试用之后，我认为它已经能够与领先的编程智能体竞争。这并不意味着它能赢下所有测试，也不意味着我会放弃现有工具；但现在确实多了一个值得认真考虑的选择。

我知道大家会怀疑 Meta 是否为这个评价付了钱。答案是没有。我获得了提前体验的机会，视频有另一个赞助商，但我的判断来自自己让模型完成的工作。

这里有两个名字非常相近的版本：Muse Wonder 和 Muse Wonder Full。按照我的体验，普通版速度更快，约为每秒 120 个 token；Full 接近每秒 50 个。理解下面的例子时，不能把两者混为一谈。

标准版有 API 价格，但录制视频时 Full 通过订阅提供，尚未公布 API 定价。与许多选择相比，订阅价格不高，但我还没有摸清用量限制，因此现在比较总体成本还为时过早。

标准版 Wonder 的标价是每百万输入 token 4 美元、每百万输出 token 20 美元、每百万缓存读取 token 0.20 美元。这些数字适用于标准版，不适用于 Full。比起命名，我更关心 Full 的实际能力。

第一个弱点是 3D。在拖拉机和 Fish Slap 的例子里，游戏机制可能可以运行，但三维物体看起来很糟。Meta 自己也承认空间和 3D 任务较弱，所以精美的交互游戏演示并不是选择这个模型的理由。

我猜测，一些实验室可能使用了相似的专门 3D 训练环境或数据集。这只是推测，但可以解释为什么一个模型的通用编程能力很强，却仍会在这类演示中落后。单一视觉测试不能代表通用智能。

订阅的价值还取决于 Full 实际允许使用多少次。我目前无法告诉你用量上限在哪里，所以有吸引力的订阅价格只是决策的一部分，并不是经过测量的单次任务成本。

在我的 SkateBench 命名测试中，Full 得分约为 95%，标准版 Wonder 约为 81%。画面是测试运行中的快照，而这个基准只衡量范围很窄的命名任务。它是有用的证据，却不能给编程能力排出完整名次。

如果你的主要目标是漂亮的用户界面或精致的 3D 视觉效果，我的例子就没那么令人振奋。更有意思的结果出现在我把真实代码仓库交给模型，让它调查问题并阅读其推理和修改的时候。

我让它审查加载缓慢的 Thunderstore 模组索引。它区分了 CDN 表现正常与索引缓存效果不佳这两件事，并按优先级列出具体问题。报告简短易读：目标是根据发现采取行动，而不是欣赏一份冗长的回答。

我常用的 AGENTS.md 会要求模型照顾我的 ADHD，使用简短、简单的英语。没有这条指令时，它也可能更加啰嗦，但即便如此，我仍觉得它的写法独特且易读。我原以为 Meta 的模型会更像 Claude，这个模型却经常不是那样。

我还在 Rust 项目 Lust 上测试模型：分别让 Muse 和 Opus 执行任务，再请一个评审模型小组比较修改。这只是使用模型评审的小规模实验，并不是对模型所有任务能力的严格测量。

其中一次比较里，评审以 41 比 30 更偏好 Opus 的结果，Opus 的结果速度还快了约 2.5 倍；Muse 的版本存在一个 bug。这是一个重要的反例，说明不能简单地说 Full 总能追平最强的替代模型。

尽管如此，整个工作过程中 Muse 仍产出了很多最终合入的修改，包括有用的测试、审查和模糊测试探索。我发现让模型交换方案很有帮助：Opus 可以处理风险较高的设计，Muse 则负责更常规的修复和审查。

质量和速度都取决于具体任务，而且我们仍不知道 Full 的 API 价格。一个模型给另一个模型打分值得一读，但它不是独立的成本或质量测量。

Full 作为其他智能体的指挥者，使用体验也不错。我看重这样的委派方式：要求执行者阅读实际代码并提供证据，而不是把搜索片段当成证明。它分配任务和整合结果的方式让我用起来很舒服。

这里有一个主观陷阱：就像测评音箱的人可能因为新声音而兴奋一样，我也可能部分是因为陌生感而喜欢这个模型不同的写法。我希望把这种偏好与它是否真的做出了更好的工程决策区分开。

使用几天后，在我自己的工作中，它似乎也犯了更少的低级错误。这只是短时间内的个人观察，不是公开的错误率。你可以组合使用不同模型，而不必把每个任务都交给同一个模型。

一个远程更新 bug 展示了我为什么喜欢它的处理方式。我让多个智能体调查同一个问题。Opus 需要一些引导，但找到了问题并提交了拉取请求；这是合理且有用的结果。

在我的这次运行中，Sol 忽略了检查针对的是新服务器这一重要限定，并移除了一个 npm 检查，因而走向了错误的行为。它还遇到了提问工具的代理错误。这些是单次运行中的观察，并不意味着这个模型处理此类任务时总会失败。

Muse 把故障追踪到一个 HTTP 请求：追踪头触发了 CORS 预检。它还发现已有一个移除这些头的拉取请求，因此报告了原因，而没有在工作区里新增代码。这个简洁的诊断避免了不必要地创建一份相互竞争的修改。

在我非正式的 T3 架构评估中，Opus 领先，Full 接近 Astra，而标准版 Wonder 的表现明显较弱。评审可能偏向自己或同系列模型，而且没有任何模型找到了所有问题。这些分数描述的是本次测试设置，并非客观的通用排行榜。

Lakebed 评估对 Full 没那么有利：我看到 Full 大约是 5.75 分，Sol 是 9 分，Sonnet 约为 8.5 分。换一个基准就会改变排序，这正是我不会凭单一分数做购买决定的原因。

在一项 TypeScript 转 Rust 的任务中，比较结果显示 Full 的水平大致与 Fable 相当，同时完成得更快，约用了 17 分钟。再次强调，没有 Full 的 API 价格，速度和 token 数量不能告诉我们完成任务的美元成本。

我看到的 token 效率数字很接近：Full 每项任务约 53,800 个 token，标准版 Wonder 约 54,200 个。这提供了有用的背景，但不能证明两个版本成本相同，也不能证明任何一个比竞争对手便宜。

在另一项比较中，我审阅了针对八个拉取请求的发现。Opus 报告了 23 个问题，我认为其中 21 个有效、一个可能有效、一个错误，另外还有八条细枝末节的意见。Sol 报告了九个问题，其中七个有效、两个无效，没有细节意见。

Muse 报告了 16 个问题，其中五个是新发现，还有几个严重程度较高的问题。有些发现与其他模型重叠。这是一个小样本，有效性也由我判断，但它展示了多个审查者为何能互补。

接着，我让模型为 T3 的工作安排优先级。Opus 使用了十个受委派的智能体，花了约半小时；我的 Muse 运行中途被打断，总计约 17 分钟。时间只是估计，但比较其输出有助于观察真实的规划工作。

这些建议的基本主题是可靠性：先修复让现有功能失效的问题，再考虑不断增加新功能。相比计算智能体能产生多少个点子，这是一个更有用的优先级原则。

Muse 围绕主张和批评者组织调查，其中包括尝试证伪最高优先级的主张。我喜欢它直接的综合方式：工作顺序和支持证据更容易检查。

例如，它建议在判断积压的拉取请求之前先抽样，并处理配额和负载消耗问题。重点并不是必须接受每一项建议，而是智能体应展示足够的推理，让人能够评估优先级。

它还区分了根本原因与针对单个范围的补丁，例如处理 scope 导致的搁置问题；同时把较简单的第一优先级工作与更大的结构性问题分开。我觉得这份报告比另一个版本更容易阅读，但这种可读性偏好是主观的。

我的结论是，Full 确实是一个可以投入使用的模型。在很多情况下，我仍更喜欢用 Opus 处理最难的工作和做审查，Full 也有明显弱点。但它在真实代码仓库、任务委派和问题调查中展现出的优势，使它值得一试。

我还没有足够的信息了解 Full 的用量限制或未来 API 价格，因此不会建议你取消 Claude 订阅。用自己的工作测试它，比较结果和限制，保留真正有帮助的工具。更多有实力的实验室参与竞争，对开发者来说是好消息。

有用的问题并不是新模型是否永远赢了，而是它的优缺点在实践中出现在哪里、它能否可靠地处理你关心的任务，以及未来的价格是否适合这些工作。