最近发现本地音乐文件中有不少元数据信息是乱码或不准确的，比如专辑名称、作者、歌名… 这些附加在MP3等音乐文件中描述性的数据。问题根源主要是不同时期遗留的中文编码（如GBK）没有被正确识别或存储为UTF-8造成的。苹果音乐的自动匹配功能虽然能修正一部分，但对于这类由原始乱码导致的元信息错误却无能为力。最让人抓狂的是，它会把本该属于同一张专辑的歌曲，因为乱码造成的细微差异（肉眼可能看不出区别），分到了两个显示为‘同名’但实际上不同的虚拟专辑里！这对于强迫症来说简直不能忍。

最初我打算把它当作一个「无脑」的休息活动，准备一个个手工改写成UTF-8，这将是一个耗时不菲的「愚蠢任务」。

朋友CloudZ一句话点醒了我：“为啥不写个程序处理呢？”对啊！这种批量、规则明确的重复任务正是程序的强项。

我立刻动手，借助Claude Code来生成和迭代代码脚本。大概用了不到一个小时，核心的元数据读取、编码转换与重写的功能就实现了基本可用版本。 接着一边运行程序处理我那六千多个音乐文件，一边继续用Claude完善错误处理和特殊场景支持。当天就搞定了所有问题音乐文件！成就感爆棚之余，顺手把这个工具开源放到了Github。

这次经历让我深刻体会到，像audio meta fixer解决的这类问题，正是当下人工智能辅助编程最能发挥威力的典型场景：

使用者只是需要一次性的使用某个功能处理一些数据，但因为问题的复杂度，需要编制一个程序来实现。

按传统软件工程角度，这类任务往往也需要若干程序员的一些时间才能完成，为了能保证质量，有时候还需要加上需求调研、测试这些过程成本，这么一来，无论多小的功能，实现成本都不会低。于是很多需求就因为成本问题无法实现，或者只有当需求具有相当共性的特征时，才可能被立项开发，又或者最终被某个专业工具集成实现后，需要购买这个专业工具来实现需求。

但是，哪怕是专业工具往往也并不能100%解决用户的各种特殊问题。比如我的音乐库中有一张久石让的CD，当时烧录时直接使用了默认的日文片假名歌曲名称，如果简单地直接按照原来的编码转成UTF-8，日文片假名可能会变成一堆毫无意义的中文字符组合。发现问题后，我提示让Claude Code针对这个特殊情况进行处理，只用了两次对话就解决了。类似问题还有拉丁语、法语等西欧字符集的歌曲名称问题，这些非常个性化的特殊问题，都得以用极小的成本快速解决。

在这个时代，大型通用软件依然不可或缺，但解决个性化、一次性或长尾需求的定制化开发场景，正迅速被生成式人工智能驱动的「新生产力」所变革。这不仅挑战着专业程序员的工作方式，也意味着普通用户具备了前所未有的能力去自主实现特定小目标。

未来的关键竞争力不再是单纯拥有解决问题的能力，而是能够敏锐发现那些值得被解决的独特问题场景的能力。

最后，如果你的本地音乐库的元数据也有一些乱码的问题，可以下载试试，或者自己写一个程序解决它。

https://github.com/samyn/audio_meta_fixer