# 如何在内容报告中区分 X 原创帖、回复帖和引用帖

逐条核查已知帖子在公开页面中的上下文，区分 X 原创帖、回复帖和引用帖。每条不同的账号发帖只保存一条记录。将每条符合纳入条件的帖子归入一个主要类别。保留被回复帖子和被引用帖子的链接作为参考。类型不确定时，保留为未确定。不要把被引用的来源帖或重复地址，另算成研究账号发布的一条帖子。

回复帖用于回应另一条帖子。引用帖在分享另一条帖子的同时添加内容。在本报告中，原创帖是指经过核查、既不是回复帖也不是引用帖的账号发帖。回复帖也可以包含引用。将这条帖子计为一条回复帖，并单独记录它是否包含引用。

先进行人工核查，并建立已知帖子登记表。登记表是一份保存帖子及其证据的列表。如果你已经获准使用账号所有者的导出数据，可以使用这些数据。公开指标采集可以辅助这项工作，但不能替代确认作者和类型所需的核查。

结果应回答买家所问的“他们的哪些推文表现最好”的一个具体问题：在各类别和观测规则下，哪些已核查帖子获得了报告所述的公开反馈？所提供的[公开提问记录](https://www.reddit.com/r/SideProject/comments/1rpwva4/how_do_founders_analyze_other_twitterx_accounts/)支持这种报告需求。它不能证明需求规模，也不能证明哪种帖子类型表现最好。

## 1. 明确账号、样本和计数单位

分类前，先写明账号列表。记录你将接受的账号标识符。标识符，也称 ID，是用于区分不同账号或帖子的值。

将样本明确定义为你准备核查的那些已知帖子。如果还按发布日期筛选，也要记录这些日期。所提供的地址列表是一个选定样本，不能证明它涵盖了账号的完整历史。

以一条不同的账号发帖为一个计数单位。单位是每个计数所代表的对象。请区分以下单位：

- 请求地址：你提交用于采集的地址。
- 不同帖子：通过这些请求找到、并已核查的帖子 ID 所代表的帖子。
- 账号发帖：作者与账号列表匹配的不同帖子。
- 已分类帖子：主要类型已经核查的账号发帖。
- 指标观测记录：在明确时间保存的计数器读数。

一条帖子可以对应多个请求地址，也可以有多条指标观测记录。这两种情况都不会增加账号发帖数。

如果需要先查找帖子再核查，应将查找视为单独的采集任务。[按关键词和日期搜索 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. 核查已知地址，并保留返回的标识信息

Actor 是一种托管的数据采集程序。[X Post Metrics Actor](https://apify.com/chronometrica/x-post-metrics)的文档说明了它适合本任务的用途：它接受已知的公开 X 或 Twitter 帖子地址，并为尝试采集的帖子返回指标快照行。快照是在某个观测时间取得的一次读数。

2026 年 10 月 25 日核查并冻结保存的公开接口约定描述的是构建版本 1.0.4。它通过 `startUrls` 接受 1 至 1,000 个地址。它不搜索帖子，也不返回账号历史归档。这些是文档所述的能力，并非为本指南实际运行所得的结果。参见[已核查的公开构建接口约定](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)。

计划首次核查时，可以使用以下小型输入结构：

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

2. 核查已知地址，并保留返回的标识信息

将示例地址替换为你声明的样本中的一条已知公开帖子地址。所提供的输入在结构上有效。本指南没有使用该输入实际运行。添加更多已知地址前，先检查返回的第一行。

Task 是为 Actor 保存的输入预设。核查时，公开的 [X Campaign Post Metrics Task](https://apify.com/chronometrica/x-post-metrics/examples/x-campaign-post-metrics) 页面存在。未通过已认证账号读取其保存的设置，也未运行该 Task。使用前，请检查其输入。

将请求地址 `inputUrl` 与返回的帖子地址 `postUrl` 分开保存。同时保存返回的帖子 ID `postId` 和返回的作者账号 ID `profileId`。

对于转帖地址，这一区分很重要。当前公开 README 说明，转帖输入对应的输出行描述的是可见的原始帖子。返回的标识信息、作者、正文和指标都属于该原始帖子。保留请求与返回帖子之间的对应关系。不要把该请求另算成转帖账号发布的一条原创帖。[公开构建和 README 证据](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)记录了这一行为。

## 3. 保存对应关系、帖子登记表和指标观测记录

不同单位使用不同的表。台账是记录判断及其支持证据的已保存表格。以下字段名用于建议读者建立的台账；只有反引号中的确切 Actor 字段名属于 Actor 字段。

首先，为每次尝试提交的输入保存一条请求对应记录。

| 保存字段 | 用途 |
| --- | --- |
| 请求编号 | 区分每个提交的地址 |
| `inputUrl` | 保留请求地址 |
| `postUrl` 和 `postId` | 记录返回的帖子标识信息 |
| `profileId` | 记录返回的作者标识信息 |
| `status` 和 `statusReason` | 保留返回行的结果及原因 |
| `observedAt` | 记录该行的观测时间 |
| 对应关系判断 | 说明标识信息已经核查还是仍未确定 |

接着，为每个已核查的不同帖子 ID 建立一条帖子登记记录。

| 保存字段 | 用途 |
| --- | --- |
| 已核查的帖子 ID | 确保一条帖子只作为一个单位 |
| 作者及其与账号列表的匹配情况 | 说明该作者是否属于报告范围 |
| `postType` | 原样保留文档所述的类型线索 |
| 主要类别 | 记录经核查作出的原创帖、回复帖、引用帖或未确定判断 |
| 是否包含引用 | 记录已核查为是、已核查为否或未知 |
| 被回复的来源帖链接 | 按需保留人工核查过的回复关系 |
| 被引用的来源帖链接 | 按需保留人工核查过的引用关系 |
| 类型证据及理由 | 解释判断及任何不确定之处 |
| `publishedAt` | 保留返回的发布时间 |
| 纳入资格判断 | 说明该帖子是否纳入分类报告 |

线索是有助于作出判断的证据。将原生 `postType` 字段视为文档所述的一项线索。如果分类判断需要作出仅凭该行无法确定的区分，就核查公开上下文。

此台账中的被回复来源帖链接和被引用来源帖链接，是读者自行添加的证据。Actor 的接口约定不导出被回复或被引用帖子的 ID。不要把人工添加的字段说成 Actor 的原生输出。

最后，单独保存指标观测记录。保留帖子 ID、指标名称、数值、`observedAt`、发布时间、指标状态、精确度和来源。精确度说明数值有多精确。将重复读取的数值保留为同一帖子的多次观测。

这些字段属于文档所述的输出字段。文档列出这些字段，并不能证明每次尝试返回的行都会包含可用值。这一区别应以[已核查的输出约定](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)为准。

## 4. 采用一套主要类别判定规则

汇总各类别前，先写明规则。本报告采用以下顺序：

1. 确认帖子 ID 和作者均已经核查。
2. 确认作者与声明的账号列表匹配。
3. 如果已经核查为回复帖，就将其主要类别设为回复帖。
4. 否则，如果已经核查为引用帖，就归为引用帖。
5. 否则，只有在公开上下文支持这一判断时，才归为原创帖。
6. 类型不确定时，保留为未确定。

这条规则使各类别互斥。也就是说，一条符合纳入条件的帖子只能归入一个主要类别。

对于包含引用的回复帖，将其归为回复帖，并将“是否包含引用”保留为“是”。如果分析需要，保存两种参考链接。不要在引用帖类别中再次计数。

将参考来源的记录与账号发帖的计数分开。被引用的来源帖有助于解释作者分享了什么，但不会因此成为该账号发布的另一条帖子。如果该来源帖本身也在你声明的样本中，就为它建立单独的已核查记录，并按通常的作者归属规则处理。

关系字段缺失，不能证明关系不存在。尤其是，缺少原生的被回复或被引用帖子 ID，是此输出约定的限制。这不能证明该帖没有被回复的来源帖或被引用的来源帖。

如果两次观测对类型的判断不一致，保留两份证据。通过核查公开上下文解决冲突，或将类型保留为未确定。不要选择能得出偏好结果的类别。

## 5. 计算前，先明确反馈比较方法

选择一个指标，并明确观测规则。指标是测量得到的数量，例如公开浏览次数或点赞数。没有单独定义时，不要将不同计数器的数值相加。

将帖子发布时的类型与收到的反馈分开。引用帖可以收到回复、转帖和引用。这些收到的互动计数描述的是对该条帖子的反馈。它们不会改变该帖的发布类型，也不会在登记表中增加帖子。

比较观测值时，记录帖子发布后经过的时长。这是从发布到读取指标之间的时间。发布后不久读取的计数器与很久之后读取的计数器，覆盖的时长不同。如果发布时间缺失，这一时长就是未知。不要用 `observedAt` 代替 `publishedAt`。

Actor 文档说明，`postMetricStatus` 条目包含指标、状态、精确度和来源。状态可以是 `present`、`unavailable` 或 `not_attempted`。精确度可以是 `exact`、`unavailable` 或 `unknown`。对每个使用的指标，都保留这些值。不要因为一个指标可用，就认定全部六个指标都可用。

提前写明质量规则。例如，报告可以要求数值存在、精确度为精确，且来源明确。这是建议读者采用的规则，并不表示某次运行已经满足该规则。

缺失值应保留为缺失。返回的零是一个测量数值。不要为了填满表格而将缺失的计数替换为零。一条帖子的类别可以已经核查，但它仍可能不符合指标行的纳入条件。

对每个类别，列出已分类帖子数和符合纳入条件的指标记录数。总值只包含符合纳入条件的观测值。如果展示均值，就用总值除以该指标对应的符合纳入条件的帖子数。均值就是总值除以纳入的帖子数。当帖子数为零时，均值无定义。

公开读数与仅账号所有者可见的报告数值，可能采用不同的定义和时间范围。如果你已经持有获准使用的导出数据，将其作为单独来源保存。在把两者视为等同之前，请参阅[公开计数器与账号所有者导出数据对比指南](/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/)。

## 6. 逐步分析一个标明为原创虚构的示例

原创虚构示例。本例中的所有标签和计数均为虚构。它们不是 Actor 结果、Task 结果，也不是真实的帖子 ID。

提供的六个地址解析为五条不同的帖子。其中两个地址解析为 P1，其余四个分别解析为 P2、P3、P4 和 U1。

| 虚构请求 | 解析得到的虚构帖子 |
| --- | --- |
| R1 | P1 |
| R2 | P1 |
| R3 | P2 |
| R4 | P3 |
| R5 | P4 |
| R6 | U1 |

示例中，经核查的分类如下：

| 虚构帖子 | 主要类别 | 是否包含引用 | 虚构浏览次数 |
| --- | --- | --- | --- |
| P1 | 原创帖 | 示例中未说明 | 100 |
| P2 | 回复帖 | 示例中未说明 | 40 |
| P3 | 引用帖 | 是，由已核查的引用帖类别确认 | 200 |
| P4 | 回复帖 | 是 | 60 |
| U1 | 未确定 | 未知 | 缺失 |

“未说明”不等于已经核查为否。真实台账必须保留每项判断的依据。本例中的 U1 没有可用的浏览次数。它的缺失值不是零。

帖子数量的计算如下：

- 6 个请求地址解析为 5 条不同帖子。
- 5 条不同帖子包括 4 条符合纳入条件的已分类帖子，以及 1 条类型未确定的帖子。
- 4 条符合纳入条件的已分类帖子包括 1 条原创帖、2 条回复帖和 1 条引用帖。

虽然 P1 对应两次请求，但在帖子数中只计一次。P4 在回复帖数中只计一次。它的引用标记仍然保留，但不会因此增加第二条分类记录。

根据本例明确给出的前提，虚构反馈表使用的是条件相匹配的浏览观测值。示例没有提供实际的发布时间或观测时间戳。真实报告必须保存这些时间，并核实观测条件是否匹配。

| 主要类别 | 符合纳入条件的帖子数 | 浏览次数计算 | 浏览事件总数 | 每条符合纳入条件帖子的平均浏览事件数 |
| --- | --- | --- | --- | --- |
| 原创帖 | 1 | 100 | 100 | 100 / 1 = 100 |
| 回复帖 | 2 | 40 + 60 | 100 | 100 / 2 = 50 |
| 引用帖 | 1 | 200 | 200 | 200 / 1 = 200 |

全部符合纳入条件的数值合计为 100 + 40 + 200 + 60 = 400 次虚构浏览事件，涉及四条帖子。按类别汇总也得到 100 + 100 + 200 = 400 次浏览事件。

这些是来源计数器记录的事件数，不是去重人数。在这个虚构样本中，引用帖类别的总值和均值最高。这不能说明引用行为带来了更多反馈，也不能确立普遍适用的类别排名。三个类别分别只有一条、两条和一条帖子。

不要将 U1 纳入类别均值。不要给它赋予零浏览次数。在表格旁保留说明：有一条类型未确定、指标缺失的帖子。

## 7. 核查计数，并明确展示未成功确定的状态

分享报告前，完成以下验收检查：

1. 将每个请求地址追溯到已保存的结果。保留标识信息未确定的请求，使其可见。
2. 通过稳定的帖子 ID 核查不同帖子。不要将重复观测计为额外帖子。
3. 将作者与声明的账号列表匹配。不要将作者未知的帖子纳入已确认的账号发帖精确计数。
4. 检查每条符合纳入条件的已分类帖子是否恰好归入一个主要类别。
5. 确认包含引用的回复帖在主要类别汇总中只出现一次。
6. 将每个纳入的指标值追溯到其观测时间、状态、精确度和来源。
7. 根据纳入的帖子行重新计算各类别总值。
8. 在结果旁说明未确定和已排除的数量。

对不同问题保留不同状态。帖子 ID 缺失时，无法精确统计不同帖子数。作者未知时，无法确认其与账号列表匹配。作者已知但不在账号列表中，属于排除情况，不属于作者未知。类型未确定可能使帖子无法纳入分类，但帖子标识信息仍然可以是已知的。

指标缺失是另一种状态。它不会使已核查帖子消失，也不会使其变成分类失败。即使所有帖子的标识信息和类型均已知，发布后经过的时长不同，仍会限制反馈比较。

交付请求对应表、已核查帖子登记表、指标观测记录、书面分类规则，以及明确适用范围的表现表。说明每个计数包含什么。说明样本来自公开核查、获准使用的账号所有者记录，还是两者都有。

后续问题需要单独的方法。统计账号每天发布的回复帖，需要发布日期和报告时区。比较主题需要内容标签。这两项任务都不能直接从类别汇总中得到结果。同样，[关键词共现分析](/zh-Hans/articles/%E7%BB%99%E5%AE%9Ax%E5%B8%96%E5%AD%90%E6%A0%B7%E6%9C%AC%E7%9A%84%E5%85%B3%E9%94%AE%E8%AF%8D%E5%85%B1%E7%8E%B0%E5%88%86%E6%9E%90/)统计的是帖子中的词语，不能确定回复或引用关系。

## 下一步

对照账号列表和公开上下文，核查一条已知帖子。保存请求地址、返回的标识信息、主要类别、参考链接和未确定的字段。然后核查一个重复地址，或一条包含引用的回复帖。确认你的规则仍然只生成一条账号发帖记录。

使用 [X Post Metrics Actor](https://apify.com/chronometrica/x-post-metrics)，为已知地址采集文档所述的公开标识信息和指标字段。计划运行前，先替换示例输入。只有当你能将每条分类记录追溯到一条已核查的帖子，并将每个报告数值追溯到一条符合纳入条件的观测记录时，才扩大采集范围。

## 来源和延伸阅读

- [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 日核查；仅确认公开页面存在；未通过身份认证读取已保存设置，也未运行 Task](https://apify.com/chronometrica/x-post-metrics/examples/x-campaign-post-metrics)
- [创业者如何分析其他 Twitter/X 账号？——2026 年 8 月 11 日获取；仅为一条公开提问记录，不是需求或规模估计](https://www.reddit.com/r/SideProject/comments/1rpwva4/how_do_founders_analyze_other_twitterx_accounts/)