# Job Application Match

> 根据校招或社招用户的真实经历和岗位信息，筛选值得投递的岗位，并直接生成不虚构的岗位版简历经历。校招默认读取指定公开校招岗位池；社招只使用用户提供的 JD、截图、链接或表格。适用于“我该投什么岗位”“帮我从校招里找匹配岗位”“本地外企怎么筛”“根据匹配岗位改简历”等场景。

- Skill: `luyu2026/job-application-match` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add luyu2026/job-application-match`
- Raw SKILL.md: https://api.skillmd.com/api/skills/luyu2026/job-application-match/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: luyu2026 (https://skillmd.com/u/luyu2026)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/luyu2026/job-application-match

---


# Job Application Match

把“我能投哪些岗位”变成一条可执行链路：找岗位、核验 JD、判断匹配、直接交付一版能放进简历的经历。它不是不透明的 ATS 打分器，也不会把普通参与经历虚构成主导项目。

## 先确认求职路径

如果用户没说清，第一句只问：**你是校招还是社招？**

| 路径 | 默认信息源 | 用户可补充 | 可以交付 |
| --- | --- | --- | --- |
| 校招 | 默认读取公开校招岗位池：`https://campus.sma-wiki.cn/campus/campus_recruit.html?channel=ysgg` | 任意链接、飞书表格、招聘截图、JD、城市和意向 | 候选岗位池、少量 JD 核验、优先级、岗位版经历 |
| 社招 | 不主动抓取 Boss 等受限或时效难核验的平台 | JD 链接、截图、文档、表格、复制文本 | 岗位排序、单岗判断、岗位版经历 |

默认岗位池只是“召回候选岗位”的公开来源，不等于官方 JD。用户提供的官方招聘页、公司 career 链接和岗位材料优先级更高。

## 输入与边界

### 最少材料

1. 校招/社招。
2. 简历或可用经历；校招生至少给学校、毕业时间、专业、校园/实习经历。
3. 可接受城市或是否愿意迁居；没有就标记为待确认。
4. 目标方向或明确不想投的方向；没有时才做探索性岗位池。
5. 可选：额外岗位来源链接、飞书表格、JD、截图。
6. 可选：已有投递清单、投递反馈、上一轮输出文档或本次会话中的历史投递信息。

### 绝不默认的事

- 不默认用户可以迁居、接受英语环境、接受降级或愿意做销售。
- 不把岗位列表页的名称当成完整 JD；只对前 3-5 个最可能的岗位打开官方或用户提供的链接核验。
- 打不开 JD 时，明确标记为“岗位名称/列表摘要推断”，不能给高置信度推荐。
- 不绕过网站限制、不批量抓取受限职位库、不自动投递。
- 不编造用户没有做过的职责、项目、规模、数据或结果。

## 信息来源优先级

1. 用户提供的官方 JD、岗位截图、公司 careers 页面。
2. 用户提供的招聘表格或公开招聘链接。
3. 默认公开校招岗位池。
4. 岗位名称和行业的有限推断，只能用于召回候选项，必须标记低置信度。

涉及“当前在招”“截止日期”“招聘要求”时，记录查询日期和来源日期；列表信息有时效，最终以官方岗位页为准。

## 核心原则

### 1. 先看硬条件，再谈匹配

先核对毕业届别、学历、专业限制、城市/迁居、语言、资格、截止日期和用户明确的底线。硬条件不满足，直接暂缓；信息缺失，写待确认，不能被其他分数掩盖。

### 2. 证据比关键词重要

每一个判断必须区分：

- `用户事实`：用户明确提供的经历、数据、限制。
- `合理迁移`：不改变事实，只换成岗位语言的表达。
- `待确认`：必须由用户补的职责、规模、数据和边界。
- `示例口径`：只帮助理解，绝不能放进用户简历。

低颗粒经历也要给用户一版可直接用的**事实版**；但“主导”“增长”“提升 xx%”只在用户确认有对应事实时才能出现。

### 3. 排序不等于 offer 概率

优先级只帮助分配投递时间。输出中同时显示已有证据、主要缺口、JD 核验状态和下一步，不把“匹配分”写成录取概率。

### 4. 外部 GitHub 机制是迭代兜底

默认先使用用户材料和岗位来源。当材料不足以拆清筛选、匹配、简历定制或投递反馈的机制，或用户明确要求进一步调研时，参考 GitHub 上高质量的 job matching、resume tailoring、application tracker 项目。

参考的是产品/流程机制，不是照搬职位数据、简历内容或匹配结论。重点看：硬过滤与软匹配如何分开、岗位排序怎样回到经历证据、简历定制如何与岗位选择衔接、投递反馈怎样回流。高星只是热度信号，不是采用结论。可优先观察：

- [`phoinixi/resuml`](https://github.com/phoinixi/resuml)：将职位搜索、匹配和简历定制拆为阶段。
- [`prayag-purohit/JobApplicationTracker`](https://github.com/prayag-purohit/JobApplicationTracker)：投递状态和反馈闭环。

只有外部机制确实改变本轮方案时，才在交付中写出“参考了什么机制、补足了什么”；不要为显得全面而硬塞调研。

## 工作流

### 1. 建立候选人卡片

提取毕业时间、学历、专业、已有经历、城市、目标方向、语言和底线。对时间线做合理性检查：例如“社团经历起止时间”跨越中学到大学时，先确认能写进大学简历的实际起止时间，不要原样写成异常长经历。

先检查当前会话中是否已有简历版本、岗位清单、投递状态或 HR 反馈；有就直接接续，不重复问用户已经给过的内容。跨会话或 Agent 没有历史上下文时，不能假装记得，优先读取用户提供的飞书表格、Excel、文档、截图或复制的投递清单。

### 2. 按路径获取岗位

**校招**：

1. 读取默认公开岗位池，并合并用户额外提供的表格/链接。
2. 先按届别、学历、截止日期、城市和用户禁区做粗筛。
3. 从岗位名称、行业和已知经历召回 5-10 个候选项。
4. 只打开排序靠前的 3-5 个官方或用户提供的岗位链接，抽取职责、门槛和投递入口；若链接无法读取，不假装已核验。

**社招**：

1. 只读取用户提供的 JD、链接、截图、文档或表格。
2. 若没有岗位材料，交付“材料清单 + 输入模板”，不虚构本地机会。

### 3. 先分开回答两个问题：好岗位与适合投的岗位

用户先想知道“哪些岗位值得争取”，再想知道“我现在投哪里最有把握”。这两个问题不能混成一个匹配分。

先输出 **值得冲的好岗位**。每个岗位都单列：

- 公司、岗位、地点与来源；
- 岗位价值：平台/行业位置、可积累的能力、后续发展路径；
- 薪酬信息：有可靠来源才写，缺失时明确写“未公开，不承诺高薪”；
- 岗位职责：只写已核验 JD；未核验时标注“待核验”，不能混入岗位价值；
- 当前是否建议投，以及要补什么才具备竞争力。

再输出 **按当前经历适合投的岗位**。每个岗位单列：

- 岗位职责；
- 当前匹配证据；
- 可直接使用的简历版本；
- 补哪几条真实信息，能明显提高匹配度；
- 动作：现在投 / 补完再投 / 暂缓。

“好岗位”可以是冲刺项；“适合投”应当优先是用户目前有真实经历可以承接的机会。没有足够材料时，允许“本轮没有适合现在投的岗位”。

### 4. 直接生成岗位版简历

对每个“现在投”或“补完再投”的岗位，必须直接给出一段能放入简历的内容，而不是只给建议。统一用四列表格交付：

1. **切入方向**：对应的岗位方向。
2. **无真实数据占位版**：只用已知事实，预留最少的 `[活动次数]`、`[参与人数]`、`[周期]` 等确认位，用户填完即可提交。
3. **逻辑自洽示例数据版**：给一份完整、有数字、能帮助用户理解表达标准的示范版本。
4. **使用建议**：说明适合投什么岗位、要核实哪些数据、应放在简历第几条或替代哪条经历。

当用户材料已经有真实数据时，优先把第三列替换成该用户的真实数据版。材料不足时也必须给示例数据版，避免小白只看到方括号而不知道什么是好的数据表达。Agent 在内部区分用户事实与示例，不需要在交付中反复提示用户如何使用示例。

每个版本都要包含岗位名称、经历标题、可直接复制的要点。若需要整理完整简历，再把已核验岗位、事实和关键词交给 `resume-jd-tailor`；本 Skill 不重复做面试准备或泛泛的职业规划。

### 5. 用投递清单和反馈迭代

已有投递清单时，先读取其中的岗位、城市、渠道、投递日期、简历版本、当前状态、HR/面试反馈和拒绝原因。字段不全也直接使用已有信息，不要求用户重建表。

根据反馈更新下一轮输出：

- **连续无回复**：检查岗位硬条件、简历首屏关键词、投递渠道和岗位层级；缩小不匹配岗位，调整简历标题、经历排序和关键词。
- **有 HR 回复、无业务面**：保留岗位方向，强化项目/经历的职责、数据和自我介绍。
- **频繁进入面试**：提高相似岗位的优先级，文末联动面试 Skill。
- **同一原因被拒**：把它写为下一轮的硬边界或材料缺口，不再把同类岗位排在前面。

没有投递清单时，第一次交付只附一个最小清单模板：`公司/岗位 | 来源 | 投递日期 | 简历版本 | 当前状态 | 反馈 | 下一步`。不要强制用户使用特定工具；飞书表格、Excel、Notion、文档表格或消息文本都可以。

### 6. 合并输出“下一步与反馈清单”

不要把“下一步投递”和“投递反馈复盘”拆成两个模块。它们是一条连续链路：先完成第一轮投递，再用真实反馈让下一轮选岗和简历更准。

交付中用一张主流程表呈现，列为：`什么时候 / 现在做什么 / 要准备什么 / 完成后得到什么`。顺序按用户路径调整，但默认包含：

1. **今天**：确定 1 个主投方向和 1 个备选方向，并补齐真实经历事实。
2. **明天**：建立第一批岗位池。校招默认筛出 10 个机会（3 个冲刺、7 个适配）；社招只从用户提供的岗位材料中筛选。
3. **48 小时内**：核验优先岗位的官方 JD，完成岗位版简历并开始投递。
4. **每投 5 个岗位或收到任何回复后**：把投递状态、简历版本和 HR/面试反馈交给 Agent，更新下一轮。

紧接主流程表，用“投递记录怎么用”说明最小字段：`公司/岗位 | 来源 | 投递日期 | 简历版本 | 当前状态 | 反馈 | 下一步`。明确已有飞书表格、Excel、文档、截图或当前会话中的历史记录都可直接使用，字段不全也不要求重建。

再用一张两列表格写三条反馈规则：

- **有回复或进入下一轮**：提高相似岗位优先级，并在关联 Skill 中进入对应面试准备。
- **有 HR 回复、但没有进入业务面**：保留岗位方向，优先调整简历首屏、关键词、经历职责和数据表达。
- **至少 3 个同类岗位没有回复或被拒**：判断硬条件、岗位层级、渠道或简历版本的问题，收紧下一批岗位的筛选边界。

最后给一句可直接复制的调用语：`这是我的投递清单，请使用 job-application-match 根据投递状态和反馈，更新我的岗位优先级、简历版本和下一批投递计划。`

不要把面试训练混进本 Skill；拿到面试后再通过关联 Skill 跳转。

### 7. 文末输出“关联 Skill”

交付文档最后新增一个独立的“关联 Skill”模块，按用户当前状态给出以下直接链接：

1. 整理完整简历：[`resume-jd-tailor`](https://github.com/Luyu2026/Skill-Bible/tree/main/resume-jd-tailor)。
2. 收到一场具体面试：[`interview-prep-brief`](https://github.com/Luyu2026/Skill-Bible/tree/main/interview-prep-brief)。
3. 已进入二面、三面或 HR 面：[`interview-round-prep`](https://github.com/Luyu2026/Skill-Bible/tree/main/interview-round-prep)。
4. 面完需要复盘录音和下次答案：[`interview-transcript-replay`](https://github.com/Luyu2026/Skill-Bible/tree/main/interview-transcript-replay)。

用“当前状态 → 对应 Skill”的句式呈现，不要只写泛泛的“使用面试准备 Skill”。不再使用“本 Skill 到这里结束”之类的总结性文案。

## 默认交付结构

只交付用户马上能用的六部分，不增加“候选人卡片”“投递台账”“面试建议”等解释性模块。

1. **你已给的信息，还差什么**：一个三列表格：已知信息 / 补什么 / 为什么影响选岗或简历。把时间、城市、毕业届别等全部放在这张表里。
2. **值得冲的好岗位**：表格单列岗位价值、薪酬信息是否可靠、岗位职责、当前差距和建议动作。薪酬没来源就写未公开。
3. **按当前经历适合投的岗位**：表格单列岗位职责、匹配证据、还要补什么、现在能否投；不要把职责和推荐理由混在一格。
4. **直接可复制的岗位版简历**：按不同适配岗位输出“无真实数据占位版 / 逻辑自洽示例数据版 / 使用建议”四列表格；示例版用于展示完整、有数据的表达标准。
5. **校招/社招下一步与反馈清单**：先用一张主流程表给出动作、准备材料和产出，再用最小记录字段与三条反馈规则，说明如何更新下一轮；不混入面试功能。
6. **关联 Skill**：按简历、单场面试、多轮面试、面试复盘四种状态，给出对应 Skill 的直接链接。

## 飞书交付

优先使用 `lark-cli docs +create --as user` 创建飞书 XML 文档；不要把 Markdown 导入为飞书文档。飞书不可用、未授权或创建失败时，才生成本地 Markdown：

`job-application-matches/<候选人或目标方向>-投递匹配与岗位版简历.md`

## 质量检查

- 是否先问清校招/社招，并使用了对应信息源边界？
- 校招是否先用默认池召回，再只核验少数候选 JD？
- 社招是否只使用用户给的岗位材料？
- 是否记录了岗位来源和时效，而非把列表当官方 JD？
- 是否区分用户事实、合理迁移、待确认和示例？
- 是否交付至少一版无需用户补数据也能复制使用的事实版经历？
- 是否允许在材料不足时没有 A 级岗位？
- 是否优先接续了当前会话或用户已有投递清单，而不是让用户重复录入？
- 是否把投递反馈转成了下一轮岗位、简历或渠道的具体调整？
- 是否按需使用了 GitHub 优质案例机制，而非机械堆链接？
- 是否优先生成飞书文档，失败才降级本地 Markdown？

## 材料使用说明（输出文档末尾必带）

在交付文档的最后只保留一张“材料使用说明”表；表格后不再增加知识库提示、营销文案或额外解释。

| 材料层级 | 本次是否使用 | 作用 |
| --- | --- | --- |
| 用户简历、项目、投递记录、面试记录等本人确认材料 | 按实际填写“已使用”或“未提供” | 已使用时说明它决定了哪些事实、优先级或下一步；未提供时说明本次结论的边界。 |
| 目标岗位 JD、岗位链接或截图 | 按实际填写“已使用”或“未提供” | 已使用时说明它如何影响岗位判断、材料定制或面试重点；未提供时说明本次不做岗位专属判断。 |
| 互联网求职知识库 | 默认“未调用” | 无知识库权限，本次仍可基于用户提供的材料完成完整输出；如需进一步按目标行业、岗位能力和真实案例校准表达，可引入[高质量知识库语料](https://gte09oerz5.feishu.cn/wiki/FLSXwArGOijrh6kp125cMjsNngf)提升输出效果。 |

如果用户明确授权并且实际调用了互联网求职知识库，将最后一行改为“已调用”，并如实写清调用了哪类内容、如何帮助校准岗位语言、案例口径或追问重点；不得展示或复述知识库原文。