最近我自己一直在找 AI Agent / 大模型应用相关的工作。
找了一段时间以后,我发现真正耗时间的,其实不只是"写简历"。
更麻烦的是这一整套重复流程:
看到一个岗位 → 查公司 → 看是不是还在招 → 找官网招聘页 → 搜公司口碑 → 看有没有劳动纠纷 → 判断值不值得投 → 打开申请页 → 填一遍又一遍的信息 → 记录投递状态 → 几天后再回来确认有没有进展。
单独看,每一步都不复杂。
但当你同时跟进十几家甚至几十家公司时,这些琐碎工作会迅速堆起来。
所以我干脆把自己实际在做的求职流程整理成了一个 AI Skill:
job-application-assistant
它目前可以运行在 Claude / Codex 中。
我并不想把它做成一个"AI 一键海投器"。
我真正想解决的是:
让 AI 处理求职中的信息搜集、整理和重复操作,而真正影响你的决定和真正的提交动作,仍然交给人。
项目已经开源:
GitHub:

它到底解决什么问题?
我一开始就没有想做一个"求职 SaaS"。
它有一个非常明确的定位:
这是一个给个人管理自己求职流程使用的 AI Skill。
所以目前没有服务器、没有账号系统,也没有云同步。
你的投递记录保存在本机。
我希望它解决的,不只是"投递"这一个动作,而是把求职前后的几个高频步骤串起来:
找岗位 → 筛公司 → 做背调 → 找官网招聘入口 → 准备申请材料 → 辅助填表 → 人工确认 → 投递 → 持续跟进
完整流程大概是这样:
找岗位
↓
确认目标公司
↓
公司背调
↓
找到官网招聘页
↓
阅读 JD / 准备材料
↓
辅助填写申请表
↓
人工检查
↓
本人确认提交
↓
记录投递
↓
后续跟进
这里有一个我很在意的设计原则:
Automation ≠ Autonomous Submission
我希望自动化的是信息处理和重复工作,而不是把不可逆的求职决策也交给 AI。
第一步:先找公司,而不是上来就海投
现在很多求职自动化工具都会强调:
"一分钟帮你投几十份、几百份简历。"
但我做这个项目的时候,思路正好相反。
对于我来说,更重要的问题不是:
"今天能投多少份?"
而是:
"有哪些公司真的在招我想去的岗位?"
所以整个流程第一步,是先根据:
目标岗位
地区
行业
公司规模
Senior Level
薪资要求
建立一批候选公司。
例如,你可以直接告诉它:
diff
帮我寻找上海 / 杭州的 AI Agent 开发岗位。
优先:
- AI 应用工程师
- Agent 开发工程师
- LLM 应用开发
先列出正在招聘的公司,
优先寻找官网招聘页面,
不要直接投递。
项目里有一个:
bash
scripts/search_target_companies.py
负责整理岗位信息,例如:
bash
company
title
location
posting_url
source
之后再按照公司进行去重。
这里我也没有尝试去绕过登录墙、验证码或者付费限制。
如果目标平台提供公开 API,就优先使用公开 API;如果页面需要登录或者触发反爬机制,就不强行突破。
因为我希望这个项目最终是一个能够长期使用的个人求职工具,而不是一次性爬虫。
第二步:为什么我要把"公司背调"放在投递之前?
这是我做这个项目时比较在意的一部分。
因为大部分求职工具都在解决:
"怎么让我投得更多?"
但求职者其实还有另外一个非常现实的问题:
"这家公司到底值不值得我花时间?"
尤其是创业公司、小微公司或者信息不透明的企业。
你可能花几个小时准备简历、做面试、完成作业题,最后才发现:
- 公司有大量劳动纠纷
- 工资发放存在争议
- 员工口碑长期偏差
- 团队频繁变动
- 公司融资情况并不稳定
所以我专门做了一条 Company Due Diligence 流程。
它会去整理几类公开信息。
比如工商和法律相关信息:
国家企业信用信息公示系统
裁判文书
执行信息
劳动争议
股权变动
再结合员工侧的信息:
知乎
看准
脉脉
小红书
其他公开讨论
以及:
融资情况
新闻报道
公开舆情
但是这里有一个很关键的问题:
不同信息源不能等权。
一条法院公开记录,和一篇匿名社交媒体吐槽,显然不能用同样的可信度去判断。
所以在项目设计里,我专门增加了一个原则:
优先使用官方、一手记录验证事实;社交媒体只作为辅助信号,不把单个负面评价直接当作事实结论。
最后,Agent 会把整理出来的信息形成结构化数据,再交给:
bash
scripts/due_diligence_report.py
生成一份独立的公司背调报告。
报告里可以包括:
公司基本信息
法律 / 司法风险
员工口碑
社交媒体评价
风险提示
综合建议
这样,在真正投入时间准备这家公司之前,可以先看一眼:
值不值得继续。

公司背调报告 Demo:把公司基本信息、法律风险、员工口碑和公开舆情整理成一个决策页面。Demo 数据仅用于展示界面。
第三步:发现岗位之后,尽量回到公司的官方招聘页
另外一个我自己求职时经常碰到的问题是:
你在招聘网站上看到了一个岗位。
但那个页面只是一个"岗位发现入口"。
真正的申请入口可能在:
公司官网
Greenhouse
Lever
Workday
SmartRecruiters
BambooHR
Workable
所以项目里又做了一个:
find_career_page.py
它的逻辑大概是:
bash
招聘平台发现公司
↓
确定公司官网
↓
检查 /careers
↓
检查 /jobs
↓
识别常见 ATS
↓
找到官方申请入口
比如常见路径:
bash
/company/careers
/careers
/jobs
/join-us
/work-with-us
也会识别一些第三方 ATS 托管的官方申请页。
这里我想表达的其实不是:
"官网一定比招聘平台好。"
而是希望 Agent 能够区分两个概念:
发现岗位的渠道
和
正式申请的渠道
这两者并不一定是同一个地方。
第四步:真正麻烦的是 ATS
如果你投过国外公司,应该对下面这些名字并不陌生:
Greenhouse
Lever
Workday
SmartRecruiters
iCIMS
BambooHR
Workable
这些系统统称为:
ATS,Applicant Tracking System。
也就是企业用来收集、管理求职申请的招聘系统。
问题在于:
每套 ATS 的页面结构都不一样。
比如 Greenhouse 通常比较直接:
sql
First Name
Last Name
Email
Phone
Resume
Cover Letter
而 Workday 就可能是:
My Information
↓
My Experience
↓
Application Questions
↓
Voluntary Disclosures
↓
Review
而且不同公司的 Workday 页面还可能不完全一样。
所以我没有尝试做一个:
"万能 CSS Selector,一套代码投遍所有公司。"
项目里维护的是一套 ATS Reference,用来识别不同平台的:
URL 特征
DOM 特征
常见字段
表单结构
然后按照不同 ATS 使用不同策略。
整体思路是:
javascript
识别 ATS
↓
选择对应 Field Map
↓
打开真实浏览器
↓
填写已知字段
↓
截图 / 人工检查
↓
暂停
核心脚本是:
bash
scripts/ats_form_filler.py
目前使用 Playwright。
为什么浏览器默认必须是"可见的"?
这是这个项目里一个我比较坚持的工程决策。
我没有让浏览器默认使用:
ini
headless=True
而是默认打开真实可见窗口。
因为真实招聘网站里,很可能突然出现:
reCAPTCHA
hCaptcha
Cloudflare Challenge
登录验证
额外确认页面
如果整个浏览器完全运行在后台,用户甚至不知道现在到底发生了什么。
所以我的处理方式是:
markdown
检测到 CAPTCHA
↓
停止自动化
↓
把控制权交给用户
↓
用户自己完成验证
↓
继续执行
项目不会尝试破解 CAPTCHA。
也不会尝试绕过登录墙或者反机器人验证。
这并不是因为"自动化能力不够"。
而是我觉得:
有些边界,本来就不应该被自动化掉。
第五步:我故意没有做"一键自动提交"
这一点应该也是这个项目和很多 Auto Apply 工具最大的区别之一。
表单填完以后,它不会默认执行:
scss
click("Submit")
而是停下来。
用户需要先看到准备发送的信息,例如:
公司
岗位
简历版本
Cover Letter
表单信息
确认没有问题之后,再进行真正的提交。
所以 Skill 里有几条比较严格的规则:
不自动提交
不破解验证码
不编造简历经历
不编造公司背调结论
不无人值守连续海投
我也看过一些现有的开源 Auto Apply 项目。
里面有不少很值得借鉴的设计。
但有一种模式我刻意没有采用:
一小时自动投几十份甚至几百份简历的 Spray and Pray。
因为这并不是我真正想解决的问题。
我更希望 AI 帮我完成的是:
低价值的重复劳动。
而不是:
把最终决策权也一起自动化。

第六步:投完以后,真正的问题才刚开始
如果同时找过很多工作,很容易出现这种情况:
"这家公司我到底投没投过?"
"这个岗位现在进行到什么阶段了?"
"HR 上周说让我等等,现在过去几天了?"
"之前是不是查到过这家公司有风险?"
"我到底用了哪一版简历?"
所以项目里还有一个核心模块:
track_applications.py
它本质上是一个本地的 Application Ledger。
默认数据存在:
applications.json
不需要注册账号。
不需要服务器。
也不需要为了管理求职记录再部署一个数据库。
目前可以做:
sql
add
list
stats
followups
check
diligence
dashboard
export
例如投递之前可以先运行:
bash
python scripts/track_applications.py check \
--company "Acme Corp"
检查有没有重复投递。
也可以运行:
bash
python scripts/track_applications.py followups --days 7
看看有哪些岗位已经超过 7 天没有状态变化。
最后还能生成一个完全本地的 HTML Dashboard。

背调和投递记录其实应该是连起来的
我一开始做这个项目的时候:
公司背调报告
和:
投递记录
其实是两个独立模块。
后来我发现这样并不太合理。
因为真正查看求职状态的时候,我更希望看到的是:
arduino
公司 A
AI Agent Engineer
面试中
HIGH RISK
→ 查看背调
所以现在背调结果可以直接关联到 Application Tracker。
Dashboard 每一家公司可以显示:
arduino
LOW
MEDIUM
HIGH
这样的风险标签。
同时链接到对应公司的完整背调报告。
这样:
"我投到哪一步了?"
和:
"这家公司当时查出来怎么样?"
就不再是两个完全割裂的信息。

从 Agent 架构上看,它其实在做什么?
如果把整个项目抽象一下,大概可以拆成下面几层:
css
User Intent
↓
Job Discovery
↓
Company Shortlist
↓
Due Diligence
↓
Official Career Page
↓
ATS Detection
↓
Resume / Form Preparation
↓
Human Review
↓
Submit
↓
Application Tracker
下面使用的能力包括:
sql
Web Search
Python
Playwright
Local JSON
Static HTML
Claude / Codex Skill
所以它不是单纯:
LLM → Answer
而是一个比较典型的:
markdown
LLM
+
Tools
+
Structured Workflow
+
Local State
+
Human-in-the-loop
组合。
为什么我把数据设计成本地保存?
因为这个项目本来就是为了我自己的求职过程做的。
而求职记录里会包含很多比较个人的信息:
投了哪些公司
投了什么岗位
面试到哪一步
用了哪版简历
公司评价
跟进情况
个人备注
所以我不太想为了做一个个人 Tracker,再额外搭:
rust
Backend
Database
Account System
Cloud Sync
目前项目选择的是:
sql
Local JSON
+
Static HTML
对于这种单用户工具,我觉得已经足够。
而且还有一个额外收益:
数据完全在自己电脑里。
这也是我现在越来越喜欢的一种产品思路:
复杂度应该和问题规模匹配。
如果只是给一个人使用,并不是所有东西都需要 SaaS 化。
怎么使用?
目前整个项目主要按照 Claude Skill 的形式组织:
objectivec
SKILL.md
scripts/
references/
Claude 用户可以直接导入 Skill。
Claude Code / Codex 用户可以按照对应工具的 Skill 目录方式使用。
安装以后,并不需要记住所有 Python 命令。
可以直接告诉 Agent:
帮我寻找 AI Agent 开发相关岗位。
先找正在招聘的公司,
优先找到官网招聘页。
准备投递前先做公司背调。
如果我要继续,
再帮我准备申请材料和表单。
真正提交之前必须让我确认。
投递完成后加入我的求职看板。
然后 Skill 会按照整个 Workflow 往下推进。
如果只想单独使用某个功能,也可以直接调用里面的 Python 脚本。
这个项目现在是什么定位?
我暂时不想把它包装成:
"AI 自动求职神器。"
更准确地说,我觉得它是一个:
面向个人求职者的 Human-in-the-loop Job Search Agent / Skill
它负责:
sql
Research
↓
Organize
↓
Prepare
↓
Assist
人在关键节点负责:
Judge
↓
Confirm
↓
Submit
我其实比较喜欢这种 Agent 设计。
不是:
"Agent 帮我把所有事情都做掉。"
而是:
机器负责它擅长的部分,人保留真正重要的判断权。
开源
项目已经放在 GitHub:
目前使用 MIT License。
如果你正在找工作,可以直接拿去试。
如果你也在做:
AI Agent
Browser Automation
Career Tech
Claude Skill
Codex Skill
也欢迎交流。
后面我还准备继续完善几个方向:
更多 ATS 适配
更自然的交互入口
更好的岗位 / 公司筛选
投递状态整理
公司背调覆盖率
真实用户测试
不过有一条应该不会变:
我不希望把它做成一个无人值守的海投机器人。
我更希望它最后变成一个真正能陪着个人完成整个求职流程的 Agent。
如果这个项目对你有帮助,欢迎:
Star / Issue / Feedback
GitHub:
LH-kevin/job-application-assistant
