飞书口述 → 结构化 PromptPack
AI MUSIC / CREATIVE OPERATIONS
Music OS
一套从飞书灵感、AI 生成、本地处理到专辑发布的创作系统，以及由它持续积累的音乐作品库。
- 角色
- Owner / 创作工作流设计 / 自动化工程 / 音乐策展
- 时间
- 2025-2026 · Ongoing
- 平台
- Feishu / macOS / Music Board / NetEase Cloud Music / DistroKid
自动化负责重复劳动；人保留对声音、封面和最终发布的审美决定。
PART I / THE SYSTEM
先看我构建了什么：一条有人类质量门的音乐生产服务
- 它不是一段脚本，而是跨越飞书、生成平台、本地处理设备、资产看板、播放器与发布平台的服务链。
- 全局工作台先回答“现在在哪一步、库存如何、哪里需要人接管”，再进入具体执行。
全局工作台把灵感、生成、下载入库、试听筛选、发布归档和运行排障放进同一张服务地图；先判断今天卡在哪一步，再进入具体操作。
读取未处理需求并回写状态
获取、分轨、人声与可靠落盘
喜欢 / 待处理 / 待发布
封面质量门 → 分平台发布
IDEA → ASSET → CATALOG → RELEASE
系统管理的不是一次生成，而是从创意到可发布资产的完整生命周期。
03 / Intake & Feedback
飞书既是低摩擦入口，也是跨设备状态回路
- 口述灵感被整理为主题、人声、结构和风格字段，形成可消费的 PromptPack。
- Windows 后台任务把进度、磁盘、进程和日志位置回传到同一频道。
- 通知不是附属功能，而是人能安全离开执行设备的控制机制。
Windows 任务通过飞书回传状态、进度、磁盘余量、进程与日志位置；人可以离开执行设备，仍然知道任务在跑什么、是否需要接管。
低摩擦输入被转换为包含主题、人声、结构和风格的可追踪需求。
04 / Production
自动、半自动和人工不是口号，而是可观察的责任边界
- AUTO：队列消费、下载、分轨、基础处理、归档与通知。
- SEMI：专辑编排、元数据准备、平台填表与异常接管。
- MANUAL：听感、封面、最终取舍和发布确认。
- 运行控制台让后台任务、日志和停止机制保持可见。
机器承担可重复、可校验的步骤。
系统准备，人确认并接管异常。
主观质量不伪装成可量化规则。
AUTOMATION BOUNDARY
半自动不是未完成，而是系统有意识保留的人类质量门。
运行控制台把当前人工任务与后台自动任务并排呈现，并保留日志、结果目录和停止入口；自动化不再是不可见的黑箱。
05 / Curation
本地播放器负责操作，看板负责全局资产视图
- Air Final Player 按路径加载真实音频，把试听与状态操作放在一起。
- Music Board 联合读取音频、歌词与配置，呈现类型、风格和状态。
- 人工可以删除、喜欢、送入待处理或待发布；封面与最终声音偏好不交给自动评分。
本地播放器不是作品网站的复制品：它把试听、删除、改名、优化标记、待发布和已发布状态放在同一个操作面。
Music Board 是资产进入人工判断阶段后的统一浏览、检索和试听表面。
音频、歌词和配置一起流转，状态比文件夹数量更重要。
06 / Release
库存形成专辑，平台适配留在最后一公里
- 库存达到合适规模后，系统辅助整理歌名、专辑名、目录和元数据。
- 网易云承担发布与长期备份；DistroKid 承担更广分发。
- 批量操作可以自动辅助，但提交、异常恢复和封面质量仍由人确认。
转码、专辑草稿、歌词与发布后回填。
按专辑准备 CSV、元数据和批量填表。
平台差异被保留在各自适配层，发布前仍由人确认。
07 / Boundary
正确的完成状态是半自动，而不是无人值守
- 已经运行：创意输入、部分批量生成、本地处理、资产看板、人工分类和部分平台发布。
- 部分运行：专辑整理、封面和跨平台发布。
- 尚未完成：按周检测库存并自动生成完整发布包。
- “800+ 首”和“每天节省约 2 小时”来自创作者口述，不作为独立审计指标。
已有源码、目录与运行记录。
半自动运行，人工处理质量与异常。
仍是目标状态，不当作已经完成。
案例明确区分已运行、部分运行和仍待实现的部分。
PART II / THE CATALOG
系统最终留下的，是可以被听见和持续积累的作品资产
- 公开音乐站承担内容展示：专辑、单曲、歌词与试听。
- 它是生产系统的结果层，不再被误称为自动化系统本身。
- 页面的两个出口因此各自回答不同问题：我是怎么做的，以及我最终做出了什么。
公开站点承担结果层：用专辑、单曲与试听入口呈现自动化系统最终留下的内容资产。
体验深描
痛点、用户故事与交互设计
这一段不讲技术栈，只讲「人在什么处境下用它、哪里卡住、我做了什么回应」。
我的痛点
这些项目都从我自己被卡住的地方开始。
- P01
生成一首歌只要几分钟，但下载、分轨、改名、归档、比对、填表这些重复动作能吃掉整个晚上。
- P02
灵感来的时候手边只有手机，等回到电脑前，当时想要的那个味道已经说不清了。
- P03
生成额度有窗口，人不可能一直守着；错过窗口就白等一天。
- P04
网易云和 DistroKid 要求的元数据格式不同，一张专辑要手填几十个字段。
- P05
但全自动会毁掉质量——机器听不出哪一版好听，也选不出对的封面。
用户故事
写成「作为…我想…以便…」，每条对应一个可验证的产品动作。
- US01
作为在路上突然有灵感的人，我想口述一段想法就生成可追踪的 PromptPack，以便灵感不依赖我在不在电脑前。
- US02
作为额度受限的创作者，我想让系统在额度窗口自动消化积压队列，以便我不在的时候产能仍在跑。
- US03
作为有审美要求的人，我想在一块看板上快速试听并标记喜欢 / 待处理 / 待发布，以便注意力只花在判断上。
- US04
作为多平台发行者，我想让系统备好各平台的元数据表单、我只做确认，以便不再手填几十个字段。
- US05
作为长期运营者，我想每个音频资产都有明确状态，以便半年后仍然知道这首歌走到了哪一步。
用户体验旅程
按真实使用顺序展开：此刻在做什么 / 哪里有摩擦 / 产品怎么回应。
阶段此刻在做什么摩擦点产品回应
01Intake 收灵感
在飞书里口述一段想要的方向。
灵感和产线之间隔着一次手工录入，多数灵感死在这一步。
ChatOps 把口述直接落成带状态的 PromptPack 并进入队列，不需要打开任何后台。
02Generate 排队生成
额度窗口打开，队列里还有积压需求。
人守着额度窗口不现实，错过就浪费一天。
队列驱动生成：窗口一到自动消化积压，处理状态可查。
03Process 本地后处理
需要分析、分轨、人声与时间线处理。
这一段是纯机械劳动，却最占时间。
Python / shell / Reaper 串起处理链路，空闲设备接手本地后处理。
04Curate 人工定稿
试听挑选、修复瑕疵、组成专辑。
「好不好听」「封面选哪张」机器判断不了。
Music Board 提供喜欢 / 待处理 / 待发布状态，系统只负责备料，审美决策留给人。
05Release 分平台发布
准备网易云与 DistroKid 的专辑与元数据。
两个平台字段口径不同，手填几十个字段且易错。
按平台备好表单与专辑资料，人点确认；发布后状态回写到资产。
交互细节
决定「用起来顺不顺」的微观判断。
- AUTO / SEMI / MANUAL 三档标注
- 每个步骤在界面上明确属于哪一档，人一眼看出哪里需要自己出手。
- 状态即入口
- 资产的「喜欢 / 待处理 / 待发布」不是标签而是工作队列，点状态直接进入下一步动作。
- 口述即入队
- 飞书消息就是入口，不需要额外打开管理后台。
- 试听优先于元数据
- Board 上先能听，再看字段——判断顺序决定信息排布顺序。
- 失败不静默
- 处理链路中断时资产退回上一个状态，而不是消失在队列里。
设计细节
视觉系统、状态语言与节奏上的取舍。
- 用状态驱动资产生命周期
- 界面不是围绕「生成按钮」组织的，而是围绕内容资产从输入到发布的状态流转。
- 明确划出人机边界
- 系统准备与人拿主意在界面上分开呈现，不让自动化伪装成审美判断。
- 看板保持列表密度
- 本地资产看板一屏能扫完一批，便于批量试听与筛选。
- 平台差异收在系统里
- 分平台适配器吸收字段差异，界面上保持同一套操作语义。