如何用已儲存紀錄統計自己每天在 X 發布的回覆數

1. 先準備經過核對的自有回覆紀錄

請使用已核對作者及貼文類型的紀錄。自己發布的回覆，是指由你的帳戶發布的回應。貼文 ID 是用來識別貼文的值。每筆紀錄都應保留這個 ID。

如果你還沒有自有帳戶紀錄，X 的說明文件提供了申請帳戶封存檔的方法。封存檔是下載到本機的帳戶資訊副本。X 說明其中包含可供機器讀取的 HTML 和 JSON 檔案，內容包括貼文。這些是軟體可以讀取的結構化檔案格式。這份文件不保證提供已刪除貼文的完整歷史，也不保證提供一組固定欄位來識別回覆。請參閱 X 封存檔指南——於 2026 年 10 月 25 日核對；提供帳戶資料下載方法，不能證明已刪除貼文的歷史完整無缺。

使用這個方法之前，請先取得並核對這些紀錄。保留一份未經修改的來源副本。記錄來源涵蓋的期間，以及尚未確定的部分。檔案含有部分回覆，本身並不足以證明資料涵蓋完整。

本指南從完成作者及回覆類型檢查之後開始說明。不涵蓋如何取得封存檔，也不完整說明如何區分原創貼文、回覆及引用貼文。

公開搜尋回答的是另一個問題：搜尋傳回了哪些符合條件的貼文？如果你也使用搜尋，可透過 X 關鍵字與日期搜尋指南檢查搜尋的時間範圍。請將搜尋結果與證明自有帳戶紀錄涵蓋完整一天的證據分開處理。

2. 定義帳戶、日期及報表時區

開始計數前，先撰寫一份簡短的報表說明：

1. 明確指出要統計哪個帳戶的回覆。
2. 註明要求統計的起始及結束日曆日期。
3. 選定一個具名的報表時區。
4. 列明來源檔案，以及已核實的資料涵蓋範圍。
5. 註明哪些紀錄仍待釐清。

請使用 `America/Toronto` 這類時區名稱。這是 IANA 時區名稱。IANA 名稱所識別的時區，其時鐘規則可能隨日期而變。固定時差，例如比 UTC 慢四小時，不能取代這些規則。

加入計數之前，先為要求統計的每個日期建立一列。這樣可避免沒有匯入紀錄的日期從報表中消失。

可使用下列建議欄位。這些是你為報表建立的欄位，並非 X 保證提供的封存檔欄位名稱。

符合條件的回覆，是指通過作者、回覆類型、穩定 ID 及可用發布時間檢查的紀錄。

請在報表說明中定義資料涵蓋狀態標籤。涵蓋全日，表示你已核對來源涵蓋當地完整的一個日曆日。部分涵蓋，表示你知道紀錄只涵蓋當天的一部分。涵蓋缺漏，表示缺少所需的來源。涵蓋範圍不確定，表示你無法確定資料涵蓋到什麼程度。

不要只因為沒有例外清單，就在 `unresolved_count` 填入零。必須完成檢查，且沒有發現待釐清的候選紀錄，才能填零。資料涵蓋缺漏時，可能還有你不知道的紀錄。

3. 每個回覆 ID 只計一次

多次匯入可能帶入同一則回覆的重複副本。每個穩定的回覆 ID 只計一次。其餘副本應保留作為匯入證據，但不納入活動計數。

不要因為文字或時鐘顯示的時間相同，就刪除紀錄。兩則不同的回覆可以使用相同文字，也可以顯示相同時間。

除了每日表格，也保留一份小型的逐則回覆表格：

時間戳記是表示日期及時間的值。時間點則是時間軸上一個確切的時刻。如果時間戳記缺少足夠的時區資訊，就可能無法確定它代表哪個時間點。

如果同一個 ID 的各份副本含有互相矛盾的資訊，請清楚保留這項衝突。不要只為了完成表格，就選一個方便的日期。受影響的計數應暫留待審查，直到來源足以支持判定。

原創貼文不納入這項回覆計數。收到回覆的計數器也不納入。整份報表都以一個不重複的自有回覆 ID 為計數單位，不是人數、收到的回覆數或匯入的資料列數。

4. 先轉換發布時間，再指定日期

請使用回覆的發布時間。不要使用下載封存檔或蒐集公開紀錄的日期。

保留原始時間值，再用已證實的時區資訊確定來源時間點。將該時間點轉換成報表時區。完成轉換後，才取得日曆日期。

UTC 是協調世界時，是記錄時間點時常用的基準。UTC 偏移量表示當地時鐘比 UTC 快或慢多少。例如，`-04:00` 表示比 UTC 慢四小時。

請依下列順序處理：

1. 讀取原始發布時間。
2. 確認其時區或偏移量足以確定時間點。
3. 將該時間點轉換成指定名稱的報表時區。
4. 儲存當地時間戳記及其偏移量。
5. 指定其所屬的當地日曆日期。
6. 保留所有這些值，以供審查。

如果缺少時區或偏移量，時間就必須保留為待釐清，除非其他已核對的來源證據足以確定時間點。不要只因為軟體函式庫接受某個時間值，就假定它是 UTC。

Python 的 `zoneinfo` 支援 IANA 時區及 UTC 偏移量變更，也支援時鐘往回調時重複出現的小時。請參閱 Python zoneinfo 文件——於 2026 年 10 月 25 日核對；支援時區轉換及重複小時的處理。

請測試當地午夜前後的紀錄。它們的 UTC 日期可能相同，但報表日期不同。這項檢查可找出每日計數錯移一天的問題。

也請測試日光節約時間變更時重複出現的小時。日光節約時間是隨季節調整當地時鐘的制度。時鐘往回調時，同一個當地時間讀數可能出現兩次。不同的偏移量可以區分這兩個時間點。不要只因為時鐘顯示的文字相同，就合併它們的回覆 ID。

5. 將已知計數與完整的每日總數分開

完成時間檢查後，將符合條件的回覆 ID 依其歸屬的當地日期分組。計算每組不重複的 ID 數，再進行資料涵蓋範圍及例外檢查。

請採用下列規則：

已知計數告訴讀者，經過核對的紀錄能確定多少則回覆。完整總數還需要已核實的資料涵蓋範圍，且不能有任何可能改變總數的待釐清紀錄。

例如，兩則已確定日期的回覆，可以證實有兩則已知回覆。但如果還有另一筆可能是回覆的紀錄，其時間尚待釐清，就無法確定當天的確切總數。

不要將一筆待釐清的候選紀錄加上兩則已知回覆，就報告共有三則回覆。候選紀錄仍需判定。請分別列出兩則已知回覆及一筆待釐清的候選紀錄。

6. 計算範例：午夜、重複小時及資料缺漏日

這是原創虛構範例，未匯入任何帳戶資料。範例中的四筆時間轉換已在本機用 Python `zoneinfo` 核對。這些是教學用紀錄，不是 X 帳戶觀測資料，也不是 Actor 執行結果。

報表時區為 `America/Toronto`。要求統計的期間為 2026 年 10 月 24 日至 11 月 1 日。

這份虛構檔案包含六筆匯入紀錄：四則不同的回覆、回覆 R1 的另一份副本，以及原創貼文 O1。

R1 與 R2 相隔兩分鐘，UTC 日期都是 10 月 25 日。在多倫多，R1 屬於 10 月 24 日，R2 則屬於 10 月 25 日。若依 UTC 日期分組，就會將 R1 放到錯誤的報表日期。

D1 與 D2 在多倫多都顯示為 01:30，但偏移量不同。它們是兩個不同的時間點，也有兩個不同的回覆 ID，兩者都屬於 11 月 1 日。若因時鐘顯示的文字相同就刪掉其中一筆，會少算一則回覆。

匯入後的計算如下：

• 6 筆匯入紀錄減去 1 份重複副本 = 5 個不重複的貼文 ID。
• 5 個不重複的貼文 ID 減去 1 則排除的原創貼文 = 4 個符合條件且已確定日期的回覆 ID。
• 10 月 24 日的 1 則回覆 + 10 月 25 日的 1 則回覆 + 11 月 1 日的 2 則回覆 = 4 則符合條件且已確定日期的回覆。

另一份經過單獨核對、完整涵蓋 10 月 26 日的來源沒有任何回覆。10 月 27 日則有資料涵蓋缺漏。範例提供的時間轉換，不能證明其他日期的資料涵蓋全日。

標示「無法提供」的儲存格不代表零。已知的數值計數合計為四則回覆，其中包括 10 月 26 日經過核實的零。這不能證明整個要求期間的完整總數。

現在另外延伸這個原創虛構範例。另一筆候選紀錄只寫了 11 月 1 日 01:30，沒有經證實的偏移量。它不在原本的六筆紀錄檔案中。請將其時間保留為待釐清。如果它可能影響 11 月 1 日，請顯示兩則已知回覆及一筆待釐清的候選紀錄。不要猜測它指的是兩次重複小時中的哪一次。

最後，再次匯入原本的六筆紀錄檔案。結果仍必須只有四個符合條件的回覆 ID。各歸屬日期的已知每日計數必須維持為 1、1 及 2。第二次匯入不得讓計數加倍。

7. 僅在另有需求時使用公開貼文指標

這項計算不需要蒐集公開指標。經過核對的自有帳戶紀錄，便可提供自己發布的回覆。

Actor 是在託管環境中執行的資料蒐集程式。X Post Metrics Actor——公開規格於 2026 年 10 月 25 日核對；提供已知貼文的狀態快照，不是自有帳戶封存檔可透過 `startUrls` 接收 1 至 1,000 個已知的公開 X 或 Twitter 貼文網址。它不執行搜尋，也不傳回自有帳戶封存檔。

提供的簡短輸入範例如下：

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

請將範例網址替換成你打算查核的已知公開貼文網址。提供的輸入已通過格式檢查，但未實際執行。格式檢查不能證明該貼文可供存取。

文件列出的輸出包含 `postId`、`profileId`、`postType`、`publishedAt`、`replies` 及 `observedAt`。`publishedAt` 是發布時間。`observedAt` 是觀測公開資料的時間。`replies` 的值是收到回覆的計數，因此不得納入自己發布的回覆數。

文件列出的輸出不包含上一層貼文或被引用貼文的 ID，也無法證明活動清單完整。公開文件也說明，若輸入的是轉發貼文，輸出描述的是可見的原始貼文。請區分 `inputUrl` 與 `postUrl`：前者是請求的網址，後者是傳回的貼文網址。不要將傳回的原始貼文算成自己另一次發布活動。這些是文件記載的規則，不是為本文實際執行所得的結果。請參閱 X Post Metrics 建置版本 1.0.4——於 2026 年 10 月 25 日核對；僅涉及公開輸入與輸出規格。

如果要將傳回的計數器與自有帳戶報表比較，請使用 X 公開計數器與自有帳戶匯出資料指南。這種比較需要的檢查，與依發布日期統計自己回覆數的檢查不同。

8. 通過這些檢查後，才確認每日表格可用

使用報表之前，請完成下列檢查：

1. 確認要求統計的每個日曆日期都有一列。
2. 確認每個符合條件的回覆 ID 都恰好計入一天。
3. 確認重複副本不會增加任何計數。
4. 確認已排除原創貼文及收到回覆的計數器。
5. 確認當地午夜及重複小時範例都歸入正確日期。
6. 確認已知每日計數的總和，等於要求期間內符合條件且已確定日期的回覆 ID 數。
7. 確認所有零值都有涵蓋全日的資料證據。
8. 確認資料涵蓋缺漏的日期仍標示為無法提供計數。
9. 確認受影響日期旁仍清楚列出待釐清的候選紀錄。
10. 確認再次匯入同一檔案不會改變任何計數。

總和檢查用來確認已知回覆的日期歸屬與計數是否一致，不能證明來源包含每一則回覆。重複匯入檢查用來確認重複副本是否會改變結果，不能解決時間戳記缺漏的問題。

交付每日表格時，請一併提供逐則回覆表格、來源參照、資料涵蓋範圍說明及時間戳記例外紀錄。如果某項檢查未通過，請依據證據修正紀錄，或將結果保留為待釐清。不要填入零來掩蓋檢查未通過的情況。