如何審查 X 貼文是否提及你的產品

按步驟進行審查

1. 審查候選貼文前，先建立產品身分紀錄。列出準確的產品名稱、已知別稱、官方公開網站、官方帳號名稱及產品專用詞。這些規則須由讀者自行制定，並與 Actor 的驗證欄位分開保存。
2. 以提供的已知候選貼文網址及目前的 Task 輸入作為起點。進行先導測試時，請將已儲存的 startUrls 清單換成你打算測試的 1 個已知候選貼文網址。
3. 檢查來源原生的 ID 或網址、文字，以及狀態或時間。審查文字是否足以作出判定。圖片、引用貼文的內文及連結頁面，可能包含資料列未呈現的語境。若缺少必要語境，請另行查看原始公開來源，或將該項標記為需要審查。文字字串非空白，並不代表語境完整。
4. 將字面吻合情況與所指對象的判定分開記錄。列明吻合的字詞或別稱，以及作為證據的段落。River 這類同時是普通詞語的別稱，可能與討論河道的內容吻合。不要因為大寫字母、關鍵字吻合、藍色徽章或大量追蹤者，就推斷作者指的是該產品。
5. 使用書面語境規則。實際段落中若出現經核查且完全吻合的產品網址、官方帳號名稱，或具辨識度的產品名稱，便可按該規則支持其指向目標產品的判定。只出現名稱或代名詞，仍可能無法確定所指對象。請仔細閱讀相關句子及前後文。
6. 將結果分類為「有證據支持的產品提及」、「普通詞語用法」或「需要審查」，並列明具體原因。有證據支持的產品提及，表示經審查的段落指的是所述產品。這不代表陳述屬實、評價正面、由客戶發表，或獲品牌認可。情感傾向與聲稱是否屬實，須另行分析。
7. 在這個小型隊列中保留來源證據、規則版本、審查人員、時間，以及尚未釐清的語境。同一則貼文在匯出資料中重複出現，不應計作多次提及。互相矛盾的來源副本應維持未判定狀態。無法取得來源，不足以證明沒有提及產品。不要在未作說明的情況下，用較早版本的文字填補缺失，並當作目前文字。
8. 只將已審查的相關性判定交給下一個流程。若日後建立通知工具，請分開保存收集、相關性判定及傳送的回執紀錄。本文沒有測試任何通知整合功能。本指南的成果是有來源證據支持的相關性審查隊列，以及一個具體的未能確定個案，並不承諾通知能涵蓋每則貼文。

OUTPUT 及欄位結構

X Post Metrics 1.0.4 Actor 接受在 `startUrls` 中輸入已知的公開貼文網址。每則貼文傳回的原生欄位名稱為 `inputUrl`、`postUrl`、`postId`、`postType`、`publishedAt`、`text`、`profileUrl`、`profileId`、`profileUsername`、`profileName`、`status`、`statusReason` 及 `observedAt`。

請注意，`text` 可以是 null，而 `postMetricStatus` 陣列說明的是指標的可用情況及精確程度，並非文字是否完整或語意是否相關。執行摘要會輸出彙總計數（`inputCount`、`datasetRows`、`usefulRows`、`billableRows`、`failedRows`、`statusCounts` 及 `stopReason`）。以下以 1 則貼文進行的對照執行，展示執行摘要的輸出結構：

純文字

inputCount: 1
datasetRows: 1
usefulRows: 1
billableRows: 1
failedRows: 0
statusCounts: {"ok": 1}
stopReason: "inputs_exhausted"

在這次對照執行中，目標貼文傳回了 200 個字元的非空白文字。這證實工具支援收集這 1 則已知公開貼文的文字，但不保證所有貼文、圖片、引用貼文的內文、連結頁面或過往原始措辭均有文字可供取得。若無法取得文字，關鍵字吻合狀態應為未知，而不是判定為不吻合。

逐步解說的範例隊列

以下所有教學文字及範例均為原創虛構內容。

讀者自行建立的產品身分紀錄

• 產品名稱：RiverQueue
• 別稱：River（不區分大小寫的關鍵字規則：小寫的 "river" 與別稱 "River" 吻合，但不改動原始來源文字）
• 官方帳號名稱：@RiverQueue
• 官方網域：riverqueue.example
• 已核查的前提／來源：經讀者核實的品牌身分紀錄（規則 v1.0，由 Reviewer 於 2026-10-13 核查）

候選貼文相關性審查隊列

4 則不同的候選貼文得出 1 則有證據支持的產品提及、1 則普通詞語用法，以及 2 則需要審查的個案。不要將此稱為整個 X 平台的準確率、假陽性率或聲量佔比，因為這裏沒有測試任何已知真實分類的樣本。這個虛構的公開產品連結，是經人手核查的身分判定前提，並非 Actor 的查詢結果。