Mads Lorentzen 在 README 里写了一段话，我读完之后决定认真看这个项目：“Sixty-nine tailored applications, twenty first interviews, and one signed contract later, I started as an AI engineer in June 2026. People kept asking whether this actually works. It got me hired.” 69 份定制申请，20 场一面，1 份合同，然后他在 2026 年 6 月入职当了 AI 工程师。这句”它真的帮我找到了工作”，是整个项目最好的广告。
他把帮自己找到工作的那套流程做成了开源项目 ai-job-search，官方描述一句话：The job search that runs on your machine。基于 Claude Code 跑在本地，评估职位、定制简历、写求职信、准备面试，MIT 协议，Fork 之后整条流水线就归你，改多少随你。
这个仓库 2026 年 3 月 23 日创建，到 7 月初突然爆发。单周新增约 1.3 万星，是 GitHub Trending 周榜第一；7 月中旬累计冲到 2.28 万，月末稳定在 2.3 万以上，位列 7 月 AI 项目月榜第六。对一个给个人求职用的工作流来说，这个增速在开源世界里相当罕见。
这篇文章想搞清楚一件事：它是真的把求职这件事工程化了，还是只是把”AI 帮你写简历”包装成了流水线。往下翻。
打动我的几个地方
先说它的核心工作流，三个斜杠命令闭环：/setup 构建个人档案，/scrape 抓取并去重职位，/apply 对指定职位跑完整申请流程。档案是地基，抓取是漏斗，申请是产出。外围还挂了 /rank、/interview、/outcome、/upskill、/html-report 等十来个扩展命令，把批量排序、面试准备、申请结果跟踪、技能差距分析全包了进去。
真正有区分度的是 /apply 内部的双代理设计。起草代理 Drafter 拿到职位描述和个人档案，生成 LaTeX 简历与求职信；审查代理 Reviewer 被要求独立调研这家公司，然后批判性地挑草稿的毛病；最后 Drafter 根据反馈修订。用两个 Agent 互相制衡而不是一个 Agent 一次生成，这个思路直接冲着 AI 写材料最致命的两个问题去：幻觉和模板化。
比双代理更狠的是它把质量门禁做进了流水线。简历用 lualatex 编译，求职信用 xelatex，AI 会读渲染后的 PDF 页面，反复迭代直到简历恰好 2 页、求职信恰好 1 页且无排版错误。可选的 pdftotext 会模拟 ATS 解析，检查联系信息完整性、阅读顺序和关键词覆盖率。生成不是终点，通过校验才是。
下面是 /apply 内部的完整流水线，输入、起草、质检、输出四层怎么串起来的，一眼能看明白：
图里最值得玩味的是质检层。多数 AI 求职工具把”生成完成”当成交付标准，这个项目把”编译通过、页数达标、ATS 可解析”当成交付标准。差之毫厘，投出去的效果完全不同，因为 HR 和 ATS 系统根本不在乎你用的模型多聪明。
第三个亮点是可扩展性设计。框架声明语言与国别无关，核心流程是通用的，具体市场靠门户技能接入：内置 Jobbank、Jobindex、Jobdanmark、Jobnet 等丹麦招聘网站，但通过 /add-portal 可以给任意本地招聘网站生成搜索技能。扩展点有三个：门户搜索技能、文档模板、档案里的自由文本评估标准。
安全上也有考虑。职位描述被当成不可信输入，工作流不会执行其中嵌入的指令，仓库里还有 security_guards.py 做 CI 守卫。不过 README 很诚实地补了一句：这是指令级防御，不是沙箱。翻译一下：别在明显可疑的网站上乱点，抓回来的内容提交前最好扫一眼。设计层面的东西聊完了，那它跑起来到底什么感觉？
上手什么感觉
这个项目没有”安装”这个概念，它是让你 Fork 下来跑在自己机器上的工作流。前置依赖有四个：Claude Code CLI、Python 3.10+、Bun、带 lualatex 和 xelatex 的 LaTeX 发行版。没有外部 API key 要配，Claude Code 自己就是引擎。
拉下来之后，在仓库目录里启动 Claude Code 就能开跑：
git clone https://github.com/MadsLorentzen/ai-job-search.git
cd ai-job-search
claude
进到 Claude Code 里，核心操作就三个斜杠命令：
/setup # 构建个人档案：导入文档、粘贴简历或接受访谈
/scrape # 抓取职位，去重并按匹配度排序
/apply <URL> # 对指定职位跑完整申请流程
下面是实际跑起来的一次会话，从 setup 到 apply 三步命令依次走完，末尾两行就是一次真实投递包的生成结果：
卡点主要集中在环境上。LaTeX 是最大的一道坎，很多人没有现成的 TeX Live 或 MacTeX，好在 TinyTeX 这类最小发行版也能满足 lualatex 和 xelatex 的需求。Bun 和 Python 反而是小事，装完就完。
另一个需要提前知道的现实：内置的门户搜索技能是丹麦市场的。中文或英语用户得用 linkedin-search、freehire-search 这类国别无关技能，或者自己跑 /add-portal 适配本地网站。而且 linkedin-search 有使用限制，因为自动访问违反 LinkedIn 服务条款，只能个人低流量使用。环境关卡摸清了，接下来要回答的问题更实际：这东西到底什么时候该用，什么时候该绕道走？
什么时候用，什么时候别用
适用场景用一张表说清楚：
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 质量优先的求职冲刺 | 有目标行业、想认真投的人 | 每份申请都定制，双代理把关 | 需要折腾本地环境 |
| 材料批量定制 | 同时投多个方向的人 | 简历与求职信按 JD 逐份生成 | 门户适配要自己来 |
| 隐私敏感 | 不想把简历交给第三方的人 | 数据全程不出本机 | 需要自备 Claude 额度 |
| 求职过程复盘 | 想跟踪每一份申请的人 | 结果跟踪、面试包、技能差距分析 | 跟踪效果依赖主动使用 |
不适合的情况也得说清楚：
-
完全不想碰命令行的，直接用 Teal、Simplify 这类 SaaS 更省事，打开网页填资料就行 -
想”投完就不管”的别来，框架只生成材料，发送得自己来，这是故意的 -
在国内市场求职的，门户生态基本要从零适配，投入产出比要自己掂量
它的价值主张和自动海投是相反的。LazyApply 那类工具追求的是数量，一键把简历群发到几百个岗位，赌概率。ai-job-search 走的是另一条路：把每一份申请做成可审计的定制产品，赌质量。适用边界画清楚了，再看它背后的社区靠不靠谱。
社区怎么样了
判断社区健不健康，别只盯着 Star 数。先看一组硬指标，数字本身会说话：
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | 2.3 万+（截至 2026 年 7 月末） | 7 月单周曾新增约 1.3 万 |
| 核心维护者 | 1 人（Mads Lorentzen） | Bus Factor 高风险 |
| 贡献者 | 17 人 | 对 5 个月的项目不算少 |
| Open Issues | 9 个（截至 2026 年 7 月 9 日） | 偏少 |
| 协议 | MIT | 商业友好 |
贡献者结构比预想的好。17 个贡献者里有为项目编写 CLI 技能的外部开发者，社区还维护了一个 fork 与适配索引帖，有人把丹麦之外的适配版本分享出来，甚至有人 fork 之后独立修了 bug 再回传。这种自组织程度，在个人项目里不多见。
风险点也明显：核心维护者就作者一个人。他在 2026 年 6 月入职当了 AI 工程师，本职工作忙起来之后还能不能维持现在的提交节奏，是实打实的问号。目前看答案偏向乐观，8 月 19 日还有新提交，第 342 个 PR 在修 jobbank-search 的日期字段问题，项目没停。
社区声音方面，最硬的一条来自作者写在 README 里的经历：69 份定制申请、20 场一面、1 份 offer，2026 年 6 月入职 AI 工程师岗位。英文评测媒体 The Next New Thing 在 2026 年 8 月做了完整上手视频。项目上线不到半年，Reddit 和 HackerNews 上成规模的讨论还不算多，以上判断主要基于文档、代码和 Issue 动态。数据和社区都摆完了，说说我的真实看法。
我的真实看法
先说结论：这是 2026 年上半年”AI Agent 进入个人事务性工作流”这个趋势里最有代表性的项目之一。它和写代码的 Agent 完全不同，处理的是简历、求职信、面试这种高情绪成本的个人事务，而它证明了 Agent 在这类场景里能稳定产出。
我一开始以为这就是个 prompt 套壳：给 Claude 一段”帮我写简历”的指令，加几个斜杠命令。翻完 README 和仓库结构之后改观了。Python 和 TypeScript 双语言实现，LaTeX 模板工程，CI 里跑安全守卫，围绕求职这件事它建了一整套工程设施，不是几句话的事。
它最值钱的判断是：求职材料的核心矛盾不是”生成”，是”验证”。AI 生成一封漂亮的求职信太容易了，难的是保证它不掺假、排版合规、能过 ATS。Drafter 和 Reviewer 互审解决前半段，PDF 页数硬校验和 ATS 模拟解决后半段。这个”生成之后必须过质检”的思维，是它区别于所有同类工具的分界线。
换个角度看它的定位。三条路径摆在一起，各自的位置很清楚：
和 SaaS 简历工具比，它的优势是数据不出机器、流程全透明可改；代价是没有现成的门户生态和客服，适配成本自己扛。和自动海投比，它把质量和可控放在数量前面，效率上限低，但每一份材料的质量下限高得多。对”认真找一份好工作”的人来说，后者重要得多。
一个可以拿出来争议的判断：2.3 万星里，真正跑起来用的人可能远少于收藏的人。9 个 open issue 对 2.3 万星的项目来说太少了，两种解释，要么维护者处理得太快，要么大部分人只是 star 了没动过手。我更倾向后者，毕竟 LaTeX 环境这道门槛已经能劝退一大半人。
趋势判断上，我不认为这种形态会昙花一现。个人事务自动化是 Agent 应用层接下来的主战场，ai-job-search 的价值不在于代码本身有多难，而在于它示范了一种范式：把高情绪成本的个人流程拆成可验证的流水线。这个范式会被复制到简历之外的无数场景。
还有一个细节值得注意：这套流水线把求职的闭环也做了。投出去之后，/outcome 记录结果，/gmail-sync 能从邮箱自动识别申请状态，/notion-sync 把进度同步进 Notion 数据库，/html-report 生成一份离线仪表盘。多数工具只做”投”这一步，它连”投完之后怎么跟进”都包了。判断聊完了，最后给你一句落到实处的建议。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/MadsLorentzen/ai-job-search |
| 社区 Fork 与适配索引 | https://github.com/MadsLorentzen/ai-job-search/discussions/78 |
先 Fork，再本土化
如果你正在求职、会用 Claude Code、愿意折腾一晚上环境，我的建议很直接：Fork 一份，跑 /setup 把档案建扎实，然后用 /add-portal 把你的目标市场门户接进来。它能帮你把每一份申请的质量下限拉高一大截。
如果你还在观望，盯两个指标：作者入职后是否保持现在的提交节奏，以及丹麦之外的门户生态是否长出来。前者决定项目会不会变成死水，后者决定你 Fork 之后的适配成本。这两点比 Star 数诚实得多。
一个把”找到工作”当成系统工程来做的项目，本身就在提醒我们一件事：AI 能帮人干的活，比大多数人想象的要深得多。求职这件事，它至少给出了一个不再靠运气的答案。