开发者重写音乐播放器代码库以移除 AI 生成的“垃圾代码”

一名正在构建自定义音乐播放器 AMP 的开发者最近删除了其代码库中近一半的内容，旨在消除由大语言模型（LLM）引入的复杂性。该项目使用 Zig 编程语言编写，最初是利用 Claude Max 20x 订阅快速生成功能，但作者发现由此产生的数万行代码难以审查和维护。

这张图片代表了项目在重大手动重构之前的早期开发阶段。

自定义播放器的动机

该项目最初是为了应对伊朗的网络断网而产生的，因为在受限政权统治下，在线音乐流媒体对于当地居民来说并不可靠。开发者寻求一种离线替代方案，因为他们发现现有的播放器（如 Strawberry）缺乏正确的行同步歌词。

新播放器 AMP 的目标是创建一个具有原生感、功能精简且无 C++ 依赖的应用程序。开发者选择在整个技术栈中使用 Zig，包括 UI 着色器，以保持一致的系统编程方法。

“我对自己无知的惊讶，以及 LLM 是如何喜欢把事情复杂化的程度感到震惊。”

— How Not to Build a Music Player

向 AI 辅助开发的转变

在一段网络恢复期间，开发者开始尝试使用前沿 LLM 来加速项目。他们使用 Claude Max 20x 订阅生成了应用程序的大大部分代码，作者将这一过程描述为“氛围编码”。

虽然这种方法提供了快速的初期进展，但它导致的代码库让作者感到在审计时精神压力巨大。开发者指出，LLM 经常把简单任务复杂化，创造出一种难以在没有清晰迭代历史的情况下管理的“垃圾代码”。

政策限制与手动重构

当 Anthropic 封禁开发者的账号且 Codeberg 宣布“无 AI”政策时，该项目面临了一个转折点。这迫使开发者在移动仓库或剥离所有 AI 生成的内容之间做出选择。

开发者选择手动重写 AI 生成部分的每一行代码。在四个多月的时间里，他们删除了近一半的代码库，同时实际上增加了应用程序的健壮性并添加了新功能。作者总结道，虽然 LLM 可以作为简单命令的“高级 IDE 功能”，但在大型项目中它们可能会引入过度的复杂性。

技术权衡与局限性

这种转变的一个重大局限是缺乏重写前的历史记录。由于开发者没有使用版本控制系统（如 Git）来保存原始的 AI 生成状态，他们无法客观地将“垃圾代码”与新的手动代码进行对比。

AMP 的最终版本（v0.1）包含一个用 Zig 编写的模糊着色器。开发者现在提倡对业余项目采用“老派”方法，优先考虑人工监督，以确保代码保持可维护和可理解。

这张图片展示了开发者手动重写后的最终产品，展示了应用程序的 UI 和功能。