Mc Workflow

作曲编曲工作流与路由（Workflow & Routing）

任何作曲/编曲请求先读这个 skill，再决定读哪个别的。

这个库的产出不是音频，是一份 ARR-SPEC（编曲规格单）。 音频由后端生成，规格单决定它长什么样、以及怎么验收它。

> 本库的根本立场：AI 味不是音色问题，是没有人做过选择。 > 整套流程就是一台强迫做选择的机器。

---

0. 三十秒定位：我该去哪

| 你现在要做的事 | 去 | |---|---| | 从零开始一首歌 | §1 阶段表，从 S0 走。★ S2a 必须先读 mc-development 再填 material 与 form[].development，只照 schema 的字段说明填会把每段写成一个新画面 | | 已有 brief，要出规格单 | §1 的 S1–S4（S2 现分 S2a 材料与发展、S2b 和声） | | 规格单写完了，要生成 | §1 的 S5 ＋ mc-render-compile | | 生成回来了，不对劲 | §4 诊断路径 | | 不知道某个问题归哪个 skill | §2 全库边界表 | | lint 不过 | §3.2 | | 要交给别的库 / 别的人 | §5 跨库接口 | | 要跑测试 | §6 三个测试装置 | | 要混合两种风格（rap + 中国风、city pop + EDM…） | ★ §2.4 |

---

1. 阶段表 S0–S7

每个阶段有明确的产出物和门禁。门禁不过不许进下一阶段。

| 阶段 | 做什么 | 产出 | 门禁 | 主用 skill | |---|---|---|---|---| | S0 立意 | 把 brief 变成"只干一件事" | intent 四项 | 四项齐全，borrow 不许只写歌名 | 本 skill §3.1 | | S1 骨架 | 定调、拍、速度、曲式表 | meta + form | 段落首尾相接；不许全是 8 的倍数 | mc-form、mc-harmony、mc-arrangement-arch | | S2a 材料与发展 | 定主题动机、原始陈述在哪段、每段拿它做什么 | material + form[].development | 先读 mc-development 再填；motif 与 stated_in 非空；每段 development 都填；填 new 的段不过半 | mc-development、mc-melody | | S2b 旋律与和声 | 写主旋律、和声进行、必要的对位 | form[].harmony + harmony_letters | 双记号都要有；至少一段有调外和弦 | mc-melody、mc-harmony、mc-progressions、mc-modulation、mc-counterpoint | | S3 编制 | 谁在场、什么时候进退、占什么频段 | arrangement 全段 | 能量曲线必须有下降；至少一件乐器提前退场；至少一个减法事件 | mc-arrangement-arch、mc-orchestration、mc-texture-layering、mc-rhythm-section、mc-sound-design | | S4 演唱与混音意图 | 怎么唱、声场怎么摆 | vocal + mix_intent | 力度逐段不同；副歌逐遍有变化；宽度至少两种取值 | mc-vocal-direction、mc-mix-intent | | S5 编译 | 规格单 → 各后端输入 | render.* | 按 §3.0 的 20 条自查一遍；不过的条目改掉或写明理由 | mc-render-compile、mc-symbolic-score | | S6 生成 | 跑后端，取多版 | 音频 | 按 backends.yaml 的 honors 决定哪些字段可指望 | mc-render-compile | | S7 验收 | 先算再听 | 照做率 + AI 味旗标 | 先分开看两件事：后端照做了没有、成品有没有机器指纹；耳朵在这之后介入 | mc-ai-tell-audit |

1.1 ★ 三条不许跳的顺序

1. intent 不齐不许写 form —— 这是整套流程唯一的硬门禁
2. 17 条不过不许编译 —— 不过说明规格没写完，不是脚本挑刺。★ 没有 Python 就按 §3.0 逐条自查，不要重写 lint
3. 照做率不过不许用耳朵返工 —— 先改规格重生成，耳朵是最后一小步

> 第 3 条最容易破。"我听着不对，我调一下混音"—— > 那一刻你就从规格驱动掉回手感驱动了， > 而手感驱动的产物无法复现、无法 AB、无法积累。

1.2 耳朵怎么介入（S7 之后）

照做率过关后才听，而且要：A/B 打乱 → 成对比较 → 同一对听两遍看结论稳不稳。 两遍不是多余的谨慎：听觉系统会在重复暴露里改变自己的处理策略，同一段声音第二次听可能得到不同的结论，这类判断天然容易不可重复（p0251-p0252）。结论两遍不一致 = 这个差异不存在，别改。

如果两次听中间隔的时间较长，还要防一种相反的偏差：耳朵会对持续暴露的音色变化逐渐适应，越听越觉得两版差不多，容易把真实存在的差异误判成"不存在"（p0342）。两次判断之间留出间断，别来回连着切，能同时防住这两头。

---

2. 全库边界表

每一个决策只有一个 owner。 拿不准就查这张表。

2.1 按问题查

| 问题 | Owner | |---|---| | 这首歌要干什么 | 本 skill S0 | | 用什么曲式、段落多长 | mc-form（乐理） ＋ mc-arrangement-arch（非对称与能量） | | 旋律怎么写、可唱性 | mc-melody | | 和弦怎么选、怎么配 | mc-harmony | | 查一个现成进行 | mc-progressions | | 怎么转调 | mc-modulation | | 节奏型是什么 | mc-rhythm-groove | | 声部怎么独立、怎么避免平行 | mc-counterpoint | | 一个动机怎么长成一段、一段怎么长成一首 | mc-development（L1）；旋律本身在 mc-melody，段落功能在 mc-form | | 乐器什么时候进、什么时候退、能量曲线 | mc-arrangement-arch | | 用哪件乐器、混合音色 | mc-orchestration | | 频段怎么分、谁和谁抢、前中后景 | mc-texture-layering | | 打得像不像人、贝司和底鼓怎么配 | mc-rhythm-section | | 合成器音色怎么做 | mc-sound-design | | 人声怎么唱、和声怎么加 | mc-vocal-direction | | 声场怎么摆、谁给谁让路 | mc-mix-intent | | 这个风格该怎么做 | mc-style-*（L3） | | 规格单怎么变成 prompt | mc-render-compile | | 要出 ABC / MIDI / MusicXML | mc-symbolic-score | | 生成的东西哪里像 AI | mc-ai-tell-audit | | 找一个真实作品的拆解 | mc-case-studies |

2.2 六组最容易混的分界（★ 逐条记住）

| A ⇄ B | 分界线 | |---|---| | mc-form ⇄ mc-arrangement-arch | form 管曲式是什么（乐理），arrangement-arch 管这首歌为什么这么切（决策） | | mc-rhythm-groove ⇄ mc-rhythm-section | groove 管节奏本身是什么，rhythm-section 管怎么把它打出来像人 | | mc-texture-layering ⇄ mc-mix-intent | texture 的解法是"改写"（换音区/减音符/交替），mix-intent 的解法是"改混"（让频/侧链/动态）。能改写解决的不许留给混音 | | mc-orchestration ⇄ mc-sound-design | orchestration 管真实乐器与混合，sound-design 管合成音色的设计 | | mc-sound-design ⇄ 库三 | 本库的 sound-design 是乐音音色；影视意义的"声音设计"（音效/拟音/空间）是另一个库，同名不同事 | | 本库 ⇄ 作词库 | 词的一切归作词库，包括词曲对齐（符割り、字余り、倒字、协音）——那是词的工序 |

2.4 ★ 风格混合：不是调匀，是分维度签字

> ★ 边界是分工，不是禁令。 隔离的目的是让每个选择都有人签字，不是把风格锁死。写 J-Pop 规格时顺手借一个 city pop 的裏和弦、写中国风时低音走了 hip-hop 的 808——只要在 style_layers / fusion_note 里写一句为什么，就是合法的混合；轻微的串音完全可以接受，真正要防的是「没人选、默认长成那样」。

污染隔离 ≠ 禁止混合。 两者的区别只有一条：

> 混合是写下来的选择；污染是没人选。 > 一首 rap + 中国风的歌（如汪苏泷《桃花扇》）完全成立——前提是规格单说得出哪个维度归谁。

做法：meta.style_layers 填一张分工表（schema §1.1.1），一个 base + 若干 overlay， 每层写明它 owns 哪些维度：

| 维度 | 《桃花扇》式的分法（示意） | |---|---| | harmony、melody、color_instruments | 中国风（五声旋律、民乐采样做色彩层） | | （完整分工见 mc-style-hiphop §8.1） | | | groove、low_end、vocal_delivery_verse | hip-hop（律动、808、主歌 flow） | | vocal_delivery_chorus、form | 中国风副歌唱、结构仍是主副歌 |

★ owns 是封闭集合，只能从这十四个里选： harmony　melody　groove　low_end　fill_policy　instrumentation　color_instruments　timbre　arrangement_hook　vocal_delivery（可拆成 vocal_delivery_verse / vocal_delivery_chorus）　form　mix。 要分配的东西不在表里，归到最接近的那个，并在 fusion_note 里写一句说明，不要自造名字。

三条规则（第 18 条自查）：

1. 每个维度只有一个 owner——两层都声称 groove = 两种默认值叠在一起，谁也没选
2. 每层至少拥有一个维度——否则它只是被读了，没起作用
3. fusion_note 一句话说这个组合为什么成立——说不出就是硬凑

怎么用各 L3 的移植表：overlay 搬进来的，正是它移植表里标"不可搬／会被认出来"的项—— 那就是你要的辨识度。但每搬一项都要在 owns 里签字，并看 base 风格的移植表是否允许让出那个维度 （例如 city pop 的移植表说"抢拍贝司可搬"，那 base 是 city pop 时 groove 让给别人就要三思）。

路由上：混合 brief 应读全部被点名的 L3 skill，这不算污染； 读了没被点名的风格才是。测试集从 v3 起区分这两种情况。

2.3 一律出库的东西

| 内容 | 去哪 | |---|---| | EQ 频点、压缩比、混响参数、总线链、母带 | 库三：声音设计与混音库 | | 影视音效、Foley、环境声、空间设计 | 库三 | | 跟画面走的配乐结构、cue sheet、spotting | 库二：配乐库 | | 歌词写作、押韵、意象、叙事人称 | 作词库 lyric-writing。★ 词的三种情况：用户没提词 → 可出可不出，出了就在 checks.exemptions 记一条"词未走作词库工序"；用户明确要纯音乐 / 轻音乐 / 器乐 → 一个字都不加，vocal 留空；用户明确要词 → 必须出词，作词库在场就走它，不在场就按本库的 mc-vocal-direction 写并记豁免。只示意人声节奏（rap 的 flow、副歌字数）时用占位音节（da-da / 拉拉）或 X 标记 | | 商业流程（compe、仮歌、版权、分成） | 不做 |

---

3. ARR-SPEC：本库唯一的交接物

完整规范在本 skill 目录下的 [ARR-SPEC.schema.md](ARR-SPEC.schema.md)（v1.0），空模板 [ARR-SPEC.template.yaml](ARR-SPEC.template.yaml)，后端能力档案 [backends.yaml](backends.yaml)。 ★ 写规格单前先 Read 模板，照它的字段名填——实测不看模板的话 agent 会自己发明字段（intent.scene/borrow、push_pull 写成字符串）。 （这三个文件就是本库随包交付的全部"格式"——除了 Read 它们，不需要任何工具。）

3.1 一物四用

| 用途 | 怎么用 | |---|---| | 对外交接 | 给混音师/乐手/别的库看的，是这一份 | | AB 测试对象 | 改一个字段 → 重生成 → 比对。变量可控 | | 编译源 | mc-render-compile 把它编译成 Suno prompt / YuE 输入 / MIDI | | 验收基准 | 生成回来的东西逐字段对照它，看后端照做了多少 |

★ 第二和第四条是关键：没有规格单就没有可控实验，没有可控实验就只能靠感觉。

3.0 ★ 写完的 20 条自查

本库不需要用户机器上有任何工具——没有 lint、没有脚本、不预设 Python 或 Node。 写完规格单，自己把下面 20 条逐条过一遍，结果写进 checks.self_audit。 ★ 这是判据，不是铁律：某条不过，要么改，要么一句话写明为什么这首歌就该这样。 写了理由的偏离就是合法的选择；没有任何一条会"卡住"后面的编译。 ★ 不要为了检查去写脚本（实测有 agent 这么干过，白费很多轮）——20 条全部用眼睛就能判。

| # | 自查问法 | 对照字段 | |---|---|---| | 1 | intent 四项都填了？reference_pair 恰好 2 项且每项写了"借哪一点"？ | intent | | 2 | 各段 start_bar 首尾相接？（上一段 start + bars = 下一段 start） | form | | 3 | 至少一段的 bars 不是 8 的倍数？ | form[].bars | | 4 | energy_curve 的 key 集合 == form 的 id 集合？（不多不少） | energy_curve | | 5 | 能量曲线至少下降一次？ | energy_curve | | 6 | subtraction_events ≥ 1？ | subtraction_events | | 7 | 每件乐器有 entry；至少一件 exit 不是 end？ | roster | | 8 | arrangement_hook.what 非空？ | hooks | | 9 | 至少一个非 Intro/Outro 段有调外和弦或转调标记？ | form[].harmony | | 10 | fill_policy.bars 不是公差 4 的等差数列？ | groove | | 11 | push_pull 至少一项 offset_ms ≠ 0，且每项是 {part, offset_ms, note} 字典？ | groove | | 12 | width_map 至少两种取值？ | mix_intent | | 13 | style_prompt 非空且无 epic/emotional/beautiful；section_tags 若手填则与 form 段数、顺序一致（由 form[].name 派生，可不填）？ | render.suno | | 14 | Σbars × 每小节拍数 ÷ tempo × 60 与 target_duration 偏差 ≤ 10%？ | meta | | 15 | 有人声时 dynamics_by_section 至少两种取值？（器乐作品跳过） | vocal | | 16 | 有人声时 chorus_variation 非空？（器乐作品跳过） | vocal | | 17 | 多风格时：恰好一个 base；每个维度只有一个 owner；每层至少一个维度；fusion_note 非空？ | meta.style_layers | | 18 | material.motif 与 stated_in 非空；每段 development 填了；new 不过半；至少一段 repeat 或 recap；副歌各遍不全是 new？ | material form[].development | | 19 | 和弦拼写全 ASCII，后缀在封闭集合里（maj7 m7b5 dim，不写 △ ø ° ♭ ♯ ×）？ | form[].harmony_letters harmony | | 20 | key 是"主音 major/minor"；mode 在枚举内；段名在封闭集合内；subtraction_events[].at 是 {section, bar_offset} 这样的结构不是句子？ | meta form[].name subtraction_events |

YAML 本身的自查（agent 最常写坏的地方）：

• 列表字段（roster / sound_stage / push_pull / emotional_arc …）的 - {…} 条目下面不能挂 note: 键——要注释用同级 xxx_note: 或 #
• 冒号后有空格；值里有冒号的加引号；缩进统一两格

3.2 自查不过怎么办

不过的条目通常指向一个没读的 skill，而不是需要硬填：

| 不过的条目 | 多半是哪个 skill 没读 | |---|---| | 1（intent 不齐） | 本 skill §1 的 S0——回去想清楚，不要硬填 | | 2、3、14（段落与时长） | mc-arrangement-arch §4 | | 4、5（能量曲线） | mc-arrangement-arch §2 | | 6（减法事件） | mc-arrangement-arch §3 | | 7（编制进退场） | mc-arrangement-arch §5 | | 8（arrangement_hook） | mc-arrangement-arch §7 | | 9（和声单调） | mc-harmony、mc-modulation | | 10、11（fill 与律动） | mc-rhythm-section §3、§8 | | 12（宽度恒定） | mc-mix-intent §2 | | 13（编译不完整） | mc-render-compile | | 15、16（人声） | mc-vocal-direction §1、§4 |

豁免的规矩：写进 checks.exemptions，必须带理由。 静默跳过 = 没写完。

3.3 ★ 生成后端的默认值对照表

后端在无指令时会滑向左列。ARR-SPEC 的对应字段就是为了把它拉回来。

| 后端默认倾向 | 对抗字段 | lint | |---|---|---| | 段落等长、都是 8 的倍数 | form[].bars | #3 | | 能量单调上升到底 | energy_curve | #5 | | 开场就把乐器铺满 | roster[].entry | — | | 所有乐器从头响到尾 | roster[].exit | #7 | | 只加不减 | subtraction_events | #6 | | 每 4 小节一个过门 | fill_policy.bars | #10 | | 全声部严格对齐网格 | groove.push_pull | #11 | | 人声全程一个力度 | vocal.dynamics_by_section | #15 | | 副歌逐遍原样复制 | vocal.chorus_variation | #16 | | 人声音准全中 | vocal.pitch_policy | 人工项 | | 立体声宽度全曲不变 | mix_intent.width_map | #12 | | 动态被压平 | mix_intent.dynamics | 人工项 | | 没有非人声记忆点 | hooks.arrangement_hook | #8 | | 时长永远 3:30 | meta.target_duration | #14 |

---

4. 诊断路径：生成回来不对劲

按这个顺序查，不要凭直觉跳。

听着"像 AI"
 └─ 先分开两个问题：后端照做了没有（照做率）、成品有没有机器指纹（AI 味旗标）
     ├─ 照做率低  → 后端没照做
     │   ├─ 查 backends.yaml：这个字段该后端 honors 是 none 吗？
     │   │   └─ 是 → 不是它的错。换后端（YuE2 控制力最强）或接受
     │   └─ 否 → 编译问题，查 mc-render-compile
     └─ 照做率高但仍像 AI → 规格本身不够
         └─ 走 mc-ai-tell-audit 的清单

4.1 具体症状 → skill

| 症状 | 先查 | |---|---| | 平、没起伏 | mc-arrangement-arch §2 能量曲线 | | 糊、浑 | mc-texture-layering §4 → 先查持续音，不是先怪鼓 | | 主角不突出 | mc-texture-layering §3 四条深度线索 | | 机械、太准 | mc-rhythm-section §2 ＋ mc-vocal-direction §4 | | 听着还行但记不住 | mc-arrangement-arch §7 —— arrangement_hook 是不是空的 | | 第二遍副歌和第一遍一样 | mc-arrangement-arch §6 ＋ mc-vocal-direction §1④ | | 人声埋在伴奏里 | 先查音准（mc-vocal-direction §4.1），再查频段 | | 贝斯在手机上消失 | mc-sound-design §6 差音 | | 结尾很突兀 / 淡出了事 | mc-arrangement-arch §8 三种结尾 | | 技术上干净但情绪不对 | mc-mix-intent §3.1 —— mood 是不是没写 |

4.2 ★ 两个数不许混为一谈

| | 问什么 | 怎么算 | |---|---|---| | 照做率 | 后端照着规格做了多少 | 逐字段对照规格听/看；仓库内部的度量工具能算成 0–100，不随包发布 | | AI 味旗标 | 成品有没有机器指纹 | mc-ai-tell-audit 的清单，独立计数 |

照做率 100 的东西完全可能满是 AI 味——那说明规格写得像 AI。 反过来，照做率 40 但好听，说明后端自己干得不错，但你不可复现。

---

5. 跨库接口

| 对方 | 交接物 | 方向 | |---|---|---| | 作词库 | LYR-SPEC ⇄ ARR-SPEC | 双向：先曲后词走 ARR→LYR，先词后曲走 LYR→ARR。共享 form[] 的段落 id 与小节数 | | 配乐库（库二） | ARR-SPEC + 时间码表 | 单向：配乐要跟画面，段落由 spotting 决定而非曲式 | | 声音设计与混音库（库三） | mix_intent 段 | 单向：我们只给意图，参数归他们 | | 影视线 | 成品音频 + stems | 单向 |

5.1 与作词库共享的字段（必须一致）

form[].id / form[].bars / form[].name / meta.tempo / meta.key / vocal.persona

任何一边改了这六项，另一边必须同步。 这是双向耦合唯一的代价。

---

6. 三个测试装置

6.1 路由／污染测试（回归测试）

本库用 20 条典型请求做回归（仓库内，不随包发布），每加一个 skill 就重跑一次，看：

1. 路由正确率：每条 brief 该读的 skill 有没有被选中
2. 污染率：不该被选中的 skill 有没有混进来

—— 尤其是 L3 风格层，加一个风格 skill 最容易污染别的风格

> 这就是为什么每个 skill 都必须有「边界：什么不归这个 skill 管」表—— > 那张表是给路由看的，不只是给人看的。

6.2 文本层 AB

评判表在看结果之前定稿。 改一个字段 → 重生成 → 盲比。 定稿之后再看结果，否则你会不自觉地把评判标准调向你已经看到的那个。

比响度前先对齐电平，再比内容：声音只要更响，耳朵就倾向觉得它更好，这条偏差会把"哪个字段起了作用"的判断，悄悄换成"哪个版本更响"（p0299-p0300）。两版生成结果如果响度或整体密度对不齐，先拉平这两项再做成对比较，不然字段本身的效果会被响度差盖过去。

6.3 先算再听（照做率）

见 §1 的 S7 与 §4.2。

★ 零点校准（仓库实验数字，供理解量级，不是交付门槛）：不相关的、制作精良的成品在度量工具上得 63–66， 所以我们把 82 / 70 当"照做得好 / 勉强"的参考线，不是 60。 用户侧没有度量工具时，照做率就是逐字段对照后的一个判断，不必算成数。

---

7. 目录地图

随包发布（用户拿到的就是这些，全是文本）：
  skills//SKILL.md, reference.md
  skills/mc-workflow/ARR-SPEC.schema.md      ★ 规格单定义（v1.0）
  skills/mc-workflow/ARR-SPEC.template.yaml  空模板
  skills/mc-workflow/backends.yaml           ★ 各后端的 honors 声明
  skills/mc-workflow/example-*.yaml          填好的示例（citypop / 混合 / 反面样本）

仓库内、不随包发布（skill 里提到它们只是标注来源）：
  本库架构文档、读书笔记（40+ 本）、实验记录与实测语料、度量与实验工具

---

8. 写完一首歌的自检

• [ ] intent 四项是想出来的，不是为了过 lint 填的
• [ ] §3.0 的 20 条逐条过了，不过的都写了理由
• [ ] 每个字段都能说出是哪个 skill 的哪一节决定的
• [ ] 逐字段对照过生成结果，且知道哪些项因 honors: none 本来就不指望
• [ ] 跑过 mc-ai-tell-audit
• [ ] 耳朵是最后介入的，且 A/B 结论两遍一致

---

附：这个库为什么这样分层

分库/分 skill 的判据是四件事全不同：交接物、裁判、语料、评判方法。 按工序切，不按知识领域切。

所以：

• "和声"是知识领域，但它被切进 mc-harmony（写的时候）和 mc-progressions（查的时候）——

因为这是两道工序

• "city pop"是风格，它的鼓型不进 mc-rhythm-section，进 mc-style-citypop-rnb——

因为"打得像人"和"打得像 city pop"是两道工序

• "混音"横跨三层：意图在 mc-mix-intent，改写型解法在 mc-texture-layering，

参数在库三——因为它们的裁判不同（作曲判断 / 编曲判断 / 工程判断）

详见 本库架构文档。

附：来源

• Howard & Angus《音乐声学与心理声学》（Acoustics and Psychoacoustics）——§1.2 两遍复听的两条心理声学依据：重复听音会改变听觉系统的处理策略、以及持续暴露带来的听觉适应。页码为中译本页。
• Roey Izhaki《Mixing Audio》（混音指南）——§6.2 提醒的响度偏差：更响的版本容易被判定"更好"，与内容本身的差异无关。页码为该书页。

本库其余各 skill 引用的书目见各自的「附：来源」。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jtydhr88
• Source: jtydhr88/music-composition-skills
• License: MIT

Install and usage instructions live in the source repository linked above.