已有 LinkedIn 帖子 URL：Chronometrica 与 API Maestro 对比

哪个 Actor 符合你的需求？

如果你首先想知道“我们提供的每个帖子 URL 的处理结果是什么”，Chronometrica 就适合这项需求。其文档说明，每个已尝试的输入都有记录行，因此你可以一起检查可用记录和结果未明的记录。独立的 `activityId`、`ugcPostId` 和 `postUrn` 字段保留了每种帖子标识符的类型。标识符是用来指代帖子的值。Chronometrica 文档

可用下表做初步选择。表中描述的是已核查的文档内容，并非实测性能。

产品事实来自已核查的 Chronometrica 文档和 API Maestro 文档。

如果你需要在单次运行中处理超过 1,000 项输入，API Maestro 不符合这项要求。API Maestro 输入文档

上限未知不代表容量无限。这些证据未能确定 Chronometrica 的最大输入量。运行前，请根据计划执行的任务检查实际设置。

还要明确“完整结果”的含义。逐项记录每个输入的尝试情况，与从每篇帖子中获取可用文本，是不同的要求。已核查的公开文档不能证明任何一款产品可以完整访问所有公开帖子。如果你必须从每个所提供的 URL 获取可用文本，现有证据不能证明任何一款工具符合这项要求。

为什么需要每个输入的尝试记录

内容审查需要可用的帖子文本。对于未能提供可用文本的输入，也需要说明原因。只包含已验收内容的表格无法同时满足这 2 项需求。

Chronometrica 文档列出的输出支持这种审查。用 `inputUrl` 将记录行对应到所提供的 URL。阅读 `status` 和 `statusReason`，了解报告的处理结果。保留 `observedAt`，让后续审查者知道观测发生的时间。Chronometrica 输出文档

观测时间和发布时间含义不同。发布时间表示帖子何时发布。观测时间表示采集程序何时记录帖子的状态。请在记录中区分这 2 种含义。

帖子标识也需要谨慎处理。保留 `activityId`、`ugcPostId` 和 `postUrn` 的原始字段名。不要将它们合并为一个没有标签的值，并假定它们含义相同。独立字段保留的信息，可能对后续关联记录很重要。Chronometrica 输出文档

完全相同的输入字符串只检查 1 次。同一篇帖子的不同 URL 形式可能产生独立的尝试记录。这是按字符串完全一致进行去重。它不保证会合并指向同一篇帖子的所有链接。Chronometrica 输入文档

这一区别会影响预期记录行数。请统计工作输入列表中按完整字符串去重后的数量。除非你已单独核查帖子标识，否则不要使用推测的独立帖子数量。保留原始列表，以便说明准备过程中做了哪些改动。

这些记录有助于回答一个实际问题：为什么已验收内容表中的行数少于输入列表的项数？有了已记录的处理结果，你就能说明原因，无需事后重新推查采集过程。

使用 5 步验收检查

验收检查用于判断每条采集记录是否满足你已明确的需求。在执行完整任务前，先制定规则。运行完成本身不能证明返回的记录适合你的工作。

1. 准备确切的输入列表。

保留一份原始 URL。另建一份工作列表，移除完全相同的字符串。记录这一步前后的项数。用工作列表确定预期尝试次数。

使用 Chronometrica 时，请输入公开的 `/posts/` URL。只有这种 URL 格式符合已核查的输入证据。按此方法操作时，不要改用 `/feed/update/` URL。如果多个链接似乎指向同一篇帖子，请保留这个问题供后续审查。不要假定 Actor 会将它们合并。Chronometrica 输入文档

1. 明确通过验收的记录必须包含什么。

写下下一项任务所需的字段。内容编码是指为内容分配标签，以便分析。这需要可用文本和来源 URL。逐项核对输入处理情况，还需要每次尝试的结果。后续匹配记录时，可能需要可用的、按类型区分的帖子标识符。

为你的任务定义什么是可用文本。短帖子也可能完整且有用。文本为空的记录需要先审查，再进行内容分析。不要只用文本长度作为验收规则。还要确定计数缺失是否会阻碍工作，或是否可以在缺少该计数时使用文本。

1. 用一小份列表核对返回结果。

选择少量输入，确保你能逐行检查。在检查前设定数量上限。使用所选 Actor 的实际设置。这项检查用于判断文档所述行为是否适合你的工作，不能据此确定总体成功率。

使用 Chronometrica 时，通过 `inputUrl` 将尝试记录对应到工作列表。阅读 `status` 和 `statusReason`。按验收规则检查返回的文本。这些文档列出的字段支持逐项核对输入和结果。Chronometrica 输出文档

如果输入和输出的总数不同，请查明原因。检查完全相同的字符串、URL 形式和报告的处理结果。不要编造成功或失败记录来填补原因不明的差额。

1. 区分未知计数与 0。

0 是一个已知数值。计数为 `null` 表示数值缺失。Chronometrica 文档说明，缺失的公开计数保留为 `null`。导出或计算结果时，请保留这一区别。Chronometrica 计数处理说明

不要将计数缺失描述为没有活动。如果计算平均值，请说明有多少条记录具有已知数值。不要用 0 替代缺失计数。文本为空的情况要单独审查：已知计数不能证明该记录包含分析所需的内容。

1. 导出已验收的内容，并保留被排除输入的处理结果。

建立内容表，只纳入符合规则的记录。保留来源 URL 和观测时间。将被排除输入的处理结果保存在单独的审计表中。审计表用于记录检查了什么，以及每项输入通过验收或被排除的原因。

使用以下验收列：`inputUrl`、解析后的 URL、按类型区分的帖子标识、`status`、文本是否可用、`observedAt`，以及验收通过或需复查的原因。这些是审查用列，不代表每个列名都是 Actor 的输出字段。保留未知值，不要编造解析后的 URL 或标识符。

检查已验收和被排除的处理结果，确保两者合起来涵盖工作输入列表。保留每项被排除的原因。后续审查者应当能够区分文本缺失、输入不可用和尝试失败，无需猜测。

检查前先准备输入

LinkedIn Post Text & Engagement Data Task 提供了一份起始预设。Task 是已保存的输入预设。为本次简报核查时，其公开页面返回了 HTTP 200。这说明当时页面可访问，不能验证该 Task 当前保存的输入。运行前，请检查输入，并应用当前输入模式中的设置。

输入模式用于定义允许使用的输入字段和值。以下输入通过了本地格式检查，检查依据是已保存的公开输入模式。该字段名存在于这一输入模式中。这项检查不能证明源帖子可访问。本次简报未执行采集运行。Chronometrica 输入文档

{
  "startUrls": [
    "https://www.linkedin.com/posts/timferriss_i-took-my-whole-genome-dumped-it-into-ai-activity-7333162625675038720-TJPX"
  ]
}

示例 URL 来自已保存的公开输入模式或示例。请将其替换为你计划使用的公开来源。不要将它视为新采集的结果。

已核查的输入模式要求 `startUrls` 是一个至少包含 1 项的数组。数组是一组值的列表。这项最低要求不能确定最大输入量。首次检查时使用小规模工作列表，然后将返回记录与保留的列表逐项核对。Chronometrica 输入模式

即使预设名称符合你的任务，也要检查预设。页面检查和输入格式检查回答的是不同问题。前者检查公开页面，后者检查允许的输入结构。两者都不能替代采集后的逐行验收检查。

一个涉及 12 个 URL 的虚构选择示例

以下示例为虚构内容。它不是 Actor 测试、客户结果、买家引述或实测成本对比。

一名研究人员有 12 个完整字符串各不相同的 URL。任务需要帖子文本用于内容编码，还需要记录每个输入的尝试情况。这项需求符合 Chronometrica 文档所述的逐项记录输入处理情况的优势。

在这次虚构检查中，9 条记录包含可用文本。2 条记录说明输入不可用。1 条记录说明尝试失败。研究人员保留了全部 12 条输入尝试记录，但只将 9 条可用记录纳入内容编码。

计算如下：

• 9 条可用记录 + 2 条输入不可用记录 + 1 条尝试失败记录 = 12 个已尝试的输入。
• 9 ÷ 12 = 75%，即这次虚构检查中可用记录的比例。

75% 只描述这些虚构结果，不是产品成功率。这 12 次尝试也不代表 12 条成功且计费的结果。根据 Chronometrica 文档所述的服务约定，失败尝试不属于成功且计费的结果。Chronometrica 文档

研究人员现在有了 2 份有用的记录。内容表支持对 9 篇帖子进行分析。审计表说明了另外 3 项输入未进入分析的原因。保留这 2 份记录，可以避免有人误以为原始列表只有 9 篇帖子。

这 9 条已验收记录可以适用于内容编码，但从全部 12 项输入获取可用文本的原始要求仍未满足。针对某一用途通过验收，并不能消除这一缺口。分享结果时，研究人员必须清楚说明这一区别。

如果任务改为从单独的帖子 ID 开始，并且只需要解析后的详情记录，API Maestro 可能更合适。API Maestro 文档

证据能够确认什么

产品证据采集于 2026 年 10 月 20 日。已核查的构建版本为 Chronometrica 1.0.60 和 API Maestro 0.1.18。这些是针对特定日期的文档核查结果。本文未进行新的同条件对比测试。Chronometrica 公开服务约定、API Maestro 公开服务约定

这些证据支持根据文档所述的输入和输出行为做出选择。它们不支持有关成本更低、采集更快、准确性更高或可靠性更好的说法。本文未对另一款工具进行失败记录行或数据丢失缺陷测试。文档未说明的行为仍属未知。

买家需求的证据范围也很明确。一则公开讨论询问如何为用于寻找潜在客户的机器人采集 LinkedIn 帖子。它没有要求进行这次供应商对比，也没有要求逐项核对输入和结果。本文将这一采集需求应用于读者已经拥有公开帖子链接的阶段。选择这 2 款产品进行对比，是我们的编辑决定。本文不承诺提供合格潜在客户、发现个人资料或执行外联。关于 LinkedIn 帖子采集的公开讨论

采集完成后，评估帖子中的主张是另一项任务。你可以将已验收文本和来源 URL 配合《如何比较 LinkedIn 帖子中的主张与支持证据》使用。该指南审查内容内部的证据。本文则帮助你选择采集工具，并明确开始分析前所需的检查。