把找工作当成一个工程问题：用 AI 编码 CLI 搭一套属于自己的求职评估系统（原理 + 实操全拆解）

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

一句话先把结论给你：现在技术岗求职最大的不对称，是公司那一侧早就用机器在批量筛人，而你这一侧还在手动点开一个又一个职位描述。要扳平这个差距，靠的不是"AI 帮你海投"，而是反过来——把一套评估系统装进你自己常用的 AI 编码命令行里，让它替你读职位、对照简历打分、生成定制简历、查这个岗位是不是"幽灵职位"，最后把要不要投的决定权留给你。 本文会把这套思路从原理到操作整个拆开讲：它为什么跑在终端里而不是做成网页、它那套 A–F / 1.0–5.0 的评分引擎是怎么工作的、为什么要专门加一个真实性检测模块、定制简历背后的"关键词镜像"到底是什么、批量评估时多个子进程是怎么并行的，以及你怎么在十分钟内把它装起来跑出第一份评估报告。

我自己折腾下来最大的感受是：它真正解放的不是"投递"这个动作，而是"投递前的判断"。 把重复的读、比、记交给机器，把"这个岗到底值不值得我花一个下午改简历"这种需要人来拿主意的事留给自己。

想看完整拆解，往下翻。

一、先说清楚：现在的技术岗求职到底卡在哪

很多人对找工作这件事的痛苦，停留在"投了没回音"这种情绪层面。但如果你愿意把它当成一个系统来看，会发现卡点其实非常具体，而且大部分是结构性的。

第一个卡点：筛选是单向的

招聘这件事在过去几年发生了一个很隐蔽的变化：公司筛你，用的是机器；你筛公司，用的是肉眼。

任何一家超过五十人的公司，背后基本都挂着一套申请人追踪系统（ATS，Applicant Tracking System，说白了就是企业用来批量收简历、自动打分、把"看起来匹配"的人挑出来交给 HR 的后台软件）。Greenhouse、Ashby、Lever、Workday 这些名字你可能在投递页面的网址里见过，它们干的就是这件事：把成百上千份简历按职位要求自动过一遍，排个序，再决定哪几份能送到真人面前。

行业里流传一个数字：通过 ATS 提交的简历，超过七成在真人看到之前就被过滤掉了。 这个比例不一定每家都精确，但方向是对的——你精心写的那份简历，很可能压根没被人读过，就被关键词匹配这道闸门拦下了。

问题在于，公司那一侧已经全面自动化，求职者这一侧却几乎是纯手工。你打开招聘网站，搜一个关键词，跳出来两百多个岗位，然后只能一个个点开，把每份七八百字的职位描述读完，再凭感觉判断"这个像不像我能投的"。这就是莫潇羽@无忆研习社想反复强调的那个核心矛盾：一边是流水线，一边是手工作坊。

第二个卡点：你读完才发现根本不合适

更扎心的是，这套手工流程的"废品率"高得离谱。

按那位把这套系统开源出来的作者的实测，他评估过的岗位里，大约有七成多最终评分都低于"值得投"的门槛。换句话说，每读十份职位描述，可能只有两三份真正值得你认真对待。剩下那七八份，你是读完八百字之后才发现不合适的——时间已经花掉了。

这里的浪费是双重的：一是阅读本身的时间，二是你在"看起来沾边"的岗位上改简历、写求职信、填那种十几个字段的申请表所花的精力。等你折腾完十来份，两周后陆续收到的是一批"经慎重评估，我们决定……"的自动回复。

第三个卡点：你投的岗位可能根本不存在

如果说前两个卡点还只是"效率低"，那这第三个就有点离谱了——你认真对待的那个岗位，可能从一开始就没打算招人。

这类岗位有个专门的名字，叫"幽灵职位"（ghost job）：公司是真的，招聘页面是真的，岗位挂在那儿也是真的，但背后没有任何一个招聘经理在等着看你的简历。 它可能是用来攒人才库的、是预算还没批下来的占位、是合规要求必须公开发布的内部内定岗，甚至有些是为了给现有员工制造"你随时可被替换"的压力而挂出来的。

这不是小众现象。多份行业报告给出的区间是：2026 年前后，主流招聘平台上的岗位里，大约有五分之一到接近三分之一属于"挂着但不真招"的状态，比 2022 年差不多翻了一倍。还有调研显示，相当高比例的招聘从业者承认自己所在的公司发过这类岗位。落到个人身上，平均每碰上一个幽灵职位，就要白白搭进去将近一个工作日的时间——而你完全不知道自己投进了一口空井。

把这三件事连起来看

把上面三点叠在一起，你会得到一张相当残酷的图：投递量被人为推高（幽灵职位 + 各种自动海投工具制造的虚假繁荣），真人能看到的简历又被 ATS 过滤掉大半，而你判断一个岗位真假优劣的工具，还停留在"自己一个个点开读"的阶段。

这就是为什么，单纯"投得更多""投得更快"根本解决不了问题。海投只会让你更深地陷进这台机器里。真正的破局点，是把"判断"这件事本身工程化——在你投出去之前，就尽可能准确地知道：这个岗位是不是真的、值不值得投、我该怎么定位自己。这正是下一章要讲的思路转变。

二、换个思路：把"求职"重新定义成一个可工程化的问题

大多数所谓的"AI 求职工具"，本质上只是两类东西：要么是个简历改写器，要么是个无脑群发的海投机器人。前者帮你润色文字，后者帮你把同一份简历轰炸到几百个邮箱里。这两类工具有个共同点——它们都在帮你"更努力地投"，却没人帮你"更聪明地选"。

我自己踩过的坑就是这个。最开始也信过那套"广撒网"的逻辑，结果就是简历发得越多，回音的比例越低，人越来越没底气。后来才想明白一件事：求职的真正瓶颈，从来不是"找不到岗位"，而是"找不到既真实又匹配、值得我投入精力的那几个岗位"。

核心理念：做一个"过滤器"，不是做一个"喷枪"

这套系统最值得拿出来说的设计哲学，就一句话：它是个过滤器（filter），不是喷枪（spray-and-pray）。

"spray-and-pray"是个很形象的英文说法，直译就是"一通乱喷然后祈祷"——海投工具干的就是这事。而过滤器的思路完全相反：它默认你面对的是几百个机会，它的工作是帮你从里头筛出真正值得花时间的那一小撮，并且明确建议你别去投那些评分不达标的岗位。系统里甚至硬性写了一条：低于某个分数线（通常是 5 分制里的 4.0）的岗位，直接劝你别投——你的时间宝贵，招聘方的时间也一样。

这个取向特别重要，因为它从根上把"成功"的定义改了。海投工具的成功是"投得多"，过滤器的成功是"投得准"。莫潇羽@无忆研习社个人是更认同后者的：与其投一百个石沉大海，不如投五个每个都认真打磨过、确认过是真岗、确认过匹配的。

为什么偏偏卡在 4.0 这条线？这不是拍脑袋定的。按作者大规模评估后的实测分布，真正落在评估里的岗位，有七成多分数都低于 4.0——也就是说，绝大多数"看起来沾边"的岗位，认真评下来其实并不值得你投。如果没有这道线，你会把大量时间花在那些读完才发现不合适的岗位上。把阈值定在 4.0，等于强行把你的注意力锁死在"值得认真打磨"的那两三成机会上。这背后其实是一个很朴素的资源分配观：精力是有限且不可再生的，与其平均地撒在几十个岗位上、每个都只给到三分力，不如集中火力在少数几个上、每个都给到十分力。 在如今这个真人简历大半会被机器拦掉的环境里，"投得准"远比"投得多"更能换来真实的回音。

核心理念：把候选人这一侧也武装起来

前面讲过，招聘市场最大的不对称是"公司有 AI、候选人没有"。这套系统想干的事，用作者自己的话来概括就是一句：公司用 AI 来筛候选人，那就把 AI 也交到候选人手里，让候选人来挑公司。

这句话听起来像口号，但它确实是整个系统的出发点。所有的功能——评分、定制简历、幽灵职位检测、谈判脚本——都是在为这一个目标服务：把候选人那一侧长期缺失的"机器辅助判断能力"补上。 这是 2026 年招聘市场里一个一直没被认真填补的缺口，而这套系统就是想从候选人这一侧把它补上。

最关键的一条：人始终在环里（Human-in-the-Loop）

如果只让我留这套系统的一个设计原则，我会留这条：它永远不会替你自动提交申请。

这就是所谓的"人在环"（Human-in-the-Loop，简称 HITL，意思是 AI 负责干重活，但关键决策点必须由人来拍板）。AI 在这套系统里负责的是评估、分析、研究、生成内容——读职位描述、对照你的简历、查薪酬基准、起草求职信。但每一个"投不投""怎么投""点不点提交"的决定，都交还给你。

这条原则不光是个道德姿态，它也是实打实写进默认提示词里的：系统的默认配置明确指示 AI 不要自动投递。当然，作者也很坦诚地提醒——AI 模型的行为有时是不可预测的，如果你自己改了提示词或者换了别的模型，风险就要自己承担，所以任何 AI 生成的内容，投出去之前都得自己再过一遍。

我特别欣赏这种坦诚。它没把自己包装成"帮你躺着拿 offer 的神器"，而是老老实实告诉你：这更像一个特别能干的研究助理，帮你把所有重复性的分析活儿干完，把你的时间和精力解放出来，用在真正需要人来判断的地方。

这种思路对"人"提出了什么要求

顺带说一句，把求职工程化，对你自己也是有要求的。它意味着你得：

• 愿意把模糊的"感觉这个岗不错"翻译成明确的、可打分的标准；
• 接受"少而精"，能忍住不去海投的冲动；
• 把每一次评估的副产物（比如面试故事、谈判话术）当成可以复用的资产攒起来。

把这几条想清楚，后面所有的功能模块你才会用得顺。下一章，我们就从最底层开始：这套系统到底长什么样、为什么要做成跑在终端里的本地工具。

三、整体架构：一套跑在 AI 编码 CLI 里的本地系统

理解这套系统，最反直觉的一点是：它不是一个网站，也不是一个手机 App，而是一堆"装进你现有 AI 编码命令行里的能力"。 这个设计选择背后有很清晰的考量，值得单独讲讲。

它寄生在你已经在用的 AI CLI 上

所谓 AI 编码 CLI，指的是 Claude Code、Codex、OpenCode、Gemini CLI、Qwen、GitHub Copilot 这一类——你在终端里打开它，用自然语言给它派活，它能读文件、写文件、跑命令。这套求职系统的做法，是不自己造一个全新的 AI，而是直接"骑"在你已经订阅的那个 CLI 上面。

这么做的好处很直接：

• 不用再单独付一份钱。 你本来就为某个 AI CLI 付着月费，这套系统不额外收费，它本身是开源的、MIT 协议、对个人永久免费，唯一的成本就是你已经在用的那个 CLI。
• 换引擎自由。 同一套评估规则，你喂给 Claude、OpenAI、Gemini 还是 Qwen，得到的推理是可比的。哪个便宜、哪个质量好、哪个更注重隐私，你随时换。
• 数据全在自己机器上。 这是莫潇羽@无忆研习社最看重的一点：你的简历、联系方式、个人资料，全程留在本地，只会直接发给你自己选的那个 AI 服务商，不经过任何第三方的服务器。没有云端、没有埋点、没有账号。

它到底由哪几块拼起来

把外壳掀开，这套系统其实就由三样东西组成，朴素得有点出乎意料：

• 一批 Markdown 技能文件。 系统的全部"能力"——十几种工作模式（评估、扫描、生成简历、写求职信、批量处理、查申请状态等等）——本质上就是十几个 Markdown 文件，里头写满了给 AI 看的指令和规则。
• 一个用 Go 写的终端面板（TUI）。 TUI 就是"跑在终端里的图形界面"。这个面板叫 Dashboard，基于 Bubble Tea 框架做的，你可以在里头浏览、筛选、排序自己的整条求职管道，不用去翻一堆零散的文件。
• 一座 Playwright 桥。 Playwright 是个浏览器自动化工具。对于那些没有干净 API 的招聘门户，系统会通过你的 AI CLI 调起 Playwright，让它像人一样去网页上翻职位。

除此之外，剩下的全是配置。这意味着整套东西的"可改造性"极强——你想改评分权重、加几家目标公司、把模式翻译成中文、调整谈判话术，直接告诉 AI 改哪里就行，因为 AI 读的正是它自己会用到的那些文件，它知道该动哪一处。

用五个动词概括整条流水线

如果要把这套系统的工作流压缩成最短的描述，作者给的版本是五个动词。我把它整理成一张表，方便你建立整体印象：

这条流水线最妙的地方，是前四步基本可以自动跑，第五步死死地卡在人这里。 这就把"机器擅长的重复劳动"和"人类擅长的价值判断"干净地分开了。

为什么是"本地优先"而不是做成 SaaS

最后说一句架构选型的话。把这种工具做成网页版的 SaaS（在线订阅服务）当然更好商业化，但作者偏偏选了"本地优先"。原因不复杂：求职是一个人信息最敏感、心态最脆弱的时刻之一。 你的完整简历、你正在偷偷看的机会、你的联系方式，这些东西一旦上传到别人的服务器，主动权就不在你手里了。本地优先的代价是你得会在终端里敲几条命令（哪怕你不是专业写代码的），换来的是数据始终攥在自己手上。这笔账，怎么算都划得来。

四、评分引擎：从一个 URL 到一份结构化评估报告

如果说前面都是铺垫，那这一章才是整套系统的心脏。所谓"把求职工程化"，最具体的体现就是这台评分引擎：你丢给它一个职位链接或者一段职位描述，它读你的简历、读职位要求、读你的作品集，然后吐出一份结构化的报告，外加一个分数和一个等级。

输出长什么样：一个分数 + 一个等级 + 一组结构化模块

先说最终产物。每次评估，引擎都会给你两层结果：

• 一个 1.0 到 5.0 的分数，外加一个 A 到 F 的等级。分数低于 4.0，系统就会明确建议你别投。
• 一份按结构化模块（Block）组织的完整报告，而不是一句干巴巴的"匹配度 78%"。

这份报告的价值，恰恰在于它不只给结论，还给出"为什么是这个结论"的全过程。下面逐块拆开。

六个核心模块（Block A–F）分别在干什么

这里有几个点值得单独说：

Block A 里的"岗位原型"是个关键设计。 系统会先判断这个岗到底属于哪一类——是偏 LLMOps（大模型运维）、偏智能体系统、偏产品经理，还是偏解决方案架构师。判断出原型之后，它才会套用对应的评估细则。这一步很聪明，因为同样叫"AI 工程师"，不同原型看重的能力完全不一样，用一把尺子量所有岗位是会出错的。

Block B 的核心是"用推理而不是关键词匹配"。 这是它和传统 ATS、和普通简历工具最本质的区别。它不是去数你的简历里有没有出现"Kubernetes"这个词，而是去推理你那段"带团队把一个服务的可用性从两个九做到三个九"的经历，到底能不能支撑岗位要求的"大规模生产环境经验"。它会逐条把职位要求映射到你简历里的具体证据点（proof point），还会主动标出差距，并给差距标上严重程度、提出弥补方案。

Block F 会沉淀面试故事。 STAR 是行为面试里经典的回答框架（Situation 情境 / Task 任务 / Action 行动 / Result 结果），这套系统在 STAR 后面又加了个 R——Reflection（复盘反思）。每评估一个岗，它都会针对性地生成几个 STAR+R 故事，并且把它们攒进一个故事库里，最后帮你提炼出 5 到 10 个"母故事"——这几个故事足够灵活，几乎能回答任何行为面试问题。这一块的价值在后面"故事库"那章还会展开。

那个独立的 Block G：真实性检测

除了 A 到 F，还有一个游离在评分体系之外的 Block G——岗位真实性检测。它专门用来标记那些可疑的诈骗岗和幽灵职位。

注意一个细节：Block G 不影响那个 1.0–5.0 的主分数，它是一项独立的合法性检查。 这个设计很合理——一个岗位"匹不匹配你"和"它是不是真的在招"是两个正交的问题，不该混在一个分数里。这一块太重要，下一章会专门讲。

背后那套"加权维度"：从 10 维到 6 维的演化

很多介绍会强调这套系统有"10 个加权维度"，也有的说是"6 个维度"，这俩说法其实都对，只是处在不同阶段。

作者在还没开源、自己私用的时候，用的是一套带 10 个加权子轴的评分表，覆盖的维度大致包括：

• 技能匹配度
• 经验 / 级别匹配
• 公司阶段与文化
• 薪酬与福利
• 地点 / 远程政策
• 职业成长潜力
• 团队质量
• 产品与技术方向的兴趣度
• 稳定性信号
• 个人价值观契合度

每个维度都带权重，可以按你自己的偏好调。等到正式开源时，作者把这 10 个子轴收敛成了 6 个类别维度，让公开版更好理解和维护，官方把当前最新的完整评分细则单独挂在方法论页面上。这 6 个维度大致是：匹配度、北极星目标对齐、薪酬、文化信号、危险信号（red flags）、全球适配度，最终产出一个带引用的 1.0–5.0 分——引用会精确到你简历的某几行、职位描述的某几条要求。

我觉得这个"从 10 维收敛到 6 维"的过程本身就很有启发：私用时可以追求颗粒度，开源给大众用时，可理解性比颗粒度更重要。 维度不是越多越好，关键是每一维都能被人看懂、能被人按自己的情况去调。

一个现实的提醒：头几次评估不会很准

最后泼一盆冷水。系统的文档里有一句很实在的提示：头几次评估的结果不会太好，因为它还不了解你。 这套引擎的质量高度依赖于它对你的了解程度——你的简历写得够不够细、你的偏好和权重调得对不对、你的目标原型选得准不准。它不是开箱即用就完美的魔法，而是一个越用越贴合你的系统。这一点期望值要摆正。

五、Block G 与"幽灵职位"：为什么要专门做一个真实性检测

第一章里提过幽灵职位的概念，这一章把它和系统里的 Block G 模块放在一起讲清楚——因为这是整套系统里我个人觉得最"懂行"的一个设计。

幽灵职位到底有多普遍

先把规模感建立起来。多家机构在 2025 到 2026 年间给出的数据，方向高度一致：

• 主流招聘平台上的岗位，大约五分之一到接近三分之一处于"挂着但没真打算招"的状态，这个比例比 2022 年差不多翻了一倍。
• 在一些以 ATS 起家的招聘平台上，被认为是"假"或"已填满"的岗位比例同样落在两成上下。
• 多份针对招聘从业者的调研显示，承认自己所在公司发过幽灵职位的人占了相当高的比例，有调研里这个数字甚至高达八成以上；其中相当一部分是"经常发"。
• 不同行业差异巨大：政府类、教育与医疗、信息与科技这些领域的幽灵职位比例往往明显偏高。
• "每个岗位最终真招到人"的比率在过去五年里几乎腰斩——从大约每十个岗位招到八个人，掉到了每十个岗位只招到四个人左右。

这些数字背后的逻辑也不难理解：招聘平台奖励"活跃度"，刷新一个旧岗比关掉它更省事；自动海投工具又在源源不断地往池子里灌低匹配度的简历，制造出一种"需求很旺"的假象。两头一夹，结果就是一个吞掉你时间、精力和信心的简历黑洞。

幽灵职位为什么对求职者特别有害

它的伤害不只是浪费时间这么简单。最阴险的一点在于心理层面：当你投了上百份申请却几乎收不到任何回音时，你的大脑很难理性地得出"这里头很多本来就是假岗"的结论，它更容易得出的结论是"我不够好"。这种自我否定的累积，比浪费几个小时严重得多。

所以，能在投递之前就识别出幽灵职位，本质上是在保护你的判断力和心态。 这正是 Block G 存在的意义。

Block G 是怎么识别的：用的全是"免费信号"

Block G 的聪明之处在于，它不需要任何付费数据或特殊权限，全靠一些公开的、免费的信号来给岗位的"真实性"打个风险标记。它会综合参考这样几类线索：

把这些信号综合起来，Block G 就能给一个岗位贴上"可能是幽灵职位"的标签，提醒你投递前再多做一步尽职调查。

扫描器里的 --verify：再加一道闸

除了 Block G 这个评估层面的检测，系统的扫描器还提供了一个更硬核的验证手段——--verify 模式。

它的工作方式是两步走：先用 API 把岗位列表拉下来，再用 Playwright 一个个去网页上验证这个岗到底是不是还真的在招，把那些已经关闭却还挂在聚合页上的过期岗过滤掉。这相当于在"评估"之前先做了一道"去伪"，让你后面花时间评估的，尽量都是还活着的真岗。

一点延伸思考

我自己用下来，觉得 Block G 这类设计的真正意义，是把求职者从"被动承受"变成"主动核查"。 过去你只能默默地投、默默地等，把所有沉默都归咎于自己；现在你至少能在投之前问一句："这个岗，是不是真的在招？" 这一问，可能就帮你省下了将近一整天的无效投入，也省下了一份本不该承受的自我怀疑。

六、定制简历的原理：关键词镜像 + 自适应框架，而不是无脑替换

普通求职者一份 PDF 简历走天下，谁都投同一份。这套系统的用户则是每投一个岗，就有一份专门为这个岗调过的简历。 但这里的"定制"不是简单的查找替换，背后的原理值得讲细一点，否则很容易理解成"把岗位里的词抄到简历里"那种廉价操作。

核心手法：关键词镜像（keyword mirroring）

"关键词镜像"听起来玄乎，拆开看其实是两层意思：

第一层，提取。系统先从职位描述里"嗅"出这个岗真正在乎的关键词和能力点——不是随便抓几个名词，而是结合岗位原型判断哪些是真正的考核重点。

第二层，镜像。它把这些重点"映射"回你的简历，调整的是经验描述的侧重点和措辞，而不是凭空往里塞词。 比如同样一段项目经历，投一个偏工程的岗，它会把性能、稳定性、规模这些点往前提；投一个偏产品的岗，它会把用户价值、决策影响、跨团队协作往前提。素材是你真实的那段经历，变的只是讲述这段经历的角度。 这就是"自适应框架"（adaptive framing）的含义。

我特别想强调这个边界：它绝不是教你往简历里编造没有的经历。 它做的是"同一段真实经历，换一个更贴合目标岗的讲法"。这条线一旦越过，就不是定制，而是造假了，那是要出大问题的。

为什么要"镜像"：因为要先过 ATS 这道机器关

回到第一章那个数字：超过七成的简历在真人看到之前就被 ATS 过滤掉了。ATS 的过滤逻辑很大程度上就是在做关键词和要求的匹配。所以"关键词镜像"的第一层价值，是让你的简历能更顺地通过机器这道闸——你简历里讲述经历的用词，如果能和岗位真正看重的能力点对上，被机器误杀的概率就低。

但要注意，这套系统在评估你的匹配度时用的是"推理"而不是关键词匹配（前面 Block B 讲过）；而在生成简历时之所以要做关键词镜像，是因为对面的 ATS 仍然在用相对机械的方式读简历。换句话说：它对你用的是高级方法，但它知道帮你应付的那个对手还停留在初级方法，所以生成产物时必须照顾到对手的读法。这个"知己知彼"的设计挺到位的。

从内容到 PDF：模板渲染这一步

定制好内容之后，还要变成一份能投出去的、排版专业的 PDF。这一步的技术路线是：HTML 模板 + 关键词注入 + 自适应排版，最后用浏览器引擎（Playwright / Puppeteer 这类）把 HTML 渲染成 A4 的 PDF。

设计上也有讲究，比如默认用了 Space Grotesk 配 DM Sans 这样的字体组合，让产出的简历既有现代感又不失专业。用伪代码大致表达一下这条生成管道的逻辑：

输入：你的简历数据(JSON/Markdown) + 这个岗的职位描述
步骤 1：从职位描述里提取重点关键词与能力点
步骤 2：对照重点，对每段经历做"自适应框架"——调整侧重与措辞(不造假)
步骤 3：把调整后的内容灌进 HTML 模板(字体/版式已定义好)
步骤 4：用浏览器引擎把 HTML 渲染成 A4 PDF
输出：output/ 目录下一份针对该岗的定制 PDF
=> 投递前，你必须自己再过一遍

求职信也是同一套管道

值得一提的是，求职信（cover letter）走的是和简历几乎一样的生成管道：同样的关键词镜像、同样的 HTML + 浏览器引擎渲染成 A4 PDF。不同的是，求职信生成时会多问你几个互动式的角度问题——为什么是这个岗、你想解决什么问题、你打算怎么做、用什么语气——而且有一道"在对话里先给你看草稿、你点头了才生成"的审批闸门。 每次评估时它会自动起个草稿，你也可以用专门的命令随时补全和生成。

一句话总结这一章

定制简历这件事，真正的难点从来不是"改文字"，而是"判断该突出什么"。 这套系统的价值，就是把"读懂这个岗到底要什么、再决定我这段经历该怎么讲"这个最费脑子的判断过程，用机器辅助你完成——而最终那份简历到底投不投、要不要再手动改两笔，依然是你说了算。

七、扫描器与批量处理：零 token 拉职位 + 多 worker 并行

到这里，单个岗位的评估链路已经讲完了。但现实里你面对的是几百个岗位，所以这套系统在"量"上的处理能力同样关键。这一章讲两件事：怎么把岗位高效地"扫"进来，以及怎么"批量"地评估。

扫描器：直接打 API，零 token、零费用

很多人以为"扫描招聘网站"一定很费钱、很费 AI 调用。这套系统的扫描器恰恰相反——它的第一选择是直接去打 Greenhouse、Ashby、Lever 这些招聘平台的公开 API，把岗位列表拉下来。

这一步的妙处在于：它不消耗任何大模型 token，因为这一步根本不需要 AI 参与，纯粹是接口调用。 系统里预置了几十家公司的扫描配置（Anthropic、OpenAI、ElevenLabs、Retool、n8n 这类 AI 行业的主要玩家都在内），官方还在持续扩充，覆盖的招聘门户已经到了上百个的量级。

对于那些没有干净 API 的门户，扫描器才会退一步，通过你的 AI CLI 调起 Playwright，让它像人一样去网页上翻岗位。 扫描的产物是一个扁平的文件，里头列着所有