Bluesky 上一个第三方 For You 推荐流，正在由个人开发者 spacecowboy 运行。用户规模约 7 万到 7.2 万。它不是 Bluesky 官方默认推荐系统，而是用户可选的自定义 feed。
这件事的硬信息很直接：一台 16 核、96GB 内存、4TB NVMe 的游戏 PC，放在开发者客厅里；单个 Go 进程；SQLite 存储；公网入口用每月 7 美元的 OVH VPS，再通过 Tailscale 连回家里服务器。总成本约 30 美元/月。
发生了什么：7 万人的推荐流，成本约 30 美元/月
这套 For You Feed 的推荐逻辑基于 likes。简单说，喜欢相同内容的人，还喜欢什么，就拿来推荐给你。
它消费 Bluesky firehose，保留最近 90 天相关数据。当前 SQLite 数据量约 419GB。这个规模不小，但还没有大到必须祭出一整套云上重型架构。
| 关键项 | 具体情况 | 该怎么理解 |
|---|---|---|
| 运行者 | spacecowboy | 第三方开发者，不是官方默认推荐 |
| 使用规模 | 约 7 万至 7.2 万用户 | 已有真实使用量，但仍是可选 feed |
| 主机 | 16 核 / 96GB RAM / 4TB NVMe 游戏 PC | 消费级高配硬件，放在客厅 |
| 服务架构 | 单个 Go 进程 + SQLite | 赢在问题收窄，不是技术神话 |
| 数据窗口 | 最近 90 天，约 419GB SQLite 数据 | 数据边界明确，成本才压得住 |
| 网络路径 | OVH VPS + Tailscale | VPS 扛公网入口，家中服务器不直接裸奔 |
| 月成本 | 约 30 美元 | 20 美元电费、7 美元 VPS、3 美元域名 |
spacecowboy 估算，如果使用他们找到的最低成本可用算法，现有系统或许能支撑 Bluesky 约 100 万日活用户。
这句话要降温看。它是开发者估算，不是经过全量生产验证的承诺。真实系统会被热点、攻击、刷赞、宕机、硬盘故障和维护疲劳重新定价。
对开发者来说，这个案例的用处很明确：如果推荐目标足够收窄，数据窗口足够清楚，SQLite、Go、Tailscale 和一台高配个人机器，确实能撑起一个有真实用户的服务。
对普通 Bluesky 用户来说，动作也很简单：可以试用这类第三方 feed，但别把它当成平台级 SLA 服务。遇到延迟、断流、推荐漂移，要知道背后可能就是一个人在维护一台机器。
为什么重要：推荐算法变成了可替换组件
Bluesky 真正有意思的地方，是 AT Protocol 允许别人运行自定义 feed。推荐不再只能由平台总部关门调参。
这和 X、TikTok、Instagram 的主流模式不一样。那些平台的 For You 是核心资产，也是权力中心。它决定谁被看见，谁被埋掉，谁吃到流量，谁被商业化。
用户通常只能点“不感兴趣”。很少能换掉整套推荐机制。
Bluesky 这套机制给了另一种路径：推荐可以像 RSS 阅读器、邮件客户端、搜索排序一样，由不同实现竞争。旧互联网里，用户拿着订阅权；平台时代，分发权被平台收回。
“天下熙熙，皆为利来。”这句老话放在算法推荐上并不突兀。黑箱不只是技术选择，也是商业选择。平台把推荐做成不可替换的黑箱，等于把注意力入口、广告效率和创作者命运绑在自己手里。
我不买“大厂做不到，所以个人开发者赢了”这种说法。大厂当然做得到。问题是，大厂通常不愿让用户意识到：很多推荐并不需要披着天书外衣，也不必天然绑定平台权力。
这件事最刺眼的地方，就是它把推荐从神坛上拽下来了一点。不是说个人 feed 立刻能取代大平台算法，而是它证明了一件事：一部分推荐能力可以外包、可以竞争、可以被用户替换。
对做社交产品的团队，这会改变一个判断：feed 不一定非要塞进单一官方算法里。可以把推荐当插件、当市场、当生态接口。但这么做会削弱平台控制力，也会增加治理复杂度。
真成本不在服务器账单，在治理账单
低成本架构解决的是“能不能跑”。它没解决“谁来负责”。
推荐系统不是只在数据库里排个序。它还要面对垃圾账号、刷赞、协同操纵、隐私暴露、错误推荐、用户申诉和维护者不可用。
如果某个第三方 feed 被人用刷赞操纵，用户该找谁？开发者、Bluesky 官方，还是协议层？如果 feed 突然停摆，用户能否迁移？如果推荐逻辑放大骚扰或低质内容，谁来降权？
这些问题现在看起来像边角料。用户规模一大，就会变成主菜。
SQLite 也别被神化。它在这里成立，是因为几个条件同时满足：数据只保留 90 天，推荐逻辑基于 likes，查询模式相对可控，硬件配置也不弱。
换成更复杂的多模态推荐、实时反作弊、跨区域低延迟和高可用容灾，30 美元的故事马上变成另一张账单。
最该观察的不是“百万日活”这句估算，而是三个硬变量：
- 延迟.用户增长后，推荐刷新是否仍稳定。
- 滥用.刷赞、垃圾内容、协同操纵出现后，第三方 feed 怎么处理。
- 责任.Bluesky 官方、协议层和 feed 维护者之间，故障与治理责任怎么切。
对 Bluesky 用户，现实做法是多订阅几个 feed，不要把信息入口押在一个第三方实现上。对开发者，现实做法是把可观测性、备份、降级策略和滥用处理写进设计，而不是只晒月账单。
历史上，铁路、电力、报业都经历过类似阶段：早期个人和小团队能做出惊人的低成本实验，规模一上来，调度、监管、责任和垄断问题立刻登场。今天的推荐算法不完全一样，但人性和利益结构很像。技术扩张得越快，治理欠账越不肯自动消失。
这次少见地把算法权力撬开了一条缝。缝不大，但足够让人看清：平台所谓复杂，有一部分是技术复杂；另一部分，是不想让你替换它。