| name | job-application-match |
| description | 根据校招或社招用户的真实经历和岗位信息，筛选值得投递的岗位，并直接生成不虚构的岗位版简历经历。校招默认读取指定公开校招岗位池；社招只使用用户提供的 JD、截图、链接或表格。适用于“我该投什么岗位”“帮我从校招里找匹配岗位”“本地外企怎么筛”“根据匹配岗位改简历”等场景。 |
Job Application Match
把“我能投哪些岗位”变成一条可执行链路：找岗位、核验 JD、判断匹配、直接交付一版能放进简历的经历。它不是不透明的 ATS 打分器，也不会把普通参与经历虚构成主导项目。
先确认求职路径
如果用户没说清，第一句只问：你是校招还是社招？
| 路径 | 默认信息源 | 用户可补充 | 可以交付 |
|---|
| 校招 | 默认读取公开校招岗位池：https://campus.sma-wiki.cn/campus/campus_recruit.html?channel=ysgg | 任意链接、飞书表格、招聘截图、JD、城市和意向 | 候选岗位池、少量 JD 核验、优先级、岗位版经历 |
| 社招 | 不主动抓取 Boss 等受限或时效难核验的平台 | JD 链接、截图、文档、表格、复制文本 | 岗位排序、单岗判断、岗位版经历 |
默认岗位池只是“召回候选岗位”的公开来源，不等于官方 JD。用户提供的官方招聘页、公司 career 链接和岗位材料优先级更高。
输入与边界
最少材料
- 校招/社招。
- 简历或可用经历；校招生至少给学校、毕业时间、专业、校园/实习经历。
- 可接受城市或是否愿意迁居；没有就标记为待确认。
- 目标方向或明确不想投的方向；没有时才做探索性岗位池。
- 可选：额外岗位来源链接、飞书表格、JD、截图。
- 可选：已有投递清单、投递反馈、上一轮输出文档或本次会话中的历史投递信息。
绝不默认的事
- 不默认用户可以迁居、接受英语环境、接受降级或愿意做销售。
- 不把岗位列表页的名称当成完整 JD；只对前 3-5 个最可能的岗位打开官方或用户提供的链接核验。
- 打不开 JD 时，明确标记为“岗位名称/列表摘要推断”，不能给高置信度推荐。
- 不绕过网站限制、不批量抓取受限职位库、不自动投递。
- 不编造用户没有做过的职责、项目、规模、数据或结果。
信息来源优先级
- 用户提供的官方 JD、岗位截图、公司 careers 页面。
- 用户提供的招聘表格或公开招聘链接。
- 默认公开校招岗位池。
- 岗位名称和行业的有限推断，只能用于召回候选项，必须标记低置信度。
涉及“当前在招”“截止日期”“招聘要求”时，记录查询日期和来源日期；列表信息有时效，最终以官方岗位页为准。
核心原则
1. 先看硬条件，再谈匹配
先核对毕业届别、学历、专业限制、城市/迁居、语言、资格、截止日期和用户明确的底线。硬条件不满足，直接暂缓；信息缺失，写待确认，不能被其他分数掩盖。
2. 证据比关键词重要
每一个判断必须区分：
用户事实：用户明确提供的经历、数据、限制。合理迁移：不改变事实，只换成岗位语言的表达。待确认：必须由用户补的职责、规模、数据和边界。示例口径：只帮助理解，绝不能放进用户简历。
低颗粒经历也要给用户一版可直接用的事实版；但“主导”“增长”“提升 xx%”只在用户确认有对应事实时才能出现。
3. 排序不等于 offer 概率
优先级只帮助分配投递时间。输出中同时显示已有证据、主要缺口、JD 核验状态和下一步，不把“匹配分”写成录取概率。
4. 外部 GitHub 机制是迭代兜底
默认先使用用户材料和岗位来源。当材料不足以拆清筛选、匹配、简历定制或投递反馈的机制，或用户明确要求进一步调研时，参考 GitHub 上高质量的 job matching、resume tailoring、application tracker 项目。
参考的是产品/流程机制，不是照搬职位数据、简历内容或匹配结论。重点看：硬过滤与软匹配如何分开、岗位排序怎样回到经历证据、简历定制如何与岗位选择衔接、投递反馈怎样回流。高星只是热度信号，不是采用结论。可优先观察：
只有外部机制确实改变本轮方案时，才在交付中写出“参考了什么机制、补足了什么”；不要为显得全面而硬塞调研。
工作流
1. 建立候选人卡片
提取毕业时间、学历、专业、已有经历、城市、目标方向、语言和底线。对时间线做合理性检查：例如“社团经历起止时间”跨越中学到大学时，先确认能写进大学简历的实际起止时间，不要原样写成异常长经历。
先检查当前会话中是否已有简历版本、岗位清单、投递状态或 HR 反馈；有就直接接续，不重复问用户已经给过的内容。跨会话或 Agent 没有历史上下文时，不能假装记得，优先读取用户提供的飞书表格、Excel、文档、截图或复制的投递清单。
2. 按路径获取岗位
校招：
- 读取默认公开岗位池，并合并用户额外提供的表格/链接。
- 先按届别、学历、截止日期、城市和用户禁区做粗筛。
- 从岗位名称、行业和已知经历召回 5-10 个候选项。
- 只打开排序靠前的 3-5 个官方或用户提供的岗位链接，抽取职责、门槛和投递入口；若链接无法读取，不假装已核验。
社招：
- 只读取用户提供的 JD、链接、截图、文档或表格。
- 若没有岗位材料，交付“材料清单 + 输入模板”，不虚构本地机会。
3. 先分开回答两个问题：好岗位与适合投的岗位
用户先想知道“哪些岗位值得争取”，再想知道“我现在投哪里最有把握”。这两个问题不能混成一个匹配分。
先输出 值得冲的好岗位。每个岗位都单列：
- 公司、岗位、地点与来源；
- 岗位价值：平台/行业位置、可积累的能力、后续发展路径；
- 薪酬信息：有可靠来源才写，缺失时明确写“未公开，不承诺高薪”；
- 岗位职责：只写已核验 JD；未核验时标注“待核验”，不能混入岗位价值；
- 当前是否建议投，以及要补什么才具备竞争力。
再输出 按当前经历适合投的岗位。每个岗位单列：
- 岗位职责；
- 当前匹配证据；
- 可直接使用的简历版本；
- 补哪几条真实信息，能明显提高匹配度；
- 动作：现在投 / 补完再投 / 暂缓。
“好岗位”可以是冲刺项；“适合投”应当优先是用户目前有真实经历可以承接的机会。没有足够材料时，允许“本轮没有适合现在投的岗位”。
4. 直接生成岗位版简历
对每个“现在投”或“补完再投”的岗位，必须直接给出一段能放入简历的内容，而不是只给建议。统一用四列表格交付：
- 切入方向：对应的岗位方向。
- 无真实数据占位版：只用已知事实，预留最少的
[活动次数]、[参与人数]、[周期] 等确认位，用户填完即可提交。
- 逻辑自洽示例数据版：给一份完整、有数字、能帮助用户理解表达标准的示范版本。
- 使用建议：说明适合投什么岗位、要核实哪些数据、应放在简历第几条或替代哪条经历。
当用户材料已经有真实数据时，优先把第三列替换成该用户的真实数据版。材料不足时也必须给示例数据版，避免小白只看到方括号而不知道什么是好的数据表达。Agent 在内部区分用户事实与示例，不需要在交付中反复提示用户如何使用示例。
每个版本都要包含岗位名称、经历标题、可直接复制的要点。若需要整理完整简历，再把已核验岗位、事实和关键词交给 resume-jd-tailor；本 Skill 不重复做面试准备或泛泛的职业规划。
5. 用投递清单和反馈迭代
已有投递清单时，先读取其中的岗位、城市、渠道、投递日期、简历版本、当前状态、HR/面试反馈和拒绝原因。字段不全也直接使用已有信息，不要求用户重建表。
根据反馈更新下一轮输出：
- 连续无回复：检查岗位硬条件、简历首屏关键词、投递渠道和岗位层级；缩小不匹配岗位，调整简历标题、经历排序和关键词。
- 有 HR 回复、无业务面：保留岗位方向，强化项目/经历的职责、数据和自我介绍。
- 频繁进入面试：提高相似岗位的优先级，文末联动面试 Skill。
- 同一原因被拒：把它写为下一轮的硬边界或材料缺口，不再把同类岗位排在前面。
没有投递清单时，第一次交付只附一个最小清单模板：公司/岗位 | 来源 | 投递日期 | 简历版本 | 当前状态 | 反馈 | 下一步。不要强制用户使用特定工具；飞书表格、Excel、Notion、文档表格或消息文本都可以。
6. 合并输出“下一步与反馈清单”
不要把“下一步投递”和“投递反馈复盘”拆成两个模块。它们是一条连续链路：先完成第一轮投递，再用真实反馈让下一轮选岗和简历更准。
交付中用一张主流程表呈现，列为：什么时候 / 现在做什么 / 要准备什么 / 完成后得到什么。顺序按用户路径调整，但默认包含：
- 今天：确定 1 个主投方向和 1 个备选方向，并补齐真实经历事实。
- 明天：建立第一批岗位池。校招默认筛出 10 个机会（3 个冲刺、7 个适配）；社招只从用户提供的岗位材料中筛选。
- 48 小时内：核验优先岗位的官方 JD，完成岗位版简历并开始投递。
- 每投 5 个岗位或收到任何回复后：把投递状态、简历版本和 HR/面试反馈交给 Agent，更新下一轮。
紧接主流程表，用“投递记录怎么用”说明最小字段：公司/岗位 | 来源 | 投递日期 | 简历版本 | 当前状态 | 反馈 | 下一步。明确已有飞书表格、Excel、文档、截图或当前会话中的历史记录都可直接使用，字段不全也不要求重建。
再用一张两列表格写三条反馈规则：
- 有回复或进入下一轮：提高相似岗位优先级，并在关联 Skill 中进入对应面试准备。
- 有 HR 回复、但没有进入业务面：保留岗位方向，优先调整简历首屏、关键词、经历职责和数据表达。
- 至少 3 个同类岗位没有回复或被拒：判断硬条件、岗位层级、渠道或简历版本的问题，收紧下一批岗位的筛选边界。
最后给一句可直接复制的调用语：这是我的投递清单，请使用 job-application-match 根据投递状态和反馈，更新我的岗位优先级、简历版本和下一批投递计划。
不要把面试训练混进本 Skill；拿到面试后再通过关联 Skill 跳转。
7. 文末输出“关联 Skill”
交付文档最后新增一个独立的“关联 Skill”模块，按用户当前状态给出以下直接链接：
- 整理完整简历：
resume-jd-tailor。
- 收到一场具体面试：
interview-prep-brief。
- 已进入二面、三面或 HR 面：
interview-round-prep。
- 面完需要复盘录音和下次答案：
interview-transcript-replay。
用“当前状态 → 对应 Skill”的句式呈现，不要只写泛泛的“使用面试准备 Skill”。不再使用“本 Skill 到这里结束”之类的总结性文案。
默认交付结构
只交付用户马上能用的六部分，不增加“候选人卡片”“投递台账”“面试建议”等解释性模块。
- 你已给的信息，还差什么：一个三列表格：已知信息 / 补什么 / 为什么影响选岗或简历。把时间、城市、毕业届别等全部放在这张表里。
- 值得冲的好岗位：表格单列岗位价值、薪酬信息是否可靠、岗位职责、当前差距和建议动作。薪酬没来源就写未公开。
- 按当前经历适合投的岗位：表格单列岗位职责、匹配证据、还要补什么、现在能否投；不要把职责和推荐理由混在一格。
- 直接可复制的岗位版简历：按不同适配岗位输出“无真实数据占位版 / 逻辑自洽示例数据版 / 使用建议”四列表格；示例版用于展示完整、有数据的表达标准。
- 校招/社招下一步与反馈清单：先用一张主流程表给出动作、准备材料和产出，再用最小记录字段与三条反馈规则，说明如何更新下一轮；不混入面试功能。
- 关联 Skill：按简历、单场面试、多轮面试、面试复盘四种状态，给出对应 Skill 的直接链接。
飞书交付
优先使用 lark-cli docs +create --as user 创建飞书 XML 文档；不要把 Markdown 导入为飞书文档。飞书不可用、未授权或创建失败时，才生成本地 Markdown：
job-application-matches/<候选人或目标方向>-投递匹配与岗位版简历.md
质量检查
- 是否先问清校招/社招，并使用了对应信息源边界？
- 校招是否先用默认池召回，再只核验少数候选 JD？
- 社招是否只使用用户给的岗位材料？
- 是否记录了岗位来源和时效，而非把列表当官方 JD？
- 是否区分用户事实、合理迁移、待确认和示例？
- 是否交付至少一版无需用户补数据也能复制使用的事实版经历？
- 是否允许在材料不足时没有 A 级岗位？
- 是否优先接续了当前会话或用户已有投递清单，而不是让用户重复录入？
- 是否把投递反馈转成了下一轮岗位、简历或渠道的具体调整？
- 是否按需使用了 GitHub 优质案例机制，而非机械堆链接？
- 是否优先生成飞书文档，失败才降级本地 Markdown？
材料使用说明（输出文档末尾必带）
在交付文档的最后只保留一张“材料使用说明”表；表格后不再增加知识库提示、营销文案或额外解释。
| 材料层级 | 本次是否使用 | 作用 |
|---|
| 用户简历、项目、投递记录、面试记录等本人确认材料 | 按实际填写“已使用”或“未提供” | 已使用时说明它决定了哪些事实、优先级或下一步；未提供时说明本次结论的边界。 |
| 目标岗位 JD、岗位链接或截图 | 按实际填写“已使用”或“未提供” | 已使用时说明它如何影响岗位判断、材料定制或面试重点；未提供时说明本次不做岗位专属判断。 |
| 互联网求职知识库 | 默认“未调用” | 无知识库权限，本次仍可基于用户提供的材料完成完整输出；如需进一步按目标行业、岗位能力和真实案例校准表达，可引入高质量知识库语料提升输出效果。 |
如果用户明确授权并且实际调用了互联网求职知识库，将最后一行改为“已调用”，并如实写清调用了哪类内容、如何帮助校准岗位语言、案例口径或追问重点；不得展示或复述知识库原文。
