公司用AI筛简历，他写AI帮你反选公司

公司目前已经在使用 AI 进行简历初筛，但许多求职者依然在手动复制岗位链接、反复修改简历、用 Excel 记录进度。一位名叫 santifer 的开发者将这一繁琐过程进行了系统化工程——他在 Claude Code 上搭建了一套求职自动化系统，亲自评估了 740 多个职位、生成了 100 多份定制化简历，最终成功获得了 Head of Applied AI 的录用通知。随后他将这套系统开源，命名为 career-ops。

仅两个多月，该项目已收获 56k 星标与 11k 复刻，WIRED 和 Business Insider 均做了报道。

但值得关注的并非“又一款求职神器”。真正值得剖析的是，一位开发者如何将日常琐事，构建成一套本地优先、模型无关、人机协同、可升级且不丢失数据的 agent 系统。这套架构可以广泛应用于各类个人工具。

一、海投无效，关键在于筛选

career-ops 反复强调一个理念：这不是盲目海投工具，而是智能过滤器。

它为每个岗位打分，涵盖 A 到 F 共十个加权维度，最终输出 1 到 5 的总分。系统建议：低于 4.0 分的岗位直接放弃。理由很务实——你的时间宝贵，招聘方的时间同样宝贵，海投只会造成双方资源浪费。

除了评分，还有一个值得关注的模块叫 Block G：用于识别岗位本身的可靠性。它会分析招聘信息中的信号，判断是否为不正规公司或长期挂出却无人招聘的“幽灵岗位”。有过求职经历的人都知道，这类岗位最消耗精力。

评估结果是一份结构化的报告：包含岗位画像、与你的简历匹配度、定级策略、薪资行情、针对你简历的修改建议以及面试准备方向。这不是简单的关键词匹配，而是让 AI 结合你的简历内容与岗位描述进行深度推理。

二、它的“大脑”是一堆 Markdown，而非代码

这是第一个值得借鉴的设计思路。

career-ops 的核心逻辑——如何打分、如何评估、如何修改简历——并未写入代码中，而是存储在 modes/ 目录下的一系列 Markdown 提示词文件里。oferta.md 定义了 A–G 评估模块，_shared.md 则包含评分核心：1 到 5 的评分标准、岗位类型识别、招聘真实性信号及全局规则。AI 读取这些文件，结合你的 cv.md，生成评估报告。

逻辑与代码分离带来了直接优势：模型无关性。同一套提示词，可以使用 Claude Code 运行，也可以切换到 Codex、OpenCode、Gemini 或 Qwen，没有任何模型被写死。仓库中的 .claude、.codex、.qwen、.kimi 配置目录正是为此设计。

换句话说，它将“业务逻辑”沉淀为纯文本，任何模型均可执行。这与我们编写 skill 的思路一致：将确定性流程固化为提示词，模型只负责理解和执行。

三、最值得借鉴的一点：系统文件与数据分离

如果只能学习一个要点，那就是这个。career-ops 将其称为 data contract（数据契约），是整个项目最重要的架构原则。

它将所有文件严格分为两层：

系统层属于工具本身——modes/、各类脚本、模板、仪表盘等。这些随版本更新，由 update-system.mjs 负责管理。

用户层则是你的数据——cv.md、个人配置、data/、reports/ 等。更新器从不触及这一层。

为什么这一点如此关键？任何需要迭代的 agent 工具都会面临相同问题：发布新版本时，如何确保不覆盖用户辛苦积累的数据？许多个人项目因此失败——更新后配置丢失、记录消失。career-ops 的做法是将边界写入 DATA_CONTRACT.md 作为唯一事实来源，再加上一组迁移测试，强制检查：任何系统路径都不得与用户路径重叠。测试不通过，更新便无法发布。

这一思路与求职本身无关。但凡你需要开发一个长期更新、又存储用户数据的工具，都应该采用这种设计。

四、为何它消耗的 token 极少

career-ops 在成本控制上有几个巧妙安排，并非盲目将所有任务交给大模型。

岗位搜索这一步完全零 token。scan.mjs 直接调用各大招聘系统的公开 API——Greenhouse、Ashby、Lever、BambooHR、Workday 等，配合各招聘平台的模块获取数据。这一步完全不需要模型，纯脚本即可完成。需要登录或绕过验证的渠道，它故意不纳入核心，留给插件层处理。

评分这一步也能从交互式 CLI 中分离出来。它额外提供了几个独立评估器，让你使用更便宜或本地模型运行同一套评分逻辑：ollama-eval.mjs 完全本地，gemini-eval.mjs 使用 Google 免费层，openai-eval.mjs 可接入任意兼容接口。批量评估时，再通过子 agent 并行处理——开启多个 claude -p 的无头 worker 同时计算。

哪些步骤该用脚本、哪些该用模型、哪些该用便宜模型，划分得十分清晰。这是认真考虑成本的设计。

五、它从不代替你提交申请

career-ops 全程保持人机协同。AI 负责评估、推荐、准备简历和求职信，但最后一步——是否投递、点击提交——始终由你亲自完成。系统从不代你投递。

这一点界限清晰，并配合一套追踪机制：每个评估过的岗位都会被记录在一张总表中，完整报告单独存档。后台有一系列脚本确保这张表不出错——原子写入、SQLite 索引、自动去重、合并、状态归一化，甚至报告编号都是原子领取的，避免两个并行 worker 获取同一编号。

AI 完成繁琐工作，人做决策，工程确保数据一致性。该自动化的自动化，该人工的保留人工。

收尾：值得借鉴的是架构，而非求职工具本身

career-ops 走红，表面是因为它切中了“求职太痛苦”这一普遍痛点。但从技术圈的角度看，它更像一个样板：一个人如何将一件具体的烦心事，打造成一套站得住脚的本地 agent 系统。

大脑是纯文本提示词，因此模型可随意更换；系统与用户数据分离，所以能持续更新而不丢失数据；扫描零 token、评估可降级，因此成本可控；人机协同加完整性检查，所以可靠。求职只是它恰好选择的场景，换成报销、运维、个人知识库，这套骨架同样适用。

下次你想为自己搭建一个 agent 工具，不妨先考虑这四条设计原则。