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

若要統計自己每天在 X 發布多少則回覆，請先準備經過核對的自有貼文紀錄。選定一個報表時區。依當地日曆日期計算，每個不同的回覆 ID 只計一次。只有在紀錄涵蓋完整一天，且確認沒有回覆時，才填入零。資料涵蓋缺漏必須另行標示。確認每日表格可用之前，請檢查午夜前後，以及日光節約時間變更時的紀錄。

這個方法計算的是你寫的回覆。貼文上的回覆計數器顯示該貼文收到多少則回覆，並不代表你自己發布回覆的活動量。

你將建立每日表格、記錄時間問題，並確認重複匯入不會改變計數。你可以視需要蒐集公開貼文，但這無法證明已儲存的帳戶紀錄包含每一則回覆。

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

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

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

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

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

公開搜尋回答的是另一個問題：搜尋傳回了哪些符合條件的貼文？如果你也使用搜尋，可透過 [X 關鍵字與日期搜尋指南](/zh-Hant/articles/%E6%8C%89%E9%97%9C%E9%8D%B5%E5%AD%97%E5%8F%8A%E6%97%A5%E6%9C%9F%E6%90%9C%E5%B0%8B-x-%E5%B8%96%E6%96%87/)檢查搜尋的時間範圍。請將搜尋結果與證明自有帳戶紀錄涵蓋完整一天的證據分開處理。

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

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

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

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

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

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

| 每日資料欄位 | 應保存的內容 |
| --- | --- |
| `account_id` | 已核對的帳戶身分 |
| `date` | 報表時區的日曆日期 |
| `reporting_zone` | 選定的 IANA 時區名稱 |
| `coverage_state` | 資料涵蓋狀態：已核實涵蓋全日、部分涵蓋、缺漏或不確定 |
| `known_reply_count` | 歸入此日期、符合條件且不重複的回覆 ID 數 |
| `unresolved_count` | 可能影響此日期的已知待釐清候選紀錄數；僅在數量可確定時填寫 |
| `source_reference` | 支持此列資料的已儲存檔案及紀錄 |

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

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

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

## 3. 每個回覆 ID 只計一次

多次匯入可能帶入同一則回覆的重複副本。每個穩定的回覆 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 日核對；支援時區轉換及重複小時的處理](https://docs.python.org/3/library/zoneinfo.html)。

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

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

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

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

請採用下列規則：

| 來源狀況 | 每日結果 |
| --- | --- |
| 已核實涵蓋全日，且沒有回覆或待釐清的候選紀錄 | 確切總數為 0 則回覆 |
| 已核實涵蓋全日，所有符合條件的回覆都已確定日期，且沒有待釐清的候選紀錄 | 確切總數等於不重複的回覆數 |
| 有部分有效回覆，但資料涵蓋不完整或不確定 | 列出已知回覆數；無法提供完整總數 |
| 缺少所需範圍的來源資料 | 無法提供計數；不可用 0 代替 |
| 有待釐清的候選紀錄可能影響該日期 | 列出已知回覆數，並明確註明不確定之處 |

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

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

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

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

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

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

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

| 回覆 ID | 來源 UTC 時間戳記 | 多倫多時間戳記 | 歸屬日期 |
| --- | --- | --- | --- |
| R1 | `2026-10-25T03:59:00+00:00` | `2026-10-24T23:59:00-04:00` | 2026-10-24 |
| R2 | `2026-10-25T04:01:00+00:00` | `2026-10-25T00:01:00-04:00` | 2026-10-25 |
| D1 | `2026-11-01T05:30:00+00:00` | `2026-11-01T01:30:00-04:00` | 2026-11-01 |
| D2 | `2026-11-01T06:30:00+00:00` | `2026-11-01T01:30:00-05:00` | 2026-11-01 |

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 日則有資料涵蓋缺漏。範例提供的時間轉換，不能證明其他日期的資料涵蓋全日。

| 日期 | 資料涵蓋狀態 | 已知回覆數 | 完整的每日總數 |
| --- | --- | --- | --- |
| 2026-10-24 | 尚未確定涵蓋全日 | 1 | 無法提供 |
| 2026-10-25 | 尚未確定涵蓋全日 | 1 | 無法提供 |
| 2026-10-26 | 已核對完整來源；沒有回覆 | 0 | 0 |
| 2026-10-27 | 缺漏 | 無法提供 | 無法提供 |
| 2026-10-28 | 尚未確定 | 無法提供 | 無法提供 |
| 2026-10-29 | 尚未確定 | 無法提供 | 無法提供 |
| 2026-10-30 | 尚未確定 | 無法提供 | 無法提供 |
| 2026-10-31 | 尚未確定 | 無法提供 | 無法提供 |
| 2026-11-01 | 尚未確定涵蓋全日 | 2 | 無法提供 |

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

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

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

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

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

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

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

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

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

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

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

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

如果要將傳回的計數器與自有帳戶報表比較，請使用 [X 公開計數器與自有帳戶匯出資料指南](/zh-Hant/articles/%E6%A0%B8%E5%B0%8D-x-%E5%85%AC%E9%96%8B%E8%A8%88%E6%95%B8%E5%80%BC%E8%88%87%E8%87%AA%E6%9C%89%E5%88%86%E6%9E%90%E5%8C%AF%E5%87%BA%E8%B3%87%E6%96%99/)。這種比較需要的檢查，與依發布日期統計自己回覆數的檢查不同。

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

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

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

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

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

## 選擇下一步

先選一段可用已儲存的自有帳戶紀錄核對的期間。選定報表時區，為每個日期建立一列，並通過身分、時間、資料涵蓋範圍及重複匯入檢查。只有在檢查結果足以支持時，才列出完整的每日總數。其他情況則列出已知回覆數及尚未釐清的部分。

如果你只需要自己的每日回覆數，完成這些表格即可。如果你還需要查核特定已知貼文目前的公開資訊，可查看 [X Post Metrics Actor](https://apify.com/chronometrica/x-post-metrics)。請替換範例輸入，並將公開觀測資料與自有帳戶的活動紀錄分開保存。

## 來源與延伸閱讀

- [X 說明中心：下載封存檔——於 2026 年 10 月 25 日核對；提供自有帳戶封存檔的取得途徑，但不保證已刪除貼文的歷史完整，也不保證固定的回覆資料結構](https://help.x.com/en/managing-your-account/how-to-download-your-x-archive)
- [Python zoneinfo 文件——於 2026 年 10 月 25 日核對；支援 IANA 時區及重複小時的處理；虛構範例中的時間轉換不是帳戶觀測資料](https://docs.python.org/3/library/zoneinfo.html)
- [X Post Metrics Actor 及公開建置版本 1.0.4——於 2026 年 10 月 25 日核對；僅有文件記載的已知網址輸入與輸出規格；未測試實際執行或歷史資料完整性](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)