海投时代横评：这波AI求职CLI工具谁能让你少做无用功
海投时代横评：这波AI求职CLI工具谁能让你少做无用功
2026 年，AI 求职工具迎来了一轮罕见的爆发：ai-job-search 先是冲上 GitHub Trending 榜首，社区记录显示它单日新增超过 5,000 颗 Star、总量破 1.5 万、fork 接近 4,800，随后一个月内又涨了接近两万颗 Star，直到 10 月中旬仍在日榜速报里出现。与此同时，面向国内招聘平台的 boss-agent-cli 也在社区获得关注。当"海投"成为技术人求职的常态，这批命令行工具的涌现其实指向同一个问题：AI 到底能不能帮你把"广撒网"变成"少做无用功"？
本文不打算替任何一个项目站台。我会结合社区里流传的舆情信息与本地仓库源码，把当下 AI 求职 CLI 工具的能力边界、筛选准确率、工作流体验逐一拆开，最后给出可落地的选型清单——用事实和数据说话，让"少做无用功"这件事可验证、可复现。
一、为什么"AI 求职"突然变成了 CLI 的战场
在社区对 ai-job-search 的解读里，有一句话点破了本质：它真正解决的不是"写作能力"，而是求职过程的状态管理和质量控制。传统用 AI 找工作的流程，是打开聊天工具、粘贴 JD、粘贴简历、让模型改写、再手动导出——这套流程有四个工程师一眼就能看出的毛病：
- 上下文散：经历散落在旧 CV、LinkedIn、作品集、过往申请里，每次临时粘贴，模型既容易漏、也容易"补出"你没说过的东西；
- 生成物不可验证：模型写出来的简历"看着顺眼"，不代表 PDF 排版没炸、不代表 ATS 能读出文本层、不代表里面的公司信息是真的；
- 没有反馈回路：投了十个岗位，哪类有面试、哪类石沉大海，这些信息永远不会进入下一轮生成；
- 搜索与申请割裂：招聘站搜索、职位筛选、材料定制、结果记录，通常是四五套互不相通的工具。
把求职做成 CLI，本质上就是把这条碎片化的链路收拢进一个可版本化的本地工作区。ai-job-search 的 README 把这层定位写得非常直白："The job search that runs on your machine"，并且给出了一组真实的交付数据：作者本人用这套工作流投出 69 份定制申请、拿到 20 次初面、最终签下 1 份合同。这组数字来自仓库根目录的 README.md，是"它到底有没有用"最直接的证据。
二、能力盘点：两条路线、四种形态
把社区情报里提到的工具放在一起，可以归纳出 AI 求职 CLI 的两条技术路线：
路线 A：Agent 工作区/框架（ai-job-search）。它不是一个单一 CLI，而是一套以 Claude Code 为运行时的"求职工作区"。真正的应用逻辑不在传统后端代码里，而是四层结构：
- 命令层：
.claude/commands/apply.md、rank.md、outcome.md等定义了/apply、/rank、/interview等十余个命令的执行步骤； - 技能层：
.claude/skills/job-application-assistant/下的候选档案、行为画像、写作风格、职位评估框架； - 工具层：
.agents/skills/下每个招聘站点一个 TypeScript CLI（搜索/详情/JSON 输出契约），加salary_lookup.py薪资基准； - 产物层：
cv/、cover_letters/、documents/、job_scraper/存着生成结果与全流程状态。
路线 B：平台工具层（boss-agent-cli）。社区 2026-05 的文章把它描述为"给 AI Agent 使用的招聘工具层"：把 BOSS 直聘里的搜索、详情、沟通、跟进封装成一组 CLI，核心设计是 stdout 只输出 JSON 信封、用 boss schema 自描述能力、支持 MCP 接入 Claude Desktop/Cursor/Codex，并覆盖求职者端与招聘者端双工作流。
除了这两条主线，还有三种常见形态可以顺手对比：临时对话式（ChatGPT/Claude 粘贴 JD 一次性生成）、简历生成器 SaaS（表单 + 模板 + 导出 PDF）、自动投递爬虫（批量抓职位、批量投递）。下表把关键差异压缩成一张图：
| 维度 | 临时对话 | SaaS 简历器 | 自动投递爬虫 | boss-agent-cli | ai-job-search |
|---|---|---|---|---|---|
| 定位 | 一次性生成 | 模板产出 | 批量投递 | 平台操作层 | 完整求职工作区 |
| 状态管理 | 无 | 弱 | 无 | 中 | 强（本地文件即状态） |
| 可验证性 | 无 | 弱 | 弱 | 中 | 强（编译+ATS 校验） |
| 反馈闭环 | 无 | 无 | 无 | 部分 | 有（/outcome 回流校准） |
| 数据归属 | 云端 | 云端 | 云端/本地 | 本地+平台 | 本地优先 |
值得强调的是，"仓库本身即是产品"是路线 A 最特别的一点：命令是 Markdown 规格、评估框架是 Markdown 文档、CLI 是普通 TypeScript，任何使用者都能读、能改、能 fork。这正是它能引发大量技术博客二次创作的原因——它展示的不是"一个 AI 写求职信的小工具"，而是"把现实流程拆成文件、命令、校验和状态，让 coding agent 在本地执行"的工程模板。
三、筛选准确率：从关键词命中到"五维评估 + 双 Gate"
海投时代最大的浪费，是用关键词硬筛把大量机会筛错：搜"Python 后端"出来一半是"Python 爬虫"，JD 里写"高级 Go 经验丰富"和简历里"用过半年 Go"被当成同一层级。ai-job-search 对这件事的处理，是仓库里最能体现工程功底的部分，全部源码级可查。
评分框架定义在 .claude/skills/job-application-assistant/04-job-evaluation.md，包含五个打分维度：Technical Skills Match（权重 30%）、Experience Match（25%）、Behavioral/Culture Fit（15%）、Career Alignment（30%），Location 为 Pass/Fail 不参与加权。最终映射到五档结论：Strong Fit（75+）/ Good Fit（60-74）/ Moderate Fit（45-59）/ Weak Fit（30-44）/ Poor Fit（<30）。
两道硬 Gate是准确率的另一半。Eligibility Gate 把公民身份、PR、security clearance 等硬性资格做成"一票否决"，明文要求"Silence is not permission"——JD 没提不等于放行，大型雇主往往把资格要求写在自家招聘页而不是广告里。Language Gate 则要求 JD 要求的语言必须出现在候选人语言表中：未声明即 FAIL 硬拒；声明了但 JD 门槛明显更高（如 B1/B2 对"fluent"）则 FLAG 而非静默淘汰，把判断权交还给真人。这两道 Gate 共同保证了"分数高的岗位不会违反硬约束"。
批量排序层由 .claude/commands/rank.md 承担：/rank 把 /scrape 抓回的新职位交给并行 agent，每个 agent 只依据真实抓取到的 posting 文本打分，并明确规则"绝不从标题臆造内容"。排序时，location/language 的 FAIL 直接 veto 出局，7 天内截止的岗位挂 🔥 优先，/rank 还会对存储 deadline 做过期清扫、对超过 30 天未更新的 posting 打 ⚠ 年龄标记——过期职位和幽灵职位都不会再浪费你的投递。
最关键的是诚实性规则贯穿始终：评估框架明确"gaps are stated, never smoothed over"，ATS 关键词检查只做"覆盖/同义词/缺失（有）/缺失（真缺口）"四态标注，真缺口"never stuff keywords"，绝不把简历没有的技能硬塞进去。相比之下，路线 B 的 boss-agent-cli 更侧重"搜索准确性"而非"匹配准确性"——它把 --welfare "双休,五险一金" 这种福利筛选做成 AND 语义的结构化参数，解决的是"筛得准、拿得到结构化结果"的问题，匹配判断仍要交给上层 Agent。
四、工作流体验：有没有闭环，决定了"无用功"多少
筛选再准，如果产出物提交不出去、ATS 读不出来，一样是白干。这部分是 ai-job-search 与多数同类工具拉开差距的地方，其细节全部可以在仓库里逐条核对。
/apply 是一个强制八步的 drafter-reviewer 双代理流程（见 .claude/commands/apply.md）：解析 JD → 五维评估（先问用户"是否继续"）→ LaTeX 起草定制 CV 与求职信 → 另起一个 reviewer agent 以招聘经理视角研究公司并批判 → 修订 → 强制编译 PDF → ATS 文本层校验 → 带核对清单交付。其中两步最值钱：
- PDF 验证循环：CV 用
lualatex编译必须恰好 2 页、求职信用xelatex编译必须恰好 1 页，配合 tools/verify_pdf.py 的页数断言和 tools/verify_layout.py 的版式测量（空洞、孤儿标题、页脚碰撞），自动修复\needspace这类换页问题——LaTeX 里"看着没问题"、PDF 里标题被孤零零甩到页尾的情况被系统性消灭。 - ATS 文本层校验：ATS 读的是 PDF 内嵌文本而非渲染页面。
/apply提取 CV 文本层，验证邮箱电话以字面文本存在、阅读顺序正常、关键词覆盖率达标。这一条直接决定了简历"能不能被机器读走"。
闭环则由 outcome.md、interview.md、gmail-sync.md、html-report.md 等命令补齐：/outcome 把申请结果归档到 documents/applications/<company>_<role>/ 并回流校准评估框架；/outcome followup 自动找出 10 天无音讯的申请并起草跟进邮件（只起草不发送，每个申请至多两次）；/interview 从申请档案构建分阶段面试准备包。搜索、申请、复盘全部沉淀为本地文件——这也是社区文章反复强调的"它不是一次生成，而是越用越像你"。
反无用功的工程细节同样密集：.claude/skills/job-scraper/SKILL.md 里用 tools/job_key.py 生成确定性去重 key、跨运行去重，还实现了批量发布检测（同一 JD 在 6 个城市重复投放会被合并提醒）；linkedin-search 的 detail 返回 isActive 标记，拦截"搜索时活着、抓取时已关闭"的幽灵职位；/apply 还会对不在白名单的域名标注"⚠ 未验证来源"并提示核实雇主真实性。合规边界也做进了工具链：tools/robots_check.py 在浏览器头重试前先查 robots.txt，LinkedIn skill 明确声明"personal use only"，security_guards.py 在 CI 里盯权限白名单与 gitignore 规则。
成本与门槛则是体验的另一面：ai-job-search 需要 Claude Code、Python 3.10+、Bun 和 LaTeX 发行版四件套（详见 SETUP.md），对不碰终端的人并不友好；boss-agent-cli 则用 uv tool install + Playwright 起服务，面向国内平台、上手门槛更低，但它的输出要再交给上层 Agent 才能形成匹配判断。一句话：A 重全链路质量，B 重平台可操作性，两者并不是替代关系。
五、选型清单与试用路径
结合前两节的分析，选型可以按三问来对号入座：
问一：你在哪个市场投递？ 用国内平台（BOSS 直聘、智联）优先 boss-agent-cli 这类平台工具层；面向海外或全球市场，ai-job-search 自带 LinkedIn 全球搜索与 freehire 多市场聚合，且核心工作流语言与国别无关（四个丹麦门户 skill 只是示例模式，可换）。
问二：你要的是"匹配判断"还是"投递操作"？ 需要五维打分、诚实缺口分析、ATS 校验、面试准备的完整链路，选 A；只需要一个稳定、结构化、可被 Agent 调用的平台操作层，选 B。
问三：你愿不愿意为"少做无用功"付学习成本？ 愿意折腾终端与 LaTeX，A 的长期回报更高——它的每次申请都会沉淀进 documents/ 与 job_search_tracker.csv，越用越准；不想折腾，从 B 的 boss schema 起步更轻。
ai-job-search 的推荐试用路径，社区文章与仓库 README.md 的建议高度一致，六步走：
# 1. 私有仓库接 upstream（GitHub 不允许公开仓库的私有 fork，
# 个人求职数据写进的是 tracked 文件，隐私优先选私有仓库）
# 2. 安装门户 CLI（自动发现 .agents/skills/ 下全部 CLI）
python3 tools/install_portal_clis.py
# 3. 进入 Claude Code 完成个人画像
claude
/setup
# 4. 抓取与批量排序
/scrape
/rank
# 5. 真实职位上完整流程
/apply https://jobindex.dk/job/1234567
# 6. 提交后记录结果，让反馈闭环开始工作
/outcome followup
如果只想先感受门户 CLI 的形态，可以直接跑仓库里零运行时依赖的 LinkedIn 搜索：
bun run .agents/skills/linkedin-search/cli/src/cli.ts search -q "data engineer" -l "Berlin, Germany" --jobage 30 --format table
最后是两条红线：合规——所有自动抓取都受 robots.txt 与平台条款约束，LinkedIn 等站点明令 personal use only，高频抓取既危险也无必要；隐私——简历是最高敏感度数据，本地优先的方案天然优于上传式 SaaS，但任何接入远程模型 API 的操作都意味着数据上云，/setup 写入个人信息的目录要放进私有仓库，[PLACEHOLDER] 占位符机制就是为了让模板可安全提交而设计的。
六、冷思考：工具的上限与边界
社区对 ai-job-search 的"冷思考"文章里有一句被反复引用的话：Star 数量不等于项目价值。两万 Star 里有多少是话题热度带来的从众效应，GitHub 不提供"使用率"指标，需要靠 issue 活跃度、PR 合并、提交节奏来交叉验证——而就本文核对仓库的结果看，作者的高频迭代（CHANGELOG 里几乎每个 release 都在修真实抓取/版式/状态管理的边角问题）与 README 里 69 投 20 面 1 签的真实数据，比 Star 数更能说明问题。
更重要的是预期管理。这类工具的本质是"信息过滤器 + 效率放大器"：它帮你把海量 JD 收敛成可评估的短名单、把申请材料做到 ATS 可读、把进度整理成可复盘的状态，但它不会替你找到工作——最终 offer 取决于硬实力与面试表现，模型对"文本间关联"的理解也不等于招聘方的真实偏好。谁把工具当"自动投递机"，谁就会在合规与质量上付出代价；谁把它当"本地工作区的工程化求职流程"，谁才能让每一次投递都被下一次复用。
回到开头的问题：这波 AI 求职 CLI 工具，谁能让你少做无用功？答案不在某一个项目里，而在你对"匹配判断、质量校验、反馈闭环、合规边界"这四件事的取舍里。ai-job-search 用 69 份真实申请证明了闭环的长期价值，boss-agent-cli 用结构化协议证明了平台层的工程潜力——而是否让 AI 参与求职、以及参与多深，仍然是一道留给每个求职者自己的选择题。