先看证据
一次作曲测试，同时也是一次工具构建测试
2026年10月6日，Simon Willison介绍了 Scrimshaw Jukebox：他用 Claude Opus 5.5 测试模型能否创作电脑游戏音乐。提示词不只要求模型写曲，还要求它先设计一种简单的文本音乐格式，再做一个能播放示例曲目的交互页面，风格参照《猴岛小英雄》原版配乐。最后得到的不是一段单独的录音，而是一套可以承载曲目并播放它们的浏览器工具。
Willison的评价是，成品听起来“出奇地好”，而且比他原先希望的更像《猴岛小英雄》。这两句话既说明演示为何吸引人，也暴露了判断上的张力：风格相似可以让结果立刻显得贴题，却不能单独证明模型掌握了稳定的作曲能力。要读懂这个案例，得把“曲子好不好听”和“模型能否搭起一条可修改的创作流程”分开看。
文本乐谱把旋律变成可操作的结构
这套工具的关键不是把文字提示直接变成音频，而是先把音乐写成结构化文本。乐谱中可以描述速度、拍号、声部和乐段，解析器检查并编译这些内容，浏览器再按乐谱演奏。用户能够直接编辑文本，播放修改后的版本，也可以单独静音某个声部。这样一来，曲子不是封装好的成品，而是能被检查、拆分和反复改动的对象。
这种表示方式还让试听和创作处在同一条工作流里。作者要求模型同时设计乐谱格式和播放器，因此模型的任务包含了建立表达规则、按规则组织音乐，再提供一个听取结果的界面。对技术负责人来说，这比“模型写出了一段旋律”多出一个值得观察的能力维度：模型能不能定义一个足够清楚的中间表示，并围绕它交付可用工具。材料并未证明这种格式可以导入其他音乐软件，因而它目前更适合被理解为可编辑的演示环境。
声音由浏览器合成，不能把结果全算在模型头上
播放机制会影响我们怎样归因。项目源码说明，页面没有使用采样音频，而是在浏览器里通过 Web Audio API 实时生成声音，使用振荡器发出音调，再用滤波器和音量包络塑造音色与起落。因此，听到的成品是文本乐谱、解析与编译逻辑、合成器共同作用的结果，不等同于模型直接生成了一份录音。
这不是削弱演示，而是划清它实际展示的边界。模型参与了音乐的结构化表达和工具构建，合成器则决定这些符号如何成为声音。若团队要把类似流程用于游戏配乐草稿，评估就不能只听最终播放效果，还要看乐谱是否容易编辑、声部是否能独立调整，以及换一个播放实现后作品是否仍符合预期。现有材料展示了前两项的交互入口，却没有提供跨播放器或音色质量的对照结果。
六首曲目说明了覆盖面，不说明了评测结论
页面列出六首示例曲目，时长约从56秒到2分11秒，展示的速度约在66至152 BPM之间，拍号包括3/4、4/4和6/8。格式指南允许的速度范围则是20至400 BPM。它还用“每小节步数”组织时间：以4/4为例，每拍划分四步，一小节就是16步。这些数字说明工具覆盖了不止一种节奏和曲长，也让音乐成为可以明确操作的时间结构。
但曲目数量、速度范围和拍号种类并不是音乐质量的替代指标。它们证明页面提供了若干不同设定的可播放样例，不能告诉我们旋律是否原创、编排是否成熟，也不能说明模型在重复任务中能否维持质量。Willison的听感判断是有价值的观察，却仍是单人主观评价。现有材料没有独立听评、盲测或新旧模型对照，因此不能据此断言作曲能力是近期才出现的。
把它当成创作原型，而不是能力定论
对于实际团队，这个案例最可用的启发是把评估对象从一首成曲扩展到整条创作链。可以检查模型是否能提出可读的音乐表示，能否按格式生成可解析的曲目，工具是否让人方便地试听和修改，再分别判断最终音乐是否适合具体场景。这样的拆分能避免把播放器的声音效果误认成模型本身的作曲质量，也能指出流程中究竟是哪一环需要人工接手。
要判断能力是否进步，实验还需要控制模型版本、提示词、乐谱格式和播放机制，并让评审在尽可能一致的条件下听作品。尤其需要把风格贴合与原创性分开评估，因为这次结果比预期更像《猴岛小英雄》，但材料没有提供旋律相似性审查，也没有证明这种风格可以按要求收放。Scrimshaw Jukebox因此是一个有说服力的端到端原型，却不是关于模型音乐能力的完整证据。可以先用它探索可编辑的配乐草稿流程，再把风格控制、原创性和跨模型表现留给专门验证。