如何在同一个电子表格中合并 LinkedIn 职位与申请跟踪记录

1. 从自己的申请记录开始

合并任何数据前，先保留一份当前申请清单的原样副本。如果官方账户导出功能能提供所需记录，就使用该功能。否则，从自己的记录和凭证中手动复制少量记录。

LinkedIn 提供了申请获取本人个人数据的途径。其帮助页面说明，只提供你本人的数据，而且只提供适用于你账户的数据类别。这些证据无法确认能否完整导出私人的 Job Tracker 数据。请检查你的账户实际提供哪些内容。LinkedIn 个人数据帮助，核查于2026年10月25日；尚未确认能否完整导出 Job Tracker 数据。

对每次申请，记录雇主、职位、可获取的职位链接、申请日期和相关凭证。凭证可以是提交确认信息，也可以是雇主的消息。如果缺少日期，就保持缺失。不要填入零，也不要使用复制记录当天的日期。

为每次独立申请分配一个申请 ID。ID 是用于识别一条记录的固定标识。随着同一次申请增加更多事件，继续使用同一个申请 ID。申请另一个职位时，需要使用不同的申请 ID，即使雇主和职位名称相同。

收藏职位不等于申请职位。草稿不能证明已提交申请。如果无法确认自己是否提交过申请，就记录这项不确定性。不要把所有收藏职位都标为已申请。

2. 采集少量公开职位样本

如果已有经过核查的公开导出数据，就使用这些数据。否则，LinkedIn Jobs Scraper，公开接口规范核查于2026年10月25日；未做付费运行测试支持输入已知的职位 ID 或职位 URL。Actor 是在云端运行的数据采集程序。这个 Actor 可为下述方法提供公开职位信息。

所提供的小规模输入如下：

{
  "fetchJobDetails": true,
  "jobIds": ["4251746246"],
  "maxItems": 1,
  "saveOnlyUniqueItems": true
}

将示例职位 ID 替换为自己清单中一个已知的职位 ID 或职位 URL。ID 必须放在引号内。所提供的输入已按公开的输入结构规范核查；该规范定义了可接受的设置。本指南没有进行付费采集运行。运行采集是建议读者自行执行的操作。

`maxItems` 限制所有采集输入合计可保存的职位数量。此处上限为一条职位。`fetchJobDetails` 请求获取完整描述和详细信息，但以来源可提供的内容为限。它不保证每个字段都有值。`saveOnlyUniqueItems` 会在单次运行中去除重复职位。你的电子表格仍需为后续导入另设处理规则。

Task 是为 Actor 保存的一组预设输入。公开的 LinkedIn Jobs to Google Sheets Task，核查于2026年10月25日；仅确认公开存在，未测试已保存的输入或实际运行也可作为起点。使用前，检查其已保存的设置，并替换示例值。仅凭名称，不能确认它会合并个人申请或保留事件历史记录。

3. 以核实的职位身份为基础建立职位表

用平台名称和来源职位 ID 组合成职位键。键是用于关联匹配记录的值。这两部分都应存为文本。绝不要把两个空白 ID 视为匹配，也不要仅凭职位名称和雇主判断是同一个职位。

职位跟踪指南解释了为什么在多次采集中保持平台名称和职位 ID 稳定很重要。进行本次合并前，先应用这项身份识别规则。通知发送仍是另一项任务。

在“职位”表中使用以下列。最后两行说明的是需要你自行维护的字段。

当前公开的 Actor 接口规范记录了这些来源字段。它们描述的是职位信息，而非你的私人申请历史。可选字段的值可能缺失。公开默认构建版本 0.2.26，核查于2026年10月25日；仅静态检查接口规范，未进行付费运行。

原始输出应保持不变。添加数据行前，检查是否存在缺失 ID 和重复键。没有可用 ID 的数据行应留待核查。不要给互不相关的数据行分配“未知”等共用键。

4. 建立申请事件表

将个人操作保存在“申请事件”表中。每个有证据支持的事件各占一行。申请、面试、收到拒信、撤回申请和收到录用通知都属于个人事件。它们不是公开职位字段。

同一次申请有多个事件时，申请 ID 必须重复使用。同一次申请的提交事件和后续面试事件共用一个申请 ID，但事件 ID 必须不同。

将同一个申请 ID 分配给两次不同的申请，才是 ID 使用错误。因此，申请 ID 重复本身不代表数据重复错误。应检查每个 ID 标识的具体申请。还要单独检查事件 ID：每个事件 ID 只能标识一个事件。

凭证应由你自己保管。公开数据采集方法不需要你的私人消息。如果只保存参考记录就能在以后找到证据，那么在电子表格中保存参考记录即可。

5. 匹配申请，不确定的职位键留空

联接是通过相同的键关联数据行。在本方法中，只有核实职位身份后，才能将申请与“职位”表联接。

对每次申请，依次进行以下检查：

1. 在申请记录中查找原始 LinkedIn 职位 URL 或职位 ID。
2. 核查该 ID 是否属于预期的雇主和职位。
3. 确认“职位”表中存在相同的平台和 ID。
4. 填入已核实的职位键，并记录匹配证据。
5. 如果证据不足以确认匹配，职位键应留空，并将匹配状态设为待确认。

将雇主招聘页面的 URL 与 LinkedIn 职位关联前，可能需要更多证据。相似的职位名称和雇主名称是有用的线索，但不能证明两条记录描述的是同一个职位。重新发布且 ID 不同的职位也需要核查。

在当前视图中保留待确认的申请。未找到匹配，不会抹去你已确认提交的申请。这只说明该申请与某条公开职位记录的关联尚未核实。

同一次申请的所有事件应一致使用已确认的匹配。保留原始个人导出数据和匹配决定。如果后续证据改变了匹配结果，应记录更正内容及原因。不要在不留记录的情况下，将申请改为关联另一个职位。

6. 制定当前申请状态的判定规则

“当前视图”应按申请 ID 显示，每个申请 ID 占一行。先根据“申请事件”表建立视图，再为有已核实职位键的申请补充公开职位信息。这样，即使申请没有匹配的公开职位，也仍会显示在视图中。

写明如何根据事件确定当前状态。小型手动跟踪表可以采用以下建议规则：

1. 使用同一个申请 ID 下有证据支持的事件。
2. 按事件日期排序；如有具体时间，也纳入排序。
3. 使用最近一个能明确确定状态的事件。
4. 如果事件存在冲突、缺少日期或时间相同，且先后顺序会改变结果，应交由人工核查。
5. 后续如重新启动申请流程，应明确记录。不要假定新增备注就能取消被拒绝或已撤回的状态。

已确认的提交记录可以支持“已申请”状态。有证据支持的面试事件可以支持“面试”状态。拒信、撤回申请或录用通知可以支持各自对应的状态。关于职位页面的备注不能支持上述任何个人申请状态。

事件日期和记录日期应分开保存。今天录入一封旧拒信，并不意味着拒绝发生在今天。事件日期未知时，应保持未知，直到有证据确认。

显示申请 ID、当前状态、支持该状态的事件、已核实的职位键、匹配状态、可获取的职位信息，以及最近一次来源核查。如有帮助，可以在视图中显示“日期未知”等说明。不要把这类说明存入日期字段。

7. 后续导入职位时，保留个人历史记录

导入会将新的数据行加入电子表格。公开职位导入只应写入“职位”表。更新公开信息前，先匹配现有职位键。遇到新键时，新增一条职位记录。不要仅因为再次导入同一职位，就创建申请事件。

导入前，保存电子表格副本和原始来源输出。核查重复键和意外变化。如果职位条件的变化可能影响你的决定，应保留之前的观察记录。公开职位条件比较指南说明了如何比较已保存的职位文本，同时避免把采集时间当作雇主的编辑时间。

分别处理以下情况：

职位从搜索结果中消失，不能证明申请被拒绝、职位已招到人或招聘已结束。最近一次成功的来源核查与申请状态回答的是不同问题。

职位筛选也应单独处理。决定哪些职位值得投入申请工作前，可使用职位匹配候选清单指南。本合并方法保留的是已有记录支持的决定，不会为简历评分，也不会提交申请。

8. 完整演练一个示例，并核对总数

本演示示例为原创虚构内容。以下所有职位标识、申请、日期、凭证和事件均为虚构。它们不是 Actor 输出，也不是雇主调查结果。所有日期均为2026年10月。

一次公开数据导入包含五行，对应五个不同且已核实的职位键：

个人清单包含三次申请。其中两次已核实对应的 LinkedIn 职位身份。第三次只有雇主页面的凭证，没有证据支持其与 LinkedIn 职位的匹配。

事件表包含四行：

“在电子表格中留空”只是本文中的显示说明。实际电子表格中的该单元格应留空。不要把这句话、“待确认”或其他共用占位文本存为职位键。“待确认”应填在单独的匹配状态列中。

申请 A001 出现两次是正确的，因为它有两个事件。E001 和 E004 仍是两个独立事件。这次申请仍只计数一次。

得到的当前视图如下：

核对计算结果时，应明确各项计数的单位：

• 公开数据导入：5 行职位记录，对应 5 个唯一职位键。
• 个人清单：3 个不同的申请 ID，对应 3 次申请。
• 事件历史：3 个提交事件 + 1 个面试事件 = 4 行事件记录。
• 匹配总数：2 次已匹配申请 + 1 次待确认申请 = 3 次申请。
• 已关联的公开职位键：2 个键。未关联的公开职位键：5 − 2 = 3 个键。

在本示例中，三个未关联的职位键没有匹配的申请。这无法说明这份个人清单以外的任何记录。这些数字是记录数量，不是整个市场中的人数或空缺职位数。

现在，再次导入相同的五行公开数据。“职位”表应仍有五个唯一键。“申请事件”表应仍有四行事件记录。当前视图应仍有三次申请，且申请状态和匹配状态均保持不变。

接下来，假设后续某批数据中没有 F102。除非获得更新的核查结果，否则应保留其10月3日的观察记录。按前述规则，A002 仍为“已申请”。职位记录缺失不会新增拒绝事件。

验收电子表格前，检查每个非空的申请职位键是否都存在于“职位”表中。检查待确认的申请是否都没有使用占位键。检查事件 ID 是否唯一，以及重复的申请 ID 是否属于同一次申请。最后，对比重复导入前后的个人日期、凭证、备注和状态。