本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

先给只想要结论的朋友一句话：ai-job-search 不是一个网站、也不是一个 App，而是一套跑在 Claude Code 里的"求职工作流框架"。你把它 Fork 到自己电脑上，填好个人资料，就能用三条命令走完一整套流程——/setup 建档、/scrape 找岗位、/apply 生成简历和求职信。它最狠的地方不是"帮你写"，而是"帮你改"：一个 AI 负责起草，另一个带着全新上下文的 AI 专门去研究目标公司、给初稿挑刺，然后再改。写完还会真的把 LaTeX 编译成 PDF、逐页"看"一遍排版，甚至模拟招聘系统抽取简历里的文字层做关键词复核。它是 MIT 协议的独立开源项目，和 Claude Code 的开发方并没有从属关系。

这套东西之所以最近在开源社区里被反复讨论、一路冲上 GitHub 趋势榜前列、star 数很快过万，是因为它把一个"人人都痛、但很少有人做对"的事情——精准投递——拆成了可复用、可验证的工程流程。

下面我会从"为什么海投注定失败"讲起，一路拆到它底层依赖的 Claude Code 技能与子代理机制，再手把手带你把它跑起来，最后聊聊我自己折腾下来的几个心得和坑。想看完整拆解，往下翻。

一、ai-job-search 到底是个什么东西

我第一次看到这个项目的名字，脑子里冒出来的第一反应是"又一个 AI 简历生成器吧"。市面上这类东西太多了，套路也大同小异：贴一段岗位描述，吐一段 Markdown，完事。真正上手翻了它的仓库之后我才发现，方向完全不一样。

1.1 它是一套"工作流"，不是一个产品

准确地说，ai-job-search 是一套结构化的求职工作流框架，它把 Claude Code 这个命令行里的 AI 助手，改造成了一个"全流程求职参谋"。你不需要打开任何网页，也不用注册任何账号，整个过程都发生在你自己的终端里。

它的使用姿势是这样的：

• 第一步，把项目 Fork 到你自己的仓库，再 clone 到本地；
• 第二步，把你的简历、履历、证书这些材料喂给它，让它给你建一份结构化档案；
• 第三步，剩下的评估岗位、定制简历、写求职信、准备面试，交给 AI 一条龙跑完。

它的核心是三条命令，逻辑非常直白。我用一张流程图把主链路画出来，你一眼就能明白它在干嘛：

flowchart TD
    A["/setup 建立个人档案"] --> B["/scrape 搜索岗位并按匹配度排序"]
    B --> C["/apply 评估匹配 + 生成申请材料"]
    A -.-> A1["产出：结构化档案文件"]
    B -.-> B1["产出：带匹配评分的岗位清单"]
    C -.-> C1["产出：定制简历 + 求职信 PDF"]

看懂这张图，你就抓住了这个框架七成的精髓：建档 → 匹配 → 申请，一条主线跑到底。除了这三条主命令，它还配了几条辅助命令（比如补全技能、缺口分析、注册自定义模板），后面我会一个个讲。

1.2 一个必须先说清楚的前提

有一点我觉得必须放在最前面讲，免得后面产生误会：这是一个社区个人维护的独立开源项目，采用 MIT 开源协议，作者本人在项目说明里写得很直白——它和 Claude Code 背后的官方团队没有从属、赞助或背书关系，提到官方工具只是为了说明"这套流程是搭在哪条工具链上的"。

换句话说，它是一个"民间高手"用官方提供的能力，攒出来的一套自动化玩法。这一点其实挺重要：它意味着你完全可以按自己的需求去魔改它，而不用担心动了谁的"官方规矩"。

1.3 它到底解决了谁的痛

找工作这件事，说起来就四个字——投简历、等面试；做起来能把人熬秃。每天刷招聘平台刷到眼花，看到个差不多的岗位就得重新折腾一版简历和求职信。最让人崩溃的是，你熬了一晚上改出来的材料，投出去经常连个回音都没有，像扔进了黑洞。

ai-job-search 想解决的，正是这个"黑洞"问题。它不追求"帮你多投几家"，而是反过来——让你把每一份投递都做扎实。这背后其实藏着一个很反直觉的认知：在今天的招聘环境里，海投几乎是无效劳动。想弄明白为什么，我们得先看看你的简历投出去之后，第一关到底遇到了什么。

辛梓煜@词元二号站在研究这个项目的时候，最感兴趣的也是这一点：它不是在"提高投递数量"，而是在"提高每一次投递的命中率"。这是一个思路上的分水岭。

二、为什么"海投"没用：先搞懂招聘背后的机器筛选

要理解这个框架的价值，你得先接受一个可能有点扎心的事实：你的简历，很可能第一关就没被人看到，是被机器刷掉的。

2.1 挡在你和 HR 之间的那道"闸门"

现代招聘流程里有一个几乎无处不在的角色，叫 ATS（Applicant Tracking System，申请人跟踪系统）。你可以把它理解成企业招聘的"前台机器人"——所有投进来的简历，先经过它这一道自动化筛选，达标的才会被推到 HR 面前。

这道闸门有多普遍、又有多严？公开的行业数据给出的画面相当残酷：绝大多数中大型企业都在用 ATS 来处理简历，而在这些企业里，很大一部分简历会在机器筛选环节就被直接淘汰，HR 连看都不会看一眼。想象一下，一个热门岗位放出去，几天内可能收到成百上千份简历，靠人一份份读根本不现实，机器初筛就成了刚需。

这就解释了那个折磨无数人的场景：你背景明明对口，投出去却石沉大海——问题很可能不是你不够好，而是你的简历没能通过那道闸门。

2.2 ATS 到底怎么"读"你的简历

搞清楚 ATS 的工作方式，你才知道该怎么对付它。它的处理链条大致是这样几步：

这里有个特别关键、也特别容易被忽视的点：**即使两个人实际经验一模一样，只要关键词的写法不同，ATS 给出的分数就可能天差地别。**举个例子，岗位要"项目管理"，你写成"项目协调"，稍微传统一点的系统就可能识别不到；虽然更聪明的系统会尝试理解近义词，但你没必要把命运押在"它今天心情好不好"上。

再往深一层，稍微高级点的 ATS 还支持布尔搜索——招聘方可以用"与、或、非"这类逻辑运算符，拼出很精细的检索条件，比如"必须同时出现 A 和 B、但不能出现 C"。这意味着在一些筛选严格的岗位上，你简历里关键词的组合是否齐全，会直接决定你排在候选池的哪个位置。同时，很多系统还维护着一个庞大的简历数据库，你这次没被选中的简历，可能会被存进去，等下一个岗位空出来时再被检索到。

这里有一个特别容易被误解的点，我得专门说一下：优化关键词，绝不等于把岗位描述里的词一股脑抄进简历。机械堆砌关键词，一来在人看来非常刺眼、显得很假，二来一些成熟系统还会通过和海量真实简历的写法比对，识别出这种"注水"痕迹。正确的做法，是把这些关键词自然地融入你真实的经历和成果描述里——这本身就是个技术活，也正是 ai-job-search 后面用 AI 帮你干的核心事情之一：它不是替你"塞词"，而是帮你用招聘方看得懂的语言，把你真做过的事重新讲一遍。

2.3 花哨简历是"排版党"的坟墓

还有一个坑，专坑那些花了大价钱做"设计感简历"的人。ATS 在解析阶段最怕两样东西：多栏复杂布局和图形化元素。很多好看的双栏模板、带图标进度条的"技能雷达图"，在机器眼里就是一团乱码，甚至会把你的姓名、电话都解析丢。

所以对求职者友好的做法其实很朴素：单栏、清晰层次、纯文本能被正常抽取。这一点，恰恰是 ai-job-search 在后面"PDF 复核"环节死磕的地方——它不光要生成简历，还要保证生成出来的东西在机器眼里是干净、可读的。

2.4 结论：解药是"精投"，不是"多投"

把上面这些串起来，逻辑就通了：

• 海投失败，是因为一份"通用简历"对任何一个具体岗位的关键词覆盖都不够；
• 想过闸门，你得针对每个岗位的描述，把简历里真实存在、但没写清楚的能力，用对方看得懂的词重新组织一遍；
• 但"针对每个岗位重写一遍简历"这件事，靠人力根本扛不住，一天投三家就精疲力竭了。

这就是 ai-job-search 切进来的口子：用自动化把"精投"的成本压到你能承受的范围。它不是让你偷懒少投，而是让"认真投"这件事变得可持续。想让 AI 干好这件事，它得先有一套足够聪明的底层机制。下一节我们就掀开引擎盖，看看它是靠什么跑起来的。

三、它凭什么跑得起来：Claude Code 的技能与子代理机制

很多人看到"基于 Claude Code 构建"就直接划过去了，觉得那是开发者的事。但如果你想真正用好这个框架、甚至改造它，这一节的原理值得花几分钟搞懂。我尽量用大白话讲。

3.1 先认识一下 Claude Code

Claude Code 是一个跑在命令行里的 AI 编程助手。你可以把它想成一个住在你终端里的"数字助理"，它能读你的文件、写文件、执行命令，还能按照你事先写好的规矩办事。它本来是给程序员写代码用的，但因为它足够通用、又能被高度定制，慢慢就被人拿来干各种"结构化的自动化活儿"——求职，就是其中一个很妙的用法。

它有三个可定制的"积木"值得认识，ai-job-search 整套东西就是拿这三块积木搭出来的。

3.2 三块积木：斜杠命令、技能、子代理

**第一块：斜杠命令（Slash Command）。**就是你在对话框里敲的那种 /setup、/apply。它本质上是一段被起好名字、存起来的"标准指令"。你不用每次都把一长段要求复述一遍，敲一个斜杠命令，AI 就知道该照着哪套流程走。这正是它把"重复劳动"固化下来的方式。

**第二块：技能（Skill）。**技能比单条命令更"重"一点。它通常是一个文件夹，里面有一个叫 SKILL.md 的说明文件，外加各种支撑材料（模板、脚本、参考文档）。一个很聪明的设计是：平时只有技能的"名字和简介"被加载进上下文，AI 知道"有这么个本事可以用"；只有真正用到的时候，技能的完整内容才会被读进来。这样既省资源，又不会让 AI 的"脑容量"被一堆用不上的说明挤爆。

第三块：子代理（Subagent）。这块是理解 ai-job-search 精髓的钥匙。子代理相当于主 AI 临时"外包"出去的一个专员——它在一个全新的、干净的上下文里独立干活，干完只把最终结论回传给主线，中间那一堆过程和杂念，不会污染主对话。

三者的区别，我做了张表帮你对齐概念：

3.3 为什么"上下文隔离"这么关键

你可能会问：既然主 AI 已经写了简历，为什么还要专门叫一个子代理来审？让同一个 AI 自己检查一遍不行吗？

还真不太行。这里有个很反直觉、但一线用过 AI 的人都深有体会的现象：一个 AI 审自己刚写的东西，很容易"自我感觉良好"。因为它写的时候的所有思路、所有自我说服，都还留在上下文里，它会不自觉地维护自己的判断，挑不出真正的毛病。

而子代理不一样。它是在一个干净的上下文里"空降"进来的，它没看过起草者的心路历程，只看到最终的稿子。它会像一个第三方 reviewer 一样，冷静地拿岗位要求去对照、去研究目标公司、去揪那些"读起来通顺但其实很空"的套话。这种"换个脑子重新看"的机制，正是靠子代理的上下文隔离实现的。

3.4 为什么"求职"这件事，特别适合这套机制

你可能会好奇：这套技能加子代理的玩法，本来是给写代码用的，怎么套到求职上反而这么顺？

我琢磨下来，是因为求职这件事的"形状"，天生契合这三块积木。业内有一条被反复验证的经验法则：**判断该用哪块积木，看的是活儿的"形状"，不是活儿的大小。**一段反复要用的固定指令，就该做成命令；一套需要模板、脚本、规则手册撑着的多步流程，就该做成技能；一个需要在干净上下文里、和主线并行或隔离跑的活儿，才值得动用子代理。

对照一下求职：投每个岗位都要走"评估—起草—审阅—排版"这套固定动作，天然适合固化成命令；简历模板、求职信模板、评分规则这些需要成套材料支撑，天然适合封装成技能；而"跳出起草者视角、独立审稿"这个需求，又刚好命中子代理"上下文隔离"的看家本领。三块积木各就各位，谁也没被硬塞去干不擅长的活儿——这种"形状上的严丝合缝"，是它跑得顺、也跑得稳的深层原因。

理解了这三块积木，你再回头看 ai-