Chronometrica 与 Tweet Scraper V2：哪款适合采集1条已知的 X 帖子？

账单问题说明了什么

Apify Store 中1个已关闭的历史问题记录了一位买家的疑问：他只有1个已知帖子的 URL，却遇到了被描述为每1,000条结果收费 $0.40 的费用。这个金额来自过去的问题。它不能确定当前价格，不能解释完整账单，也不能证明换用其他产品会花多少钱。这个问题不能作为当前服务故障的证据。历史买家问题

再次运行之前，应该先问：所选产品是否支持你要提交的具体任务？

提供1个 URL，意味着要查询一条已知帖子。你已经知道需要哪条帖子。你希望在明确的时间点观测它的文本和公开计数。你不需要采集工具寻找一组符合条件的帖子。

查找帖子是另一种任务。你提供主题、个人资料或列表，是因为需要找到帖子。这类任务可能需要不同的输入、限制和计费单位。适合查找帖子的产品，不一定适合单个已知 URL。

Actor 是在 Apify 上托管运行的采集程序。运行之前，应分别检查3件事：它支持的用途、输入字段和当前计费条款。输入字段有效，只能回答其中1个问题。

本文无法根据保存的问题计算当时的账单。但它可以帮助你选择支持该任务的采集工具，并在使用结果前进行检查。

先比较产品支持的任务

用下表选择方案。付费之前，再查看当前产品页面。

来源：Chronometrica、V2、Unlimited。

不要仅凭 `startUrls` 这个字段名选择产品。JSON 输入结构定义了允许使用的字段名、类型和值。它不能替代产品的用途规则。数组能够容纳 URL，本身并不能证明产品支持所有类型的 URL。

表格比较的是文档所示的适用性。它没有对速度、准确性、可靠性、覆盖范围或实测费用进行排名。本文提供的证据不足以支持这些排名。

Chronometrica 能为这一需求提供什么

Chronometrica 接受包含1至1,000个公开 X 或 Twitter 状态 URL 的 `startUrls` 列表。其文档规定的输出保留1条输入采集尝试的快照记录，包括可获取的文本、可获取的公开计数、结果状态和观测时间。缺失的计数保持缺失。输入和输出规范

输入采集尝试的快照，是对所提供帖子进行观测尝试的记录。它不代表每次尝试都一定能返回完整的文本和计数。

这一区别使输出适合用于检查已知帖子。你既需要知道采集工具观测到了什么，也需要知道这些观测是否能满足预期用途。计数如果没有附带可用状态，可能会让人误以为结果十分确定。

例如，一份报告可能需要帖子文本和1项公开计数。如果文本可用，但计数缺失，文本仍可能满足其用途。报告中的数值部分则仍不完整。分别作出这2项判断，可以避免把部分结果写成看似完整的报告。

文档列明的列表上限也很重要。如果你需要在1次运行中提供超过1,000个 URL，这个 Actor 就不符合该要求。不要把文档规定的上限描述为无限采集。更大的项目需要单独制定计划，包括检查重复 URL，以及确保观测时间一致。输入限制

在这里选择 Chronometrica 的理由很明确：它支持的输入与已知 URL 相符，而且文档规定的输出记录保留了判断此次尝试所需的状态。

围绕1条帖子的虚构选择示例

以下示例为虚构内容。它不是客户结果、Actor 测试、实时数据集或费用测量。

分析师 Maya 有1个营销活动帖子的 URL。她需要公开文本和可获取的计数，用于今天编制的报告。她不需要搜索其他活动帖子。

在选择采集工具之前，她先写下需求：“尝试采集这1条公开帖子。保留结果状态、可用字段、来源 URL 和观测时间。”

Chronometrica 文档规定的快照输出符合这一需求。Maya 也将 Unlimited 保留在候选列表中，因为它是开发者支持的单条帖子采集方案。Chronometrica、Unlimited

她的验收检查分为2部分。第1，运行是否记录了目标帖子？第2，报告所需的字段是否可用？一条记录可能通过第1项检查，却未通过第2项。如果某项必需计数不可用，Maya 会在报告中将其保留为 null，并将该部分标记为不完整。

下一周，她的需求发生了变化。她必须通过关键词查找200条帖子。她重新评估 V2，因为新任务是查找帖子。之前针对单条帖子作出的选择，不能决定这次的新选择。V2 支持的用途

这些数字只能说明有限的事情：1个已知 URL 对应1个查询请求；要查找200条帖子，则是另一种任务。这2个数字都不能预测费用、返回记录数、速度或是否成功。

大规模运行前，先做小规模验收

验收检查要确认输出能否满足你的具体报告需求。它不需要大型测试数据集。先准备目标公开 URL，以及一份简短的必需字段清单。

1. 用清楚的语言写下需求

记录准确的状态 URL。列出每个必需的公开字段。将必需字段与有用但非必需的字段分开。

例如，你的报告可能必须包含文本和观测时间，但将部分公开计数视为可选项。另一份报告则可能必须包含某项特定计数。即使使用相同的 URL，这些报告的验收条件也不同。

还应说明你需要当前观测值，还是过去的值。当前查询无法恢复帖子上个月的计数。如果需求涉及过去的值，应在选择采集工具之前明确说明。

2. 检查支持的用途和当前计费单位

阅读当前产品规则。然后查看计划运行所适用的当前价格。弄清哪些操作会产生费用，以及所列计费单位如何应用于你的输入。

不要把旧问题中的金额用于这次计算。不要假定1个 URL 总是对应1条付费结果，也不要以为熟悉的字段名能决定计费单位。如果当前条款无法解答你的疑问，应在运行前弄清楚。

价格和适用性需要分别检查。产品即使定价清楚，也可能不符合你的输入要求。即使产品支持该任务，仍需检查费用是否符合预算。

3. 检查已保存的 Task 输入

Task 是 Apify 上保存的输入预设。Chronometrica 提供了公开的 X 帖子分析快照 Task。

打开 Task，检查实际输入。公开 Task 页面只是一个起点。页面存在，并不能证明其中保存的 URL 就是你的目标。

以下最简输入符合已核查的公开输入结构定义：

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

将示例 URL 替换为你的目标公开帖子 URL。示例展示的是输入格式。它不是采集结果，也不能证明示例帖子目前仍可访问。输入结构定义允许 `startUrls` 数组包含至少1项、最多1,000项。公开输入结构定义

所提供的输入通过了已保存的公开输入结构定义校验。这项检查确认了允许使用的字段和列表格式。它不能确认实际在线采集一定会成功。

4. 使用数值前，先检查采集尝试

按计划进行小规模运行后，检查 `status`、`statusReason` 和 `postMetricStatus`。将这些状态与返回的文本和计数一起查看。核对解析后识别的帖子，确认它就是你要采集的帖子。输出文档

不要因为有1条输出记录，就认定所有必需字段都已采集。按照第1步写下的验收条件，逐项检查必需字段。

报告中不可用的值应保留为 null。不要将其改为0。0是一个数值。null 表示你没有可用的值。将 null 改为0，可能改变总计、比较结果和结论。

5. 保留来源和观测时间

为此次输入采集尝试保存1条记录。将来源 URL、解析后识别的帖子、尝试状态、指标可用性和观测时间保存在一起。

如果文档列明了 Actor 返回的字段名，就使用这些名称。如果报告系统需要其他列名，应保留清楚的映射关系。不要编造 API 字段名，并将其说成 Actor 规范的一部分。

要测量后续变化，应再次采集并检查快照。只有2次观测都包含可用值时，才能比较同一帖子中的同一字段。

将快照视为一次观测，而非完整历史

当前公开计数回答的是一个与特定时间有关的问题：本次尝试观测帖子时，能获取到什么值？它不能解释该计数是如何变化至今的。

2次经过检查的快照可以用于计算变化。如果两者都包含所需计数，就用较晚的值减去较早的值。在结果旁保留2次观测时间。这个差值描述的是2次观测之间这段时间内的变化。

如果任意1个值缺失，变化就是未知的。不要用0填补缺失值，不要在没有明确规则的情况下沿用之前的值，也不要将差值描述为实测增长。缺失的观测会影响你能得出的结论。

帖子文本也可能缺失或不完整。在引用、分类或用它识别营销活动用语之前，应先检查文本。采集工具的输出是报告的输入，因此报告仍需进行验收检查。

本比较不承诺提供存档、恢复旧指标或获取历史关键词频率。这些需求需要不同的证据。公开与非公开报告数据差异指南提供了相关报告背景。如果要分析一组已提供的帖子文本，请参阅单独的关键词共现指南。该方法回答哪些词语会共同出现，不能替你选择采集已知 URL 的工具。