我如何用 AI 改造求职流程：从匹配公司到飞书跟进

我为什么开始改造求职流程#

我找岗位时，信息总是散在不同地方：传统招聘网站要看，闲鱼、抖音上的招聘内容也不能完全不看。有人会在这些平台发岗位或运营招聘账号，但同一个岗位名背后，要求可能完全不同；帖子也可能不全、过期，所以真正准备投之前，我还是会回到公司的官方 JD 再核一遍。

投得多了，靠记忆追状态就很容易乱：哪些已经投过、用的是哪版简历、下一步该做什么，都得一件件记。我改这套流程，并不是想让 AI 替我包办求职，而是想把这些重复的整理工作交给它，自己把精力留给真正需要判断的地方。

与其让 AI 替我盲目投递，不如让它先负责信息整理和匹配判断，把人的精力留给真正需要决策的部分。

我想先让 AI 帮我把信息理清楚、把不合适的岗位筛掉，至于最后要不要点投递，还是我自己决定。

我先把求职拆成一条流水线#

于是我把投递前的事情顺了一遍，拆成一条能跟着走、也方便回头查的流程：

1
岗位信源
2
  ↓
3
AI 发现岗位
4
  ↓
5
官方 JD 核验
6
  ↓
7
简历与岗位匹配
8
  ↓
9
人工决定是否投递
10
  ↓
11
飞书记录与跟进

大概是这样：

岗位信源：先把传统招聘网站、闲鱼、抖音这些入口放在一起。渠道虽然杂，但都可以先拿来找线索。
AI 发现岗位：让 AI 按我设定的方向，把可能合适的岗位先捞出来，后面我再慢慢挑。
官方 JD 核验：内容平台上的帖子只能算线索。准备投之前，我还是会回到官方渠道，把 JD 原文核一遍，免得被过期或残缺的信息带偏。
简历与岗位匹配：把 JD 和手上这版简历放在一起看，让 AI 帮我找出匹配的地方，以及还差什么。
人工决定是否投递：到这里就停一下。AI 给的是建议和整理好的信息，投不投、用哪版简历，最后都由我自己定。
飞书记录与跟进：确定投了之后，再把结果记进飞书。以后查状态、看用的是哪版简历、安排下一步，就不用全靠记忆。

第一个 Skill：让 AI 帮我找匹配的公司和岗位#

第一个 Skill 做的事其实很单纯：帮我筛，不替我投。它大致按这个顺序来：

1
岗位信源 → 去重 → 官方 JD 核验 → 简历逐项匹配 → 1–5 分评估 → 推荐少量岗位

先从岗位信源开始#

我给它的材料主要有两份：一份自己维护的岗位信源清单，以及一份已经确认过的简历画像。信源清单是只读的，里面收了不同的发现入口，大致可以分成几类：

传统招聘网站：校招聚合站、公司招聘官网这类正式渠道，信息相对完整，是主要的发现来源。
闲鱼 / 咸鱼：有些公司会在上面运营账号、发岗位或招人信息，是值得扫的发现入口之一。
抖音：内容平台上的招聘帖子可能不完整、过时，同样只能当作线索看待，不能当作最终依据。

我最在意的是，三类渠道都只是发现入口，不能当成最终依据。内容平台上的信息可能不全，也可能已经过期；真准备投之前，我会回到官方 JD，把岗位编号、城市、届次、职责、任职资格和投递直链重新核一遍。

不只看岗位名称，而是对照 JD 和简历#

候选岗位出来以后，我让 AI 把官方 JD 和这版简历逐项对照，再给出一个 1–5 分的匹配度——5 分通常意味着有直接的项目或实习证据，只差少量可以补上的优先项；4 分是核心方向和大部分技能都对得上，但还有小缺口；3 分主要靠可迁移能力，且有一个明显的硬性缺口；再往下，基本就是关键经历不足或方向不太合适。

为了避免岗位名字看起来像、实际差很多的情况，匹配度不是看岗位名称里有没有「AI」或「全栈」就拍板，而是真的要对着 JD 逐条比——

1
公司：某科技公司
2
岗位：AI 应用开发工程师
3
匹配度：4 / 5
4
匹配依据：有全栈开发、AI 应用和后端项目经验
5
主要缺口：缺少某项特定业务经验
6
结论：值得投递

所以它给我的不能只有一个分数，还要把匹配证据和主要缺口一起说清楚。这样我才能判断要不要补简历、值不值得投。这个分数只是 AI 的主观参考，不是招聘方的评分，更不是替我拍板；方向偏好、城市等条件，也只按我明确说过的偏好来参考。

它通常只给我三到五个更值得看的岗位，并挑出一个首推，不会把抓到的几十条结果一股脑倒过来。官方信息没核实到的，会先标成「待核实」，不会硬放进首推清单。最后再补一句行动建议：值不值得占用一个投递名额、该用哪个意向和简历，以及推荐码要不要留空。

这里有一道必须守住的闸门：筛选阶段不写入。岗位找完、核验完、排好顺序之后，流程就停在这里，不会自动往飞书投递表里写。要不要投、用哪版简历，还是我自己决定；只有我明确说了「已投」，才会交给下一个 Skill 记录。

第二个 Skill：把已经投递的岗位记到飞书#

前一个 Skill 负责「筛」，这一个负责把确认投出去的岗位记下来。它实际做的事情是：

1
用户确认“已投” → 按岗位编号查重 → 创建或更新记录 → 记录后续行动 → 回读验证

只有确认已投，才写入记录#

它什么时候动手？只有我明确说了「已投」之后。选出岗位不等于已经投递，筛选阶段不会提前写入；等我确认投了，再把这项记录交给它处理。投出去之前怎么判断、用哪版简历，仍然由我自己负责。

让投递记录可以查重、更新和跟进#

写入时，我会先按岗位编号查一遍。如果飞书里已经有这条记录，就更新原来的那一行，不再重复创建。这个做法叫幂等：同一件事重复做几次，结果还是一样，不会越写越多。

飞书里的一行记录，我会尽量留下这些有依据的信息：公司、岗位名称、方向、状态、轮次、优先级、岗位匹配度、城市、工作模式、岗位发布日期、投递日期、官方 JD 直链、关键词、渠道、使用简历、下一步行动和日期、最新进展、备注。匹配度和「使用简历」都以我明确提供的信息和官方 JD 为准，不会为了把岗位说得更合适而补编经历。

有些字段本来就不一定能查到。比如薪资、截止日期、工作模式，没找到可靠来源时就留空或标「未知」，不为了填满表格去猜。

还有个容易被忽略的细节：API 返回成功，不等于事情就完成了。我会等写入器返回 status: ok，再把记录读回来核对；两步都通过，才算真的写进飞书。中间任何一步失败，都直接报告错误，不绕过校验，也不另写临时脚本掩盖问题。

写入时还会顺手记下「下一步行动」和跟进日期。比如投递后过一段时间提醒自己看邮箱、短信和 ATS 状态，后面跟进就不用全靠记忆。

一次完整的使用过程#

下面用一个完全脱敏的例子，看看这套流程实际怎么走。它不是某次投递的复盘，也没有真实公司、岗位编号或链接，只是把每一步串起来。

1
我让 AI 检查岗位信源
2
→ 它筛出更匹配的公司和岗位
3
→ 它回到官方页面核验信息
4
→ 我查看匹配依据并决定投递
5
→ 我回复“已投”
6
→ 岗位进入飞书看板
7
→ 后续按状态跟进

我先让岗位筛选 Skill 把已经整理好的信源过一遍。闲鱼、抖音和其他渠道的内容都只当线索，它会先去重，再回到公司的官方招聘页核对 JD，最后结合简历画像挑出少量更值得看的岗位。给我的结果除了岗位信息和匹配度，还会说明为什么匹配、差在哪里，我不用对着一个分数猜。

接下来我会自己打开官方链接，看一遍匹配依据和缺口，再决定要不要用掉这个投递名额。如果决定投递，我就明确回复「已投」。收到这句话后，投递记录 Skill 才会按岗位编号查重：没有记录就新建，有记录就更新，写完再读回来核对。之后我照着飞书里的状态、下一步行动和跟进日期继续处理，不会把筛选建议当成已经投递。

复用飞书里的 OpenClaw 应用#

如果现成的飞书 OpenClaw 应用接口能用，我会先复用它，不再另起一套连接。飞书开放平台的官方文档确认，OpenClaw 这类 Agent 可以一键接入飞书，也可以预置常见的权限和事件订阅。不过，文档里的默认清单没有多维表格记录权限，所以“能连上飞书”和“能读写目标多维表格”是两回事。

我实际会这样处理：

1
现有飞书 OpenClaw 应用接口
2
→ 用搜索 CLI 查官方文档
3
→ 确认最小权限和多维表格访问范围
4
→ 检查本地配置
5
→ 用户确认后写入配置
6
→ 用一条脱敏记录读写回测

这样做的好处是不用再维护第二套集成，但开始前有三件事得先确认：OpenClaw 能不能访问这个应用，应用有没有目标多维表格的访问范围，以及记录的读写权限是否真的开通。如果控制台还要求管理员审批，也要先把审批走完。多维表格官方概览文档也写得很清楚：用 tenant_access_token 访问 Base 时，应用必须是这个 Base 的所有者或协作者，否则调用会失败。

权限、搜索和配置写入#

这件事里其实有两条线，别混在一起：

能搜索岗位：search cli 用来搜官方文档和岗位信源。它能搜索，不代表 OpenClaw 就有了飞书多维表格的访问权。
能读写多维表格记录：这是另一组 Bitable API 能力。能搜索或读取记录，也不等于能创建或更新；具体还得看官方列出的权限，或者是否使用更宽的 bitable:app。

最小权限核对清单#

权限清单我只写已经从官方文档核对过的名称。至于当前 OpenClaw 连接到底用哪一种，还是要以你正在使用的 OpenClaw / 飞书界面和官方文档为准：

base:record:retrieve：用于按条件搜索已有记录；如果按岗位编号查重时调用“搜索记录”接口，则需要它，见官方搜索记录文档。
bitable:app:readonly：官方定义为“View, comment, and export Base”，可作为搜索或列出记录的只读权限；只读查重和回读需要它时才申请，见官方搜索记录文档和列出记录文档。
bitable:app：官方定义为“View, comment, edit and manage Base”，是搜索、列出、创建和更新记录时列出的较宽替代权限；它不是最小权限首选，只有在当前实现确实需要且用户接受更宽访问范围时才考虑，见官方搜索记录文档、创建记录文档和更新记录文档。
base:record:create：用于创建新记录；只有用户确认“已投”、查重后不存在对应记录并且流程要新增一行时才需要，见官方创建记录文档。
base:record:update：用于更新已有记录；只有幂等写入命中已有岗位记录并且流程要更新它时才需要，见官方更新记录文档。

这些名称只是接口文档给出的候选项，并不代表你的应用已经自动获得授权。官方的快速接入多维表格文档也把“列出记录”和“创建记录”当成不同操作。所以我会先按实际需要开搜索 / 读取权限，确认真的要写入之后，再申请创建或更新权限，不会因为“能搜到岗位”就顺手把写权限全开了。

认证这部分，我只说明方法，不把任何凭据放进文章。若当前方案使用自建应用的 tenant_access_token，官方认证文档说明了它的获取方式和最长两小时的有效期，也说明这个令牌接口本身不要求权限；但这并不等于应用已经能访问 Base 或调用记录接口。app_id、app_secret、Token、Base 信息和表信息，都应该只放在自己的安全配置里。

我查到这里，公开官方页面里还没有现成应用对应的 OpenClaw 配置 schema，也没有找到 OpenClaw 把各个飞书 scope 映射到具体配置键的权威说明。也就是说，配置项名称、JSON 结构和权限映射目前都只能先标成“待核实”：先在当前 OpenClaw / 飞书界面或对应官方文档里确认，再检查现有配置；真正要改时，只展示最小变更，等确认后再写。回测用一条虚构的脱敏岗位记录，并回读检查字段，不能直接写入真实投递记录。

给 Agent 的配置提示词#

如果你也想让 Agent 帮忙配一遍，可以直接把下面这段提示词发给它。里面没有应用标识、资源标识或凭据，搜索、权限确认、配置写入和回测也都要求一步步确认，不会一上来就改真实配置。

1
你是我的求职自动化配置助手。我要使用飞书里的 OpenClaw 应用接口，把经过核验的岗位信息写入飞书多维表格。
2

3
请严格按以下顺序执行：
4
1. 先使用 search cli 搜索飞书开放平台、飞书多维表格和 OpenClaw 的官方文档，确认当前版本的认证方式、应用权限、资源访问范围和配置格式；不要凭记忆猜权限名称。
5
2. 列出每一项拟使用的权限、用途、是否必需，以及对应的官方文档链接。缺少官方依据的内容标记为“待核实”。
6
3. 检查我现有的配置和目标多维表格信息；缺少 Base、数据表或字段信息时先向我提问，不要自行猜测或读取无关私人文件。
7
4. 先展示准备修改的配置和最小变更内容，等我确认后再写入；不要输出或记录任何 Token、Secret、Cookie 或其他凭据。
8
5. 配置完成后，用一条虚构的脱敏岗位记录做最小读写测试，并回读验证字段是否正确；不要直接写入真实投递记录。
9
6. 最后报告已确认的权限、修改的配置项、测试结果和仍需我手动完成的开通步骤。

这套方法为什么不追求自动海投#

我没把目标定成“让 AI 尽可能多地自动提交申请”。求职里，下面这些事情还是不能省：

岗位信息会过期，也可能被读错：内容平台的帖子只是线索，岗位状态、任职要求和投递入口仍要以官方 JD 为准。
AI 不能替我编造经历：匹配时只能使用简历里真实存在的项目、实习和技能证据，不能为了提高分数虚构经验。
每个岗位都得单独判断：相同的岗位名称可能对应不同团队、城市和工作内容，是否投递、使用哪版简历，都应该结合具体情况判断。
重复操作很容易把事情做坏：没有核验就反复提交，可能投错岗位、重复投递，甚至把不适合公开的信息发出去。
警惕虚假招聘和收费内推：内容平台上的线索要通过公司官网、官方招聘页和可核验的招聘主体确认；凡是要求先付费、索要与投递无关的敏感信息，或无法回到官方渠道的，都不应继续。

对我来说，AI 负责把信息找出来、比一遍、记下来就够了。要不要投，还是我自己决定。

这也是我给这套流程定的边界：AI 最适合辅助发现、比较和记录，不应该替我承担未经确认的投递决定。

普通求职者怎样复用#

不需要照搬我的文件名和工具。把下面五件事准备好，换成别的 AI 工具和表格，也能按这个思路跑起来：

准备一份结构化简历画像。
整理可信的岗位信源，同时把咸鱼、抖音等内容渠道当作待核验线索。
要求 AI 输出岗位信息、匹配依据和关键缺口。
复用已有的飞书 OpenClaw 应用接口，使用搜索 CLI 核对官方文档、权限和配置。
用飞书多维表格或其他表格记录已投岗位、状态和下一步行动。

我觉得最值得复用的是这条流程，不是某个私人命令。简历画像得自己确认，岗位事实要回官方渠道核一遍，飞书应用的开通、权限审批和凭据也要自己负责。前面的条件没确认好，就先停在“待核实”，别让 Agent 猜配置，更别让它直接写真实投递记录。

结语：把 AI 用在真正消耗精力的地方#

对我来说，AI 赋能找工作，不是把投递按钮交给 AI，更不是让它替我海投。它能帮我把分散的岗位信息整理出来，做一轮匹配比较，再把已经投过的岗位记下来；我自己则负责核验事实、判断方向，最后决定投不投。

所以最后真正值得复用的，不是某一条命令，而是“发现—核验—匹配—决策—记录—跟进”这条顺序。工具可以换，表格可以换，岗位信源也可以换；只要边界清楚、记录能查，AI 就能在求职里帮我省掉一部分重复劳动，同时把真正需要判断的事情留给人。

音乐

音乐