Meta 推出 Muse Spark 1.2 及专用编码工具

Meta 正式发布了其模型的最新迭代版本 Muse Spark 1.2，并同步推出了一款专为该模型设计的编码助手工具——Muse Code。尽管 Muse Spark 1.2 是核心更新，但 Muse Code 作为前置重点被特别强调。这是一个基于终端的命令行编码工具，旨在通过特定的工作流提升代码生成效率。作者指出，虽然官方将其称为“代理（Agent）”，但其本质是一个针对 Muse Spark 1.2 模型优化的命令行工具。该版本目前处于 Beta（测试版） 阶段，支持 Mac 和 Linux 系统。这一跨平台特性对于开发者而言至关重要，因为它避免了强制使用 macOS 环境的限制。

“Muse Code operates with a simple agent loop plus a set of async background agents.”

该工具的一个显著技术特点是其子代理（Sub-agents）的协调机制。与传统为每个任务单独生成临时代理不同，Muse Code 采用了一种同步后台代理（Sync background agents）架构。这些子代理在整个会话期间保持活跃状态，而非仅在处理特定任务时生成和销毁。这种设计旨在通过更持久的上下文关联来更快地解决复杂问题并提高准确性。虽然子代理概念并非全新，但这种持久化的实现方式在现有编码工具中较为少见。

模型迭代与基准测试数据对比

Muse Spark 1.2 被视为 Muse Spark 1.1 的迭代升级版本，官方通过一系列基准测试展示了其性能提升。在相关的编码和代理能力评估中，Muse Spark 1.1 的数据以浅蓝色图表显示，而新的 Muse Spark 1.2 则以深蓝色图表呈现。作者注意到，这些基准测试的结果可能受到两个因素影响：一是模型本身的整体能力提升，二是该模型与 Muse Code 工作流的深度适配。为了优化这种协同效应，Muse Spark 1.2 在与 Muse Code 共同训练（Co-trained）的过程中进行了优化，以确保两者结合时能达到峰值性能。因此，本次测试将同时评估模型本身及其在专用编码工具中的表现。

除了常规的基准测试，官方还展示了一些更具趣味性的案例，如由模型直接生成的游戏。这些演示虽然技术难度不如长期复杂的基准测试高，但直观地展示了模型的代码生成能力。作者表示更倾向于关注这些实际生成的应用案例（如游戏），因为它们更能体现模型在真实场景下的可用性。测试方法论的细节表明，Meta 试图通过这种联合训练和专用工具链来最大化模型在编码任务上的潜力。

定价策略与测试环境配置

在使用 Muse Spark 1.2 API 进行测试前，作者详细分析了其定价结构与信用额度。Muse Spark 1.2 拥有 100万 Token（tokens）的上下文窗口。标准 API 的价格为：输入每百万 Token $1.25，输出每百万 Token $4.25。这一价格与前任版本 Muse Spark 1.1 保持一致，未发生变动。此外，Meta 还提供了一种“贡献者版本（Contributor version）”，价格大幅降低至：输入每百万 Token $0.10，输出每百万 Token $0.20。然而，该低价版本有两个主要限制：一是用户允许 Meta 使用其数据进行训练，二是存在速率限制（Rate limited）。

“I don't want to be rate limited, so that's a big part of the reason why I'm opting to use this one right here.”

鉴于测试需要稳定的响应速度，作者决定放弃低价版本而选择标准版 API。尽管这意味着更高的成本且数据会被用于训练，但避免了速率限制对测试流程的干扰。作者账户中剩余的免费信用额度为 $8.12，这将用于覆盖本次测试的全部费用。在具体的测试设置中，作者计划首先运行传统的 Browser OS Test V2.5 基准测试，以评估模型的基础能力。同时，作者也计划尝试 Muse Code 提供的特殊技能（Special skills）和规划网格（Plan grill）功能，以观察这些额外特性是否能带来显著的性能提升。测试过程中还将监控 Muse Code 终端代理的表现，因为这是与模型同步发布的新产品。

实际测试过程与初步结果验证

在正式运行基准测试时，Muse Code 首先请求权限以执行网络操作。它随即向 Google DNS (8.8.8.8) 发起 ping 请求，以验证互联网连接状态。确认网络通畅后，工具自动开始获取 3.js 库的特定依赖项，这是构建 Web 应用所必需的前置步骤。作者还注意到该模型支持多种可选的推理模式（Reasoning modes），当前测试运行在 Ultra 模式下，这是该模型提供的最高潜在推理能力层级。

经过约 5.5 分钟的处理时间，测试完成。作者的信用额度从初始的 $8.12 下降至 $7.18，表明单次基准测试消耗了约 $0.94 的费用。查看 Browser OS Test V2.5 的结果显示，生成的系统运行稳定：壁纸设置为“Void Mesh”，右上角显示了时间信息。作者对这一结果表示满意，并推测这可能是由于模型针对此类特定测试进行了优化或使用了特殊功能。目前系统状态稳定，作者准备进行下一轮更具挑战性的“大型”基准测试，以进一步验证模型是否达到了性能瓶颈（Bench maxed）。

界面风格与基础功能测试

视频首先展示了新版本的视觉设计，用户注意到新的紫色渐变风格和类似黑客风格的斜体文本提示。在创建新文件时，系统自动生成了名为“Hacker One”的文件。随后进行的绘图测试中，用户尝试生成照片但操作失误导致失败，接着成功生成了一个名为“Nebula Pad”的绘图作品并保存了时间戳。在设置界面中，用户观察到更干净的LLM文本风格，并确认了“Singularity Core”等核心功能依然存在。此外，上传图像的功能也被验证为可用。

“I'm seeing like hints of just this style with the italicized text seems text. It seems like the new version of like the purplish gradients.”

GTA克隆游戏性能与交互体验

接下来测试了一个名为“Steel City”的GTA风格克隆项目。用户指出该项目的运行速度非常缓慢，并对比了之前使用Quan 3.8 Max模型时的体验。虽然之前的版本也有速度限制（约40 km/h），但Muse Park 1.2的表现被评价为“需要医疗警告”。在物理引擎方面，车辆和建筑物缺乏网格碰撞体（mesh colliders），导致玩家角色可以穿过物体。尽管存在这些缺陷，用户认为其整体表现仍优于Muse Park 1.1版本。

“It is quite slow... It's about a toss-up.”

模型选择与C++滑板项目规划

在测试设置中，用户展示了模型选择机制：可以选择折扣版（允许训练数据使用且速率受限）或全价版。为了获得最佳性能，测试全程保持在“Ultra”模式。随后进入C++自包含滑板游戏的规划阶段。用户特意指定了200年代初纽约市街区作为背景，并要求不使用Raylib库以增加难度。系统生成了一个包含Markdown格式计划的方案，并启动了“Grill”功能来压力测试该计划。

“I want to try this grill feature as well. It basically created a plan, put it in markdown... and said it's not going to use Raylib.”

C++滑板项目执行结果与缺陷分析

经过约12分钟的生成过程，用户花费了$4.41完成了C++滑板游戏。最终结果被评价为“不太好，但也不算糟糕”。主要缺陷包括：摄像机容易被建筑物遮挡、滑板与玩家角色绑定导致无法独立移动（这是小模型常见的特征），以及缺少预期的多个行人和两个街区块。用户指出，让AI自行调试往往不如人类直接干预有效，因为人类能更直观地发现摄像机视角和物理交互的逻辑错误。

“It's not great. But it's also not horrible... the board does not move independently of the player in this result.”

迭代反馈与游戏可玩性修复

测试者对 Muse Spark 1.2 进行了严厉的反馈，旨在推动模型突破现有局限。经过调整，Muse Spark 1.2 在“Gate Game”测试中显著改善了核心交互问题。虽然整体图形表现与之前版本持平，但此前阻碍游戏可玩性的重大缺陷得到了修复。最明显的改进在于棋盘不再与玩家角色绑定移动，且新增了身体、手臂和脚部的动作特效。在随后的“Rail Grinding”（轨道滑行）测试中，虽然初期出现了滑板丢失导致脚部滑行的小插曲，但整体物理反馈和动作连贯性明显优于前作。测试者指出，尽管场景中行人过多略显杂乱，但主要玩法障碍已被清除。相比之前的版本，虽然仍未达到完美状态，但在可玩性方面实现了实质性提升。

现实物体3D建模：从失败案例到初步成功

为了测试AI处理真实世界杂乱数据的能力，测试者使用了一台20多年前的微型遥控F1赛车底盘作为对象。由于电池仓损坏，测试者拍摄了多张不完美的实拍照片（包含测量垫背景），要求AI重建3D模型。这一测试旨在验证视觉理解与建模能力的结合。作为对比，GPT-5.6 Soul 和 Fable 5 在类似任务中表现糟糕，前者结果完全偏离，后者甚至在使用网格纸绘图辅助的情况下仍给出“令人尴尬的失败”结果。相比之下，Muse Spark 1.2 在消耗了 50美分（此前剩余免费额度）后，生成了初步渲染图。尽管预览效果可能略有误导，但模型大致还原了整体形状。测试者指出，虽然背部细节和孔位分布不够精准，但对称性有所体现。通过网格纸对比估算，模型长度误差约为 10毫米（实际约160mm），在如此混乱的输入条件下，这一尺度还原度尚可接受。

前端网页设计与复杂3D渲染综合测试

最后一项测试要求AI为虚构品牌“Slapist”设计一个高端手表网站，需包含带有电影级运镜的3D渲染表盘、英雄区域及 aesthetically pleasing 的整体设计。Muse Spark 1.2 成功生成了包含3D手表模型的网页。测试者观察到，表盘指针逆时针转动属于常见异常现象。尽管相机环绕运镜导致部分视觉伪影（如表冠看似旋转），但刻度位置准确，日期显示为“8号”这一细节处理得当。网页整体布局合理，产品卡片支持颜色选择交互。虽然部分元素（如表带）被遮挡或布局存在小瑕疵，但测试者认为这是所见过的最佳表盘绘制之一。整体而言，该版本在处理复杂前端需求与3D内容生成结合的任务上，明显优于前代产品。

3D建模测试：OpenSCAD引擎模型的生成局限

评测者首先对Meta Muse Code Spark 1.2进行了3D建模能力的测试，目标是用OpenSCAD代码生成一个包含真实RC电机的2.6升引擎模型。测试结果显示，该模型在局部细节上表现出色，评测者指出它在顶部组件的生成上“做得非常出色”（Fantastic. Very well done），甚至让评测者误以为它生成了完整的装配体。然而，核心功能存在致命缺陷：模型未能生成容纳真实电机的空腔，导致无法实现“适配现实部件”这一关键需求。尽管在局部几何结构上展现了能力，但整体装配逻辑的失败表明其在处理复杂物理约束时仍有不足。此次测试消耗了$6.85，且评测者特意将模型设置在最高推理设置（highest possible reasoning setting）下以追求最大性能，但结果仍不尽如人意。

飞行模拟器测试：UI良好但玩法缺失

随后，评测者尝试了一个经典的“老派”飞行战斗模拟器游戏生成任务。该测试要求模型从三架飞机中选择，并具备一定的人物个性和趣味性。经过9分30秒的生成时间，总花费上升至$8.47。从用户界面（UI）的角度来看，生成的游戏看起来相当不错。然而，实际体验却令人失望：评测者认为模型并未完全理解其期望的玩法（not quite grasped what I was hoping for），虽然能看到其他飞机的模型，但游戏缺乏可玩性（not hyper playable）。尽管画面中出现了敌机并具备基本的交互元素，但整体体验并未达到“真正可玩”的标准，显示出模型在将视觉生成转化为互动逻辑方面的局限性。

复杂叙事游戏：Street Eater与Steve的PC维修店

评测者接着测试了两个更复杂的叙事驱动游戏。首先是“Street Eater”，这是一个带有开场动画的吃豆人风格游戏，评测者为其提供了详细的API密钥以生成语音资产。花费达到$11.13后，生成的游戏包含了音乐、角色对话以及独特的开场剧情（如Gary被插队）。虽然车辆比例过小是一个瑕疵，但模型成功实现了复杂的场景互动和音效集成。评测者评价道：“这个模型有点疯狂，就像Opus 5一样。”

最后是一个名为“Steve the PC Repairman”的复杂提示词测试，旨在生成一个具有Windows 98美学风格的浏览器OS游戏。评测者使用了“YOLO模式”（全力生成）并允许模型自主规划场景。仅耗时6分钟，生成的游戏便包含了完整的角色对话、跳过功能和彩蛋（如Doom元素）。评测者对结果感到满意，认为其美学风格和叙事完整性远超之前的版本。对话内容如“Windows 98 will outlive us both”展现了模型对特定时代氛围的捕捉能力，且成功解决了之前版本无法通过开场动画的问题。

沉浸式叙事游戏生成：从指令到互动的完整流程

本次测试的核心案例是要求AI构建一个名为“Steve the PC Repairman”的伪电影游戏。该任务不仅涉及代码生成，还包含复杂的叙事逻辑和资产调用。AI成功生成了开场剧情：黑客Anton Volkov（自称silver support）在布拉格策划窃取Matryoshka金库数据，目标涉及40,00名受害者。系统通过类似游戏过场动画的方式呈现剧情，包括窃贼Stevo与处理人Mira的通讯细节。这是一个显著的进步，因为AI能够自动拉取API资产并构建连贯的场景。

在交互环节，用户扮演Stevo执行任务。AI提供了详细的行动指南：“Volkov's penthouse is dark tonight. Only skeleton crew... Use the cloner on a guard with red badge.” 用户需要克隆持有红色徽章的守卫以通过生物识别检查。尽管过程中出现了一些小插曲，如用户误操作或AI对指令的延迟响应（“Oh, sh I hate when this happens”），但整体流程顺畅。最终任务成功完成，金库数据被释放，Volkov帝国崩塌。这种从剧情设定到具体操作指令的无缝衔接，展示了模型在长上下文和复杂逻辑链上的处理能力。

“Okay, so we're getting some instructions from our handler. Okay. Is that a ticket? It's like a cutscene.”

性能对比与成本分析：Spark 1.2的进化轨迹

评测者将Muse Spark 1.2与前一版本进行了对比，发现“It became significantly, significantly better”。在相同的提示词下，新模型在处理复杂游戏生成任务时表现更为稳定。以“Steve the PC Repairman”为例，该任务在目标模式下仅耗时6分钟；而随后的FPS地铁站游戏测试虽然问题难度不高，但AI在21分钟内仍在进行故障排除和修复。这种持续的调试能力表明模型正在逐步收敛解决方案，尽管过程略显缓慢。

成本方面，评测者特意关闭了允许使用用户提示进行训练的折扣模式，以获取更真实的定价数据。测试开始时账户余额约为$8.50免费额度，最终支出达到约$14。加上之前的测试费用，今日总花费约为$23。虽然这一价格在AI编码代理中不算低廉，但考虑到其生成的内容质量和功能完整性，评测者认为“it's just better than I expected”。然而，对于是否值得这一价格，评测者持保留态度，认为其表现虽好但并未达到惊艳的程度。

综合评估：优势、劣势与市场竞争格局

尽管Muse Spark 1.2在叙事游戏生成上表现出色，但在其他测试项目中表现平平甚至令人失望。例如，飞行战斗模拟器任务中“properly show the plane models. Everything was inverted”，视觉效果完全错误；手表网站生成仅属“acceptable”（可接受），缺乏亮点。评测者指出，“I'm not blown away with any one specific result”。

在竞争格局方面，Meta仍处于追赶阶段。评测者认为Anthropic、xAI、Google和OpenAI等竞争对手正在快速迭代，尤其是即将发布的新版Grok可能超越Muse Spark。此外，Thinking Machines等新兴实验室也在推出具有竞争力的模型。“I would pretty heavily assume [Grok] is going to beat this”。尽管Muse Spark 1.2相比其早期版本（1.0至1.2）有代际提升，但在当前激烈的市场竞争中，其性价比和性能优势尚不足以形成绝对壁垒。评测者总结认为，“pricing-wise, this may be a little too weak to be competitive”。

“I think overall I'm not blown away, but we have to remember that Muse Spark 1.0 came out, then 1.1, and now we're at 1.2.”

基于负面反馈的自我迭代案例

在针对滑板游戏（Skateboard game）的测试中，模型展现出了令人印象深刻的基于反馈改进结果的能力。尽管提供的反馈并非极具建设性，甚至带有强烈的情绪色彩，模型依然能够准确捕捉核心问题并加以修正。测试者通过直接表达不满来观察模型的响应，这种非结构化的交互方式验证了其在复杂指令下的适应性。

"I basically just yelled at it and was like, 'WTF is this?' And it definitely took that to heart and improved the main things that we'd complained about."

这一案例表明，当前的AI模型在处理模糊或情绪化的负面反馈时，具备将主观抱怨转化为具体优化行动的能力。这种自我修正机制是评估编码代理实用性的关键指标，证明了其在无需精确调试指令的情况下，仍能通过多轮交互提升输出质量。这种鲁棒性对于实际开发场景中的快速原型迭代具有重要意义。

模型独特的UI风格与独立性观察

在浏览不同测试案例时，一个显著的特征是各个AI模型开始呈现出独特的用户界面风格（UI style）。这种差异不仅体现在浏览器操作系统层面的元素上，更细微地反映在文本卡片和具体游戏场景中。例如，在“Steve the PC Repairman”（史蒂夫电脑维修工）游戏中，以及Subway FPS提示符中，都能观察到这种特有的视觉或交互风格。

"It does seem to have a more like, it has its own UI style... Like, this is its own like unique style."

这种风格的独立性暗示了底层模型正在形成各自独特的交互范式。测试者对此持积极态度，认为这种多样性反映了模型的独立性。与早期AI工具高度同质化的输出不同，现在的模型开始在呈现方式上展现个性。这种风格化差异不仅是视觉上的变化，更可能代表了模型在逻辑处理和用户交互策略上的深层分化。对于开发者而言，理解并适应这些不同的风格有助于选择最适合特定项目需求的AI工具。

Muse Code代理的成本与效率分析

本次测试的最终成本核算显示，总花费约为$15.25。如果算上之前使用的8.5美元免费额度，整个测试周期的总价值评估在$24至$25之间。这一数据为评估AI编码工具的性价比提供了量化基准。测试者推测，随着功能深入使用，成本可能会略有上升，但目前的支出水平在可接受范围内。

"So, let's call the entirety of today's testing between 24 and $25, including the 8 and 1/2 dollars of free credit that we went through."

在引入新的编码终端工具Muse Code后，测试重点转向了其子代理（sub agents）的工作机制。特别是在启用“目标模式”（goal mode）后，模型在6分钟内完成了Steve the PC Repairman游戏的提示构建。值得注意的是，这一过程消耗的token数量相对较少。这种高效率与低资源消耗的结合引发了测试者的兴趣，但也带来了一些疑问：为何在如此短的时间内能完成复杂任务且token消耗低？这可能与目标模式下的高度自动化规划有关。测试者建议用户亲自尝试“目标模式”，以验证其在实际场景中的表现。

测试总结与功能推荐

本次对Meta Muse Spark 1.2及新编码代理Muse Code的测试涵盖了从游戏生成到代码终端工具的多个维度。核心发现包括模型在负面反馈下的自我优化能力、各模型间逐渐形成的独特UI风格差异，以及Muse Code在目标模式下展现出的高效低成本特性。尽管某些机制（如低token消耗下的快速生成）仍需进一步探究，但整体表现证明了该工具在实际应用中的潜力。

"It was interesting the way the sub agents work... I would urge anyone interested in trying this."

测试者建议对AI编码工具感兴趣的用户，特别是那些希望探索自动化开发流程的人，亲自尝试Muse Code的目标模式。通过实际体验“目标”与“计划网格”（plan grill）等功能，用户可以更直观地评估其是否适合自身的工作流。本次测试不仅展示了技术细节，也为后续AI辅助编程工具的选型提供了参考依据。

结论

Meta Muse Spark 1.2在复杂叙事游戏生成与基于反馈的自我迭代方面表现显著优于前代，展现出强大的长上下文逻辑处理及鲁棒性。其配套的Muse Code代理通过持久化子架构提升了编码效率，尤其在“目标模式”下实现了低成本快速生成。然而，该模型在物理模拟、3D几何精度及视觉渲染一致性上存在明显短板，且API定价缺乏竞争力。总体而言，它适合需要高容错率的叙事类应用开发，但在对物理准确性和视觉保真度要求极高的场景中尚不成熟。