最近我自己一直在找 AI Agent / 大模型应用相关的工作。
找了一段时间以后，我发现真正耗时间的，其实不只是“写简历”。
更麻烦的是这一整套重复流程：
看到一个岗位 → 查公司 → 看是不是还在招 → 找官网招聘页 → 搜公司口碑 → 看有没有劳动纠纷 → 判断值不值得投 → 打开申请页 → 填一遍又一遍的信息 → 记录投递状态 → 几天后再回来确认有没有进展。
单独看，每一步都不复杂。
但当你同时跟进十几家甚至几十家公司时，这些琐碎工作会迅速堆起来。
所以我干脆把自己实际在做的求职流程整理成了一个 AI Skill：
job-application-assistant
它目前可以运行在 Claude / Codex 中。
我并不想把它做成一个“AI 一键海投器”。
我真正想解决的是：
让 AI 处理求职中的信息搜集、整理和重复操作，而真正影响你的决定和真正的提交动作，仍然交给人。
项目已经开源：
GitHub：
github.com/LH-kevin/jo…
它到底解决什么问题？
我一开始就没有想做一个“求职 SaaS”。
它有一个非常明确的定位：
这是一个给个人管理自己求职流程使用的 AI Skill。
所以目前没有服务器、没有账号系统，也没有云同步。
你的投递记录保存在本机。
我希望它解决的，不只是“投递”这一个动作，而是把求职前后的几个高频步骤串起来：
找岗位 → 筛公司 → 做背调 → 找官网招聘入口 → 准备申请材料 → 辅助填表 → 人工确认 → 投递 → 持续跟进
完整流程大概是这样：
找岗位
↓
确认目标公司
↓
公司背调
↓
找到官网招聘页
↓
阅读 JD / 准备材料
↓
辅助填写申请表
↓
人工检查
↓
本人确认提交
↓
记录投递
↓
后续跟进
这里有一个我很在意的设计原则：
Automation ≠ Autonomous Submission
我希望自动化的是信息处理和重复工作，而不是把不可逆的求职决策也交给 AI。
第一步：先找公司，而不是上来就海投
现在很多求职自动化工具都会强调：
“一分钟帮你投几十份、几百份简历。”
但我做这个项目的时候，思路正好相反。
对于我来说，更重要的问题不是：
“今天能投多少份？”
而是：
“有哪些公司真的在招我想去的岗位？”
所以整个流程第一步，是先根据：
目标岗位
地区
行业
公司规模
Senior Level
薪资要求
建立一批候选公司。
例如，你可以直接告诉它：
帮我寻找上海 / 杭州的 AI Agent 开发岗位。
优先：
- AI 应用工程师
- Agent 开发工程师
- LLM 应用开发
先列出正在招聘的公司，
优先寻找官网招聘页面，
不要直接投递。
项目里有一个：
scripts/search_target_companies.py
负责整理岗位信息，例如：
company
title
location
posting_url
source
之后再按照公司进行去重。
这里我也没有尝试去绕过登录墙、验证码或者付费限制。
如果目标平台提供公开 API，就优先使用公开 API；如果页面需要登录或者触发反爬机制，就不强行突破。
因为我希望这个项目最终是一个能够长期使用的个人求职工具，而不是一次性爬虫。
第二步：为什么我要把“公司背调”放在投递之前？
这是我做这个项目时比较在意的一部分。
因为大部分求职工具都在解决：
“怎么让我投得更多？”
但求职者其实还有另外一个非常现实的问题：
“这家公司到底值不值得我花时间？”
尤其是创业公司、小微公司或者信息不透明的企业。
你可能花几个小时准备简历、做面试、完成作业题，最后才发现：
- 公司有大量劳动纠纷
- 工资发放存在争议
- 员工口碑长期偏差
- 团队频繁变动
- 公司融资情况并不稳定
所以我专门做了一条 Company Due Diligence 流程。
它会去整理几类公开信息。
比如工商和法律相关信息：
国家企业信用信息公示系统
裁判文书
执行信息
劳动争议
股权变动
再结合员工侧的信息：
知乎
看准
脉脉
小红书
其他公开讨论
以及：
融资情况
新闻报道
公开舆情
但是这里有一个很关键的问题：
不同信息源不能等权。
一条法院公开记录，和一篇匿名社交媒体吐槽，显然不能用同样的可信度去判断。
所以在项目设计里，我专门增加了一个原则：
优先使用官方、一手记录验证事实；社交媒体只作为辅助信号，不把单个负面评价直接当作事实结论。
最后，Agent 会把整理出来的信息形成结构化数据，再交给：
scripts/due_diligence_report.py
生成一份独立的公司背调报告。
报告里可以包括：
公司基本信息
法律 / 司法风险
员工口碑
社交媒体评价
风险提示
综合建议
这样，在真正投入时间准备这家公司之前，可以先看一眼：
值不值得继续。
公司背调报告 Demo：把公司基本信息、法律风险、员工口碑和公开舆情整理成一个决策页面。Demo 数据仅用于展示界面。
第三步：发现岗位之后，尽量回到公司的官方招聘页
另外一个我自己求职时经常碰到的问题是：
你在招聘网站上看到了一个岗位。
但那个页面只是一个“岗位发现入口”。
真正的申请入口可能在：
公司官网
Greenhouse
Lever
Workday
SmartRecruiters
BambooHR
Workable
所以项目里又做了一个：
find_career_page.py
它的逻辑大概是：
招聘平台发现公司
↓
确定公司官网
↓
检查 /careers
↓
检查 /jobs
↓
识别常见 ATS
↓
找到官方申请入口
比如常见路径：
/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 通常比较直接：
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 使用不同策略。
整体思路是：
识别 ATS
↓
选择对应 Field Map
↓
打开真实浏览器
↓
填写已知字段
↓
截图 / 人工检查
↓
暂停
核心脚本是：
scripts/ats_form_filler.py
目前使用 Playwright。
为什么浏览器默认必须是“可见的”？
这是这个项目里一个我比较坚持的工程决策。
我没有让浏览器默认使用：
headless=True
而是默认打开真实可见窗口。
因为真实招聘网站里，很可能突然出现：
reCAPTCHA
hCaptcha
Cloudflare Challenge
登录验证
额外确认页面
如果整个浏览器完全运行在后台，用户甚至不知道现在到底发生了什么。
所以我的处理方式是：
检测到 CAPTCHA
↓
停止自动化
↓
把控制权交给用户
↓
用户自己完成验证
↓
继续执行
项目不会尝试破解 CAPTCHA。
也不会尝试绕过登录墙或者反机器人验证。
这并不是因为“自动化能力不够”。
而是我觉得：
有些边界，本来就不应该被自动化掉。
第五步：我故意没有做“一键自动提交”
这一点应该也是这个项目和很多 Auto Apply 工具最大的区别之一。
表单填完以后，它不会默认执行：
click("Submit")
而是停下来。
用户需要先看到准备发送的信息，例如：
公司
岗位
简历版本
Cover Letter
表单信息
确认没有问题之后，再进行真正的提交。
所以 Skill 里有几条比较严格的规则：
不自动提交
不破解验证码
不编造简历经历
不编造公司背调结论
不无人值守连续海投
我也看过一些现有的开源 Auto Apply 项目。
里面有不少很值得借鉴的设计。
但有一种模式我刻意没有采用：
一小时自动投几十份甚至几百份简历的 Spray and Pray。
因为这并不是我真正想解决的问题。
我更希望 AI 帮我完成的是：
低价值的重复劳动。
而不是：
把最终决策权也一起自动化。
第六步：投完以后，真正的问题才刚开始
如果同时找过很多工作，很容易出现这种情况：
“这家公司我到底投没投过？”
“这个岗位现在进行到什么阶段了？”
“HR 上周说让我等等，现在过去几天了？”
“之前是不是查到过这家公司有风险？”
“我到底用了哪一版简历？”
所以项目里还有一个核心模块：
track_applications.py
它本质上是一个本地的 Application Ledger。
默认数据存在：
applications.json
不需要注册账号。
不需要服务器。
也不需要为了管理求职记录再部署一个数据库。
目前可以做：
add
list
stats
followups
check
diligence
dashboard
export
例如投递之前可以先运行：
python scripts/track_applications.py check \
--company "Acme Corp"
检查有没有重复投递。
也可以运行：
python scripts/track_applications.py followups --days 7
看看有哪些岗位已经超过 7 天没有状态变化。
最后还能生成一个完全本地的 HTML Dashboard。
背调和投递记录其实应该是连起来的
我一开始做这个项目的时候：
公司背调报告
和：
投递记录
其实是两个独立模块。
后来我发现这样并不太合理。
因为真正查看求职状态的时候，我更希望看到的是：
公司 A
AI Agent Engineer
面试中
HIGH RISK
→ 查看背调
所以现在背调结果可以直接关联到 Application Tracker。
Dashboard 每一家公司可以显示：
LOW
MEDIUM
HIGH
这样的风险标签。
同时链接到对应公司的完整背调报告。
这样：
“我投到哪一步了？”
和：
“这家公司当时查出来怎么样？”
就不再是两个完全割裂的信息。
从 Agent 架构上看，它其实在做什么？
如果把整个项目抽象一下，大概可以拆成下面几层：
User Intent
↓
Job Discovery
↓
Company Shortlist
↓
Due Diligence
↓
Official Career Page
↓
ATS Detection
↓
Resume / Form Preparation
↓
Human Review
↓
Submit
↓
Application Tracker
下面使用的能力包括：
Web Search
Python
Playwright
Local JSON
Static HTML
Claude / Codex Skill
所以它不是单纯：
LLM → Answer
而是一个比较典型的：
LLM
+
Tools
+
Structured Workflow
+
Local State
+
Human-in-the-loop
组合。
为什么我把数据设计成本地保存？
因为这个项目本来就是为了我自己的求职过程做的。
而求职记录里会包含很多比较个人的信息：
投了哪些公司
投了什么岗位
面试到哪一步
用了哪版简历
公司评价
跟进情况
个人备注
所以我不太想为了做一个个人 Tracker，再额外搭：
Backend
Database
Account System
Cloud Sync
目前项目选择的是：
Local JSON
+
Static HTML
对于这种单用户工具，我觉得已经足够。
而且还有一个额外收益：
数据完全在自己电脑里。
这也是我现在越来越喜欢的一种产品思路：
复杂度应该和问题规模匹配。
如果只是给一个人使用，并不是所有东西都需要 SaaS 化。
怎么使用？
目前整个项目主要按照 Claude Skill 的形式组织：
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
它负责：
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
