从提示词到可版本化的 Ableton 工程：Hallucinote 的 Claude Code + MCP 工作流
让 AI 参与音乐制作，最常见的结果是一次性的音频、MIDI 片段，或一串难以复现的提示词。真正进入制作阶段后，问题会变得更工程化：为什么这里要换和弦？鼓组、自动化和混音参数能否跟着 Git 一起回滚？在 Ableton Live 里手动调过推子之后，下次运行 Agent 会不会又把改动覆盖掉？
Hallucinote 是一个 MIT 许可证的本地创作环境，面向 Ableton Live 12 与 Claude Code。它不把歌曲当作一次生成结果，而是把音符、编曲、乐器链和混音状态分别记录为可读代码与可追踪快照：Agent 在歌曲工作区写入 build.py，再通过 MCP bridge 将结果推送到 Live。Live 里的工程仍是普通工程；工具提供的是一个可反复构建、检查和同步的创作闭环。
这篇文章不讨论“让模型一键写歌”。重点是理解它如何把 Agent 的非确定性创作过程，收敛为你能检查、修改和重放的工程产物。
两个状态源：代码负责重建，Live 负责试听与手工制作
Hallucinote 的歌曲目录是独立的 Git 工作区。其核心思想是把“可复现的决定”和“当下可听见的结果”分开：build.py 保存生成音符、编曲和可参数化的音乐决定；数据库和快照承载构建后的状态；Ableton Live 则承载真实的轨道、clip、设备链与返送轨，供人耳试听和继续制作。
这套分层避免了两个极端。只存 Live 的二进制工程，虽然方便试听，却难以看清 Agent 改了什么；只保留文本化 MIDI，又会丢掉在实际 DAW 中调出的乐器、路由和混音上下文。Hallucinote 的做法是让 Agent 把决定落到可读的 Python，再把它物化到 Live。
因此应把 build.py 当成歌曲的构建说明，而不是把它误解为通用音频渲染脚本。项目使用内置的 Python 生成器来表达节奏、低音或乐句等内容；Claude Code 选择生成器和参数，并把选择写进代码。相同的 build.py 在相同环境下可以重建相同的歌曲状态，但“把同一段自然语言提示交给一个新的 Agent 会话”并不保证得到相同的创作决定。可复现的是已经提交的作品状态，不是最初的对话灵感。
安装前先确认边界：它依赖 Live、Claude Code 与本机桥接
Hallucinote 不是云端 Ableton 替代品。官方当前标注的目标平台是 macOS 和 Windows 上的 Ableton Live 12；Ableton 没有 Linux 版。完整作者循环经过 Standard 与 Suite 验证，而需要测量式混音检查时，还需要 Max for Live（Suite 自带，或为 Standard 单独配备）。
安装需要已可用的 Claude Code、Ableton Live 12 和 uv。在 Claude Code 中添加 marketplace 并安装插件：
/plugin marketplace add brookstalley/hallucinote /plugin install hallucinote@hallucinote
插件已经包含技能、MCP server 与创作引擎；随后仍要执行一次 /hallucinote:ableton-mcp-install。这一步会安装 Live 侧所需的 Remote Script 与分析器。关闭并重新打开 Live 后，在 Preferences → Link, Tempo & MIDI 中把 Hallucinote 选到一个空闲的 Control Surface 插槽，最后重启 Claude Code。
不要跳过这个顺序。若 Agent 查询当前 set 时拿不到速度、拍号或轨道数，优先检查 Live 是否运行、Control Surface 是否已分配，以及 Remote Script 与插件是否因升级产生版本不匹配；这比反复让 Agent 重试更有效。
一次创作从“简报”开始，而不是从生成开始
在空的 songs 工作区中启动 Claude Code 后，可以用自然语言描述歌曲：风格、时长、段落、乐器和歌曲 slug。Hallucinote 会先把未说明但会影响结果的维度集中提出，例如速度、调性、拍号、段落时长和制作取向。确认后，它会在 songs/ 下创建 build.py、快照、测试与记录意图/决定的目录。
随后工作流并不是一次“生成完毕”。Agent 会选择每条轨道的乐器链——不只是音源，也包含效果与初始 send level——把音符生成逻辑写入 build.py，构建歌曲状态，再推送到 Live。官方将推送过程定义为固定顺序：
tempo → meter → tracks → returns → scenes → clips → mix → devices → routing → device-sidechain → envelopes → performed automation → arrangement → cues
顺序的价值在于依赖关系明确。比如先有轨道和 return，后面才能设置路由、设备侧链和自动化；也便于定位失败发生在“代码没有构建成功”、还是“Live 端连接或物化失败”。在 Live 里试听到的并非某个不可追踪的黑盒文件，而是由上述步骤建立的正常轨道与设备。
手动改 Live 后，关键不是再推一次，而是 pull → snapshot → build
真实制作中，人通常会在 Live 内调节推子、静音、send 或设备参数。如果随后直接重新构建并推送，数据库状态会重新收敛到 build.py 与已保存快照，人手修改可能消失。这不是 bug，而是需要显式处理的状态同步问题。
对推子、mute、send、音符等修改，可要求 Claude Code 执行 /hallucinote:ableton-pull，把 Live 里的变化拉回数据库路径。若改动涉及设备参数、乐器链、send 或整个混音布局，还要执行 /hallucinote:song-snapshot，把状态写入 Git 可追踪的 captured_session.json。接下来再构建，才会从新快照恢复这些决定。
可以把这条规则记为：pull → bake snapshot → build。项目会拒绝让未烘焙的混音修改悄悄进入下一次构建，以避免“我明明调过，为什么又被还原”的隐性损失。对于协作也一样：提交歌曲目录可以保留代码、快照和决定记录；但对方机器上的 Live 插件、音源与设备兼容性仍需单独检查，不能把 Git 同步误当成完整的音频环境复制。
评审应围绕意图，而不是把数值当成审美裁决
Hallucinote 把检查分为不同阶段。/hallucinote:compose-review 会读取歌曲的段落、密度、能量与旋律结构，并针对已声明的意图给出反馈；它不是一个宣称能给音乐打总分的工具。完成物化后，/hallucinote:render-analyze 可渲染并产生关于响度、遮蔽、混响、时值与律动的 MixReport；/hallucinote:mix-review 再将这些测量结果放回创作意图中解释。后两个测量式环节需要 Max for Live。
这一区分很实用。若目标是“副歌是否比主歌更有抬升感”，先做编曲评审；若目标是“低频是否遮蔽、混响是否过长”，再看渲染和 MixReport。数值可以帮助定位，但不能替代制作人的判断。官方也明确保留这种边界：工具应提出可讨论的证据，而不是阻止有意为之的非常规和声、弱动态或不协和选择。
哪些场景最适合采用
Hallucinote 适合愿意把歌曲当作可迭代工程的制作人：你希望对 Agent 的改动做 diff，希望尝试一个副歌变体后能用分支比较，希望在手工调整与代码重建之间保持同步，或希望让 Claude Code 帮忙完成重复的编曲和配置工作。
它不适合期待完全脱离 DAW 的一键成品，也不适合把 Agent 输出直接当作可发布作品。你仍需要试听、决定、修改、处理音源兼容性和完成最终混音。最稳妥的起步方式是选一首短歌：先让 Agent 创建一个明确的四轨结构，提交初始 build.py 与快照；在 Live 中只改一个 send 或一个乐器参数，完整走一遍 pull、snapshot、重新 build。确认状态不会丢失后，再把它用于更长的编曲和协作。
在团队或个人项目中，还可以为每次结构性改动留下简短的意图记录：为什么换掉和弦走向、为何将某条轨道从主奏改为铺底、这次 snapshot 对应哪一次试听结论。这样 Git diff 不只是代码差异，也能解释制作判断的来由。需要回退时，先回退歌曲目录中的代码与快照，再让 Live 按已确认状态重新收敛，比直接在多个 .als 副本之间猜测哪份较新更可靠。对 Agent 而言，这些记录也是持续协作时可读取的上下文，而不是每次都从一段模糊提示重新开始。
AI 在这里最有价值的角色不是代替音乐判断，而是把“提出想法—写下决定—推入 Live—听见结果—保留人手修改”串成可审计循环。只要把代码、快照与 Live 工程的职责区分清楚，Agent 创作就不再只能依赖记忆和聊天记录，而能成为可复盘的制作流程。