北京
Nathan写歌、录音、拍视频。但发布每个视频仍然需要做元数据的工作：标题、简介、标签、话题标签、与频道其余部分保持一致，还要检查音频有没有爆音或断掉。
于是有人给他造了一个叫Soundboard的东西。这个人跟Nathan是二十多年的朋友，用他的话说，自己算是有资格下这个判断：Nathan是音乐人，让他同时搞营销，实在是强人所难。
它先学会Nathan是谁
在动笔之前，Gemma会先读Nathan最近30条视频和10张封面图，然后提出一份品牌指南，分成保留、修改、舍弃三类清单，交给他编辑或批准。
这份被批准的指南，优先级高于他早期上传内容里的模式。读他的频道，不等于把他想改掉的东西再重复一遍。目标很明确：文案要像Nathan写的。光丢一句“给我写个YouTube标题”，模型什么也抓不住。
从成品视频到被人找到，中间那段它来补
Soundboard填的是“视频做完”和“有人找到它”之间的空档。Nathan上传视频、输入歌名，剩下的交给它：
- 起草YouTube标题、简介和标签，参考的是这个流派里听众正在听什么，同时按Nathan的写法来写
- 起草Bandcamp的About文案和署名信息，每个字段配一个复制按钮——因为Bandcamp没有上传API，也不接受嵌入
- 挑出竖版Short的钩子，由ffmpeg裁成9:16
他可以改、可以重跑、可以批准。每一次修改，都会成为下一次起草的依据。
有一条要求很实在：如果Nathan改过一次标题，就不该为同样的问题再改第二次。做法是把保存下来的修改传进下一个提示词，而不是去维护一套微调流程或向量数据库。
主视频批准时，每个被改动的字段写一行EDITED，再加一行ACCEPTED；重跑则写一行SKIPPED。Short的批准只记录修改，因为它的元数据是从视频草稿起步的。反馈和任务状态在同一个Firestore事务里提交，这样应用不会记住一次根本没发生过的批准。
修改和批准的分量，重于一次重跑——因为“再试一次”并没有说出他到底不喜欢哪里。Gemma拿到的是修改前后的对照，能看见他实际改了什么。Nathan可以改主意，他有这个权利，这是他的音乐。
演示环境会读取他的记忆，但只写进自己的任务里。让陌生人去教这个应用“Nathan喜欢什么”，那会是个蠢得离谱的功能。
三个“智能体”，其实只是三个提示词构造器
实现上跑的是Gemma 4 12B-it，通过llama.cpp的llama-server，用的是Google在Apache 2.0下开放权重的模型。所谓三个“智能体”，是三个TypeScript提示词构造器，调用同一个/v1/chat/completions接口，配严格的JSON schema，并不需要什么智能体框架。
Gemma的30秒音频上限，把窗口大小定在了29.5秒。页面每次请求只推进一步，因为一个12B模型跑在单张L4上，回答要花上几秒。这个节奏可以接受——假装它是瞬间完成，并不会让它真的变快。
页面每个请求执行一个流水线步骤。模型如果被缩容、正在加载或繁忙，会返回一个等待原因；重新加载即可恢复任务。
他没法保证算法会听到Nathan的音乐。他能做的，是把那些琐碎的杂活从他身上拿走。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
