公司这边早就用 AI 筛简历了，求职者这边还在手动复制岗位链接、改简历、记 Excel。一个叫 santifer 的开发者把这件烦事整个工程化了：他写了一套跑在 Claude Code 上的求职系统，自己用它评了 740 多个岗位、生成 100 多份定制简历，最后拿下一个 Head of Applied AI 的 offer。然后开源，叫 career-ops。
两个多月，56k star，11k fork，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 负责评估、推荐、把简历和求职信都备好，但最后那一下------投不投、点不点提交------永远是你自己来。系统从不替你投递。
这一点守得很干净，配合一套追踪机制：每个评估过的岗位都登记进一张总表，full 报告单独存档。后台一堆脚本在保证这张表不出错------原子写入、SQLite 索引、自动去重、合并、状态归一化，连报告编号都是原子领取的，避免两个并行 worker 抢到同一个号。
AI 做脏活，人做决定，工程兜住数据一致性。该自动的自动，该人来的人来。
收尾：值得抄的是架构，不是求职
career-ops 火，表面上是因为它戳中了「找工作太痛苦」这个普遍痛点。但放到我们这个圈子里看，它更像一份样板：一个人怎么把一件具体的烦事，做成一套站得住的本地 agent 系统。
大脑是纯文本提示词，所以模型随便换；系统和用户数据分家，所以能一直更新不丢东西；扫描零 token、评估可降级，所以跑得起；人在环加完整性检查，所以靠得住。求职只是它恰好选的场景，换成报销、运维、个人知识库，这套骨架照样成立。
下次你想给自己搭个 agent 工具，不妨先想想这四条。
仓库地址：github.com/santifer/career-ops（MIT 协议）。