threads-algorithm-ruleslisted

# Threads 演算法規則(發脆 self-check) ## 出處 / 授權 本 skill 內容**改自** [`akseolabs-seo/AK-Threads-Booster`](https://github.com/akseolabs-seo/AK-Threads-booster) 的 `knowledge/algorithm.md`(2026-03-31 更新),原作以 MIT 授權釋出。我們把原文幾乎逐字保留,僅加上下面這層 preamble 做術語對照,因為 AK 把規則綁到他自家的 M6.3 / M8 / M5 模組,我們不跑那套。 ## AK 術語對照(讀下面內容時用) | AK 用語 | 我們的對應 | 何時用 | |---|---|---| | `[Skill 用途] M6.3 ...` | **發前自查** | 草稿寫完、按 publish 之前的最後檢查 | | `[Skill 用途] M5 ...` | **選題** | 想下一篇要寫什麼時 | | `[Skill 用途] M8 ...` | **發後追蹤** | 發完看實際表現、學經驗 | | `[Tracker 欄位] ...` | 我們**沒有 tracker**,當作觀察維度即可 | | `Skill / 模組` | 都是指 AK 系統的子流程,我們直接照規則本身判斷 | ## 怎麼用這份規則 當你準備寫一篇脆貼文 / 改草稿 / 跑 publish-threads.mjs: 1. **第一輪先掃紅線(R1–R12)** — 命中任何一條,**直接警告使用者**,不要委婉。紅線是硬規則,踩到會被降權。 2. **第二輪看信號(S1–S14)** — 不是必殺,是「這篇潛力如何」的觀察。語氣是顧問式:「你這篇在 S1 私訊分享潛力上看起來偏弱」,不是命令。 3. **發後追蹤(P1–P4)用發文後** — 文字本體寫完後不是結束,前 3 小時的留言區互動策略也很重要,要主動提醒使用者。 4. **跨平台 / 帳號層級(A1–A2)** — 整體節奏建議,不要爆量、保持人設一致。 如果是跟 `daily-threads-post` skill 一起用:**先讀 daily-threads-post 拿格式約束(全形標點 / 列點 / 字數 / 受眾白話化),再用本 skill 做演算法對齊檢查**。daily 規則優先,因為那是使用者的硬約束,但兩條同時違反時要同時警告。 如果觸發 R1–R12 任何一條紅線跟 daily-threads-post 格式衝突,先警告紅線,讓使用者選擇。 --- # 以下為 AK-Threads-Booster `knowledge/algorithm.md` 內容(verbatim,僅微調 [Skill 用途] tag 格式對照我們流程) > 服務模組:[發前自查](AK 原稱 M6.3,演算法對齊檢查)、[發後追蹤](AK 原稱 M8,發文後回饋循環) > 最後更新:2026-03-31 > 適用場景:Threads 為主,Instagram/Facebook 官方規則與專利作方向參考 --- ## 使用說明 這份知識庫分兩大區塊: 1. **紅線區**:踩到就直��警告「這個會被降權,你確定要這樣寫嗎」。發前自查時逐條掃描,命中任一項即觸發警告。 2. **信號區**:不是硬規則,是動態參考。發前自查用來評估貼文的演算法對齊程度,發後追蹤用來追蹤各信號在用戶帳號上的實際表現。 每個知識點標