GitHub 上的 ai-job-search 很有代表性：它不是一个新的模型框架，也不是又一个聊天 UI，而是把 Claude Code 这类 coding agent 用到了求职流程。搜索职位、读取岗位描述、匹配简历、生成申请材料、整理跟进状态，这些动作本来分散在浏览器、表格、文档和邮箱里，现在被 agent 串成一条流水线。
这类工具值得评测，不是因为“自动找工作”这个口号新鲜，而是因为它展示了 agent 产品化的一个方向：把大模型放进真实个人工作流，围绕文件、网页、评分、模板和人工确认构建闭环。相比单纯聊天，求职流程更结构化，也更容易看出 agent 工程的优缺点。
工具定位
ai-job-search 可以理解为一个 career agent。它的核心不是帮你“想要什么工作”，而是减少求职过程里的机械劳动。
典型流程包括：读取用户简历和偏好，抓取或导入职位列表，提取职位要求，计算匹配度，标注缺口，生成定制 cover letter 或简历要点，保存申请记录。Claude Code 在这里承担的是本地 agent runner 的角色：它能读写文件、执行脚本、维护任务状态，也能让用户在关键节点介入。
这和传统求职网站的推荐系统不同。传统推荐多在平台内部发生，用户只能看到结果。agent 求职工具更像个人侧操作系统：你可以定义偏好、保存本地数据、跨站点整理信息、按自己的格式输出材料。
可用价值
第一，它能做职位雷达。很多开发者找工作时，会同时看公司官网、LinkedIn、HN Who is hiring、GitHub、远程工作网站和社区帖子。手动筛选很耗时。agent 可以把岗位描述转成统一结构，例如公司、地点、薪资、技术栈、经验要求、签证、远程政策和申请链接。
第二，它能做匹配解释。普通关键词匹配只会告诉你 Python 命中几次。好的 agent 能解释“为什么匹配”和“哪里不匹配”：岗位需要 Kubernetes 生产经验，而你的简历只写了 Docker；岗位强调 B2B SaaS，而你的经历更偏内部平台。
第三，它能生成材料草稿。不是凭空包装，而是从已有经历中挑选相关证据，改写成更贴近岗位语言的 bullet points。这个环节能省很多时间。
第四，它能维护状态。投递、面试、跟进、拒信、内推联系人和备注都可以落到一个本地数据库或 Markdown 表格里。对长期求职来说，状态管理比单次生成更重要。
适合的架构
一个稳妥的求职 agent 不应该一上来就自动登录平台投递。更好的架构是本地优先。
resume and preferences
-> job source import
-> extraction and normalization
-> fit scoring
-> draft generation
-> human approval
-> tracking ledger职位来源可以先从用户保存的链接、RSS、导出的 HTML 或公开 API 开始。抽取层把岗位描述转成 JSON。评分层用固定 rubric 打分。生成层只产出草稿。投递层默认关闭，只给用户提供检查清单和链接。
这种结构有两个好处。第一，个人数据不会无意间散落到多个第三方。第二，agent 的错误不会直接变成错误投递。
评分 rubric
求职匹配不能只看“像不像”。建议把评分拆成多个可解释维度。
fit_score:
must_have_skills: 0.30
domain_experience: 0.20
seniority_match: 0.15
location_and_remote: 0.15
compensation_fit: 0.10
interest_signal: 0.10每个维度都应该有证据。比如 must_have_skills 不能只给 8 分，要指出岗位要求 Go、PostgreSQL、Kubernetes，而简历中 Go 和 PostgreSQL 有项目证据，Kubernetes 只有学习记录。这样用户才能决定是否补材料、跳过岗位，或者准备面试解释。
与普通自动化脚本的区别
普通脚本擅长固定流程：打开页面、抓字段、写表格。agent 的优势在非标准文本理解。不同公司岗位描述格式差异很大，有的把技术栈写在段落里，有的写在福利里，有的把真实要求藏在“nice to have”。LLM 可以更灵活地抽取和归类。
但 agent 也更容易过度解释。它可能把含糊描述当作硬性要求，也可能夸大候选人匹配度。所以工具必须保存原文证据，让用户能回到岗位描述核对。
风险评估
第一是真实性风险。求职材料必须基于真实经历。agent 生成时可能把“参与过”写成“主导过”，把“了解”写成“精通”。这类细微夸张会在面试中反噬。工具应该要求每个 bullet point 绑定简历证据。
第二是隐私风险。简历、手机号、邮箱、当前公司、薪资期望、签证状态都很敏感。如果工具把这些信息发给外部模型或日志服务，用户要清楚知道。默认应该最小化上传，并提供本地模型或可配置 provider。
第三是平台条款风险。很多招聘平台限制自动抓取、批量操作或自动投递。即使技术上能做，也不代表应该做。工具需要把“搜索辅助”和“自动提交”分开。
第四是声誉风险。自动化投递如果生成模板化、错误公司名、错误岗位名的材料，会直接伤害候选人形象。人类最终审核是必要环节。
第五是偏见风险。模型可能根据简历背景或岗位措辞做出不合理判断，比如过早过滤掉跨领域机会。评分要可解释，用户要能调整权重。
我会怎么改造
如果把 ai-job-search 当作一个可长期使用的工具，我会优先加四个模块。
第一，本地 SQLite 状态库。岗位、公司、联系人、申请状态、生成材料、面试记录都落表，方便查询和备份。
第二，证据绑定。每个生成的简历 bullet 都必须指向原始简历片段或项目经历，不能凭空生成。
第三，隐私分级。联系方式、当前公司、薪资、身份信息默认不进入模型上下文，除非用户明确打开。
第四，投递前 diff。生成的新简历和 cover letter 必须和基础版本做差异展示，用户确认后才导出。
适用人群
它最适合三类人。第一，正在大量浏览机会的开发者，需要减少筛选和整理时间。第二，想转方向的人，需要把已有经历映射到新岗位语言。第三，做个人 agent 产品研究的人，可以从这个项目观察“本地文件加网页加生成”的工作流。
它不适合希望一键海投的人。真正高质量求职仍然依赖选择、研究、定制和沟通。agent 能帮你处理重复劳动，但不能替你承担职业判断。
结论
ai-job-search 的价值不只在求职，而在它展示了 agent 工具的新形态：围绕一个真实、高频、有状态的个人流程，把搜索、抽取、评分、生成和人工确认串起来。它不是聊天机器人，而是工作流助手。
对开发者来说，最值得借鉴的是它的产品边界。让 agent 做候选发现、证据整理和材料草稿，让人类做真实性检查、策略选择和最终提交。这个边界处理得好，agent 是效率工具；处理不好，就会变成隐私和声誉风险。
参考来源：MadsLorentzen/ai-job-search、GitHub Trending、Claude Code Docs、Hacker News。