AI 辅助声明：本文配图使用 ian-xiaohei-illustrations 辅助设计与制作；写作过程中使用 Codex 辅助梳理思路、调整结构与校对文字。
X 会从约 3000 条候选推文中筛出屏幕上的几十条；排序依据，是你接下来采取各种行为的预测概率。
很多人会把「为你推荐」理解成一套兴趣匹配系统：平台先判断你喜欢科技、摄影还是赛车，再从相应类别中挑出热门推文。X 公开的推荐算法展示了一套更具体的机制：面对每条候选推文，模型首先预测你接下来会做什么。
点赞只是这些预测行为中的一种。模型还会判断你是否回复、转帖、打开推文、观看视频、关注作者、复制链接，以及选择「不感兴趣」、隐藏账号、屏蔽账号或举报。每种行为都有不同的权重；候选推文来自哪里、作者是否已经关注、同一作者出现了几次，也会继续改变最终排名。对系统而言，这些操作共同组成一段按时间排列的行为序列。
沿着这个角度，一些日常体验就更容易理解：为什么点赞不多的陌生推文会排在朋友的新动态前面；停留、评论和负反馈又分别向系统传达了什么。接下来，本文会按照候选召回、行为预测、加权计分、排名调整和可见性检查五个环节，说明约 3000 条候选推文如何变成屏幕上的「为你推荐」。
使用交互式网页理解参数
X 在 2026 年 8 月更新了开源算法仓库1，放出了更多 Home Mixer 参数、Phoenix 模型代码和可见性过滤相关系统。代码展现了各个环节的运行方式，但只靠阅读源码，很难直观看出一项参数变化会怎样影响最后的排序。
为了更直观地展示这些计算关系，我基于开源项目 Inside the For You2，完成了一个交互式网页3。网页把抽象的排序机制拆成三组可以动手操作的实验：勾选点赞、回复、复制链接或负反馈，并切换预测概率模式，查看一条推文的分数如何形成；在一组公开的真实推文上选择不同操作，观察这些信号如何改变兴趣判断与下一次刷新的排序；拖动 13 项行为权重或切换预设，比较六条示例推文的名次变化。
页面还用一条带排名注释的模拟推荐流，解释每条内容为什么会出现在当前位置；随后通过八个可切换章节，依次串联候选召回、行为序列、互动预测、加权计分、排名调整和可见性检查等完整流程。
准确呈现参数之间的计算关系，比界面本身更关键。例如，代码里的举报权重是 −234，点赞是 0.5。把两个数直接相除，很容易得到「一次举报抵消 468 个点赞」；真正的计分逻辑却完全不是这回事。
这个网页用于解释公开参数之间的关系，采用了代码中的候选上限、行为权重和排名调整。反馈实验展示的是公开的真实推文，但互动、分数与刷新结果均为模拟；其他示例推文和预测概率也只为讲解而设，不对应真实用户或生产数据，更无法预测你的个人推荐流。
每次刷新，系统都会重新生成推荐流
X 的仓库说明写得很直接：「为你推荐」会按每次请求组装。每当用户打开或刷新页面，系统都会重新运行整套流程，而非沿用一张预先排好的无限列表。
按主要环节看，这个过程大致分为五步：
- 从已关注账号与发现系统中召回候选推文；
- 读取用户近期行为，以及关注、隐藏账号、屏蔽账号等信息；
- 预测用户对每条候选推文采取各项行为的概率；
- 把预测值转换成分数，再调整排列；
- 进行可见性检查，生成最终推荐流。
系统首先要决定哪些推文有资格参加本轮排序。这份代码快照展示了三个主要来源：
| 候选来源 | 主要内容 | 单次返回上限 |
| Thunder | 已关注账号发布的近期推文 | 1200 条 |
| Phoenix | 机器学习检索到的未关注账号内容 | 1000 条 |
| SimClusters | 根据互动社区找到的相关内容 | 800 条 |
Thunder 对应已关注账号内容：它把这些账号近期发布的推文保存在内存中，供 Home Mixer 快速读取。Phoenix 和 SimClusters 负责发现新内容：前者把用户与推文表示成向量，寻找距离较近的内容；后者根据「谁与什么互动」形成的社区关系寻找候选。三者会并行提供内容，之后再由同一个模型评分。候选来源及流程见仓库的架构说明；1200 和 1000 来自 param.rs，800 则写在 simclusters_source.rs4 中。
这三个上限相加约为 3000 条，但不能反过来理解成每次刷新都会取得整整 3000 条。候选会因重复、过期、已经看过，或屏蔽账号、隐藏关键词、访问权限等原因，在评分前被移除。这些上限也不能直接换算成最终推荐流的混合比例。
陌生内容会被发现系统主动纳入候选池，而且容量并不低。召回结束后，已关注与未关注账号的推文会进入同一套评分流程。
排序模型预测的是具体行为
兴趣标签能解释推荐内容为何与科技、摄影或赛车等主题相关，却无法说明同一主题下的先后顺序。
Phoenix 读取的是一段近期行为序列。点赞一条赛车内容、看完一段烹饪视频、回复一位朋友、跳过一串股票行情推文、打开某位作者的主页——这些行为按时间排列，构成模型理解当前用户的上下文。X 的公开说明列出了二十多种预测目标，涵盖互动、点击、注意力、作者关系和负向反馈。
面对一条候选推文，模型的输出更接近下面这样：
- 点赞概率：31%；
- 回复概率：4%；
- 转帖概率：7%；
- 观看视频概率：42%；
- 关注作者概率：1%；
- 选择「不感兴趣」的概率：0.2%。
因此，即使兴趣相同，排序也未必一致。两个人都关注 AI 编程工具，一个人最近常把教程复制给同事，另一个人习惯快速浏览产品新闻；面对同一批候选推文，模型对两人下一步行为的预测仍会有所不同。同一个人在不同时间的行为序列发生变化，排序也会随之调整。
换句话说，兴趣标签说明内容是否相关，具体行为的预测值决定排列先后。
权重和概率共同决定分数
模型会输出多项预测值，排序系统再把它们压缩成一个可供比较的分数。公开代码里的核心思路可以简化成：
推文分数 = Σ（某项行为的预测值 × 对应权重）对于点赞、回复或举报，预测值通常是用户采取该行为的概率；停留时间等目标也会使用连续数值。具体运算见 ranking_scorer.rs5。
其中一些代表性默认权重如下：
| 预测行为 | 权重 |
| 打开推文 | + 0.4 |
| 点赞 | + 0.5 |
| 转帖 | + 1 |
| 分享 | + 2 |
| 关注作者 | + 4 |
| 回复 | + 5 |
| 引用转帖 | + 5 |
| 通过私信分享 | + 5 |
| 复制链接 | + 20 |
| 回复互相关注的用户 | + 20 |
| 屏蔽账号 | - 31.2 |
| 不感兴趣 | - 43.2 |
| 隐藏账号 | - 58.8 |
| 举报 | - 234 |
最容易产生误解的，是把权重当成实际互动的兑换表。回复权重是点赞的 10 倍，不代表「一个回复抵得上十个点赞」；举报权重是点赞的 −468 倍，也不代表一条推文收到一次举报，就会抵消 468 个赞。权重乘的是系统对当前用户采取某项行为的预测，而不是推文已经积累的互动数量。
假设候选池里有两条推文：
- A 是一张讨喜的猫咪照片，你有 40% 的概率点赞，但几乎不会进一步操作；
- B 是一篇与你工作相关的工具教程，你只有 15% 的概率点赞，却更有机会打开全文、复制链接或发给同事。
A 的点赞概率更高，B 却能凭借多种高权重行为的预测概率获得更高总分。于是，推荐流第一名未必是候选池里点赞最多或发布时间最近的推文。
举报、隐藏账号等行为的权重看起来很大，是因为它们发生的概率远低于点赞。代码注释特意说明，举报的基线概率比点赞低 1000 倍以上；如果负权重不够大，这类低概率预测几乎不会影响最终分数。只有当模型给出的举报等负反馈概率明显上升时，相应预测才会显著拉低分数。
计分过程也会抑制负反馈风险较高的内容。挑衅内容或许能引出回复和引用转帖；一旦模型同时预测到「不感兴趣」、屏蔽或举报，相应的负向值也会参与计算。至于模型在现实中能否充分区分愤怒、猎奇与真正的兴趣，仅凭公开权重还无法判断。
权重表只能说明计分结构，无法单独还原某次真实推荐。
原始分数之后，还有排名调整
原始分数算完后，系统还会经过多轮调整，再决定输出顺序。
设想三条候选推文：第一条来自你经常阅读的作者，但他已经有两条内容排在前面；第二条来自从未关注过的账号，原始分很高；第三条得分也不错，却带有需要限制展示的安全标签。后续规则会分别处理它们。
首先是作者多样性。同一作者的第一条推文保留原分，后续推文会按 0.5 的衰减系数逐步折价，最低到 0.25。即使某位作者与你高度匹配，也不容易凭多条内容占满整屏。
其次，来自未关注账号的推文会乘以 0.75。陌生内容仍然可以排到前面，但需要以更高的原始分抵消折扣。与之相对，低曝光作者的内容还有机会获得冷启动提升。仓库把这些步骤概括为作者多样性、未关注账号折扣和新作者提升，之后还会由独立的 VMRanker 牺牲少量分数，让相邻内容不要过于相似。
完成排序后，推文还要接受独立的可见性过滤。排序决定位置，可见性系统决定内容能否展示，并把结果分为三类：正常显示、置于警告之后或直接移除。检查会结合用户隐藏或屏蔽了哪些账号，以及其他系统附加给推文和账号的安全标签；对于未关注账号的推荐内容，还存在一组更严格、只能执行移除的规则。仓库的过滤说明也指出，同一条推文可以向关注者正常显示，却不进入未关注用户的推荐流。
实际结果由整条流程共同决定：候选召回、行为预测、加权计分、多样性重排和可见性过滤各自负责一个环节。
理解机制后，你能做什么
了解运行机制后，你仍然无法精确控制推荐流：真实预测不可见，参数也会随实验变化。不过，你可以更清楚地判断不同操作向系统提供了什么信号。
停留同样会成为信号
公开流程会读取显式和隐式互动信号，模型的预测目标也包括停留等注意力指标。因此，持续打开、阅读或观看某类内容，会为后续预测提供同方向的上下文，即使你没有点赞。
面对令人恼火的内容时尤其如此。即便主观上出于厌恶，长时间围观、反复打开或加入争论，仍会在行为记录里留下注意力投入。系统能否准确区分「喜欢所以停留」和「愤怒所以停留」，还要结合其他行为判断，不能仅凭用户没有点赞来确定。
关注仍然直接影响候选来源
关注不仅决定 Thunder 能提供哪些候选推文，也让这些内容不必承担 0.75 的未关注账号折扣。互相关注关系下的回复，在公开参数中还会得到额外提升。
如果想长期改变推荐流，整理关注列表通常比在偶然出现的推文下面被动点赞更稳定：前者改变了候选推文从哪里来，后者只是行为序列中的一个信号。
推荐流不会因一次点击立即改变
推荐系统读取的是一段持续变化的行为，单次操作只是其中一个记录。想减少某类内容，通常需要在一段时间内少打开、少阅读，同时持续关注和反馈自己感兴趣的主题。
代码注释还说明，相关行为需要发生在推文作为 Home Timeline 内容送达之后；直接通过群聊链接进入推文，不会以同样方式计入这套推荐反馈。这一限制可降低协调点击、屏蔽或举报对推荐排序的操纵效果。但这段说明只针对公开实现，不代表 X 上所有分发与治理系统都采用相同规则。
上述操作只能改变输入信号，无法直接控制结果。模型怎样处理行为记录，还取决于当时的候选推文、上下文、实验参数与安全规则。
开源算法的边界
开源仓库能够确认候选推文来自哪里、Phoenix 预测哪些行为、预测值怎样进入分数，以及高分结果为何还会被重排或过滤。
公开代码也有明确边界。本文与交互网页依据的是这份代码快照；X 仍可修改默认值，并通过功能开关向不同用户启用不同配置。仓库的过滤说明6同样明确表示，为降低被绕过和操纵的风险，一部分安全规则没有公开。
即使信息并不完整，公开部分已经足以纠正几个常见误解：推荐流包含个性化排序，并非热度榜；点赞只是多种反馈之一；负权重作用于预测概率，而非实际举报数量；关注关系会影响候选来源和排名折扣；最终结果还要经过重排与过滤。
你的行为会影响推荐流，推荐流也会塑造之后的行为。下一次刷新 X，看到一条似乎毫无来由的陌生推文时，不妨换一种问法。
不是：
「X 为什么觉得我喜欢它？」
而是：
「X 认为我接下来会对它做什么？」
