01
PART
先说结果
THE RESULT
41 首歌分了 6 组，每组一个明确的用处。
广场舞曲 10 首
节奏轻快，好跟，副歌能齐唱。
驾车提神 10 首
九十到一百二 BPM，不催眠，副歌要醒。
夫妻 1 首
《岁月里的那双手》，体味对方疾苦、不离不弃。
励志担当 10 首
短、狠、震撼，战鼓开场，副歌全场齐吼。
歌颂祖国 5 首
交响大合唱，管乐辉煌，副歌如礼炮。
人生感悟 5 首
慢下来，卸下来，一壶茶的功夫。
每一首都不是「随便生成一下」。歌词文件里写着情境、BPM、编曲指令——比如《我来担》写的是「96 BPM，低音合唱起，战鼓三下开场，副歌全场跺脚齐吼」；《万里锦绣》是「92 BPM，交响大合唱，开篇管乐辉煌，副歌如礼炮」。
这批歌的用途很实在：广场舞队要能跳，长途司机要能提神，朋友圈要能转发。做给具体的人听的，不是做给「AI 音乐」这个标签的。
02
PART
做 1 首和做 41 首，是两件事
SCALE CHANGES EVERYTHING
手工做一首歌的流程是这样的：打开网页、粘贴歌词、点生成、盯着等、在曲库里找到它、想办法把音频弄下来、改名、做封面、检查能不能播。九步。
一首歌九步，做十首不是「九步乘以十」那么简单。因为每一步都会以不同的方式失败，而你在第五首失败时，前四首的进度、已经生成的歌、已经做好的封面，都得保住。
真正麻烦的是这三件事：
断点续跑
中途挂了不能从头再来。所以每一步完成都要往一个清单文件里写一条记录，下次开机先看清单，缺哪首补哪首。
认领
生成完了，你得分清曲库里那一堆作品哪个是你要的。这是整套流程里最容易出错的一环，没有之一。
校验
下载到的文件不一定能播。文件头对、时长对，不代表解码出来有声音。
这三点解决不了，量一大就崩。
03
PART
流水线长什么样
THE PIPELINE
整条链是八个步骤，每一步是独立子进程，失败就中止并写日志，不污染其他步骤。
1 写歌词
41 份 .txt，带情境与编曲指令。
2 等登录
浏览器就绪才开始花钱。
3 下发
自动填词、点生成。
4 认领（最关键）
在曲库里认出刚生成的那首。整套流程的技术含量，八成在这一步。
5 抓音频
录流下载，一首三分钟左右。
6 复制歌词
与成品同名归档，方便一起分发。
7 做封面
生成底图，合成 2048，叠上曲名与拼音。
8 三重校验
文件头、时长、实际解码，缺一项都不算成品。
看上去平平无奇。真正的内容在第 4 步。
04
PART
真正卡住我的六个坑
SIX TRAPS
我一开始很天真：页面上有个播放器，那必然有个音频地址，抓下来不就行了？
没有。音频是流式的，拿不到完整直链。
最后唯一的可靠办法是用浏览器的录制能力，把正在播放的流录下来——点播放，等它报「音频就绪」，录完存盘。好处是拿到的就是真实播放内容，坏处是慢，一首歌三分钟左右，一批下来要二十几分钟。
这个「慢」后来救了我：正因为每首都要真播一遍，所以任何一首是哑巴，当场就能发现。
生成完了，曲库里多出一堆作品。怎么知道哪个是你的？
第一个念头是按标题找。不行——平台会改你的标题。你提交《春风翻过那道岭》，回来可能叫别的名字。
第二个念头是按时间找「最新那个」。也不行——一次提交会生成两个版本，两个都是有效成品，你分不清哪个在前面。
最后的办法是不看名字，看内容：把歌词正文的每一行拿去和曲库里每个作品的提交原文比对，数命中的行数，算一个「重合度」。命中率过线就认领。
这里还有个反直觉的细节：某一条记录打分是0/23，意思是全曲库 785 个作品里，这首歌的 23 行歌词一行都没出现。不是「认错了」，是它根本没被生成。这个数字后来成了我判断「要不要重发」的依据。
顺带说一句：我最早用「页面里有没有特殊字符」来判断语种，结果把两条正确记录误判成错配，因为那两首的页面当时没渲染出歌词。凡是靠页面渲染状态做的判断，都不可靠；能读数据就不要读界面。
自动化最怕的不是登录，是以为自己登录了。
我用的是一个持久化的浏览器配置目录，登录一次就一直有效。但有一天它突然失效了，脚本一路跑到「点生成」才失败，白等了很久。
排查下来，Cookie 是会骗人的：配置目录里残留的旧票据还在，你一查「有没有登录凭证」，答案是「有」，但会话其实早就过期了。
后来我定了三条铁律，缺一不可才算真登录：页面停在生成页没被弹回首页、能从页面里拿到有效的会话令牌、生成按钮存在且只有一个。
还有一次更尴尬：脚本说「窗口已打开」，我这边什么都看不见。其实是窗口被压在下面，而且浮着一个「要恢复页面吗」的气泡——千万别点那个恢复，点了标签页重载，正在跑的任务就断了。
我同时在跑好几个专辑项目。它们一开始共用一个浏览器配置目录，结果互相把对方踢掉——同一个配置目录，同一时刻只能被一个进程持有。
改成每个项目一份独立配置目录，并且路径必须写绝对路径——写相对路径会因为工作目录漂移而跑到别处去。
更麻烦的是账号只有一个，生成队列是共享的。另一个项目在猛发，我这边就一直排队，表现出来的症状是「点生成按钮超时」。我一度以为是被限流，写了个错峰重试器，检测到别人在发就让路。
这个判断后来被证明是错的——真正的原因在坑 05。
有一批歌，从某一首开始，连续十几首全部失败，症状高度一致：按钮点得动、没有报错、没有验证、然后就是等不到新歌出现。
我当时的判断是「队列被挤爆了」，于是写了自动重试，让它错峰、等待、重发。
后来我把生成页的正文打印出来看，里面赫然写着一行提示：额度已用完，请升级套餐。顶上的余额徽章是0。
可怕的地方在于：额度耗尽时，这个平台表现得极其安静。生成按钮照样可点，点了不弹任何错误，不扣额度，也不生成任何东西。从脚本这一侧看，和「队列忙」长得一模一样。
教训写进了排错文档的第一条：只要出现「集体超时、一首都不出」，第一件事是查额度，不是加长等待时间。
我想判断「某个进程还活着吗」，写了一行检测代码 os.kill(pid, 0) 。在 Linux 上这就是个纯粹的存在性检查，信号 0 不会真的发信号。
在 Windows 上，它会直接把进程杀掉。链条跑到一半，自己把自己上一轮启动的任务给终止了。
还有一次更玄学：我用系统管理接口去读进程命令行，中文全部变成乱码。换成专门查进程信息的库才正常。
这俩坑的共同点是：它们在别的系统上都「看起来没问题」，所以你不会怀疑它们。
05
PART
最难的一步，其实在收尾
THE LAST MILE
八小时空转那次，我复盘日志时发现了一件让人哭笑不得的事。
链条里有个「核对」步骤，只要发现一条记录对不上就中断整条链。而那批歌里，有六首其实早就生成好了、记录也正确，就因为另外一首对不上，硬生生被堵在后面，八小时一首都没下载下来。
我改成「已确认的先交付、有问题的单独处理」，只补跑后面三步，二十二分钟就把六首全抓回来了，每一首都过了三重校验：169 秒、185 秒、214 秒、190 秒、210 秒、229 秒，码率 176 到 185 kbps。
批量生产里最容易亏的，不是生成环节，是「已经做好的东西没能拿到手」。钱花出去了，成品在云端，就差最后一步没跑。
所以现在的原则是：诊断步骤不许卡住交付步骤。可疑的先隔离，确认好的先落盘。
06
PART
如果你想抄这份作业
SIX RULES
这几条是踩完坑之后留下的，跟具体用哪个平台无关。
先跑通一首，再上量
「跑通」的标准是成品能播、封面在、歌词归档，不是「生成成功了」。
每一步都要能重跑
把进度写在清单文件里，任何一步挂掉，下次开机接着跑，绝不从头再来。
能读数据就不读界面
页面渲染状态会骗人，接口返回不会。
校验要验到「能播」为止
文件头对、时长对，还得真的解码听一遍有声音。
配额是一等公民
任何「集体静默失败」，先查额度再查别的。
诊断不许卡交付
可疑的隔离，确认的先落盘。
还有一条不是技术层面的：歌词要写给人。《岁月里的那双手》是写给一起过了半辈子的人，《卸下来》是写给扛不动了还想扛的人。你把情境、对象、情绪写清楚了，机器才知道往哪个方向使劲。
技术负责批量，人负责值得被批量。
07
PART
还有 6 首没做完
TO BE CONTINUED
《春风翻过那道岭》《人间烟火》《山河无恙》《来日并不方长》《讲和》《剩下的那几样》。
歌词都写好了，41 份一份不少，就躺在目录里。它们不是做不出来，是这个月的额度用完了。等额度恢复，一条命令就能接上。
我不打算把它们删掉凑一个整数。35/41 就是 35/41，剩下的 6 首在那儿等着，本身就是这件事的一部分。
///
END
做第二遍的意义
CLOSING
回头看，这一个月最有价值的产出其实不是那 35 首歌，而是一份写到了 C18 的排错文档。每一条都长这样：症状是什么、我误判成了什么、真正的根因是什么、以后第一步该做什么。
歌会过时，流水线会换平台，但这十八条不会——因为它们记录的不是某个按钮怎么点，而是人在自动化面前，会以哪些固定的方式被骗。
下次再做，我大概两天就能跑完同样的事。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。
THANKS FOR READING