Bluesky 一宕机，网友先怪 AI：当“氛围编程”成了科技圈的新背锅侠

如果你最近混迹 Bluesky，大概会看到一种很熟悉的互联网景观：平台一出故障，技术分析还没开始，锅已经先扣到 AI 头上了。

这一次，Bluesky 在周一出现了间歇性服务中断。按照官方说法，问题来自“上游服务提供商”，而且这次波动并不孤立，当天还有其他知名网站也报告了类似异常。按理说，这本该是一条普通的基础设施新闻——服务器抖了一下，平台解释一下，用户骂两句也就散了。可事情偏偏没这么简单。

在 Bluesky 上，很多用户几乎是条件反射般地把故障归因为开发团队在搞所谓“vibe coding”，也就是中文语境里常说的“氛围编程”——依赖 AI 工具写代码，自己不完全理解代码是怎么工作的，却仍然快速上线。有人发梗图，有人写讽刺段子，也有人火力全开，直接把“用 AI 写代码的人根本不配当程序员”这种话甩了出来。那种情绪很直白：你们不是爱用 Claude Code 吗？平台挂了吧，这就是报应。

一次故障，炸出了平台和用户之间的旧账

Bluesky 用户这次为什么这么快就把矛头对准 AI？原因不在这次故障本身，而在故障发生之前，平台已经在 AI 议题上埋了不少雷。

过去几周，Bluesky 管理层和工程团队公开谈论过自己使用 AI 编程工具的情况。联合创始人 Jay Graber 直接说过，Bluesky 的工程师，甚至部分非工程岗位员工，都在用 Claude Code。技术顾问 Jeromy Johnson 更是高调表示，最近两个月自己“99% 的代码”都是 Claude 写的。CTO Paul Frazee 也跟着半开玩笑地承认，自己“至少同样程度上在 vibe code”。

这几句话，在工程师圈子里未必算什么惊世骇俗。现在硅谷很多团队都在把 Cursor、GitHub Copilot、Claude Code、Codeium 之类工具接进开发流程，谁不用，反而显得有点落后。但问题是，Bluesky 的用户结构本来就特殊。它吸引了不少从 X，也就是原 Twitter，迁徙过来的用户。这批人对“大平台把 AI 强塞进产品里”本来就高度敏感，对数据被拿去训练模型也尤其警惕。

Bluesky 过去承诺过，不会把用户帖子拿去训练生成式 AI。这让它在一部分人眼里，成了“没有那么 AI 味儿”的社交平台。偏偏在 3 月底，Bluesky 又推出了 Attie，一个基于 Claude Code 的聊天机器人工具，用户可以通过对话自己搭建定制信息流。官方的说法很温和：这不是让 AI 生成内容，而是让不会写代码的人也能做自己的社交产品。但在一些反 AI 用户看来，味道已经变了——你说不拿我的内容训练模型是一回事，可你让整个平台的产品路线越来越围着 AI 打转，是另一回事。

所以，周一那次宕机更像一根导火索。真正爆炸的，其实是前几周积攒下来的不信任。

“氛围编程”为什么突然成了互联网新骂人词

“Vibe coding” 这个词，过去一年火得很快，也变得越来越难听。它最初指的是一些不太会写代码的人，靠大模型一路生成程序，只要“能跑起来”就算成功，至于结构、可维护性和安全性，往往顾不上。这种做法在做原型、写小工具时确实很爽，但一旦上生产环境，灾难概率也不低。

过去一年，AI 编程工具惹出的麻烦并不少。亚马逊曾被指因为 AI 辅助代码引发了长时间故障；也出现过编码代理误删用户文件、清空数据目录的事故；安全研究圈则反复提醒，AI 生成代码可能把软件供应链风险放大，尤其是在开发者没有认真审查的情况下。很多人因此形成了一种认知：只要听说哪家公司在“AI 写代码”，就默认它迟早会出事。

这种认知并不完全没有依据，但也很容易滑向另一种偷懒：把所有软件故障都解释成“AI 写的垃圾代码”。这就像看到一辆电动车抛锚，就断定新能源路线失败；或者看到一个人用导航走错路，就得出“地图软件不如纸地图”的结论。现实没这么简单。

更关键的是，“氛围编程”其实把两种完全不同的开发方式混在了一起。第一种是门外汉不懂原理，让 AI 从头到尾拼出一个看似能跑的系统；第二种则是成熟工程师把 AI 当成加速器，用它补模板、写重复代码、生成测试用例，再由人类做架构、审查、验证和上线把关。这两者都叫 AI 辅助开发，但风险画像完全不同。

Bluesky 管理层试图强调的正是这个区别。Frazee 公开解释过，团队仍然维持原有的代码审查、红队测试和 QA 流程，AI 工具只是提高效率，不会替代好工程实践。说白了，AI 可以帮你写，但不能帮你负责。

用户真正反感的，也许不是 AI，而是“你别糊弄我”

这件事最有意思的地方在于，很多用户的愤怒未必真的指向代码质量本身，而是指向一种态度：当平台主动承认自己大量使用 AI，用户就会怀疑你是不是在用更少的人、更短的时间、更低的成本，把一个原本需要严谨打磨的产品“糊弄上线”。

这种情绪并不局限于 Bluesky。Anthropic 最近因为客户端源码意外泄漏，也被许多人第一时间怀疑是“vibe coder 手滑”造成的，尽管官方解释是人工部署过程中的人为失误。换句话说，一旦公司和 AI 工具深度绑定，它在舆论场上就会失去“无罪推定”。系统出了问题，人们更愿意相信不是运气不好，而是你偷懒了。

这是 AI 时代很现实的信任账本：你用了工具，效率可能更高，但社会观感也会更差。尤其是在消费级互联网产品里，用户并不关心你是“Claude 写了 80% 还是 20%”，他们关心的是，出了问题之后，谁能担责，谁又在认真做质量控制。

从这个角度看，Bluesky 这场风波不只是一次关于 AI 编程的争论，它更像是平台治理的一堂公开课。技术团队越来越相信 AI 能提高生产力，用户却越来越怀疑 AI 会稀释责任感。两边都不是完全没道理，只是说的不是同一种语言。

接下来，所有公开使用 AI 的团队都要学会面对嘲讽

这件事还有一个颇为残酷的结论：今后任何一家公开承认使用 AI 编程工具的公司，都得准备好在每次故障时被群嘲。

哪怕故障和 AI 毫无关系，只是云服务商抽风、配置回滚失败、CDN 出现区域异常，外界也很可能先说一句：“又是 AI 写崩了吧？”这已经不是技术判断，而是一种文化反应。就像有 Bluesky 用户调侃的那样：把这次宕机归咎于 vibe coding 明显不对，但确实很好笑。

某种程度上，这种嘲笑甚至会倒逼公司变得更透明。如果你要用 AI，就得比过去更清楚地说明：工具具体用在哪，审查流程怎么做，谁对最终上线负责。否则，公众只会把“AI 参与开发”翻译成一句更刺耳的话——“原来你们在拿用户当测试员。”

我倒不觉得 AI 编程会因为几次争议就退潮。相反，它大概率会继续渗透开发流程，像自动补全、单元测试框架、CI/CD 一样，慢慢变成工程基础设施的一部分。真正的问题不在于“要不要用”，而在于“用到什么程度，怎么证明你没有失控”。

Bluesky 这次宕机提醒我们的，不是 AI 一定会毁掉软件工程，而是技术工具一旦进入公众视野，它就不再只是工程师的私事。今天用户会拿“氛围编程”开玩笑，明天他们可能会追问更尖锐的问题：如果代码越来越多由机器生成，那么出现漏洞、泄漏和宕机时，责任链条到底该怎么写？

这比一场短暂宕机，重要得多。