AI 求职不该变成“批量投递机”：把职位来源、事实履历、人机审核、隐私和结果学习做成一份申请合同
AH-0432推荐的是 MadsLorentzen/ai-job-search。 源文把它概括为： 自动抓职位、评估匹配、定制CV和求职信、做面试准备、追踪申请结果。 这个概括基本抓到了项目骨架。 而当前官方仓库比“AI自动求职”四个字更成熟的一点，是它没有把目标设成： 一天投500份。 它真正有价值的方向是： 把求职变成一个有Profile、Criteria、Draft、Revi
AI 求职不该变成“批量投递机”：把职位来源、事实履历、人机审核、隐私和结果学习做成一份申请合同
AH-0432推荐的是 MadsLorentzen/ai-job-search。
源文把它概括为： 自动抓职位、评估匹配、定制CV和求职信、做面试准备、追踪申请结果。
这个概括基本抓到了项目骨架。
而当前官方仓库比“AI自动求职”四个字更成熟的一点，是它没有把目标设成：
> 一天投500份。
它真正有价值的方向是：
> 把求职变成一个有Profile、Criteria、Draft、Review、Outcome和Learning的闭环。
这与“让Agent替我海投”是两种完全不同的产品哲学。
---
一、当前项目是什么？
这是一个独立开源项目，不是Anthropic官方产品。
当前仓库使用MIT License。
项目围绕Claude Code构建，但仓库也已经提供AGENTS等结构，部分job-search skills可被其他Agent工具发现。
---
二、它的核心流程
/setup： 建立候选人Profile。
/scrape： 搜索职位。
/rank： 按criteria排序。
/apply： 评估匹配，然后生成定制CV和Cover Letter。
/interview： 面试准备。
/outcome： 记录申请后的面试、拒绝、Offer、沉默等结果。
---
三、为什么/outcome特别重要？
很多AI求职工具只优化前端：
生成更多简历。
这会把“产量”误当成功。
真正有用的系统应该记录：
哪些职位投了； 哪些进入一面； 哪些被拒； 哪些无回应； 哪些能力反复成为gap； 哪些渠道转化更好。
---
四、这就是Learning Loop
Job → Application → Outcome → Criteria Calibration。
---
五、作者自己的结果能不能证明系统有效？
官方README披露了作者个人案例：
69份定制申请； 20个首次面试； 最后一份签约； 并在2026年6月开始AI Engineer工作。
这是很有价值的透明案例。
但必须标：
SOURCE_CASE
---
六、不能写成“使用这个框架面试率29%”
因为只有一个人、一段求职周期、一个市场和一套背景。
没有随机对照。
也不能分离：
候选人本身质量； 市场； 职位选择； 工具； 人工判断
各自贡献了多少。
---
七、所以：
One Author Funnel ≠ General Success Rate
---
八、求职Agent第一个硬门槛：事实
AI最容易让求职材料“变好看”。
也最容易偷偷把：
参与过 → 负责过； 知道 → 精通； 辅助 → 主导； 结果相关 → 结果归因给自己。
---
九、这就是Resume Fabrication Risk
看起来只是润色。
实质可能变成虚假陈述。
---
十、真正的规则
AI Tailoring ≠ Resume Fabrication
---
十一、每一句高价值Claim必须有Profile Evidence
例如：
“Reduced processing time by 40%”
需要有： 项目； 角色； 基线； 测量； 来源。
---
十二、没有证据怎么办？
可以写职责和真实贡献。
不要制造数字。
---
十三、第二个硬门槛：Fit First
这个repo一个值得保留的设计是：
先评估岗位匹配， 再做申请材料。
不是每个职位都生成一套CV。
---
十四、这能降低什么？
无意义申请； 关键词乱塞； 不符合硬门槛； 时间浪费。
---
十五、求职不是信息检索比赛
目标不是： “我找到了1000个职位”。
---
十六、目标是高质量Opportunity Set
Role Fit； Skill Fit； Location； Language； Compensation； Visa； Work Mode； Career Direction。
---
十七、第三个硬门槛：Job Posting是Untrusted Input
当前仓库明确提醒：
职位页面视为不可信输入。
---
十八、为什么职位页会是安全问题？
如果Agent自动抓网页， 网页可能包含：
隐藏指令； 恶意文本； 外部链接； 诱导执行。
---
十九、所以不能让职位文本覆盖系统规则
---
二十、Prompt Injection在求职系统里并不是理论问题
因为系统天然会接触大量陌生网页。
---
二十一、repo自己的防护也有边界
它明确说明：
部分防御是instruction-level， 不是完全sandbox。
所以仍要求用户在陌生job board上检查抓取和写入结果。
---
二十二、这句非常重要
Agent Safety Instruction ≠ Sandbox
---
二十三、第四个硬门槛：Portal Permission
技术上能抓一个job board， 不代表平台允许自动抓。
---
二十四、当前repo自己就给出例子
LinkedIn public guest endpoint可以技术访问。
但仓库明确标： 自动化访问违反LinkedIn Terms，个人使用、低频，并保留警告。
---
二十五、所以：
Public Endpoint ≠ Automation Permission
---
二十六、这对alphahole非常重要
以后任何： 招聘； 电商； 内容； 社交平台
Agent都不能把“无需登录接口”理解成“可无限自动化”。
---
二十七、第五个硬门槛：Auto Draft ≠ Auto Send
生成CV和Cover Letter， 风险可逆。
---
二十八、发送申请不可逆
一旦提交给公司， 它就是你的正式陈述。
---
二十九、因此默认需要Human Gate
Draft → Review → Approve → Submit。
---
三十、不应该默认批量自动投
尤其当： 职位质量不确定； 材料claim高风险； 公司重要； 行业狭窄。
---
三十一、第六个硬门槛：ATS
很多求职AI宣传：
“帮你过ATS”。
---
三十二、ATS优化最容易退化成关键词堆砌
---
三十三、真正应该做的是
岗位核心requirement映射到真实经历。
---
三十四、ATS Optimization ≠ Keyword Stuffing
---
三十五、关键词不是目的
可验证的相关经验才是。
---
三十六、第七层：Candidate Profile是敏感数据资产
这个框架会使用：
CV； LinkedIn export； 证书； 推荐信； 历史申请； 薪资信息； 联系方式。
---
三十七、它不应该被当成普通Markdown目录
这是职业身份档案。
---
三十八、需要Privacy Contract
Location； Encryption； Git Ignore； Backup； Cloud Sync； Deletion； Access。
---
三十九、当前repo已经对.gitignore和本地数据保护做了不少设计
这是值得肯定的。
---
四十、但用户fork后仍可能自己把资料commit进Git
---
四十一、所以要有Pre-commit Secret/PII Gate
扫描：
Email； Phone； Address； ID； Reference Contact； Salary； Private Docs。
---
四十二、第八层：References
推荐人的： 姓名； 公司； 电话； 邮箱
不是你的普通公开素材。
---
四十三、不能因为写CV需要就随便上传到第三方模型
---
四十四、第九层：Salary Data
薪资benchmark很有用。
但来源质量非常关键。
---
四十五、Glassdoor/论坛/个人研究不是同一证据等级
系统必须保留：
Source； Date； Region； Role； Level； Currency。
---
四十六、第十层：Language Gate
当前repo对语言能力有结构化处理。
这是一个好设计。
---
四十七、为什么不能让AI自动“补齐”语言能力？
因为岗位语言要求经常是硬门槛。
---
四十八、用户没声明，就不能让模型推断“应该差不多会”
---
四十九、第十一层：Career Direction
AI排序“最匹配职位”， 不代表那是用户最想走的方向。
---
五十、Fit有两种
Current Fit； Future Fit。
---
五十一、有些岗位现在不完全匹配
但能形成高价值迁移。
---
五十二、所以系统应该允许Stretch Role
但明确标Gap。
---
五十三、第十二层：Application Fatigue
自动化降低每份申请制作成本。
这也可能诱导用户投更多低质量申请。
---
五十四、Automation can reduce friction and worsen strategy
---
五十五、好的系统要有Application Budget
例如：
每周最多研究N个； 高优先申请需要人工深审； 低优先不投。
这里的N不该由我们固定。
---
五十六、第十三层：Company Research
Agent可以研究公司。
但要区分：
官方网站； 监管文件； 新闻； 员工评价； 论坛。
---
五十七、不要把匿名评论直接写成公司事实
---
五十八、第十四层：Interview Prep
这是AI特别适合的环节。
因为风险相对低， 可以做：
STAR索引； 模拟问题； 岗位要求映射； Gap回答。
---
五十九、但仍不能编造项目
---
六十、“Bridge Answer”应该诚实
例如： “我没有直接做过X，但我在Y有相邻经验……”
比假装做过更强。
---
六十一、第十五层：Outcome
每次申请结束， 系统应该记录原因。
---
六十二、但是不要过度归因
“没有面试” 可能因为：
市场； 内推； 竞争； 签证； 时间； 岗位取消； 简历。
---
六十三、不能简单得出
“某个关键词没写，所以被拒”。
---
六十四、Outcome Learning需要样本量
---
六十五、连续几次同类Gap出现
才值得调整Profile/Criteria。
---
六十六、第十六层：Silence
无回复不是失败原因标签。
只是Outcome State。
---
六十七、第十七层：Follow-up
自动起草follow-up可以。
自动无限催促不可以。
---
六十八、当前repo设计“draft only”比自动发送更合理
---
六十九、第十八层：Fork Maintenance
这类repo最容易的问题：
用户fork后改了大量私人profile， 上游更新来了不敢merge。
---
七十、当前v1.0.0 Release提供了更明确的版本checkpoint和更新工具
这是成熟项目的重要信号。
---
七十一、因此：
Forkability ≠ Maintainability
---
七十二、需要User Config与Framework Code分离
个人资料和上游框架越分离， 维护成本越低。
---
七十三、第十九层：License
MIT允许广泛使用、修改和分发代码。
---
七十四、但repo License不代表招聘网站数据License
---
七十五、Portal Data Rights独立
---
七十六、第二十层：LLM Cost
本地文件不代表模型免费。
Claude/API/订阅成本仍然存在。
---
七十七、AI Job Search的ROI应该算
Agent Cost； Human Review； Application Time； Interview Rate； Offer Quality。
---
七十八、不要只算“省了多少写求职信时间”
---
七十九、真正的产品化
AI Job Application Contract
---
八十、Layer 1：Opportunity Source
Job Board； Company Site； Recruiter； Referral； Freshness； Permission。
---
八十一、Layer 2：Candidate Truth
Claim； Evidence； Skill Level； Dates； Metrics； References。
---
八十二、Layer 3：Fit
Hard Gate； Preference； Stretch； Deal-breaker。
---
八十三、Layer 4：Draft
CV； Cover； Portfolio； Language。
---
八十四、Layer 5：Review
Fact Check； ATS Readability； Tone； Gap； Red Flag。
---
八十五、Layer 6：Human Approval
最终谁负责提交？
永远是求职者本人。
---
八十六、Layer 7：Tracking
Submitted； Interview； Assessment； Offer； Reject； Withdraw； Silence。
---
八十七、Layer 8：Learning
哪种岗位； 哪个渠道； 哪种材料； 什么Gap。
---
八十八、Layer 9：Privacy
Profile； Docs； Email； Contacts； Salary。
---
八十九、Layer 10：Maintenance
Repo Version； Portal Change； Template； Model。
---
九十、什么叫真正的AI求职自动化？
不是：
“把所有工作都交给AI。”
---
九十一、而是：
把重复工作交给AI，把身份陈述和职业判断留给人。
---
九十二、产品方向
> Career Application OS
可以和现有Career Experiment OS连接。
---
九十三、它要解决的不是“投更多”
而是三件事：
更少错投； 更少虚假claim； 更快从结果学到东西。
---
九十四、V3怎么测试？
20名真实求职者或匿名历史申请。
---
九十五、Baseline
传统： 一个CV投所有岗位。
---
九十六、Experiment
结构化： Fit → Tailor → Review → Track。
---
九十七、测
Applications； Human minutes； Interview invitations； Correction count； Fabrication caught； Job-source errors； User confidence。
---
九十八、不要以Offer rate作为唯一指标
因为外部市场影响太大。
---
九十九、一个更稳定指标
Evidence Accuracy Rate
材料里的每一个强claim是否可回溯。
---
一百、另一个指标
Application Quality per Hour
不是Application Count per Hour。
---
一百零一、Stop Rule 1
如果AI生成了用户没有的技能， 不提交。
---
一百零二、Stop Rule 2
如果job board明确不允许自动访问， 不要因为技术能抓就扩大自动化。
---
一百零三、Stop Rule 3
如果申请前用户没看最终CV， 不提交。
---
一百零四、Stop Rule 4
如果Profile包含大量敏感资料， 未确认数据流和存储，不接第三方工具链。
---
一百零五、Stop Rule 5
如果只是在提高海投数量， 没有Outcome Learning， 系统价值很可能是假的。
---
一百零六、源文最值得保留的一句
AI可以贯穿：
职位发现 → 材料 → 面试 → 追踪。
---
一百零七、但要改成
AI可以帮助每一环。
不应该自动拥有每一环的最终权限。
---
一百零八、AI求职最大的风险不是“AI味”
而是：
履历事实被悄悄改写。
---
一百零九、第二大风险
职位平台权限和抓取边界。
---
一百一十、第三大风险
隐私。
---
一百一十一、第四大风险
把申请数量当成系统成功。
---
一百一十二、真正的闭环不是“自动投”
而是：
Profile → Opportunity → Truthful Application → Outcome → Learning。
---
结论
ai-job-search值得研究，不是因为它能替人“自动找工作”。
而是它把求职中最容易散掉的东西——个人履历、职位评估、定制材料、二次审核、面试准备、申请结果——放进同一个可迭代系统。
但真正成熟的AI求职必须守住几个边界：
**AI可以改写表达，不能改写事实； AI可以搜索公开职位，不能把技术可访问当平台授权； AI可以起草申请，不能默认替你不可逆提交； AI可以记录结果，不能把一个人的成功漏斗宣传成普遍胜率； AI可以提高效率，但最终目标不是海投，而是更高质量的职业决策。**
这才是AI真正应该进入求职流程的方式。