# 如何比較固定 X 貼文樣本中的主題

比較主題時，先閱讀並標記固定清單中的已知貼文，再查看互動計數。將不同帳號、貼文類型與發布時長分開處理。接著列出各主題的貼文數、互動反應中位數、範圍及缺失案例。利用結果選擇下一個要說明的主題。原始互動計數不能證明某個主題造成了這些互動，也不能證明它會帶來未來的追蹤人數成長。

先以人工審查內容含義。[2026 年 8 月 11 日收集到的公開提問](https://www.reddit.com/r/SideProject/comments/1rpwva4/how_do_founders_analyze_other_twitterx_accounts/)問道：「哪些主題獲得最多互動？」請縮小問題範圍：在這些選定的貼文中，各主題獲得了哪些已記錄的互動反應？互動是指已記錄的動作或計數，例如按讚或回覆。比較主題前，先選定一種計數。

結果應包含三個部分：書面的主題規則、將每個主題標籤連結至來源的清單，以及清楚說明限制的互動反應表。這些部分需要由你建立。收集工具提供的是文件所載的來源欄位，並非完整分析。

## 1. 寫下決策並固定樣本

樣本是你要檢視的一組貼文。固定樣本有一份已保存的成員清單，不會為了改善結果而變更。

收集計數前，先寫下要做的一項決策。例如，你可能想選擇下一篇產品說明的主題。這是預定要做的決策，不能當作所選主題會表現更好的證據。

保存以下選擇：

1. 提供的帳號與已知貼文網址。
2. 預計納入的發布日期。
3. 選取這些貼文所用的規則。
4. 每項比較允許納入的貼文類型。
5. 將使用的互動計數。
6. 該計數要求的貼文發布時長。
7. 這項比較將支援的決策。

選取規則可以是納入指定日期內所有已提供的原創貼文。請準確描述規則。如果提供者只挑選他們認為成功的貼文，結果也必須保留這項限制說明。

不要在看到第一份表格後，才加入互動反應高的貼文。將它留給後續樣本，或記錄新的樣本版本並重新分析。

已知貼文清單不能呈現某個帳號的所有貼文，也不能衡量平台需求。請分開呈現各帳號的結果，以免將主要由某個帳號發布的主題，拿來與另一個帳號的主題比較，卻未說明帳號差異。

## 2. 先核對來源與貼文類型

指派主題前，先使用已核對的貼文類型紀錄。紀錄是為單則貼文保存的一列資料，包含事實與審查決定。

原創貼文、回覆和引用貼文可能有不同用途。回覆可能是在回答先前的問題。引用貼文可能是在討論另一位作者的說法。如果這些差異會影響比較，請將各類型分開。類型不確定時，先保留為未確認，直到能夠核對。

請區分作者自己的文字與引用的來源內容。單憑引用一則定價公告，不能認定作者在說明定價。請閱讀作者自己補充的內容，以及理解這些內容所需的上下文。

[2026 年 10 月 25 日核對的 Actor 公開規格](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)載有 `postType`，但不會匯出上層貼文或被引用貼文的 ID。請將必要的關聯核對結果保存在自己的紀錄中。不能因為缺少關聯欄位，就認定不存在關聯。

同一份規格指出，轉發貼文的輸入資料列描述的是可見的原始貼文。`inputUrl` 保留請求的網址。傳回的識別資料、文字與指標都描述該原始貼文。不要將這列資料算成轉發帳號的另一則原創作品。

本指南從完成上述來源核對後開始。它不能取代貼文類型審查。

## 3. 查看指標前先定義主題

主題是貼文所回應的讀者問題或討論的事項。編碼手冊是一套簡短的書面規則，用來指派主題標籤。

查看指標前，先建立編碼手冊。指標是已記錄的數值測量結果，例如按讚數。定義與套用主題規則時，請隱藏這些欄位。這稱為盲法審查：審查者在看不到互動數值的情況下指派標籤。

為每個主題寫下以下欄位：

| 編碼手冊欄位 | 需保存的內容 |
| --- | --- |
| 主題名稱 | 簡短且固定的標籤 |
| 讀者問題 | 這個主題回答的問題 |
| 納入條件 | 使用此標籤所需具備的含義 |
| 排除條件 | 應歸入其他主題的相似內容 |
| 納入範例 | 符合條件的簡短主題範例 |
| 排除範例 | 不符合條件的簡短範例 |
| 混合主題規則 | 出現兩個主題時如何選擇 |
| 含義不明規則 | 何時必須將含義保留為未確認 |
| 版本 | 審查使用的規則版本 |

以下建議的編碼手冊範例均為原創虛構內容：

| 主題 | 讀者問題 | 納入條件 | 排除條件 |
| --- | --- | --- | --- |
| 入門設定 | 如何開始使用產品？ | 說明首次使用步驟的內容 | 沒有設定說明的價格公告 |
| 定價 | 產品價格是多少，或包含哪些內容？ | 說明價格或方案內容的文字 | 僅提及付費方案的設定指南 |

使用一個主要主題，也就是依書面規則判定的核心內容。如果兩個主題分量相同，且規則無法判定，請使用混合標籤，或將主要主題保留為未確認。查看計數前，先記錄這項選擇。

單憑關鍵字相符，無法確認主題含義。如果要另外進行詞語計數，請使用[關鍵字共現指南](/zh-Hant/articles/%E6%89%80%E6%8F%90%E4%BE%9B%E7%9A%84-x-%E5%B8%96%E6%96%87%E6%A8%A3%E6%9C%AC-%E9%97%9C%E9%8D%B5%E8%A9%9E%E5%85%B1%E7%8F%BE%E5%88%86%E6%9E%90/)。共現是指兩個選定詞語出現在同一則貼文中。它不能取代此處的閱讀步驟。

## 4. 閱讀、標記，並保留未確認的含義

閱讀每則貼文，以及理解其重點所需的上下文。如果主題取決於圖片、引用資料或連結內容，請另行檢視這些資料。文件所載的 `text` 欄位不能證明理解內容所需的資訊已全部齊備。

對每則貼文執行以下步驟：

1. 確認來源的識別資料與已核對的貼文類型。
2. 閱讀作者的文字與必要的上下文。
3. 在不查看指標的情況下，套用已保存的編碼手冊。
4. 證據足夠時，指派一個主要主題。
5. 保存一小段文字或判定理由。
6. 記錄缺少的上下文與未確認的含義。

次要標記是用來記錄其他主題的額外標籤。請將這些標記與主要主題表分開保存。否則，同一則貼文可能被計入多個主題的總數，卻沒有清楚說明。

如果要判斷某個詞是否指稱你的產品，請使用[產品指稱審查指南](/zh-Hant/articles/%E5%AF%A9%E6%9F%A5-x-%E8%B2%BC%E6%96%87%E6%98%AF%E5%90%A6%E6%8F%90%E5%8F%8A%E4%BD%A0%E7%9A%84%E7%94%A2%E5%93%81/)。確認產品指稱與辨識貼文的主要主題，是兩項不同的判定。

含義不完整的貼文，不應納入主題已確認的比較。不要只憑一個可見詞語，就指派推測的主題。也不要將含義未確認的貼文稱為零互動貼文。

如果變更主題規則，請保存理由，並將修訂後的規則套用至完整樣本。公開指標前，先核對標籤。如果你已知道部分互動數值，請記錄這項限制，不要將審查描述為完全採用盲法。

## 5. 收集可比較的公開觀測資料

觀測是在指定時間取得並記錄的一次讀值。貼文發布時長是從發布到取得該讀值之間經過的時間。發布七天的貼文與發布一天的貼文，觀測時的發布時長並不相同。

樣本較小時，你可以人工檢視公開貼文，並保存來源、時間、計數及可用狀態。如果需要自己帳號中僅擁有者可見的紀錄，請分開保存。公開觀測不會提供其他帳號的私人分析資料。

如果已有公開貼文網址，[X Post Metrics Actor](https://apify.com/chronometrica/x-post-metrics) 適合用於資料收集步驟。Actor 是在託管環境中執行的收集程式。經核對的公開輸入規格允許在 `startUrls` 中提供 1 至 1,000 個已知的 X 或 Twitter 貼文網址。它不會搜尋貼文，也不會傳回完整的帳號貼文存檔。

以下提供的輸入符合文件所載的有效格式：

```json
{"startUrls":["https://x.com/OpenAI/status/2077446718728425686"]}
```

5. 收集可比較的公開觀測資料

將範例網址替換成固定清單中的一個已知公開貼文網址。先用這一個網址檢查，再提交其餘網址。這是建議的收集步驟。本指南未實際執行收集。

2026 年 10 月 25 日核對時，公開的 [X Campaign Post Metrics Task](https://apify.com/chronometrica/x-post-metrics/examples/x-campaign-post-metrics) 頁面確實存在。Task 是為 Actor 保存的預設輸入設定。本指南未使用已驗證身分的帳號檢視其保存設定，也未執行該 Task。使用前，請自行檢查目前的輸入。

經核對的規格載有識別資料、文字、發布時間、觀測時間與公開計數。規格也載有 `postMetricStatus`，用來記錄每項指標的可用狀態、精確程度與來源。精確程度說明數值是精確、無法取得，還是未知。請將該狀態與數值一起保存。

目前的讀值無法還原過去第七天的計數。請使用先前保存、且發布時長相同的讀值，也就是在相同的指定發布時長取得的讀值。如果沒有，請規劃未來的觀測。如果使用目前取得、但發布時長不同的讀值，請說明差異，並將它們排除於要求發布時長相同的表格之外。

## 6. 保存主題與觀測紀錄

將原始來源事實與主題判定分開保存。保留原始數值，包括缺失值。

實用的貼文主題紀錄需要以下欄位：

| 欄位 | 用途 |
| --- | --- |
| 帳號識別資料 | 將各帳號的比較分開 |
| `inputUrl`, `postUrl`, `postId` | 將請求連結至傳回的貼文 |
| 已核對的貼文類型 | 界定允許納入比較的群組 |
| 文字與上下文參照 | 提供含義判定的依據 |
| 上下文狀態 | 記錄含義是否完整、不完整或未確認 |
| 主要主題 | 保存一個已確認的主題，或未確認狀態 |
| 次要標記 | 另行保存其他主題 |
| 主題判定理由 | 說明為何適用該主要標籤 |
| 編碼手冊版本與審查者 | 顯示套用的規則與執行審查的人員 |
| `publishedAt`, `observedAt` | 提供核對貼文發布時長的依據 |
| 指標名稱與數值 | 標明計數種類與讀值 |
| 指標狀態、精確程度與來源 | 保留 `postMetricStatus` 中的狀態 |
| `status`, `statusReason` | 保留傳回資料列的狀態 |
| 納入資格與理由 | 說明貼文是否納入這項比較 |

符合納入資格，是指貼文符合這項比較的每一項規則。能夠閱讀的貼文，仍可能有無法取得的指標。指標數值精確的貼文，含義也可能尚未確認。請記錄這兩種狀態。

使用 `postId` 核對，避免重複匯出時多算一則貼文。同一則貼文的多次觀測是多個讀值，不是多則作者發布的貼文。請依發布時長規則選取所需的讀值。

請明確保留以下異常狀態：

| 狀態 | 處理方式 |
| --- | --- |
| 缺少識別資料 | 在核對識別資料前，將這次嘗試保留為未確認 |
| 缺少必要的上下文 | 將主題保留為未確認 |
| 缺少指標 | 保留數值缺失狀態，並將其排除於該指標的統計摘要之外 |
| 精確程度未知 | 將該數值排除於僅使用精確數值的統計摘要之外 |
| 觀測時的發布時長不符 | 將其排除於要求發布時長相同的統計摘要之外 |
| 已確認為零 | 若符合所有其他規則，則納入零值 |
| 主題中沒有符合資格的貼文 | 報告符合資格的貼文數為零，互動反應統計摘要則保留為未定義 |

缺失值表示無法取得測量結果。零表示有可用讀值，且該計數記錄的數量為零。這是兩種不同的事實。

## 7. 呈現數量與分布

分布顯示各則貼文的互動數值有何差異。先在相同帳號、貼文類型、指標與發布時長規則下，列出各主題符合資格的貼文數、中位數與範圍。

中位數是將數值排序後，位於中間的數值。如果數值個數為偶數，則取中間兩個數值的平均數。平均數是總和除以個數。此處的範圍是指觀測值從最低到最高的區間。

使用清楚的單位，例如發布後第七天每則貼文的按讚數。按讚數描述的是已記錄的按讚次數。它不能衡量整個樣本中不重複的人數，也不能衡量未來的追蹤人數。

列出請求的貼文數、主題已確認的貼文數、指標符合資格的貼文數，以及排除案例。只有兩則符合資格貼文的主題，所提供的證據量，與有許多符合資格貼文的主題不同。請務必在互動反應統計摘要旁列出樣本數。

保留來源清單，以供審查。如果統計摘要沒有附上納入計算的貼文，就很難核對這個模式是否可由不同用途或某一則特殊貼文解釋。

## 8. 逐步完成一個虛構比較

原創虛構範例。本範例中的所有貼文、ID 與讀值均為虛構。範例假設已保存精確的第七天按讚數讀值。這不是 Actor 的執行結果，也不是關於真實帳號的證據。

固定清單包含同一個所提供帳號的六則原創貼文。其中五則有完整文字、已確認的主要主題，以及符合資格的第七天按讚數。一則的含義仍未確認。

| 虛構貼文 | 主要主題 | 已保存的第七天按讚數 | 比較狀態 |
| --- | --- | --- | --- |
| P1 | 入門設定 | 10 | 符合資格 |
| P2 | 入門設定 | 20 | 符合資格 |
| P3 | 入門設定 | 100 | 符合資格 |
| P4 | 定價 | 25 | 符合資格 |
| P5 | 定價 | 35 | 符合資格 |
| P6 | 未確認 | 未指定 | 不納入主題比較 |

本範例沒有提供 P6 的按讚數。不要虛構數值、將它稱為零，或推斷資料收集失敗。此處說明的排除理由是含義未確認。

將「入門設定」的讀值排序：10、20、100 次按讚。中間的讀值是 20 次按讚。因此，中位數是每則貼文 20 次按讚。範圍是每則貼文 10–100 次按讚。

將「定價」的讀值排序：25、35 次按讚。中間有兩個數值。中位數計算如下：

(25 次按讚 + 35 次按讚) / 2 則貼文 = 每則貼文 30 次按讚。

「定價」的範圍是每則貼文 25–35 次按讚。

| 主題 | 符合資格的貼文數 | 第七天每則貼文按讚數的中位數 | 第七天每則貼文按讚數的範圍 |
| --- | --- | --- | --- |
| 入門設定 | 3 | 20 | 10–100 |
| 定價 | 2 | 30 | 25–35 |

核對總數：3 則「入門設定」貼文 + 2 則「定價」貼文 = 5 則符合資格的貼文。五則符合資格的貼文，加上一則含義未確認的貼文，涵蓋了全部六則提供的貼文。

P3 是離群值：它的互動數值與其他「入門設定」數值相差很大。除非書面的納入資格規則將它排除，否則請將它保留在表格中。檢視其來源與用途。不要只因為它讓範圍變寬，就將它移除。

證據能支持的說法很有限：在這五則符合資格的貼文中，「定價」的中位數較高。「入門設定」包含最高的單一讀值。「定價」只有兩則符合資格的貼文。這些事實不能依因果關係判定哪個主題較好，也不能預測追蹤人數成長。

## 9. 選擇主題前先核對結果

使用表格前，請完成以下檢查：

1. 逐一核對所有提供的貼文，確保每則都有符合資格或被排除的紀錄。
2. 確認每則納入的貼文，只在其主要主題中計算一次。
3. 確認使用相同的指標、發布時長規則、帳號與貼文類型群組。
4. 分開核對缺失值與已確認的零值。
5. 根據保存的讀值，重新計算每個中位數與範圍。
6. 對照主題定義，閱讀離群值與未確認的案例。
7. 檢查不同用途或帳號差異是否能提供其他解釋。
8. 撰寫結論，明確指出樣本及其限制。

請將這個模式描述為關聯：在這個樣本中，某個主題標籤與某種互動反應同時出現。這項比較未能單獨確定造成互動反應的原因。中位數較高，不能證明再次使用該主題就會改善結果。

## 選擇下一篇說明的主題

在虛構範例中，創辦人先檢視兩則「定價」貼文的來源，再決定下一篇定價說明的內容。這個做法利用小樣本中觀察到的模式，引導閱讀與規劃。它不能證明定價主題會帶來更多互動，或促成未來的追蹤人數成長。

將編碼手冊、已標記的來源、觀測紀錄、排除紀錄和最終表格一起保存。如果缺少可比較的觀測值，請先規劃接下來的觀測，再比較相同發布時長的貼文。如果內容含義仍不明確，請先改善來源審查，再擴大對主題的論斷。

如果資料收集步驟需要從已知的公開貼文網址取得快照，可使用 [X Post Metrics](https://apify.com/chronometrica/x-post-metrics)。主題判斷與最終內容決策，仍須納入你自己的審查流程。

## 來源與延伸閱讀

- [創辦人的公開提問 — 2026 年 8 月 11 日擷取；一筆提問紀錄，未估計需求](https://www.reddit.com/r/SideProject/comments/1rpwva4/how_do_founders_analyze_other_twitterx_accounts/)
- [X Post Metrics 公開建置版本 1.0.4 與 README — 2026 年 10 月 25 日核對；輸入與輸出有文件說明，未進行實際執行測試](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)
- [X Campaign Post Metrics Task — 2026 年 10 月 25 日核對；僅確認公開頁面存在，未驗證保存設定，未執行](https://apify.com/chronometrica/x-post-metrics/examples/x-campaign-post-metrics)