如何用已保存的记录统计自己每天在 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 帖子 URL。它不执行搜索，也不返回本人账号存档。

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

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

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

文档列出的输出包括 `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. 确认再次导入同一文件不会改变任何计数。

求和检查用于检验已确认回复的日期归属和计数是否一致，不能证明来源包含每一条回复。重复导入检查用于检验重复副本是否会改变结果，不能解决时间戳缺失的问题。

交付每日统计表时，应同时提供逐条回复表、来源引用、记录覆盖说明和时间戳异常记录。如果某项检查未通过，应依据证据修正记录，或将结果保留为未解决状态。不要用填零的方式掩盖检查失败。