那些「永远不会做完」的项目,AI 编码助手能救回来吗?

一边是坑，一边是路

坦率的讲，程序员电脑里都有几个「僵尸项目」。你可能叫它学习计划，可能叫它实验代码，但本质上都是同一类东西——那个你曾经兴致勃勃开始，后来因为工作忙、生活杂、新项目诱惑，慢慢就放下的东西。

日本有个词叫「积读」，专门形容那些买回来打算读、结果越堆越多的书。程序员也有自己的「积读」，就是那些 clone 下来、写了开头、然后永远停留在某个 commit 的项目。

说真的，这些东西的存在本身不是问题。问题在于，它们会一直待在硬盘角落，偶尔想起来就让你心里有点堵——明明是个好想法，明明技术方案都想清楚了，就是没时间把它做完。

我最近看到一篇文章，作者分享了一个很实在的发现：这类「注定不会完成」的项目，反而是 AI 编码助手最能发挥作用的地方。

一个 YouTube Music 的「中间人」项目

作者的想法其实挺简单的。他平时用的是 Navidrome 做音乐服务器，桌面端用 Feishin，手机端用 Symfonium。这些客户端都支持 OpenSubsonic 协议——一个开源的音乐流媒体 API 规范，可以把服务器和客户端解耦。

但 YouTube Music 不支持这个协议。所以作者想写一个「中间人」程序，让 YouTube Music 伪装成 OpenSubsonic 服务器，这样就能把 YouTube Music 的曲库整合进自己的播放系统里。

这个项目他几年前就写了 POC，基本的流媒体功能跑通了。但 OpenSubsonic 协议有大约 80 个端点，分布在 15 个不同的功能类别里。MVP 只需要实现 6 个核心端点就能用，但要让客户端功能完整，剩下的 70 多个端点都得一个一个啃。

这就是典型的「长尾工作」——不是技术难题，就是时间黑洞。你知道每一步该怎么做，但就是没有动力把它做完。于是这个项目就那么放着，偶尔想起来就叹口气。

为什么 AI 特别适合干这个

一个半月前，作者决定用 Claude Code 配合 Opus 4.6 来试试能不能把这个项目捡起来。

我自己的感受是，很多人对 AI 编码助手的期待方向偏了。大家总想着让 AI 从零开始写一个完整的项目，但现实是，AI 的优势不在于「创造」，而在于「执行」——尤其是那种有明确规范、步骤清晰、但就是费时间的执行。

作者的这个项目恰好就是这类工作的完美样本。OpenSubsonic 有公开的 API 规范，YouTube Music 有现成的 ytmusicapi 库，流媒体提取有 yt-dlp。每一步该做什么都清楚，就是需要时间去把这些东西缝起来。

更关键的是，作者之前已经写过 POC，他对这个项目有自己的「看法」——用什么框架、怎么分层、数据结构怎么设计。这些「看法」恰恰是 AI 最缺的，也是最需要人来提供的。

一套能复用的「启动套路」

作者分享的设置过程其实挺值得借鉴的。

他没有一上来就让 AI 写代码，而是先把「人」的部分做好。创建了一个 uv 项目，把 FastAPI、Pydantic、ytmusicapi、yt-dlp 这些依赖放进去。然后把 OpenSubsonic 的 OpenAPI 规范文件丢进项目目录。

接下来写了一个 README，几句话说明这个项目是干嘛的：「这个项目作为中间层，把 YouTube Music 暴露为 OpenSubsonic 客户端，用 FastAPI 做服务器，ytmusicapi 处理元数据，yt-dlp 处理流媒体。」

还创建了一个空的 TODO 文件，和一个 CLAUDE.md 文件，里面写了一些编码约定：方法要有类型注解和文档字符串、用 Pydantic V2 的写法、文档字符串用 Google 风格、单元测试用现代 pytest 写法。

这套设置看起来没什么技术含量，但我一直觉得，恰恰是这种「没什么技术含量」的准备工作，决定了 AI 能不能真正帮上忙。你给 AI 的上下文越清晰，它输出的东西就越符合你的预期。

从桩代码到能听见声音

作者的工作流是这样：先让 Claude 进入规划模式，描述下一步要做什么，拿到方案后看看有没有漏洞，补上问题，然后让它执行。执行完清空上下文，再进入下一轮。

第一个任务是让 AI 根据 OpenAPI 规范把所有端点的桩代码生成出来。这个过程 AI 第一次会犯错，但第二次检查的时候能自己发现大部分问题。

有了桩代码，接下来就是实现最小可用版本。作者的目标很务实：能让客户端连上来、能搜歌、能播放，就这三件事。ytmusicapi 负责搜索，yt-dlp 负责流媒体提取，FastAPI 把它们串起来。

让作者惊讶的是，几轮迭代之后，他真的在 Feishin 客户端里听到了 YouTube Music 的声音。主要的问题都是那些桩端点返回了空值导致客户端崩溃，需要让它们返回「空但结构正确」的响应。

这一步很重要。很多人用 AI 编码助手的时候，一上来就想把整个系统做完，结果到处踩坑，最后信心全没了。作者的做法是先实现最小闭环——能跑起来、能听到声音、能看到效果，然后再慢慢补全。

长尾工作才是 AI 的主场

这个项目真正的挑战不是 MVP，而是之后那 70 多个端点的实现。这些端点大部分都挺无聊的：返回空列表、返回默认值、把一个 API 的响应转成另一个 API 的格式。没什么创造性，就是耗时间。

但这恰恰是 AI 最擅长的事。你可以把它理解为一个「超级实习生」，你给它规范、给它例子、告诉它返回值应该长什么样，它就能一个一个给你吐出来。它不会抱怨工作无聊，不会因为写了十几个「返回空列表」的函数就要求换任务。

作者的迭代方式也很务实：用客户端去测，看日志里报什么错，把错误信息丢给 AI，让它修。修完再测，再报错，再修。每发现一个问题，就生成一个单元测试把它覆盖住，避免以后回归。

这套流程看起来没什么魔法，但效果出奇的好。一个半月后，这个项目居然真的能用起来了。

不是效率，是可能性

你想想看，如果不用 AI，这个项目会怎样？

大概率还是那个状态：有一个能跑的 POC，但功能不完整，客户端一用就报错，然后就没有然后了。作者也不太可能花几个月的周末时间去一个一个实现那些无聊的端点——因为值得做的事情太多了，凭什么把时间花在这个上面？

但 AI 的存在，让「不值得花时间」变成了「可以让 AI 跑一跑」。你损失的不是几个月的时间，而是几十块钱的 API 额度。这个时间成本和金钱成本的差异，直接决定了一个项目能不能「活下来」。

所以我一直觉得，AI 编码助手最大的价值不是「让你写得更快」，而是「让一些本来不会发生的事情发生」。那些被你放弃的想法，可能真的有机会落地了。

用之前想清楚三件事

当然，不是所有项目都适合丢给 AI。从这个案例里，我觉得有三点挺关键。

第一，项目要有明确的规范或参照。这个项目之所以能跑通，核心原因是 OpenSubsonic 有公开的 API 规范。AI 不需要猜测你要什么，它只需要按图索骥。如果你的项目没有类似的规范，最好先自己写一份——哪怕是几句话的需求描述，也比什么都不给强。

第二，你自己要对项目有「看法」。AI 可以帮你写代码，但它没法帮你做架构决策。用什么框架、怎么分层、数据结构怎么设计、哪些功能优先——这些都需要你先想清楚。作者的 POC 就是他自己写的，所以他对项目有完整的理解。

第三，接受「能用就行」的心态。这个项目不追求完美，客户端能正常工作就算成功。如果你对代码质量有非常高的要求，AI 生成的代码可能需要大量修改，那时候效率优势就不明显了。

那些被搁置的想法，可能真的有救了

回到最开始的话题。程序员的硬盘里总有那么几个「积读」项目，它们不一定是因为技术难度被放弃的，更多时候只是因为生活太忙、时间不够、新东西太好玩。

AI 编码助手不会让你变成超级程序员，但它可以把那些「我知道怎么做但没时间做」的事情从你的待办清单里划掉。你提供框架和方向，它负责执行长尾的琐碎。

那些曾经让你心动的想法，可能真的有机会看到它们运行起来的样子了。

这不就是技术的意义吗？不是替代你思考，而是帮你把想清楚的事情做出来。