开源社区里，弃用公告通常写得很克制。无非是"出于长期维护考虑"、"资源有限"、"建议迁移到 XX"。
但 yt-dlp 这次不一样。
5 月 20 日，yt-dlp 维护者 bashonly 在 GitHub 上挂出公告，宣布限制并废弃对 Bun 的支持。公告里，他用了一个词来解释原因之一："vibe-coded"。
这大概是第一次有严肃的开源项目，把这个词直接写进弃用理由。
这件事从哪里开始说起
读过之前几期的朋友应该知道，Bun 在今年 5 月经历了一次重大转折。Jarred Sumner 用 Claude 把整个运行时从 Zig 重写成了 Rust，超过百万行代码，从决定合并到真正落地，不过短短几天时间，近期发布的 v1.3.14 可能是最后一个 Zig 构建的版本。
yt-dlp 给出的弃用理由，正是从这次重写展开的。
yt-dlp 的公告写了什么
公告很简洁，给出两个理由：
安全问题
低版本 Bun（1.2.0 以下）在构建 ejs 包时会忽略 lockfile，这在最近供应链攻击频发的背景下是不可接受的安全风险。所以支持下限直接从 1.0.31 抬到了 1.2.11。
vibe-coded 问题
原文是这样说的：
"
Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid.
翻过来大概是：Bun 最近用 Claude 重写成了 Rust，它的开发方向似乎正在全面转向 vibe coding。这令人担忧，坦白说看起来像是一个未来的麻烦，我们宁愿绕开。
对应的处理方式：版本上限锁在 1.3.14，也就是最后一个 Zig 版本。Rust 重写之后的 Bun，一个版本都不打算跟。
yt-dlp 里负责这块的是一个叫 ejs（External JavaScript）的子项目，专门用来让 yt-dlp 支持多种 JavaScript 运行时处理视频站点的 JS 逻辑。yt-dlp 本身是 Python 写的，这也是评论区有人问"yt-dlp 不是 Python 吗，怎么有 Bun 支持"的原因。
Electrobun 2.0 跟着宣布解绑
公告一出，Electrobun 的创始人 Yoav 也在推特上跟进：Electrobun 2.0 同样会因为 Bun 的 Rust 重写而解绑。
我们在 2 月份介绍过 Electrobun v1。它的核心卖点是用 TypeScript 写桌面应用，主进程跑在 Bun 上，渲染层用系统原生 WebView，打包体积只有 12MB，比 Electron 轻得多。Bun 是整个架构的关键一环，没有 Bun 就没有那个 12MB。这个项目目前已经 12k star 了。
当时文章里也提到了一个隐患："Electrobun 强依赖于 Bun，虽然 Bun 发展迅猛，但在某些边缘场景下的稳定性仍需时间验证。"这句话现在看起来像是提前埋了伏笔。
Electrobun 2.0 的调整很大。它选择彻底脱离对 Bun 的依赖，转向对 Rust、Zig、Go 的原生支持。这意味着框架的定位也在悄悄变化，从"只用 TypeScript 就能写桌面应用"，往更底层的多语言方向走了一步。
Yoav 在帖子里补了一句：这不是对 Rust 本身的批评，Rust 很棒，这是 Anthropic 不做人工审查、缺乏理性发布节奏的结果。
image
两天里，两个知名项目先后做出同一个决定。
社区在争什么
消息传到 HN 和 GitHub 之后，评论区吵了起来，争论集中在两个方向。
有人认为这是对 AI 的偏见
评论区有人措辞强硬：「工程工作使用的工具，不决定工作的质量。」如果 Rust 版 Bun 没有暴露出实际问题，凭什么因为用了 AI 就降级支持？代码质量应该用测试和表现说话，不是用生成方式来定性。
yt-dlp 维护者也出来回应，划了一条线：「使用 Claude 和完全依赖 Claude 之间，有巨大差别。」
另一方说问题不是 AI，是工程文化
一位社区贡献者说得最准：「不是 LLM 生成代码本身有问题，是这次重写完全没有沟通。百万行 Rust，5 天 vibe coding，直接合并，没有提前通知任何依赖方，没有任何迁移窗口。」
image
这个说法对应了 Electrobun 创始人的描述。Anthropic 收购 Bun 之后，发布节奏和沟通方式明显变了，下游项目在重大变更发生之前完全不知情。
这件事真正的问题是什么
从今年 3 月 Node.js 社区的 AI 代码请愿，到这次 yt-dlp 的弃用公告，开源社区围绕 AI 生成代码的摩擦在持续积累。
单看技术层面，Bun Rust 重写之后到底跑得怎样，还有很多未知数。测试覆盖率、边界情况、长期稳定性，这些都需要时间验证。yt-dlp 在公告里也承认，目前冻结版本号更多是一种预防性措施，而不是因为已经发现了具体问题。
但下游项目等不起也不必等。当一个依赖的运行时在几天内完成了百万行代码的重写，又没有给任何清晰的质量信号，最理性的选择就是先退出，静观其变。这是一种完全正常的风险管理，和对 AI 是否有偏见关系不大。
真正需要追问的是：当越来越多的基础工具采用 AI 大规模重写之后，下游项目靠什么来评估一个运行时还可不可信？代码量、测试覆盖？合并的速度？维护者的沟通方式？
yt-dlp 给出的答案是：先看它是不是还在用最初的那套代码库。这个标准很粗糙，但至少是可操作的。
Bun 团队接下来怎么做，才是真正关键的事。