用途
mc-render-compile 是音乐生成流程中的编译层。它把 ARR-SPEC（本库唯一的中间表示 IR）编译成任意生成后端可接受的输入值。核心设计是编译器前端/后端分离：只有一个编译器负责共性，后端之间的差异全部写在 backends.yaml 里作为数据，而不是写成不同的 skill。因此新增一个模型只需要在 backends.yaml 加一个配置块，不需要改动任何 skill。
主要能力
- 后端能力对照：在 YuE2、Suno、MiniMax、ACE-Step、Stable Audio、符号路径之间，按输入形式、调性/和声、曲式/小节数、人声、可复现性、音色成品度、商用许可等维度做对照，帮助选择目标后端。
- 编译 style_prompt：按固定优先顺序从 mix_intent.mood、风格词、速度调性、乐器与音色、律动、人声、年代与制作质感等字段抽取信息，压成散文而不丢信息。
- 编译段落标签与歌词分块：把 form[].name 映射为后端标签，并保证标签数量等于 form 段落数；歌词按段落切开与标签一一对应。
- 编译 exclude / 负面提示：从“这首歌不是什么”出发编写排除项。
- 种子与批量策略：区分 AB 对照（固定种子、只改一个变量）、出成品（best-of-N）、探索（放开种子但记录）三种目的。
- honors 契约与降级：依据后端声明的 exact/hint/none 决定字段是否进提示词、是否计分、如何降级，并把降级记录写回 render.<backend>。
使用方式
动笔前需明确四项：目标后端（至少一个，多个则需做降级表）、本次要验证什么（出成品还是跑 AB）、种子策略、以及哪些字段该后端做不到（查 honors）。编译按顺序执行：先过 mc-workflow §3.0 的 20 条自查，再读 backends.yaml 的 honors 标出 none 字段，把 mix_intent.mood 放最前，然后依次编译 style_prompt、段落标签序列、歌词分块、符号路径（若支持）、exclude、种子与批量，最后写回 render.<backend>。第 9 步写回不可遗漏，否则下一轮 AB 无法知道上次送入了什么。
style_prompt 有三条硬规则：禁用 epic/emotional/beautiful 等无信息形容词；数值参数转成可听的描述（如把 bass −12ms 写成 bass playing slightly ahead of the beat）；每个词都要能指向一个 roster 项或 spec 字段。exclude 应从“这首歌不是什么”来写，并注意排除淡出结尾，因为淡出是生成模型的默认结尾。
段落标签映射中，大サビ 映射成 [Bridge] 而非 [Chorus]；落ちサビ 仍映射成 [Chorus]，稀薄编制的要求写进 style_prompt 或段落注释。标签数量必须等于 form 段落数，手动改动歌词段落后容易忘记同步增删标签。歌词从 meta.upstream.lyrics.sections 读取，按 id 对应；id 对不上时不猜，照 form[] 编，对不上的段落写进 checks.exemptions 并给作词发消息。
适用场景
- 需要把同一份规格复用到多个音乐生成后端。
- 需要做 AB 对照，验证规格是否被执行。
- 需要完全可复现的对照基准（符号路径）。
- 需要成品质感（Suno）或纯器乐/氛围（Stable Audio）。
- 需要最高控制力：把 mc-symbolic-score 编译出的 ABC 直接喂给 YuE2 的合成步骤，旁路模型自己的符号规划。
限制
- 不负责 ARR-SPEC 里的内容怎么想出来（归 L1/L2 各 skill）。
- 不负责生成 ABC / MusicXML / MIDI（归 mc-symbolic-score）。
- 不负责判断生成结果像不像 AI（归 mc-ai-tell-audit）。
- 照做率的定义在 mc-ai-tell-audit §3.1，本 skill 只管 honors 三档如何影响计分。
- 具体后端的权重放哪、节点叫什么，由 backends.yaml 决定。
- 用什么工具把编译结果送进模型由用户环境决定，本 skill 不预设、不管理。
- 商用需先解决许可：YuE2 权重为 CC-BY-NC-4.0，不可商用。
- 资料中标注：MiniMax Music 商业 API 已对新用户关闭；YuE2 合成步骤接受的 ABC 方言、其 musical invariants 与 20 条自查的对应关系尚未确认。
- 分轨：人声 AI 味审计需先分出人声轨，任何分轨工具均可。