suno-songwriting

Suno 歌曲创作

参考文件

文件	用途
references/clarifying-interview-instructions.md	信息收集记录、访谈流程、充分性门槛和草稿模式例外。
references/lyric-writing-instructions.md	歌词创作、修改、押韵、结构、记忆点、副歌桥段和标题选项。
references/style-writing-instructions.md	Suno 风格提示词、提示词长度、排序、流派融合、制作方向和负面约束。
references/genre-knowledge.md	流派选择、流派融合、年代参考、子流派术语和制作特征。
references/vocal-routing-index.md	用于人声描述、音色资料资源、比较和声音设计深度的轻量路由索引。
references/instrument-knowledge.md	乐队、管弦乐编配、合成器、节奏组、音色调色板和编曲术语。
references/lyric-tag-knowledge.md	方括号歌词标签、段落标签、演唱提示、器乐间奏和标签使用克制原则。
references/translation-instructions.md	非英语歌词、双语歌词、翻译、本地化、音节保留和演唱流畅度。
references/extended-genre-diversity-matrix.md	罕见、历史、地区和融合流派术语索引；从此处跳转到相关的 genres-*.md 文件。
references/structure-movement-tags.md	结构、律动、能量、节拍、高潮、Drop、即兴演奏和编曲标签的详细索引。
references/vocal-identity-library.md	命名人声特征、声音档案比较、档案提示词变体和评估标准索引。

只有当任务需要相应深度时，才通过索引资源加载专门的音色档案、流派和标签系列文件。

核心工作流

使用此技能生成两项相互配合的输出：

1. 适用于 Suno 歌词栏的歌词，使用段落标签，并在其中嵌入可选的演唱、律动、编曲或增强提示标签。
2. 适用于 Suno 风格提示词栏的风格提示词，根据用户的需求说明采用精简或详尽的制作简报形式。

创作新歌、进行重大改写、根据审美判断进行翻译或改编，或用户要求提供可直接用于 Suno 的结果时，首先阅读 references/clarifying-interview-instructions.md。除非用户已经提供包含所有关键输入的完整需求说明，否则默认进行访谈。将该文件中的访谈清单作为内部信息收集记录：每个必需方面都必须由用户提供、根据充分把握合理推断低影响细节，或在无关时明确跳过／省略。每轮访谈最多提出五个问题，每个问题只涉及一个未解决的输入类别；不要把不同类别合并成一个问题或答案选项。继续访谈，直到用户明确提供所有关键输入。即使用户拒绝回答问题、让你自行决定、要求快速草稿，或表示“其他都由你决定”，也不得跳过关键输入问题。不要把主题加流派，或主题加情绪，视为完整需求说明。

必须停止：如果用户对新歌只提供了简略需求，首次回复不得给出最终的四部分输出。请改为提供信息收集摘要和澄清问题。

草稿 / 草图模式

仅当用户明确要求快速草稿、粗略版本、歌词初稿、头脑风暴、初版、探索性选项或类似的非最终交付物时，才使用草图模式。草图模式旨在加快构思，而非生成可直接用于 Suno 的最终内容。

生成草图前，收集或确认以下最低限度的输入：

1. 交付物范围。
2. 主题 / 前提。
3. 主要流派或大致风格方向。
4. 如果用户要求歌词，确认歌词视角。
5. 禁止内容，或确认没有任何限制。

在草图模式下，根据最佳判断推断故事切入角度、情感落点、演唱者身份、演唱风格、目标时长、段落结构、BPM、调性、编曲变化及其他低风险控制项。不要在生成草图前执行强制关键输入审核门槛。不要将草图说成最终版、润色版、可发布版或可直接用于 Suno 的版本。

使用以下草图格式：

### Sketch Draft
...

### Assumptions
...

### Next Questions
...

如果用户要求定稿、润色、导出草图，或使草图达到可直接用于 Suno 的状态，请在生成最终的 Title / Lyrics / Style / Analysis 输出前，返回常规访谈和关键输入审核流程。

强制关键输入审核门槛

对于每个将生成歌词、风格提示词或最终 Title / Lyrics / Style / Analysis 输出的请求，此门槛都在技能层面强制执行。

生成歌词或风格提示词前，始终向用户展示简洁的关键输入审核并请求确认。即使用户已提供完整简报，也必须执行此步骤。不得在展示审核的同一条回复中生成内容。

使用以下格式：

Critical inputs to review:
- User decisions: ...
- Best-judgment decisions: ...

Reply "approved" to generate, or tell me what to change.

User decisions 必须总结用户通过简报或访谈直接提供的关键选择。Best-judgment decisions 必须仅总结技能推断或默认采用的非关键选择。

审核必须涵盖所有适用的、会影响生成内容的输入：交付物范围、前提、故事切入角度、歌词视角、收件人 / 听众、情感落点、基调、强度、主要流派、辅助流派或融合风格、BPM 或速度感、调性或调式、制作方向、演唱者身份、演唱风格、目标时长、段落计划、歌词密度、丰富标签、标签克制程度、编曲变化、语言、露骨程度、必需短语、禁止内容、安全约束、敏感内容处理方式和使用场景。对于可直接用于 Suno 的歌曲，用户必须在审核通过前明确提供段落结构、BPM / 速度、调性 / 调式、演唱者身份和演唱风格。

只有在用户批准审核，或明确要求按这些假设继续后，技能才能生成歌词、风格提示词文本、标题选项或分析。如果用户更改了关键输入，请更新审核并再次请求确认，然后再生成内容。

资源路由

仅加载特定任务所需的资源：

• 创作、修改歌词，以及处理押韵、结构、记忆点、副歌桥段和标题选项时，请阅读 references/lyric-writing-instructions.md。
• 撰写 Suno 风格提示词，以及处理提示词长度、排序、流派融合、情绪、制作和负面约束时，请阅读 references/style-writing-instructions.md。
• 选择流派、融合流派、参考时代、子流派词汇和制作特点时，请阅读 references/genre-knowledge.md。
• 描述普通歌手、和声、合唱团、说唱、口语演唱、二重唱和人声制作方向时，请先阅读 references/vocal-routing-index.md；该索引会指向精简人声风格、坐标、档案、比较和评分标准等资源。
• 处理乐队、管弦乐编配、合成器、节奏组、音色范围和编曲词汇时，请阅读 references/instrument-knowledge.md。
• 处理方括号中的歌词标签、段落标签、演唱提示、器乐间奏和标签使用节制时，请阅读 references/lyric-tag-knowledge.md。
• 处理非英语歌词、双语歌词、翻译、本地化、音节保留和跨语言可唱性时，请阅读 references/translation-instructions.md。
• 动笔前收集需求时，请阅读 references/clarifying-interview-instructions.md。

当任务需要更广泛的内容或专业词汇时，请优先使用索引资源：

• 处理少见、历史、地域或融合流派词汇时，请阅读 references/extended-genre-diversity-matrix.md，然后仅加载相关的 references/genres-*.md 系列文件。
• 处理详细的结构、推进、能量、脉搏、高潮、骤停、即兴和编曲标签时，请阅读 references/structure-movement-tags.md，然后仅加载相关的标签系列文件。
• 处理命名人声身份、人声档案比较、档案提示词变体和评估标准时，请阅读 references/vocal-identity-library.md，然后仅加载相关的档案、提示词、比较或评分标准文件。
• 无需命名档案而需详细设计人声坐标时，请阅读 references/vocal-style-knowledge.md 或 references/vocal-feature-space.md。
• 生成或扩展人声身份库时，请阅读 references/vocal-identity-generation-instructions.md。

输出规范

始终将最终结果作为 Markdown 文件返回，且必须严格按照以下顺序使用这 4 个 H3 标题：Title、Lyrics、Style、Analysis。每个 H3 标题下的内容都要放在围栏代码块内，方便复制粘贴。

使用以下结构：

### Title
```text
...
```

### Lyrics
```markdown
[Verse 1]
...
```

### Style
```text
...
```

### Analysis
```markdown
...
```

风格提示词应简洁但信息充分：简单需求使用逗号分隔的精简提示词；对于鲜明的融合风格、详细的人声表现、乐器编配、编曲推进、歌词主题或时长限制，则使用信息更密集的制作简报式提示词。歌词应便于演唱、结构清晰，并可直接粘贴到 Suno。在 Lyrics 代码块中，每个方括号内的歌词标签都必须是段落标签；将所有扩展提示标签、推进标签、编曲标签和演唱标签嵌入相应的段落标签中，例如 [Verse 1 - Spoken Delivery] 或 [Final Chorus - Big Chorus, Ad-Lib Finale]。不要在歌词中单独放置提示或演唱标签。在 Analysis 中，主要围绕歌词含义展开：叙事弧线、说话者、主题、隐喻、意象、情感转折，以及记忆点如何重新诠释歌曲。只有在有助于说明含义、叙事、主题、意象或情感节奏时，才讨论风格提示词、结构、时长或扩充内容的选择。如果用户要求提供多个选项，则每个选项都重复相同的四段结构，并通过改变流派、记忆点角度、人声方向或编曲来体现差异，避免选项近似重复。

输出后提供文件

生成并展示最终的 Title / Lyrics / Style / Analysis 输出后，询问用户是否要将所显示的 Markdown 原样写入本地文件。除非用户事先明确要求创建文件，否则不要在展示输出前写入文件。

使用以下格式提供一个具体的建议路径：

./songs/{YYYYMMDD-HHMMSS}-{song-title-slug}.md

如果可以获取用户的本地日期和时间，请使用该日期和时间。根据选定的标题创建标题 slug：转换为小写，尽可能使用 ASCII 字符，以连字符分隔，并去掉不适合用于文件名的标点符号。如果有多个歌曲选项，每个选项都提供一个文件，并使用不同的标题 slug。如果建议的文件名已存在，请追加 -2、-3 或下一个可用的数字后缀，不要覆盖现有文件。

最终回复以简短的询问结束，例如：

I can also write this to `./songs/20260512-143015-example-title.md`.

如果用户接受，请在需要时创建 songs 目录，并写入完全一致的最终 Markdown 内容，包括四个 H3 章节和围栏代码块。

对于草稿模式，除非用户明确要求保存草稿，否则不要提供写入文件的选项。

决策规则

• 优先使用具体的音乐描述，而非抽象的赞美。
• Suno 风格提示词应重点突出且排序清晰。对于精简提示词，如有标志性音色或风格，应优先写入，然后依次写入流派、BPM、调性、辅助风格、演唱身份、乐器角色、歌词主题和制作质感。对于丰富提示词，请遵循 references/style-writing-instructions.md。
• 只有当用户提供的完整需求明确包含关键输入时，才避免询问相关问题；否则，先通过澄清式访谈了解需求，再开始创作。
• 除非用户将乐器名称或音乐概念作为主题，否则不要在歌词中提及它们。
• 将生成的演唱身份视为具体的角色画像，明确其声音、流派、咬字和制作特征。
• 默认适度使用方括号歌词标签：使用常规段落标签，并在其中加入少量重要的扩展提示，避免标签过多。
• 翻译时，优先保留可唱性和情感意图，而非逐字遵循原文语序。