命名结构：四段式
歌名-内容类型-版本号-日期。歌名放最前便于排序聚合；内容类型用固定词表：干声、伴奏、混音、母带、试听；版本号 v1、v2 递增；日期 YYYYMMDD 区分同版本不同天的导出。
示例对比：反例"新建文件夹(3)/最终版2.wav"，正例"窗外的雨-混音-v3-20260830.wav"。三个月后找文件，正例三秒定位。
内容类型词表：固定不变
词表一旦建立就不要改：干声（原始录音）、伴奏（练唱版/录制版分标）、混音（处理后的成品）、母带（最终交付）、试听（快速分享）。
新增类型时先想清楚它与现有类型的边界，避免"精修版""加强版"这类模糊词进入体系。模糊词是命名混乱的起点。
版本号与日期的分工
版本号表示"同一内容类型的第几次实质修改"，日期表示"什么时候导出的"。v3-20260830 和 v3-20260901 是同版本不同导出，v4-20260901 是新版本。
版本号跳升（v2 直接到 v5）没问题，只要中间版本有留档。版本号的唯一规则是只增不减。
工具版本与文件版本双轨
工具内（如歌境）的版本管理负责回退和来源关系，文件命名负责对外交付和跨设备识别。两套体系并存，工程包导出时按命名规范落盘。
找回历史版本：先查工具内版本记录（有来源关系），再查备份文件夹（按日期归档）。双轨体系的检索路径永远清晰。
命名规范的家庭作业：花十分钟把现有文件按规范重命名一遍，混乱的存量文件是规范落地的最大阻力。重命名过程中你会发现大量重复和丢失的版本。
命名规范与协作
多人协作时命名规范是公共契约：规范文档化并放在项目说明里，所有成员按同一规范命名。协作混乱的根源往往就是"每个人一套命名习惯"。
规范的执行靠流程不靠自觉：导出环节的命名模板化（工具自动按模板生成），交付前的检查清单包含命名核对。流程兜底比提醒有效。