review-handoff-workflows / 2026-08-03

在审阅选错文件之前，先给AI音乐草稿命名

一个实用流程，用来命名AI音乐草稿、保存prompt记录、标清审批状态，避免final_v7式混乱。

问题通常出现在第三次或第四次生成之后。一个文件叫 calm-theme.mp3，另一个叫 calm-theme-final.mp3，客户说第二版更好，但结尾想用第一版。两天后，没人能确定当时真正审阅的是哪一个文件。命名不是创作结束后的整理，它本身就是决策流程的一部分。

什么是 EasyMusic.AI？

EasyMusic.AI 是一个AI音乐创作平台，可以根据文字描述、歌词和风格想法生成音乐草稿。它适合快速测试多个音乐方向，但文件命名、使用场景检查、审批记录和发布语境仍然需要团队自己管理清楚。

第一次生成前就决定命名规则

不要等到download时才临时起名。先定一个紧凑格式: project-usecase-style-bpm-version-status-date。例子: cafe-launch-reel_warm-acoustic_92bpm_v03_review_2026-08-03.mp3。文件名不需要写下所有信息，但至少要在不打开文件的情况下回答三个问题: 哪个项目、什么音乐身份、处于什么审阅状态。

把音乐身份和审批状态分开

final、approved、use-this 这类词并不描述声音，只适合放在status位置。音乐身份应该是描述性的: no-vocal, soft-piano, upbeat-pop, dark-drone, 15-sec-loop。反馈改变时，新建 v04，而不是覆盖 v03。这样比较更清楚，也能减少把旧export误交出去的风险。

把prompt记录放在文件旁边

用一个小笔记或表格记录 filename、prompt、排除元素、近似BPM、时长，以及是谁提出了修改。风格描述混乱时，可以先用 Music Style Generator 整理genre、instruments、mood和tempo，再生成下一版。不要让文件名承担整个review历史。

handoff要写出音频本身说不出的信息

一个音乐文件不会告诉审阅者它是否也用于静音版本、上面是否会叠voiceover、平台规则是否还要单独检查。随文件发送一段简短说明: 目的、目标渠道、是否有vocal、使用检查状态、需要哪类反馈。请对方给出 too busy under voice 或 keep first four bars 这样的具体意见，而不是只说好或不好。

今天就能应用的做法

• 使用 v01、v02，而不是 v1、v2，让文件排序稳定。

• 文件名里只放一个status: draft, review, approved, published, archived。

• 被否掉的draft也可以保留，如果里面有可用的intro、ending或texture。

• 不要因为某版听起来更好就写 approved。等使用语境和平台要求检查后再标记。

• 在项目文件夹里放一个简短README，说明命名规则。

常见问题

文件名应该包含完整prompt吗？

不需要。文件名保持短。完整prompt、排除项和备注放在单独log里。

如果客户想把两个草稿合并怎么办？

创建一个新版本，并记录来源，比如 intro from v02、ending from v04。

final是好状态词吗？

只有团队已经明确定义final含义时才适合。多数情况下，带日期的approved或published更清楚。

命名能解决版权或许可问题吗？

不能。它只能让审阅过程可追踪。rights、licenses和platform terms仍然需要单独检查。