mc-workflow

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

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

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

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

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

1. 阶段表 S0–S7

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

1.1 ★ 三条不许跳的顺序

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

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

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

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

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

2. 全库边界表

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

2.1 按问题查

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

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

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

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

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

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

★ 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，这不算污染； 读了没被点名的风格才是。

2.3 不归本包的东西

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 一物四用

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

3.0 ★ 写完的 20 条自查

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

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

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

3.2 自查不过怎么办

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

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

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

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

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

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

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

4.1 具体症状 → skill

4.2 ★ 两个数不许混为一谈

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

5. 对外接口

本库管一首歌的作曲与编曲决定（调、速度、段落、和声、主题材料、谁什么时候进退、能量曲线、怎么唱、混音要达到什么），产出是 ARR-SPEC。不假设下游是谁、用什么工具；对外只经规格单：交出去的字段、有就读的上游字段（§5.2）、messages（§5.3）。字段怎么理解：ARR-SPEC.schema.md §5。

镜头设计按放音拍时读速度与段落时间，交出去以后再改要先写消息；商用前的许可看 backends.yaml 的 license（制片与现场）。小节换算成秒的约定见 schema §5.1。

5.1 与歌曲另一侧共享的六个字段

form[].id / form[].bars / form[].name / meta.tempo / meta.key / vocal.persona。两边用同一套段落 id。

• 谁先做谁定。 先曲后词：本库定，写进自己的字段。先词后曲：从 meta.upstream.lyrics.shared 原样读进来，当锁死项用；词的字数和句式反过来约束 form[].bars。
• 后做时不改这六项。 词放不进这几小节、调或速度唱不下来，就写一条 messages（to: lyrics），说清改哪一项、为什么；对方接受并改了它自己的规格单，本库再重新读。
• 只有曲、没有歌词那一侧时，这六项由本库自己定。

完整规则与原文：schema §5.4。

5.2 上游：有就读

meta.upstream.brief／lyrics／picture 来自谁不重要：有就读（先词后曲时的共享六项是锁死项），没有就按本库自己的分析走——S0 从 brief 起，没有歌词就按 §2.3 的三种情况，没有画面时长就自己定时长。已填的上游字段不改写；冲突时照实写本库的字段，再写消息给来源的职能。

5.3 messages：怎么收发

• 收：S0 开工与每次改规格前读 to: music 的，交给 about 所指字段的 owner（§2.1）；改了标 accepted、不改标 rejected，reply 写改了什么或理由。
• 发：如 {from: music, to: sound, about: "mix_intent.dynamics", says: "D 段比 C2 低 6 dB 是唯一的大落差，母带请留住", status: open}；to 取 lyrics sound editing shot-design writing production。
• 不等待：读不到回话就当没有；open 不挡自查、不停阶段，交付时原样交出去。

6. 三个检验办法

6.1 选 skill 时对照边界表

开工前把这首歌要读的 skill 列出来，对照 §2 和各 skill 的边界表看两件事：

1. 该读的读了没有：brief 里每个要做的决定，都有一个 owner 被选中
2. 不该读的混进来没有

—— 尤其是 L3 风格层，多读一个没被点名的风格 skill，最容易把它的默认值带进这首歌（被点名的混合不算，见 §2.4）

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

6.2 文本层 AB

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

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

6.3 先算再听（照做率）

见 §1 的 S7 与 §4.2。

★ 零点校准（参考值，供理解量级，不是交付门槛）：拿一份 City Pop 规格（112 BPM、10 段、114 小节）去比三首与它无关、制作精良的华语成品，按字段加权打分得 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 / 混合 / 反面样本）

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 引用的书目见各自的「附：来源」。