Job Application Match

Job Application Match

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

先确认求职路径

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

默认岗位池只是“召回候选岗位”的公开来源，不等于官方 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：将职位搜索、匹配和简历定制拆为阶段。
• 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。
2. 收到一场具体面试：interview-prep-brief。
3. 已进入二面、三面或 HR 面：interview-round-prep。
4. 面完需要复盘录音和下次答案：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？

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

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

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