招聘信息能证明公司已准备购买你的产品吗？

采集招聘信息前，先定义公司问题

搜索前，先写一条简短的研究规则。写明客户类型、你的产品或服务解决的问题，以及哪项职责可能使该问题值得核查。

将问题与产品名称分开。有关维护报表的职责，可以为报表工作方面的提问提供依据。但仅凭这项职责，不能说明报表有问题，也不能说明该公司需要你的产品。

按以下步骤操作：

1. 确定你要研究的公司类型。
2. 说明你的产品或服务要解决的工作问题。
3. 列出可能与该问题有关的岗位职责。
4. 说明哪些证据会削弱两者之间的关联。
5. 写出下一步可以通过公开信息研究回答的问题。

第四步可防止你把每个相关岗位都当作支持证据。例如，一项职责可能只是某个运行良好的流程中的日常工作。在整个审查过程中，都应保留这种解释。

最终成果是一份客户公司研究简报。这里的客户公司指正在研究的公司。简报简要记录来源中的事实、可能的解释、缺失的事实，以及下一项核查。它不是销售预测。

选择一个规模小且固定的研究样本

研究样本是指按同一组搜索规则选出的招聘信息。采集前，先固定岗位、地点、公司筛选规则和审查日期。样本数量应足够小，以便你逐条阅读职位描述，并手动核查公司背景。

记录搜索输入和采集限制。限制会影响你能观察到的内容。小范围搜索可以找到供审查的记录，但不能证明你已找到所有相关公司。

不要用返回的招聘信息数量衡量公司需求的强弱。多则招聘信息可能重复相同内容。一则招聘信息也可能包含多项职责。这两种计数都不能衡量已招聘人数或购买决策。

如果你的问题变成招聘信息数量是否随时间变化，就应使用另一种方法。定期记录招聘信息快照指南介绍了这项不同的任务。让本简报继续聚焦一个公司问题，以及用于核查该问题的证据。

采集来源记录，分析仍需自行完成

Actor 是托管运行的数据采集程序。Task 是为 Actor 保存的一组输入设置。LinkedIn Jobs Scraper Actor的文档列出了适用于本方法采集步骤的输入和输出字段。它不会替你完成公司研究简报。

所提供的检查结果表明，公开默认构建版本 `0.2.26` 声明了下文使用的字段。数据模式是对允许使用的字段和值类型的定义。静态数据模式检查确认，示例输入符合该定义。这次检查没有运行 Actor，也没有测试实际结果。它不能证明当前数据可用、覆盖完整或采集成功。公开默认构建版本——检查于2026年10月25日；仅提供数据模式证据；未实际运行。

可使用以下建议的小规模采集输入：

{
  "fetchJobDetails": true,
  "location": "United States",
  "maxItems": 3,
  "maxPagesPerSearch": 1,
  "saveOnlyUniqueItems": true,
  "searchTerm": "Salesforce administrator"
}

将 `searchTerm` 替换为符合研究规则的岗位。将 `location` 替换为目标市场。首次采集应保持小规模。示例将条目上限设为 `3`，搜索页数上限设为 `1`。这些是输入限制，不是观察结果，也不保证会返回三条记录。

示例通过 `fetchJobDetails` 请求职位详情。同时，它将 `saveOnlyUniqueItems` 设为 `true`。在把收到的记录视为不同的证据之前，先检查这些记录。该设置不能证明存在不同的公司问题或不同的购买信号。

公开的 LinkedIn Jobs Hiring Signals for B2B Sales Leads Task可作为起点。该页面于2026年10月25日存在，并包含 Task ID `ef48MV6KmGoveTRcE`。其当前保存的设置和运行时行为仍未经核实。上文输入是建议的替代方案，并非已核实的保存设置副本。本指南没有报告任何 Actor 运行结果。

分开保存来源字段和研究笔记

保留采集记录的原样。将你的解读写在单独的研究笔记中。这样，其他读者就能区分来源原文与你的结论。

已检查的构建版本声明了以下输出字段。声明某个字段，不代表每条记录都会包含有用的值。多个字段允许使用 `null`，表示未提供值。

这些字段来自已检查的公开构建版本。下方的简报字段是手动研究笔记，并非声称由 Actor 输出的字段。公开默认构建版本——检查于2026年10月25日；仅涉及已声明的字段类型。

如果公司页面未注明日期，就写“未注明日期”。保留你的核查日期。近期核查过页面，不代表页面内容是近期发布的。

阅读岗位职责，核查公司背景

对每家公司，按以下顺序操作：

1. 阅读职位描述，不要直接把岗位名称当作研究发现。
2. 准确摘录一项相关职责。
3. 写出该职责能支持的、范围最小的观察结果。
4. 另行查找公开的公司背景信息。
5. 记录背景信息的来源、注明的日期和核查日期。
6. 说明这些背景信息是否改变了你的研究问题。

保留来源中关于工具、项目和职责的原文。同一个工具名称可能出现在不同语境中。它可能描述一项要求、该岗位将执行的工作，或应聘者应具备的经验。不要把每次提及工具都当作公司已部署该软件的证据。

尽可能在公司官方页面核查背景信息。确认页面说的是同一家公司。不要仅因名称相似，就把招聘信息与某个页面关联起来。如果两者关系仍不明确，就让简报保留为尚无定论。

单独查得的背景信息也需要核查相关性。一则注明日期的办公室公告，可能只能证明公司发布过办公室相关公告。它不能证明报表工作存在故障、公司购买了软件，或项目预算已获批准。除非来源明确提供了缺失的事实，否则应以问题的形式表述这种关联。

第二个页面可能只是重复第一个来源。应明确记录这种关系。两个网址并不自动构成两项独立确认。记录每条资料新增了什么信息。

作出判断前，比较其他解释

研究假设是仍需核查的一种可能解释。表述假设时，应允许证据表明它不成立。例如，可以问：某项明确写出的职责，是否与尚未解决的报表问题有关？除非来源支持，否则不要写公司需要替换产品。

在假设旁边列出其他合理解释：

这些都是需要调查的其他解释。不能仅因它们合理，就认为招聘信息已经证明了其中任何一种。

选择一个能够区分不同解释的核实问题。“哪个报表问题尚未解决，由谁负责？”比购买概率评分更有用。它明确指出缺失的事实，而不假装已经衡量了这些事实。

不要用客户公司研究简报断言隐藏的招聘意图。如果问题变成：公开招聘信息核查能说明一则疑似“幽灵职位”，即可能并无实际招聘意图的职位，存在哪些情况，请使用公开招聘信息核验指南。这个问题不同于判断某家公司是否值得开展与产品有关的研究。

完成一份虚构公司研究简报

原创虚构教学示例。Cedar Ops、它的职位描述、公司页面，以及本节全部研究发现均为虚构。这不是 Actor 运行结果、客户成果，也不是对真实公司的观察结果。

Cedar Ops 发布了一则 Salesforce 管理员招聘信息。虚构的职责原文写道：“维护报表并为用户提供支持。”另一个注明日期的公司官方页面介绍了一处新的区域办公室。研究者提供的产品或服务与报表工作有关。

这项职责支持一项关于运营工作的观察结果。办公室页面提供了公司背景。两个来源都没有说明报表流程存在故障，也都没有说明存在用于新供应商的预算。

以下算式以证据条目为单位：

1 则来源招聘信息 + 1 个单独的公司页面 = 2 条证据。

这不等于两个购买信号。它不能确定预算金额，也不能预测转化率。计算转化率需要先定义结果，并确定用于计算这些结果的群体。这份虚构简报两者都未提供。

这则招聘信息也没有告诉我们公司将招聘多少人。在这里，一则招聘信息是一条来源资料。它不等于一名已确认录用的人员。

Cedar Ops 的状态仍为“需要研究”。下一步是手动搜索有关报表问题及其负责人的公开证据。如果搜索没有找到有用信息，就记录已核查的内容，并将该问题保留为未知。不要把搜索无果当作问题不存在的证据。

明确记录缺失的事实和失败的核查

对尚未完成的工作作明确备注。空白单元格无法说明你是已经核查、无法访问，还是忘记了核查某项事实。

1. 职位描述缺失：如有招聘信息引用资料，应予保留。不要从岗位名称推断职责。
2. 公司身份不明：将公司关联保留为尚无定论。不要借用名称相似的公司的背景信息。
3. 公司页面未注明日期：记录其未注明日期。不要将核查日期当作发布日期。
4. 采集或页面访问失败：记录失败情况。这不表示相关职位数量或公司活动数量为零。
5. 采集结果为空：记录本次采集未返回任何行。这不能证明不存在匹配的招聘信息。
6. 采集受到输入设置限制：在记录旁保留这些限制。不要称结果已实现完整覆盖。
7. 证据冲突：保留两条资料，并说明冲突之处。不要不作说明就选择对自己更有用的说法。
8. 预算未知：写“未知”，不要写零。预算未知和明确写出的岗位职责，都不能提供购买日期。

将公开证据与仅所有者可访问的记录分开。本方法使用公开招聘信息和公开公司页面。它不提供私有客户记录、收件箱内容、应聘者状态，也不提供联系人信息补全。除非另有经过授权的证据加以证实，否则内部预算审批情况和采购计划仍属未知。

文档中列出的采集功能，也不同于经过测试的结果。已检查的数据模式支持建议的输入和要保留的字段。所提供的资料中，没有实际运行测试能证实采集产出、当前运行状况，或研究效果优于手动审查。