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

在同一个电子表格中，用一张表保存 LinkedIn 公开职位信息，用另一张表保存自己的申请记录。通过已核实的职位 ID 关联两张表，再建立一个视图，显示当前申请状态。首先，使用你的账户可用的方式，复制或导出个人记录。公开职位的导出数据无法说明你是否申请过，也无法说明雇主如何回复。

在同一个电子表格中使用三个工作表：职位、申请事件和当前视图。事件指一项已记录的操作，例如提交申请或参加面试。两张源表分别保存不同的信息。视图将这些信息汇总在一起，后续导入职位时不会替换你的个人历史记录。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[职位跟踪指南](/zh-Hans/articles/%E4%B8%8D%E9%87%8D%E5%A4%8D%E7%9A%84%E6%96%B0%E8%81%8C%E4%BD%8D%E6%8F%90%E9%86%92/)解释了为什么在多次采集中保持平台名称和职位 ID 稳定很重要。进行本次合并前，先应用这项身份识别规则。通知发送仍是另一项任务。

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

| 列名 | 保存内容 |
| --- | --- |
| 平台 | 来源 ID 所属的网站 |
| 职位键 | 平台名称与已核实的来源 ID 的组合 |
| `jobId` | 来源职位 ID，以文本格式保存 |
| `jobUrl` | 公开职位链接 |
| `title` | 来源中的职位名称 |
| `companyName` | 来源中的雇主名称 |
| `locationRaw` | 来源中的地点文本 |
| `descriptionStatus` | 返回的描述可用状态 |
| `descriptionText` | 返回的描述，以可获取的内容为限 |
| `scrapedAt` | 该数据行附带的采集时间 |
| 采集参考记录 | 已保存的输入、输出和运行参考记录 |
| 最近一次来源核查 | 核查时间，以及该次核查确认的内容 |

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

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

## 4. 建立申请事件表

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

| 列名 | 保存内容 |
| --- | --- |
| 事件 ID | 该事件的唯一标识 |
| 申请 ID | 该事件所属的申请 |
| 已核实的职位键 | “职位”表中已核实的键，或空白单元格 |
| 匹配状态 | 已匹配或待确认 |
| 事件日期 | 操作或回复发生的日期，以已知信息为限 |
| 操作 | 有证据支持的事件类型 |
| 来源凭证 | 确认信息或消息的参考记录 |
| 匹配证据 | 确认该申请对应此职位 ID 的依据 |
| 记录日期 | 录入该事件的日期 |
| 备注 | 相关背景或不确定信息 |

同一次申请有多个事件时，申请 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. 后续导入职位时，保留个人历史记录

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

导入前，保存电子表格副本和原始来源输出。核查重复键和意外变化。如果职位条件的变化可能影响你的决定，应保留之前的观察记录。[公开职位条件比较指南](/zh-Hans/articles/%E6%A0%B8%E5%AF%B9%E5%85%AC%E5%BC%80%E8%81%8C%E4%BD%8D%E6%9D%A1%E6%AC%BE%E6%98%AF%E5%90%A6%E5%8F%98%E5%8C%96/)说明了如何比较已保存的职位文本，同时避免把采集时间当作雇主的编辑时间。

分别处理以下情况：

| 情况 | 处理要求 |
| --- | --- |
| 来源字段缺失 | 保持缺失，不要用零替代 |
| 后续数据行缺少之前的文本 | 保留之前的观察记录，并记录文本当前是否可获取 |
| 某个已知职位未出现在本批数据中 | 保留其最近保存的观察记录和申请事件 |
| 采集失败或达到上限 | 记录采集限制，不要据此推断市场上不存在该职位 |
| 申请匹配尚不确定 | 将已核实的职位键留空，并保留申请 |
| 公开职位似乎已关闭或过期 | 将来源证据与申请状态分开记录 |

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

职位筛选也应单独处理。决定哪些职位值得投入申请工作前，可使用[职位匹配候选清单指南](/zh-Hans/articles/%E5%AF%B9%E7%85%A7%E6%8A%80%E8%83%BD%E6%8E%92%E5%BA%8F%E8%81%8C%E4%BD%8D/)。本合并方法保留的是已有记录支持的决定，不会为简历评分，也不会提交申请。

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

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

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

| 职位键 | 虚构职位 | 最近保存的采集日期 |
| --- | --- | --- |
| linkedin:F101 | 报表分析师 | 10月3日 |
| linkedin:F102 | 运营分析师 | 10月3日 |
| linkedin:F103 | 数据助理 | 10月3日 |
| linkedin:F104 | 研究分析师 | 10月3日 |
| linkedin:F105 | 项目助理 | 10月3日 |

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

事件表包含四行：

| 事件 ID | 申请 ID | 已核实的职位键 | 匹配状态 | 事件日期 | 操作及凭证 |
| --- | --- | --- | --- | --- | --- |
| E001 | A001 | linkedin:F101 | 已匹配 | 10月1日 | 已提交；确认凭证 R001 |
| E002 | A002 | linkedin:F102 | 已匹配 | 10月2日 | 已提交；确认凭证 R002 |
| E003 | A003 | 在电子表格中留空 | 待确认 | 10月2日 | 已提交；确认凭证 R003 |
| E004 | A001 | linkedin:F101 | 已匹配 | 10月4日 | 面试；记录 R004 |

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

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

得到的当前视图如下：

| 申请 ID | 当前状态 | 匹配状态 | 公开职位关联 |
| --- | --- | --- | --- |
| A001 | 面试 | 已匹配 | linkedin:F101 |
| A002 | 已申请 | 已匹配 | linkedin:F102 |
| A003 | 已申请 | 待确认 | 尚无已核实的关联 |

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

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

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

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

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

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

## 下次只导入少量数据，便于核查

先从几条个人申请记录和一个已知的公开职位 ID 开始。优先确认有明确证据的匹配。让待确认的匹配保持可见。只有重复导入公开数据后，个人历史记录仍然完整，各项总数也核对无误，才能采用这套方法。

如果需要公开职位信息，请打开 [LinkedIn Jobs Scraper，接口规范核查于2026年10月25日；本指南未做付费运行测试](https://apify.com/chronometrica/linkedin-jobs-scraper)。替换示例 ID，检查返回的数据行，再扩大采集范围。继续依据自己的证据记录申请操作。绝不能根据公开职位的导入结果，判定你已申请、获得面试或收到拒信。

## 来源和延伸阅读

- [LinkedIn 个人数据帮助；核查于2026年10月25日；提供获取本人数据的途径，尚未确认能否完整导出私人的 Job Tracker 数据](https://www.linkedin.com/help/linkedin/answer/a1339364)
- [Chronometrica LinkedIn Jobs Scraper；核查于2026年10月25日；公开采集接口规范，未做付费运行测试](https://apify.com/chronometrica/linkedin-jobs-scraper)
- [LinkedIn Jobs Scraper 默认构建版本 0.2.26；核查于2026年10月25日；仅检查输入和输出规范](https://api.apify.com/v2/acts/kkH2KvT3IfbFf6A6P/builds/default)
- [LinkedIn Jobs to Google Sheets Task；核查于2026年10月25日；仅确认公开预设存在，未测试已保存的输入或实际运行](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-jobs-to-google-sheets)