X 推薦權重表：分數一旦翻負，差多少就不重要了

事實分級說明

數字取自 xai-org/x-algorithm（Apache 2.0）2026 年 8 月 13 日的 HEAD 快照，官方以單一 commit 發布。權重與係數是這份快照以 Params::default() 取得的值；param.rs 第一行自陳，這份鏡像最後與線上設定同步的時間是 2026 年 8 月 12 日。

一則貼文在 X 的 For You 能拿到的最大單項正分，不是按讚，也不是轉推。

是「複製連結分享」——有人按下複製連結，把貼文的網址帶走。這一項的權重是 20.0。

按讚 0.5，轉推 1.0。20.0 除以 0.5，是 40 倍。

負的那一端更誇張：檢舉 −234.0。

X 在 2026 年 8 月 13 日把推薦系統的程式碼放上 GitHub，這份權重表就寫在 home-mixer/params/param.rs 裡，一行一個動作，從 20.0 排到 −234.0。接下來中文圈大概會出現一批照字面翻的表格：一個讚 0.5 分，一個檢舉 −234 分。

照字面讀會讀錯。而理由不是外面的人推敲出來的——X 自己把它寫在表格正上方。

最大的正分給了複製連結分享，按讚只有 0.5

先把表看完。以下是 param.rs 第 282 行到第 448 行的內容，一行一個動作。

動作	權重
複製連結分享	20.0
回覆	5.0
引用	5.0
私訊分享	5.0
追蹤作者	4.0
分享	2.0
轉推	1.0
按讚	0.5
點擊	0.4
開啟連結	0.2
照片展開／影片開啟／影片品質觀看／引用點擊	0.05
未探索貼文（預設僅站內）	0.02
連續停留時間	0.004
停留（二元）／個人檔案點擊	0.0
沒停留	−0.02
封鎖作者	−31.2
不感興趣	−43.2
靜音作者	−58.8
檢舉	−234.0

正的那一端，排在最前面的不是社群圈常掛在嘴上的「互動」，是把連結複製走。私訊分享、引用、回覆都是 5.0，全都排在按讚前面。追蹤作者 4.0，也比按讚重。

再往下看，量級掉得很快。點擊 0.4、開啟連結 0.2，照片展開與影片開啟這類動作是 0.05，連續停留時間 0.004。純粹的停留（有沒有停下來看）是 0 分，個人檔案點擊也是 0 分——欄位都在，權重是零。換句話說，在這條加總裡，預測一位觀看者「會停下來把它看完」能貢獻的分數，遠不如預測他「會把連結複製走」。要留意的是，表上每一個動作名詞在程式碼裡都是預測值，不是計數。

表上還有兩列跟「互相追蹤」有關。互相追蹤的作者所發的原創貼文，預測回覆這一項會額外加 15.0，合計 20.0，跟複製連結分享完全相同。但三個條件要同時成立：不是回覆、不是轉推、作者與觀看者互相追蹤。同一組互關關係另外還有一列停留加成，欄位在，值是 0.0。

負的那一端由輕到重：沒停留 −0.02、封鎖作者 −31.2、不感興趣 −43.2、靜音作者 −58.8、檢舉 −234.0。

X 把最重要的但書寫在權重表正上方

表格正上方，第 279 到 281 行，是一段三行的註解：

These weights reflect a combination of how much an action is valued in ranking and typical propensities of these actions across the X network (e.g. negative feedback is overall rare).

翻成中文：這些權重反映的是兩件事的綜合——這個動作在排序裡被賦予多少價值，以及這個動作在 X 全網上的典型發生傾向。註解自己舉的例子是，負向回饋整體來說罕見。

「綜合」在原文是 a combination of。沒有給乘法，沒有給權數，也沒有說哪一件事佔多少。

把 234.0 除以 0.5，得到 468。這是線性加總那一層的權重比值，也是接下來最容易被單獨抓出來當金句的數字。但照 X 自己那段註解，這個比值裡同時裝了「排序價值」與「發生傾向」兩件事，而註解舉的例子正好就是負向回饋很少見。兩件事各佔多少，程式碼裡沒有寫。

〈它不是在評分，是在打安全牌〉講過一件事：一個數字大不大，要先知道它是怎麼被算出來的。468 就是這種數字。

權重乘的不是你做過幾次，是模型猜你會不會做

README 第 327 行直接給了公式：

Final Score = Σ (weight_i × P(action_i))

P(action_i) 是機率。README 第 54 行寫得更白：Phoenix 讀觀看者近期的互動紀錄，對每一則貼文預測，這位觀看者做出每一個動作的可能性有多高。程式碼對得上——ranking_scorer.rs 把每一個預測值乘上對應的權重，再逐項加總。

所以權重乘的不是「這則貼文被按了幾個讚」，而是「模型認為你會按讚的機率」。

這個差別會改掉每一句話的意思。準確的說法是：模型預測的一次檢舉，抵得掉預測的 468 個讚。不準確的說法，是把同一句話裡的「預測」兩個字拿掉——那會變成在講已經發生的動作數，而這條路徑上沒有任何一項在數已經發生的動作。

〈它不是在說謊，是在賭〉講的是模型在賭下一個字的機率。這裡是同一件事換了個位置：排序引擎賭的是你會不會伸手。

兩件事要順帶講清楚。第一，這條公式走的是程式碼裡的預設路徑，也就是排序開關為真、取值模式是公開預設的 weighted；同一支程式還有其他取值模式，走那條路徑時公式不一樣。第二，Phoenix 是從 Grok 衍生出來的 transformer 排序模型，但排序這條路徑上沒有 LLM 在做決策。

加總一旦翻負，差多少就不再重要

到這裡為止都還在加權分數那一層。最反直覺的一步在後面。

ranking_scorer.rs 第 525 到 532 行有一個叫 offset_score 的函式，負責把加權分數轉成最後要用的分數。它分兩條路走。

加總是非負的，就直接加上一個常數 0.001。原本兩則貼文差多少，加完還是差多少。

加總翻成負的，換一條公式：先把分數加上所有負權重的總和，除以所有權重絕對值的總和，再乘上同一個 0.001。

用這份快照的預設值算，正權重加總 43.32，負權重加總 367.22，兩者相加 410.54。代進去，負分那一整段——從 −367.22 到 0——被映射進 0 到 0.00089448 這個區間。

寬度從 367.22 壓進 0.00089448，約 410,540 倍。

意思是：加總一旦翻負，「稍微負一點」跟「負很多」出來的分數會擠在同一條極窄的帶子裡。差距沒有消失，是被壓到看不出來。而且這個壓縮是映射本身的性質，後面再乘任何係數都不會把它重新拉開。

兩條路的落差可以直接對照。走非負那條路，加總最低是 0，加完偏移量之後的下限就是 0.001。走翻負那條路，最極端的情形是分數剛好卡在 0 的正下方，出來的值上限是 0.00089448。在加權分數這一層，兩段碰不到彼此。

壓縮的程度可以這樣感受：翻負之前，加總差 1 分，輸出就差 1 分；翻負之後，同樣的 1 分在輸出端只剩下約 0.0000024。整段負分區間加起來的寬度，還不到每一則非負貼文白拿的那個 0.001。

接下來這一步最容易接錯：翻負，不等於排在所有非負貼文的後面。

兩個區間不重疊，只在加權分數這一層成立。之後每一則候選還要依序乘上冷啟動、同作者衰減、站外折扣。舉一個算得出來的例子：一則加總非負的貼文，如果它同時是同一位作者在這份候選清單裡分數第二高的那一篇（乘 0.625），又來自你沒追蹤的帳號（乘 0.75），最終分數是 0.00046875，比翻負區間的上限 0.00089448 還低。最終分數是會交錯的。

再補一句射程：以上是拿公開預設值做的算術，不是對線上流量做的量測。線上實際跑的是什麼值，這份快照答不了。

48 小時濾網與同作者衰減，前提都比表面多

表格之外還有幾個係數，看起來最像「可以操作的旋鈕」。每一個打開看，條件都比表面上多。

先看 48 小時濾網。config.rs 第 36 行有一個編譯期常數 MAX_POST_AGE，值是 48 小時。它掛在 phoenix_candidate_pipeline.rs 的 filters 清單上，把年齡超過 48 小時的貼文從候選清單裡濾掉。射程要看清楚：這是 For You 的 Phoenix 候選管線，時間軸、個人頁與搜尋走的是別的路徑。整個 home-mixer 裡也只有這一處掛了年齡過濾器。

再看同作者衰減。乘數的公式是 (1 − floor) × decay^k + floor，這份快照裡 decay 是 0.5、floor 是 0.25。算出來：k 等於 0 是 1.0，k 等於 1 是 0.625，k 等於 2 是 0.4375，k 等於 3 是 0.34375。因為有 floor 撐著，衰減不會歸零，最低就是 0.25。

k 是什麼，最容易搞錯。k 不是你今天發的第幾篇。k 是候選清單依「調整前的分數」排序之後，同一位作者的第 k 個候選。準確的講法是：同一份候選清單裡，你分數第二高的那篇會被乘 0.625。至於哪一篇分數最高，你事前並不知道。這一整套只在作者多樣性開關為真時套用，公開預設是開的。

站外折扣有兩個值，小帳號冷啟動一份清單只挑一則

站外折扣。看到你沒追蹤的帳號所發的內容（程式碼裡叫 out-of-network），分數要乘一個係數，一般情形是 0.75。但帶有 topic 的請求讀的是另一個參數，值是 0.5。同一個機制，兩個值，看請求帶不帶 topic。另外，把站內的回覆與轉推也一起套用這個係數的開關，公開預設是開的。

程式碼裡還有一條給新帳號用的分支，係數小到 0.00001。但觸發條件是帳號年齡小於一個門檻，而那個門檻的公開預設值是 0 秒。分支在，門檻等於沒開。

小帳號冷啟動最容易被讀成「小帳號會被保障一個排名位置」，實際上不是。程式碼做的事是：在整份候選清單裡，找出所有合格候選中分數最高的那一則，把它的分數抬到目前排名第 16 名的那個分數。一份清單只挑一則，動的是分數不是格位。

合格條件要同時成立好幾個：是原創貼文（不是回覆也不是轉推）、作者粉絲數不超過 1000、這則貼文的曝光數低於 1000、位置排在非零候選的前 85%，再加上實驗分組與內容池的條件。另外，24 小時新鮮度那個檢查只在實驗組那一支才會跑。

影片那一項也是同樣的形狀。權重表上有一項叫做影片品質觀看，參數裡的最短影片長度是 10 秒，看起來像是「影片拍超過 10 秒就會被算」。實際上要成立得再過兩關：候選影片的長度必須嚴格大於 10 秒，而且觀看者自己的粉絲數要少於 10,000，兩個條件缺一個，這一項的權重直接歸 0。決定它算不算數的條件裡，有一個根本不在發文的人身上。

這幾個機制排在一起看，共通點很清楚：沒有一個是「打開就有效」的開關，全都要在一組同時成立的條件下才會動。想拿它們當操作手冊的人，會先撞上條件表。

表上的數字有保存期限

還有一件事會決定這份權重表能用多久。

param.rs 裡宣告的值，是 feature switch 的預設值。該檔第一行自陳，這份鏡像最後與線上設定同步的時間是 2026 年 8 月 12 日，而 feature switch 的線上值可以被覆寫。也就是說，這些數字是「公開快照當下的預設值」，不是「X 現在線上正在用的值」。

另外一批數字性質不同。config.rs 裡用 pub const 宣告的 MAX_POST_AGE（48 小時）與 NEGATIVE_SCORES_OFFSET（0.001），是編譯期常數，不是 feature switch。兩類值混在一起講，會得到錯的結論。

還有一件事值得記住：README 自陳，這次公開的內容排除了 Grox 的 prompt 模板與部分 botmaker 規則，倉庫裡也沒有任何模型權重檔。放出來的是一份策展過的快照。

〈權限提示有 97% 被直接按同意〉提過一件事：預設值會被改，而改的那天不一定會公告。權重表也適用。

倉庫是公開的，param.rs 就放在 home-mixer/params/ 底下，行號都在上面。〈你叫的名字，和你拿到的東西〉講過的習慣在這裡一樣好用：與其記別人翻譯過的表格，不如自己把那段程式碼打開來看一遍。

給非工程師的一句話

看完這份權重表最有用的收穫，不是知道複製連結分享值 20.0，而是知道那個 20.0 乘的是一個猜測——X 的排序引擎沒有在數你拿了幾個讚，它在猜你會不會伸手，然後拿猜測去排序。所以「衝高某個動作」這個念頭從一開始就對不準。真正該帶走的是 X 寫在表格正上方的那句話：這些權重同時裝著「這個動作值多少」跟「這個動作有多常發生」。往後看到一個很大的數字，先問它裡面裝了什麼。