# 如何用已保存的记录统计自己每天在 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-Hans/articles/%E6%8C%89%E5%85%B3%E9%94%AE%E8%AF%8D%E5%92%8C%E6%97%A5%E6%9C%9F%E6%90%9C%E7%B4%A2-x-%E5%B8%96%E5%AD%90/)，检查搜索的时间范围。请将搜索结果与证明本人账号记录覆盖全天的证据分开。

## 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 帖子 URL。它不执行搜索，也不返回本人账号存档。

提供的简短输入示例如下：

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

7. 仅在有其他需求时使用公开帖子指标

将示例 URL 替换为你打算检查的已知公开帖子 URL。所提供的输入已通过格式检查，但没有实际运行。格式检查不能证明该帖子可用。

文档列出的输出包括 `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-Hans/articles/%E6%A0%B8%E5%AF%B9-x-%E5%85%AC%E5%BC%80%E8%AE%A1%E6%95%B0%E4%B8%8E%E8%87%AA%E6%9C%89%E5%88%86%E6%9E%90%E5%AF%BC%E5%87%BA%E6%95%B0%E6%8D%AE/)。这种比较所需的检查，与按发布日期统计自己回复数所需的检查不同。

## 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 日；仅涉及文档说明的已知 URL 输入和输出；未进行实际运行或完整历史记录测试](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)