jtydhr88 作曲编曲工作流与路由（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 ★ 三条不许跳的顺序
intent不齐不许写form—— 这是整套流程唯一的硬门禁- 17 条不过不许编译 —— 不过说明规格没写完，不是脚本挑刺。★ 没有 Python 就按 §3.0 逐条自查，不要重写 lint
- 照做率不过不许用耳朵返工 —— 先改规格重生成，耳朵是最后一小步
第 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 条自查）：
- 每个维度只有一个 owner——两层都声称
groove= 两种默认值叠在一起，谁也没选 - 每层至少拥有一个维度——否则它只是被读了，没起作用
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（v1.0），空模板 ARR-SPEC.template.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 就重跑一次，看：
- 路由正确率：每条 brief 该读的 skill 有没有被选中
- 污染率：不该被选中的 skill 有没有混进来 —— 尤其是 L3 风格层，加一个风格 skill 最容易污染别的风格
这就是为什么每个 skill 都必须有「边界：什么不归这个 skill 管」表—— 那张表是给路由看的，不只是给人看的。
6.2 文本层 AB
评判表在看结果之前定稿。 改一个字段 → 重生成 → 盲比。 定稿之后再看结果，否则你会不自觉地把评判标准调向你已经看到的那个。
比响度前先对齐电平，再比内容：声音只要更响，耳朵就倾向觉得它更好，这条偏差会把"哪个字段起了作用"的判断，悄悄换成"哪个版本更响"（p0299-p0300）。两版生成结果如果响度或整体密度对不齐，先拉平这两项再做成对比较，不然字段本身的效果会被响度差盖过去。
6.3 先算再听（照做率）
见 §1 的 S7 与 §4.2。
★ 零点校准（仓库实验数字，供理解量级，不是交付门槛）：不相关的、制作精良的成品在度量工具上得 63–66， 所以我们把 82 / 70 当"照做得好 / 勉强"的参考线，不是 60。 用户侧没有度量工具时，照做率就是逐字段对照后的一个判断，不必算成数。
7. 目录地图
随包发布（用户拿到的就是这些，全是文本）：
skills/<27 个 skill>/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 引用的书目见各自的「附：来源」。