4月6日下午，Bluesky的服务器抽风了。不是那种优雅的渐变式崩溃，是那种用户刷着刷着突然看到错误页面的经典故障。
这本该是一次普通的运维事故。上游服务商出问题，波及下游平台，科技行业的日常剧本。但事情朝着奇怪的方向发展了——用户们几乎瞬间达成共识：肯定是那帮工程师又在"vibe coding"了。
「vibe coding」这个词需要解释一下。它指的是一种新兴的编程方式：开发者用自然语言描述需求，让AI生成代码，自己主要负责"把控氛围"——调调参数、改改提示词、在AI输出里挑挑拣拣。这个词最早由AI研究者Andrej Karpathy在今年初带火，原本带点自嘲的轻松感，现在在Bluesky用户嘴里已经变成了骂人的词。
故障发生后的几小时内，平台上涌现出数百条相关帖子。有人做了梗图：Bluesky工程师对着Claude说"给我做个不会崩溃的社交媒体"，Claude回复"好的，这是你的社交媒体（附带一个随时会炸的炸弹emoji）"。有人用alt text写小作文讽刺，有人用反讽语气"感谢AI让互联网更稳定了"。
用户T-Kay的帖子被转发了上千次：「任何用vibe coding或者依赖AI写代码的开发者，显然蠢到不知道自己该干什么，应该被大炮轰出去。Coding需要技术，不是垃圾。」
这种愤怒里混杂着一种有趣的矛盾。Bluesky本身是个去中心化社交协议，用户群体以技术从业者、媒体人、早期互联网怀旧者为主——恰恰是那批最清楚现代软件工程复杂度的人。但他们对AI辅助开发的抵触，几乎是一种条件反射式的排斥。
Bluesky高管的"自曝"成了弹药
用户的指控并非空穴来风。过去两个月，Bluesky的几位核心成员确实在公开谈论他们用AI写代码的经历，而且谈得相当高调。
3月底，创始人兼首席创新官Jay Graber发了一条直球帖子：「Bluesky是用AI做的，工程师甚至一些非工程师都用Claude Code。」没有铺垫，没有上下文，就这么扔出来。
技术顾问Jeromy Johnson（站内ID是"Why"）更激进。2月份他写道：「过去两个月Claude写了大概99%的我的代码。事情在变。很快。」
这两条帖子在当时就引发过争议。一部分用户觉得透明是好事，另一部分则认为这是在给"技术降级"洗地。等到4月6日的宕机发生，这些旧帖被翻出来，成了用户手中的呈堂证供。
「你看，他们自己承认的。」这种逻辑链条简单到近乎粗暴：用了AI→代码质量差→服务崩溃。中间省略了代码审查、测试流程、基础设施架构、上游服务商责任等所有变量。
CTO Paul Frazee没有直接回应这波舆论。但Bluesky官方账号在故障修复后发的声明很克制：问题来自上游服务商，已解决。没提AI，没提vibe coding，没试图反驳用户的指控。
专业开发者的真实态度：工具在用，但锅不背
有趣的分裂发生在专业群体内部。
Bluesky用户里有不少是职业程序员。他们在自己的帖子里写的完全是另一套叙事：AI工具确实在改变工作流，但"99%代码由AI写"这种话更像是修辞夸张，或者是特定场景下的统计（比如某个新功能原型阶段）。
一个获得高赞的回复来自用户lexluddy：「Bluesky员工：我们现在用AI vibe coding整个网站。是啊兄弟，我能看出来。」配图是一个翻白眼的表情。这条帖子本身也是讽刺，但讽刺的对象是"把AI当万能替罪羊"的用户，而非Bluesky团队。
更技术向的讨论指出，Bluesky的架构问题——去中心化协议（AT Protocol）的复杂性、中继节点的同步机制、流量突增时的扩容逻辑——这些都不是"用不用AI写代码"能解释的。一个上游服务商故障导致的宕机，归因于代码生成工具，相当于房子停电了怪装修工人用了电动螺丝刀。
但这种理性分析在情绪浪潮里显得微弱。用户需要简单的因果叙事，而"vibe coding"恰好提供了完美的靶子。
AI工具的双面镜像：效率神话与质量焦虑
这场闹剧的核心张力，其实是整个行业对AI编码工具的集体焦虑。
一方面，数据确实在说话。GitHub的2024年报告显示，Copilot用户编写的代码中有46%由AI生成；Stack Overflow的开发者调查显示，76%的受访者正在使用或计划使用AI编码工具。Bluesky不是孤例，用AI写代码正在成为基线操作，而非先锋实验。
另一方面，质量争议从未停止。AI生成的代码被批评为"看似正确实则脆弱"——能跑通测试用例，但在边缘场景下崩溃；能完成功能，但留下安全漏洞；能短期提效，但长期增加技术债务。这些批评有实证支撑：2024年多起安全事件被追溯到AI生成的代码缺陷，包括某知名支付平台的API密钥泄露事故。
Bluesky用户的愤怒，某种程度上是把这种行业层面的焦虑投射到了一个具体事件上。他们不是在分析4月6日的宕机原因，而是在表达对某种未来的恐惧：一个由"氛围感编程"堆砌起来的互联网，表面光鲜，内里空心。
这种恐惧有历史参照。低代码/无代码平台兴起时，专业开发者也有过类似抵触；外包开发流行时，"印度程序员"曾是质量差的代名词；甚至更早，从汇编转向高级语言时，也有声音认为这是在"纵容懒惰"。技术民主化的每一步，都伴随着精英群体的身份焦虑。
但AI工具的不同之处在于速度。低代码花了十年才渗透到企业边缘场景，AI编码工具在两年内就成了主流。Jeromy Johnson说的"事情在变。很快。"——这句话本身成了焦虑的载体。
Bluesky的特殊性：透明文化遭遇反噬
换个平台，这场风波可能根本不会发生。
Bluesky的文化基因里写着"公开对话"。创始人发产品路线图，工程师讨论技术决策，甚至服务器状态页面都做得格外详细。这种透明在Web2社交媒体的封闭语境下是差异化优势，但在危机时刻也成了 liability（ liabilities）。
Jay Graber和Jeromy Johnson的帖子，放在Twitter或Meta的语境里，要么不会发，要么会被公关团队过滤成安全话术。但Bluesky允许——甚至鼓励——这种未经修饰的技术分享。结果是，当故障发生时，用户手里有现成的"证据"。
一个对比：2024年某次大规模云服务中断，涉及多家头部平台，但没有一家用户把矛头指向"你们是不是用AI写的代码"。因为没人知道他们用什么写的代码。不透明成了保护伞。
Bluesky的困境在于，它的社区文化建立在技术人员的互信基础上，但当用户规模扩大、非技术用户涌入时，这种互信变得脆弱。早期用户能理解"用Claude Code"的语境——它是辅助工具，不是替代人类判断——但新用户看到的是字面意思：AI在写代码，所以代码很烂。
这种认知鸿沟在宕机时刻被放大成集体情绪。用户不是在攻击某个具体技术决策，而是在捍卫一种价值观：编程应该是手艺，是技能积累，是对细节的掌控，而不是对着聊天框" vibe"出来的。
梗图背后的严肃命题：谁该为软件质量负责
回到那些讽刺帖子。它们好笑，但也暴露了一个被回避的问题：当AI深度参与软件开发，责任边界在哪里？
传统软件工程有清晰的责任链条。开发者写代码，代码审查者把关，测试团队验证，运维团队监控。每个环节都有明确的人类主体。AI工具的介入模糊了这个链条：如果Claude生成了有缺陷的代码，但人类开发者审查通过了，测试没发现，上线后出了故障——谁的责任？
Bluesky用户把锅扣给"vibe coding"，实际上是在拒绝这种模糊性。他们想要简单答案：用了AI就是原罪。但这种简化回避了更复杂的现实——人类写的代码同样会崩溃，而且频率不低。
2023年CrowdStrike更新导致的全球Windows蓝屏事件，涉及的是传统软件更新流程，没有AI参与，影响范围远超Bluesky这次小范围宕机。2024年某次AWS区域故障，根因是人工配置错误。人类失误的破坏力并不逊色。
AI工具的真正风险，可能不在于"生成垃圾代码"，而在于改变开发者的心理模式。当代码产出速度大幅提升，当"先让AI试试"成为默认选项，人类对复杂系统的直觉理解是否会退化？审查环节是否会流于形式，因为"AI已经检查过了"？
这些才是值得追问的问题。但4月6日的Bluesky上，它们被淹没在梗图的狂欢里。
行业镜像：从Bluesky看AI采用的公关困境
Bluesky的遭遇给整个行业提了个醒：公开谈论AI工具使用，正在成为一种公关风险。
2024年初，多家科技公司的工程博客还在高调分享AI编码实践。某知名电商平台的CTO写过"我们如何用AI把新功能上线时间缩短60%"；某金融科技公司展示过AI生成的代码占比图表。这些内容的受众是同行和求职者，传递的信号是"我们技术先进、效率领先"。
但Bluesky事件后，这种公开分享的激励结构在改变。当"用AI写代码"可以被随时翻出来作为故障的归因，高管们的最优策略可能是：用，但不说；或者说，但留足退路。
已经有信号出现。某云计算厂商在2024年末更新了对外沟通指南，建议技术团队避免在公开渠道讨论具体AI工具的使用比例。另一家SaaS公司的内部备忘录被泄露，要求工程师在社交媒体"谨慎分享AI辅助工作的细节"。
这种转向的讽刺之处在于，它可能损害行业整体的学习效率。Bluesky的透明文化原本是一种公共品——其他团队可以参考他们的技术决策，理解真实场景下的AI采用挑战。如果这种分享因舆论风险而收缩，整个行业会变得更封闭、更重复造轮子。
但企业不是慈善机构。当用户把"用AI"等同于"质量差"，当故障时刻的旧帖成为舆情炸弹，沉默是理性的自我保护。
用户心理的深层结构：对"人味"的执念
剥开技术层面的争论，Bluesky用户对vibe coding的抵触，还有一个更感性的维度：他们想要感受到产品背后的人类存在。
社交媒体的内容已经大量由算法推荐、AI生成。如果连底层代码也是"氛围感编程"的产物，用户会质疑：这个产品里还有什么是真实的？什么是由人类的意图、判断、审美塑造的？
这种焦虑在创意领域更明显。AI生成图像的争议核心不是技术能力，而是"这不是人创造的"。音乐、写作、设计同理。代码作为一种创造性活动，正在被卷入同样的价值冲突。
Bluesky的早期用户很多是Twitter难民，逃离的是另一套算法暴政。他们对"人味"的敏感度高过平均水平。当发现产品本身可能由AI大量参与构建，这种背叛感被放大——我们逃到这里，结果这里也是"假的"？
T-Kay的帖子之所以获得共鸣，正是因为它触碰了这条情感神经：「Coding takes skill, not slop.」技能对抗垃圾，人类对抗机器，手艺对抗自动化。这是一套古老的叙事框架，在工业革命时期就出现过，现在被重新激活。
但叙事框架不等于事实。Bluesky的工程师并没有被AI替代，他们是在用新工具工作。用户感受到的"slop"，更多来自去中心化架构本身的复杂性，而非代码生成方式。情感真实与因果真实之间的错位，是这场风波的底色。
事件余波：Bluesky会改口吗
截至4月7日，Bluesky团队没有撤回之前的AI相关言论，也没有发布新的政策声明。Jay Graber的"Bluesky is made with AI"帖子仍然可见，Jeromy Johnson的"99%"言论也没有删除。
这种沉默本身是一种立场。在技术团队内部，他们可能认为用户的归因是错误的，不值得专门反驳；或者认为任何回应都会火上浇油。无论哪种，选择让帖子留在那里，等于接受了它们作为长期舆情风险的存在。
更实际的改变可能发生在工程流程层面。据接近团队的消息人士透露（Bluesky未予置评），故障后的内部复盘重点放在了上游服务商的依赖管理上，而非AI工具的使用规范。这意味着团队不认为代码生成方式是根因，至少不是优先解决的根因。
但这种技术判断能否转化为用户的信任修复，是另一个问题。一旦"vibe coding"和"服务不稳定"的关联在公众认知中建立，打破它需要大量时间和证据。下一次宕机——无论原因是什么——用户的第一反应可能仍然是："又是AI写的吧？"
这对整个AI辅助开发领域都是警示。工具采用的速度超过了质量验证的速度，也超过了公众理解的速度。当技术领先于叙事，叙事真空会被恐惧和简化填充。
Bluesky的教训或许是：用AI可以，但要想好怎么讲这个故事。不是每个用户都想听技术细节，但所有人都需要情感锚点——相信产品是由在乎它的人建造的，而不是由"氛围"生成的。
4月8日上午，一位用户在故障帖子下留言：「我还是会留在Bluesky，但下次Jay发帖说AI多好用的时候，我可能会先截图存证。」这条回复获得了数百个点赞。信任没有崩溃，但它在被重新定价。
热门跟贴