我造了一个AI求职流水线：从1500个岗位到几份精准投递

一位四十多岁的转行开发者，用一套自建的AI流水线接管了自己的求职过程。今年，这套系统评估了超过1500条招聘信息，其中1539条被自动淘汰，最终他真正投出的申请只有寥寥几份。这个悬殊的比例，恰恰是整个系统的设计初衷——不是为了多投，而是为了精准。

为什么要自己造轮子

作者的职业背景颇为曲折：在劳埃德银行工作过五年，当过八年邮差，做过两年Windows系统管理员，如今在亚马逊的印刷生产线工作。今年他刚完成英国开放大学的计算机与IT本科学位（BSc Computing and IT），却还没有正式的软件开发者头衔。他要找的是人生第一份开发岗位，而且必须是远程的。

对转行者而言，招聘平台格外令人疲惫。他筛选条件严苛，又从未担任过自己正在申请的职位。市面上买不到合适的工具，于是他干脆自己写了一个。

五阶段流水线如何运作

整套系统分为五个层次，每一层都在为“精准”服务。

采集与去重

第一阶段从十六个API和RSS源收集数据，再用Playwright对没有API的平台做抓取——包括Indeed、StepStone、带保存会话的LinkedIn，以及德国劳工局（Arbeitsagentur）。所有结果进入带去重机制的存储，确保同一条招聘绝不会被处理两次。一次LinkedIn抓取就能带回112条结果。

Playwright是微软开发的浏览器自动化框架，支持Chromium、Firefox和WebKit，可以像真实用户一样操控网页——包括点击、填写表单、等待动态内容加载。它相比传统爬虫（如requests+BeautifulSoup）的优势在于能处理大量依赖JavaScript渲染的现代招聘页面。"带保存会话"指的是将登录后的Cookie和本地存储持久化，避免每次抓取都重新登录，也降低触发反爬机制的风险。RSS源则是更轻量的方案，许多招聘平台提供标准化的RSS Feed，无需模拟浏览器即可定期获取新职位列表，两种方式结合使用可以覆盖更广的数据来源。

硬规则过滤

在任何模型介入之前，廉价的规则先做一轮淘汰：标题里有"Senior"？淘汰。城市超出通勤半径？淘汰。要求三年以上经验？不是目标层级。作者特意不让这一步调用模型——规则是免费的，而且可审查，这是关键的工程取舍。

AI评分

通过硬过滤的岗位才交给语言模型阅读。模型会对照作者“诚实的个人档案”评估匹配度，连那些通常要到面试才暴露的限制也考虑在内。比如要求“书面与口语德语达到谈判级别”且面向客户的岗位，对他并不合适——他的书面德语只有B1水平；但团队内部的德语交流没问题，口语已达C1。这种细颗粒度的自我画像，是模型能给出靠谱判断的前提。

这里的"语言模型"指的是以GPT-4、Claude等为代表的大型语言模型（LLM），其核心计费单位是Token——大致可理解为文字片段，英文约每4个字符为1个Token，中文更为密集。调用API处理一条招聘信息通常消耗数百至数千个Token，在大批量场景下成本迅速累积。这也是作者坚持将硬规则前置的根本原因：让规则先淘汰掉明显不符合条件的80%-90%，剩余少量候选再交给模型精读，既控制了费用，也让模型的"判断力"集中在真正需要语义理解的边界案例上。

验证真实文本

这一阶段是“用血的教训换来的”。聚合平台的标题往往美化失真：六个看似完美的LinkedIn候选岗位，在他读到真实招聘原文后全部出局。标着"Junior"的职位实际要五年经验，标着"Remote"的职位实际要每周三天到另一个城市坐班。现在的规则是绝对的——在真实招聘原文被加载并阅读之前，任何岗位都不许进入申请清单。

招聘聚合平台（Job Aggregator）的商业模式决定了它们倾向于优化点击率而非信息准确性。这类平台通过API或爬虫从雇主官网、ATS系统批量同步职位，但同步存在延迟，且平台自身会对标题、描述做二次加工以提升搜索排名。常见的失真模式包括：将"需要C1德语"的岗位标记为"English OK"，将要求定期到访的混合办公岗位标记为"Remote"，或将实际需要5年经验的中级岗位以"Junior"名义发布来吸引更多申请者。这些失真在自动化流水线中会被成倍放大——如果不加验证就批量投递，候选人将在明显不匹配的岗位上浪费大量时间。

最后一公里交给人

第五阶段是人。作者亲自打开URL、亲自读招聘内容，然后按表单的具体要求逐一撰写申请。没有群发信，没有模板化投递。“当申请变得昂贵，你才会真正去读”——这正是整套系统想要达到的效果。

一个转行者的几条经验

作者在实践中提炼出几点值得借鉴的原则。

先用规则硬过滤，再调用模型。 规则不花钱，token要花钱。把廉价的判断前置，是控制成本和保证可解释性的基本功。

绝不让AI凭空生成招聘信息。 直接问模型“有哪些职位”，它会编造出看似可信、连URL都像模像样的假招聘。因此这套流水线只评估抓取器真实加载到的内容，模型不负责“找”，只负责“判断”。这一点对任何用大模型做信息检索的人都是重要提醒。

最后一公里必须是人。 流水线的目标是让人变得挑剔，而不是变得偷懒。

对转行者来说，流水线本身就是作品集。 作者一直在等一个能证明自己会写软件的项目，后来才意识到——最诚实的证据早已在运行：有测试的Python代码、真实的抓取器、去重机制、CI，一套每天都在用、带来真实后果的系统。相关工具已开源：job-sweep 是抓取工具包，remote-job-engine 负责搜索与评分，其中SQL Query Builder还作为在线Demo运行。

把工具握在自己手里

作者正在寻找AI、自动化或数据方向的初级/助理岗位，完全远程，身处德国或英国（他是英国公民）。

这个案例给求职者的启示很直接：在信任招聘平台之前，先造出属于自己的工具。 平台并不以你的利益为导向，但你亲手写的流水线会——因为那是你为自己定制的。对于处在职业转折点、又具备技术能力的人来说，把求职这件事“产品化”，既解决了实际痛点，又顺手打造了最有说服力的能力证明。

背景补充

这个问题在AI领域被称为"幻觉"（Hallucination）：语言模型在训练时学习了大量招聘信息的格式与措辞，因此当被要求列举职位时，它能流畅生成结构完整、公司名称和URL看似真实的内容，但这些内容本质上是统计概率的拼接，而非对真实世界状态的检索。与搜索引擎不同，LLM没有实时索引，也无法验证生成内容的真实性。将模型的角色严格限定为"评估者"而非"检索者"，是目前在生产系统中使用LLM的重要工程原则之一，也是RAG（检索增强生成）架构兴起的核心动机——先检索真实文档，再让模型基于文档作答。