如何用 AI 编程代理开发 VST3 或 CLAP 插件

为什么代理会把音频插件写错

面对陌生的 C++ 库，代理很少会拒绝。它们只会临场发挥，而音频插件会以三种方式惩罚这种临场发挥：

1. 虚构名称。 本该存在却不存在的类，例如 CompressorPro；或者真实存在的类被套上了另一框架的方法。代码读起来完全正常，却无法编译。
2. 能编译但仍然有错的代码。 在 process() 内部进行内存分配或加锁，而 process() 运行在音频线程上。它在开发者的机器上能正常工作，却会在别人的会话里负载升高时断音。
3. 不存在于 API 中的规则。 不报告延迟的前瞻限幅器，会使它所处的每一路并行混音都变得模糊。1.1 版中重新排序的参数表，会把旧会话加载到错误的控件上。这两点在头文件中都没有任何说明。

第一个问题关乎名称，第二个关乎行为，第三个关乎约定。更大的模型对这三者都没有帮助，因为这些信息并未可靠地存在于其训练数据中，不足以信任。

代理真正需要的是什么

需要三样东西，分别对应上述三种失败模式：

这三者都由同一个脚本从 SDK 的头文件生成。这比听起来更重要。手写的代理速查表会在一个版本之内与代码脱节，然后就成了虚构名称的第二个来源。在这里，若文件与头文件不一致，npm run verify:llms 会使构建失败；npm run verify:mcp 则检查搜索能否找到每一个公共类型，因此服务器给出的“没有匹配”是确切的答案，而不是索引中的缺漏。

MCP 服务器的六个工具

该服务器从本地检出副本通过 stdio 运行，只需 Node.js，并且每个工具都只读取检出副本中的文件。

下面是它带来的差异的一个例子。若查询 CompressorPro，服务器会回答 SDK 中没有任何匹配项。若查询“ladder filter”，它会返回 LadderFilter 和二极管梯形滤波器（diode ladder），并附上它们所在的头文件。代理写的是后者，而不是前者。

安装配置

先克隆 SDK，然后把 skill 和服务器添加到你的代理中。以 Claude Code 为例：

git clone https://github.com/SonorieAI/sonore-sdk "$HOME/sonore-sdk"
npx skills add SonorieAI/sonore-sdk --skill sonore-sdk -a claude-code -g
claude mcp add --scope user sonore-sdk -- node "$HOME/sonore-sdk/scripts/mcp-server.mjs"

Codex 使用 -a codex 和 codex mcp add。Cursor 与 Antigravity 使用 -a cursor 或 -a antigravity 安装 skill，并在其 MCP 配置文件中添加服务器。首页上的 安装技能与 MCP 按钮列出了每种代理的确切命令。若不使用 skills 命令行工具，将 skills/sonore-sdk 复制到代理的 skills 文件夹中，效果相同。

一个行之有效的首个提示词

请明确说明插件的细节，并说明“完成”的标准：

Make a tape-style saturator plugin with Drive, Tone and Mix.
Start from a generated Sonore project. Look up every sonore:: name
before you use it. It is done when it builds, ctest passes, and
clap-validator and pluginval run clean.

加载该 skill 后，代理会自行遵循 SDK 的工作流程：使用 sonore_new_plugin.cmake 生成项目，将 DSP 写入唯一的 src/plugin.cpp，边写边核对名称，然后构建。一份源文件会生成 .clap、.vst3、macOS 上的 Audio Unit、LV2 包和独立应用；同一个项目还能构建供 iPhone 和 iPad 使用的 AUv3，以及 Android 应用。

“完成”的含义

能编译的插件只是草稿。生成的项目让代理依次通过三项检查，按其所能证明的内容排序：

1. 构建成功： 一次编译即可构建所有格式。
2. ctest 通过。 它运行两项测试。独立应用的 --verify 会离线渲染音频，并断言其运行正常。在从 SDK 检出副本构建的项目中，实时审计（sonore_add_rt_test）会统计音频线程上在各种采样率和块大小下的每一次内存分配，只要有一次就判定失败。SDK 本身的示例也以同样的标准要求：8 kHz 至 384 kHz 的九种采样率，块大小从 1 到 8192，零内存分配。
3. 验证器通过。 clap-validator 和 pluginval 以宿主加载插件的方式进行加载。两个项目模板在生成时即以 pluginval 严格度 10 通过验证，因此一旦失败，就说明是代理引入的问题。

审计和验证器能发现仅靠阅读代码无法发现的问题，这正是它们应当写入提示词的原因。

仍需你亲自完成的事

配备合适工具的代理能写出可以加载、通过验证且不在音频线程上分配内存的插件。但它无法告诉你饱和器听起来是否悦耳，界面在会话中的手感是否合适，或者你在意的宿主是否表现正常。聆听、审美以及在你自己的 DAW 中测试，仍然要由你来完成。带有把关方的格式也是如此：AAX 需要 Avid 的开发者协议和 PACE 签名，没有任何框架能够代为授予。

如果想看不使用代理的分步教程，请阅读快速入门。如需了解 SDK 与 JUCE、iPlug2 等框架的对比，请参阅音频插件框架对比。

来源

• Sonore SDK 仓库：README 中的“Writing plugins with a coding agent”一节、llms.txt 和 scripts/mcp-server.mjs
• sonore-sdk skill
• Model Context Protocol 规范
• Agent Skills 格式
• llms.txt 约定