Bluesky 接入 Standard.site：长文不是重点，开放分发才是

Bluesky 这次更新最容易被误读的地方，是把它看成“也要做长文”。

在 v1.122 版本里，Bluesky 接入的是 Standard.site。用户可以在应用内发现和阅读来自 AT Protocol 生态的文章、博客和 newsletter。早期形态不是完整内置编辑器，而是动态链接卡片，也就是更丰富的预览入口。

所以问题不在于 Bluesky 能不能写长文。

我更在意的是：一篇文章如果以 AT Protocol 的数据形式存在，它是不是能被更多客户端发现、预览和读取。这才是 Bluesky 和 X Articles 拉开差异的地方。

Bluesky 加的是入口，不是编辑器

Standard.site 是围绕 AT Protocol 做长文内容的社区项目。Bluesky 接入它，等于把协议生态里的文章形态放进主应用，而不是自己关门造一个 Medium 或 Substack。

这件事的边界要说清楚。Bluesky 目前没有推出完整的长文编辑、发布、订阅和变现系统。用户看到的主要是增强预览卡片，后续阅读体验还要看页面、互动、搜索和推荐怎么接。

几个相关变化放在一起看，会更直观：

这张表的重点不是“功能越来越多”。

重点是 Bluesky 在用主应用给第三方生态导流。Germ 私信服务是一个例子，Standard.site 长文也是一个例子。它没有把所有能力都收回自己手里，而是在主客户端里承认这些社区项目的存在。

对普通 Bluesky 用户，短期变化很简单：刷信息流时，可能会看到更像文章入口的卡片，而不是一条干巴巴的外链。

对写作者，动作也很具体：如果已经在用 Leaflet、pckt、Offprint，或者愿意测试 WordPress 到 Atmosphere 的发布插件，可以先把 Bluesky 当成一个新增分发入口。但现在不适合把它当成主阵地，更不适合为了这一个功能就放弃 X、邮件列表或自有站点。

它和 X Articles 的差别，在分发权归谁

X Articles 也支持长文，但它面向的是付费订阅用户或企业账号。内容分发仍在 X 的平台体系里，能不能被看见，很大程度取决于 X 的入口、推荐和账号关系。

Bluesky 走的是另一条路。文章如果发布成 AT Protocol 数据，理论上不只 Bluesky 一个客户端能读，其他兼容客户端也可以接入。

这不是理念上的漂亮话。对独立写作者和小型出版者，分发入口越少，平台风险越高。今天算法改一下，明天链接权重降一下，一篇文章的读者就可能断流。

WordPress 的动作也能解释这一点。它此前已经通过插件支持 ActivityPub，让站点接入 Mastodon 等开放社交服务；本月又推出面向 Atmosphere 的插件，支持把站点内容发布到 AT Protocol 网络。

这里不能混为一谈。ActivityPub 和 AT Protocol 是两套不同的开放社交协议。共同点是，发布者都在尝试把内容从单一平台的围墙里挪出来。

对关注社交平台和开放协议的科技读者，这次更新值得看的不是“Bluesky 有没有追上 X”。更该看的是，开放协议内容能不能从小工具走进主应用的信息流。只有走到这一步，协议才不只是开发者圈子的漂亮架构。

对内容发布者，判断更现实：可以试，但别迁。把 AT Protocol 当成增量渠道，把自有站点、邮件列表、X 或其他平台继续留着。狡兔三窟，在内容分发里不是保守，是基本风控。

规模仍是硬约束，接下来盯三个变量

开放分发有价值，但它不是流量的替身。

Bluesky 约有 4450 万注册用户。这个数字不能等同于月活，更不能等同于稳定阅读长文的人。X 的公开月活约 5.5 亿，对媒体、品牌和大号作者来说，它仍是更大的广场。

所以，Bluesky 这一步不会立刻改变长文流量格局。一个增强链接卡片，也不会让作者立刻搬家。真正要看的，是开放内容能不能被顺手读到。

接下来有三个变量比口号更重要：

目前能下的判断应该克制一点。

Bluesky 不是在复制 X Articles。它是在把第三方长文内容接进自己的信息流，用开放协议分发去对照 X 的封闭平台模式。

但它也还不是 X 的替代品。对多数写作者来说，更稳妥的选择是多发一处、多留一手，而不是押注迁移。等到搜索、推荐、互动和跨客户端阅读都顺起来，开放协议才会从“能发布”走到“有人读”。