根据用户提供的原始歌词和音乐风格提示词，生成一份适用于 Suno 等 AI 音乐平台的“带演唱控制命令的歌词版本”。当用户想给歌词加 section 控制、演唱提示、meta tags、唱腔指令、括号式 vocal direction、让歌词更适合 AI 演唱生成、在不改歌词内容的前提下增强歌曲控制力时，必须使用这个 skill。只要任务本质是“保留原歌词、增加演唱与段落控制”，即使用户没有明确说 meta tags，也应触发。
44:T6b30,
这个 skill 负责把用户原始歌词和已有的音乐风格提示词整合成一份带演唱控制命令的歌词文件，用于 Suno 等 AI 音乐平台生成更可控的歌曲。
它的核心不是重写词，也不是重新发明风格，而是：
~ 与行尾和声括号 ()它输出的不是普通 style prompt，而是：
“原歌词 + 小节级 meta tags / 控制指令 + 按需插入的歌词级演唱括号说明”
这个 skill 不负责：
~ 拖音和行尾 () 和声补唱进入这个 skill 的真实场景通常是：
~ 或行尾和声 () 来增强演唱表现[Verse 1 | ...]、[(Breathy...)] 这种格式”不应进入这个 skill 的情况：
这种时候应先交给风格判断类 skill，等整体方向确定后，再进入本 skill。
用户表面上说的是：“给这份歌词加演唱控制命令。”
但他真正缺的，通常是以下能力：
~ 拖音，或在某行末尾补 () 和声唱词也就是说，这个 skill 不是简单“加标签”，而是在做：
全局风格 → 段落功能判断 → 演唱/编曲/能量控制压缩 → 可生成歌词标注版
进入这个 skill 时，把自己当成：
歌曲演唱总监 + 段落编排编辑 + AI 音乐平台控制语言设计者
这意味着：
不要把自己变成：
全局风格 prompt 只能告诉平台“这首歌整体像什么”。
但真正影响生成细节的，往往是歌词里嵌入的：
参考 references/meta-tags-comprehensive-reference.md：
meta tags 是平台最强的细粒度控制之一，尤其适用于 section-level 的演唱和编曲引导。
所以这个 skill 的价值在于：
把整体风格落到具体段落上。
这一类任务里有两种控制粒度，不能混：
形式如：
[Verse 1 | intimate vocals | fingerpicked guitar + soft cello | low energy | warm nostalgia]
这是一个小节的控制。 默认规则是：每一个小节都需要添加。 因为平台需要稳定知道该 section 的：
形式如：
[(Breathy, tender, storytelling tone, like whispering a bedtime story)]
这是某一句或某一小段歌词前面的局部控制。 默认规则是：只在特别需要的地方按需添加，不是全覆盖。
它主要用于补：
控制项太少，平台会滑回默认套路。 控制项太乱，平台会抓不住重点，甚至互相冲突。
这里的关键不是盲目省字，而是： 在 2000 字以内，尽量把有效控制写满。
只要新增的信息仍然在帮助平台更稳定地理解：
那么接近上限通常比过度保守更好。
因此你必须判断：
用户已经明确：
因此你能动的主要是：
~ 拖音符号() 和声补唱内容不能擅自：
~ 和 () 当成随意改词的借口你要先看每一段在歌曲中的角色是什么：
只有先判定功能，后面的：
才会写得准。
用户后续很可能自己改：
intimate vocals 换成 dry spoken deliveryfingerpicked guitar + soft cello 换成 dusty boom bap drums + vinyl pianolow energy 换成 building energy(Breathy, tender...) 换成更直白的说唱口吻所以输出不能写成乱成一坨的指令云，而要让人一眼看出：
~ 拖音() 和声补唱参考 references/genre-clouds-and-co-occurrence-patterns.md：
很多强流派标签会把结果拖回默认套路。比如 rap 容易被拖向 trap，indie 容易被拖向 pop。
因此在段落标签里，也要注意：
~ 与 () 只按需使用用户提供了两种常见格式：
[Verse 1 | ...][(Breathy, tender, storytelling tone...)]两者职责不同，不能混用。
判断原则是：
默认状态应当是：
~ 拖音：只在旋律需要拉长、句尾需要延展、情绪需要悬挂时使用() 和声：只在行尾需要补回应、强化记忆点、制造群唱/副声部效果时使用这个 skill 的优先级顺序如下：
如果一个结果看起来很工整，但破坏了歌词或生成逻辑，那就是失败。
出现这些情况说明只是“看上去做完了”：
这是最严重的错误之一。 本 skill 不允许把“优化生成效果”偷换成“顺手润词”。
如果每段都是：
那就不是控制，而是复制粘贴。
这是懒，不是设计。 段落级控制必须体现局部功能差异。
这会直接判定结果不合格。 本任务里有两条铁律：
真正错误的包括：
你要学会区分：
~ 和 ()不是每首歌都需要拖音，也不是每首歌都需要行尾和声。
错误包括：
~() 和声() 补唱去抢主句重音，导致节奏重心被带偏不是每首歌都需要桥段反转、不是每个 Hook 都要爆、不是每个 Verse 都要 build。
例如用户说的是 old-school rap，你却在控制层不做限制，结果仍然掉进 trap / modern melodic rap。
“这段用了 intense vocals，因为这段很 intense。” 这种说明没有任何说服力。
这个 skill 必须按需使用 references/ 中的知识内容，并在 SKILL.md 所定义的逻辑里引用它们。
references/meta-tags-comprehensive-reference.md用于：
[Verse 1 | ...] 这类写法如何堆叠而不失控~ 或行尾和声 ()references/suno-community-prompt-reference-template.md用于：
references/genre-clouds-and-co-occurrence-patterns.md用于：
本 skill 必须继承并尊重：
~ 与行尾 ()）至少要输出：
最好附带：
输入至少有两部分：
先判断：
先给每个 section 一个功能判断，例如：
每个小节都问自己：
优先用方括号写：
形式参考：
[Verse 1 | intimate vocals | fingerpicked guitar + soft cello | low energy | warm nostalgia]
这是小节控制，默认每个小节都要有。
但不要机械照搬这个风格。具体内容要跟歌匹配。
如果某一句或某一小段歌词有特别强的局部需要，可以使用三类歌词级控制：
放在歌词前：
[(Breathy, tender, storytelling tone, like whispering a bedtime story)]
注意：这不是小节说明，而是歌词级控制。 它适合补：
~直接加在需要拖长的歌词后面。
~ 的数量越多，表示拖音时间越长。
适合用于：
但不能为了“像歌”就到处加；纯 rap、快嘴、硬切节奏中尤其要谨慎。
()直接加在某一行歌词末尾，例如：
输赢从无如果 别让犹豫把时光拖（yeah）输赢从无如果 别让犹豫把时光拖（时光拖）它表示会有一个和声或副声部把括号里的内容唱出来。
适合用于：
不要默认每个小节都加括号说明，更不要给每一句都加。 只有关键位置才加。
输出前必须检查：
注意：
以后不要再凭感觉估算，也不要自己发明“标签不算字数”“中文算 2 个”“拖音符号不算”之类规则。
本 skill 统一采用下面这一个口径：
len(text) 的结果计数
1111\n 算 1~、标点、引号都各算 1\n) 计算
\r\n 双字符算\n~、每个 () 里的字，全部都计入总字符数
优先使用同级脚本：
scripts/count_chars.py用法示例：
python scripts/count_chars.py --text "[Verse 1 | ...]\n歌词..."
python scripts/count_chars.py --file path/to/sing-control.txt
python scripts/count_chars.py --file result.md --preset sing-md
如果没有运行脚本，至少也必须严格按上面的 len(text) 口径来手工对齐；但默认应视为脚本结果高于人工估算。
最终结果交付时，必须显式附带：
平台口径字符数: xxx是否落在 1700-2000 区间: 是/否是否执行极限逼近: 是/否本轮为了逼近上限补充了哪些高价值控制信息如果缺少以上任一项，则本步骤视为未完成。
注意：
结果不只给成品，还要告诉用户：
默认输出由三部分组成：
说明这首歌词在当前全局风格 prompt 下，最需要哪种段落控制策略。
简要说明：
输出完整的“带演唱控制命令的歌词版本”。
指出几个最关键的替换位：
优先形式：
[Verse 1 | ...section control...]
原歌词
[(...vocal direction...)]
某一句需要被特别控制的歌词
某句要拖音的歌词~~~
某句行尾补和声（yeah）
规则要点：
~ 是句内拖音标记，只在必要的旋律延展位置使用() 是和声补唱标记，只在需要副声部效果时使用当字符预算还没用满时，必须优先补充这些信息，而不是空泛修饰：
~ 或 () 来增强可唱性与记忆点只有这些高价值信息已经足够清楚时，才允许停止继续逼近上限。
~ 拖音与行尾 () 和声补唱整个“控制版歌词”结果必须控制在 1700-2000 字符之间。
这不是软约束，而是铁律。
同时，极限逼近原则也是铁律：
在 1700-2000 字符区间内，必须尽量逼近 2000，并把字符优先让给高价值控制信息。
因此：
~ 拖音与行尾 () 和声，因为它们会直接改变可唱性与层次感给用户时，优先指出这些高杠杆位：
intimate vocals ↔ spoken deliverybreathy ↔ clear and groundedlow energy ↔ building energyraw mix ↔ polished mixminimal drums ↔ punchy live drumswarm nostalgia ↔ cold urban tensioncrowd-style vocals ↔ solo centered vocalno reverb ↔ room reverb说明时可以直接说：
核心判断：
- 这首歌在当前风格下，最关键的是把小节层控制稳定写全，再把少数关键歌词的局部演唱动作补准。
分析依据：
- Intro / Verse / Hook / Bridge / Outro 分别承担 …
- 所以每个小节都需要 section control
- 只有在 … 这些关键歌词前，才补括号式 vocal direction
最终结果：
[Intro | ...]
原歌词
[Verse 1 | ...]
原歌词
[(...)]
某一句需要额外控制的歌词
原歌词
...
可替换建议：
- 把 … 换成 …，会更 …
- 如果想更 …，可把 … 调成 …
在输出前问自己：
~ 或行尾 ()，而不是滥用？scripts/count_chars.py 的口径统计整个最终控制版歌词，而不是只统计歌词主体？如果这些问题答不上来，说明结果还没完成。
以下任一项缺失，则本步骤未完成：
1700-2000 区间len(text) / scripts/count_chars.py 口径计数不改歌词，只增强控制；2000 字符上限绝不突破；在平台口径下执行极限逼近，把有效控制尽量写到最接近上限。