Hugging Face 博客最近介绍了一个叫 Job Searcher 的项目。

它听起来像“AI 帮你找工作”，但真正有意思的地方不是海投，也不是替你点申请按钮。它做的是另一件更窄的事：读简历，搜岗位，给岗位打分，并解释为什么适合或不适合。

这个边界很重要。原文没有说它是商业化产品，也没有说它和 LinkedIn 官方合作。DeepSeek V4 Pro 也不是线上推理依赖，它只在离线阶段做教师模型，负责生成训练标签。

我更在意的是这个问题：大模型擅长的结构化求职判断，能不能被蒸馏到一个 8B 小模型里，然后用低成本方式跑起来？

它解决的是“投不投”，不是“帮你投”

Job Searcher 的流程很直白，分三步。

用户上传简历，并设置岗位类型、工作方式、地点和自由备注。模型先根据简历生成一组接近 LinkedIn 搜索习惯的查询。然后，项目用 JobSpy 抓取这些查询返回的 LinkedIn 岗位。

最后，模型读取“简历—岗位”组合，按五个维度打分，并给出解释。

这五个维度是：技能匹配、经验相关性、教育与证书、行业或领域适配、资历层级匹配。

环节Job Searcher 做什么对求职者的实际影响
查询生成根据简历生成 LinkedIn 风格搜索词少花时间试关键词
岗位搜索通过 JobSpy 抓取 LinkedIn 查询结果结果受查询词和抓取范围限制
匹配评分按五个维度给岗位排序并解释帮你判断“投不投”，不保证面试

这类工具最适合的场景，是早期筛选。

比如一个技术求职者每周看到上百个软件工程岗位，最累的往往不是点击申请，而是判断三件事：岗位是不是要求过高，技能栈是不是假匹配，JD 里的领域要求是不是自己补不上。

Job Searcher 的价值就在这里。它不能替你做职业选择，但可以把“先看哪几个岗位”这件事排个序。

普通非技术求职者也能用，但边界更明显。如果简历写得很散，岗位描述又很短，模型给出的解释可能只是看起来顺。真正要做动作的人，仍然要回到 JD 原文，看硬性要求、地点、签证、薪资和工作方式。

技术路线的看点，是把判断拆成两个窄任务

项目的数据闭环不复杂，但有代表性。

它用了约 2500 份简历，来源是 Divyaamith/Kaggle-Resume。DeepSeek V4 Pro 先为这些简历生成查询。JobSpy 再根据查询抓取 LinkedIn 返回的岗位，形成约 10000 条岗位数据。

之后，教师模型继续为每个“简历—岗位”组合打标签，并为五个维度写解释。

线上运行时，依赖的是 Qwen3-8B，不是 DeepSeek V4 Pro。项目训练了两个 LoRA：一个负责查询生成，一个负责岗位评估。

这个拆法比“一个模型什么都干”更务实。

路线代表做法好处现实限制
在线调用通用大模型ChatGPT、Claude 类服务泛化强，交互自然成本、隐私、接口稳定性受外部服务影响
小模型蒸馏Qwen3-8B + 两个 LoRA成本可控，格式更容易固定依赖教师标签质量，任务外能力有限
传统关键词筛选ATS、关键词过滤简单成熟对个人求职者解释不足，容易误判

作者提到一个经验：双适配器比单适配器稳定。

原因也不难理解。查询生成和岗位评估不是同一种输出。前者要像搜索词，后者要像结构化评分。一个 LoRA 同时学两类任务，容易串格式，比如查询里冒出 JSON，评估里混进散文式解释。

这也是小模型蒸馏更现实的一面。它不是把 8B 模型训练成全能求职顾问，而是把任务边界压窄，把输出格式钉住。

我不太买账的是那种“本地小模型马上替代大模型”的说法。Job Searcher 更像反例：小模型能变得有用，靠的不是突然变聪明，而是教师数据、任务拆分和格式约束一起收紧。

还有一个关键变量：教师标注提示词的质量。

作者的经验是，提示词质量比学生模型尺寸更关键。比如把“技术匹配强”写成“简历有四年 Rust，岗位要求五年 Rust”这类具体判断，学生模型更容易学会解释方式。

这对开发者的动作很明确：如果要复刻类似工具，先别急着换更大的 student。更该先检查 teacher 的标注标准、字段定义和反例覆盖。

低成本部署能跑，但别把演示当成生产系统

Job Searcher 跑在 Hugging Face ZeroGPU Space 上，用 llama-cpp-python、Q4_K_M 量化模型和 LoRA-GGUF 侧载文件提供服务。

项目还做了一个工程取舍：把一次提交里的多个岗位评估，放进一次 GPU 调用里完成。这样可以减少每个岗位都冷启动的成本。

它还用了流式推理，把解释逐字送到界面。用户不会一直盯着空白页面等结果。

这些细节说明，这个项目不是在炫模型参数，而是在免费或低成本环境里抠可用性。

但限制也要摆在桌面上。

岗位来源不是全网招聘数据，而是 JobSpy 抓取 LinkedIn 查询结果。模型不会自动投递，也不能保证拿到面试。训练数据来自简历数据集和教师生成标签，是否覆盖不同国家、行业和资历段，目前看不清。

开发者如果想拿它当样板，可以重点看三件事：

  • 是否复用“两类任务、两个 LoRA”的拆法；
  • 是否能把 teacher 标注做得更一致；
  • 是否能在自己的数据源上验证排序质量，而不是只看界面能不能跑。

技术求职者如果想用类似工具，动作更简单：把它当第一轮筛选器。先让模型把岗位分层，再人工检查前十几个岗位的硬条件。不要让模型替你决定职业方向，也不要把解释当成事实证明。

接下来最该观察的，不是它界面多像一个产品，而是两个指标。

一个是排序质量：真实简历上，它是否比关键词搜索更能找出该投的岗位。

另一个是解释质量：当 JD 很短、很虚、充满招聘话术时，它会不会编出一套貌似合理的适配理由。

这两个问题如果过不了，小模型再便宜，也只是把噪音整理得更好看。若能过关，它才算把大模型的一小块判断力，实实在在搬到了个人工具里。