career-ops：把“该不该投”放在“怎么投”之前的开源本地 AI 求职代理
career-ops 是 santifer 开源的 AI 求职代理。粘贴一个职位，它在本机判断职位是否仍开放、是否匹配，再定制简历并起草回答，最后由你亲自点提交。作者自述评估 740 个职位、投递 68 个、面试 12 次、拿到 1 个 offer。项目强调本地优先、人在回路，并支持免费与本地模型。
它是什么：一个站在求职者一边的开源 AI 求职代理
career-ops 是 GitHub 上的开源项目，口号是“The open-source AI job search agent”。作者是 santifer（Santiago Fernández de Valderrama Aparicio）。项目的起点很朴素：他连续数月投出简历，却只换来沉默。于是他没有继续海投，而是给自己造了一个过滤器。README 给出的个人数据是：评估了 740 个职位，实际投递 68 个，进入 12 轮面试，拿到 1 个 offer。作者说，他是这个工具的第一个用户，拿到工作之后才把它开源。按 README 的说法，六个月后他离开了那份工作，现在团队继续做 career-ops，帮助更多人找到自己的工作。
用法被压缩成一句话：粘贴一个职位，工具在你自己的机器上告诉你两件事，这个职位是否还开放，以及它是否适合你。随后它会按职位定制你的简历，并起草申请表中的回答。最后一步由人完成：“You press Submit”，也就是你自己点提交。这个设计选择很重要，我们在后面详细讨论。
核心设计：先筛选，再行动
大多数“AI 求职工具”解决的是产出问题：更快地生成简历，更快地批量投递。career-ops 反过来，先解决判断问题。README 的开场白是：公司用 AI 筛选候选人，而作者“给候选人 AI，让他们去选择公司”。工具的第一个输出不是一份简历，而是一个结论。如果结论是“do not apply”（不要投），你就拿回了这个晚上。如果结论是一份计划，你就知道下一步该做什么。
演示动图展示了作者自己的求职过程：一个带评分的职位列表、一个以红色显示的“不要投”数量，以及一份完整的评估报告。界面是西班牙语，这也说明项目的使用场景是多语言的。README 本身提供了 17 种语言的版本，包括英语、西班牙语、德语、法语、日语、韩语、简体与繁体中文等。
工作原理与可核实的部分
需要先说明边界：我们引用的背景材料是 README 的开头部分，它没有披露内部实现细节，例如评分维度、提示词结构、职位抓取方式或数据存储格式。下面只讨论 README 明确写出的机制，以及可以由这些表述合理推出的工程含义。 第一，本地优先。README 写明“Open source. Local. In the AI CLI you already use.”，即它运行在你已经在用的 AI 命令行工具里，而不是一个托管的 SaaS。安装入口是一条命令：npx @santifer/career-ops init。这意味着它以 npm 包的形式分发，初始化后把工作流放进你的本地环境。简历、投递记录、评估结论这类敏感的个人数据，不必交给第三方平台。
第二，模型可替换。README 链接了一份“RUNNING_ON_A_BUDGET”文档，并写明包含免费模型和本地模型。对于不想为每次评估付费的求职者，这降低了使用门槛。代价也很明显：本地小模型在长文本判断与措辞质量上通常弱于云端旗舰模型，评估质量会随模型而变。 第三，职位“是否仍然开放”的检查。许多求职者的时间浪费在已经下架的职位上。把“是否还开放”与“是否匹配”放在同一次评估里，是一个很实用的切入点。README 没有说明检查方式，我们不做猜测。 第四，人在回路。工具起草回答、定制简历，但提交由人完成。README 的宣言把这条原则写成了六行：Apply better to fewer（少而精地投）；Signal over volume（信号胜过数量）；Evidence over keywords（证据胜过关键词）；A human decides（由人决定）；Local-first（本地优先）；Dignity on both sides of the table（桌子两边都要有尊严）。
关键数据与应如何解读
最醒目的数字是 740、68、12、1。它的漏斗很说明问题：评估量是投递量的十倍以上，投递量约为面试量的五到六倍。换句话说，绝大多数职位在评估阶段被淘汰，真正投出的只是少数。这与“海投”策略相反。
但是读者应当谨慎。这是一个人的求职经历，不是对照实验。作者没有提供不使用工具时的转化率，也无法排除行业、年资、地区、时机等因素的影响。因此它是有说服力的个案，不是效果证明。README 同样没有给出延迟或成本的基准数据，成本取决于你选用的模型。
社区信号则更多。项目在 Trendshift 上被标注为当日 GitHub 趋势榜第一，在 Product Hunt 上有展示，并获得 Vercel 开源计划的支持。README 还引用了 WIRED 和 Business Insider 的报道。项目还设有“HIRED.md”，用动态徽章统计公开的“已被录用”故事，每张卡片对应一个可以打开阅读的公开 issue。这些是项目自述的采用证据，真实性可以在对应页面核对，我们没有逐条验证。
对开发者与行业的影响
对开发者而言，career-ops 是一个值得研究的样本：它把一个高度个人化的任务，做成了运行在通用 AI 命令行里的可分发工作流，而不是一个独立应用。这个路径的好处是复用你已有的模型订阅与权限，分发成本低，也容易被社区改造。
对求职市场而言，它代表一种力量对等的尝试。招聘端早已用算法筛选简历，候选人端长期只有模板和关键词堆砌。career-ops 的立场是让候选人也拥有评估工具，并且明确反对“量大管饱”。有意思的是，它把“拒绝投递”当作产品的核心价值之一，这与多数以投递数量计量成功的工具不同。
局限与风险
首先，评估质量依赖模型。评分、匹配度判断和“不要投”的结论都是模型输出，可能有偏差。用户需要把它当作建议，而不是裁决。 其次，隐私与合规。虽然本地优先降低了数据外泄风险，但只要你使用云端模型，简历内容仍会发送给模型提供商。选择本地模型可以避免，但要接受质量折中。
第三，起草内容的真实性。自动定制简历必须以你的真实经历为准。README 强调“Evidence over keywords”，方向是对的，但工具无法替你核实事实，最终责任在提交的人。 第四，证据范围有限。目前公开材料以作者自述和社区故事为主，缺少独立的、可复现的评测。
未来演进
从 README 的结构可以看出几个方向：更多语言的文档与界面，更丰富的“被录用”案例库，以及围绕宣言形成的社区。
宣言页面还带有签名计数徽章，说明项目在尝试把一套求职实践变成社区共识。若要走得更远，最需要补上的是公开的评估基准：例如在固定职位集上比较不同模型的“该投/不该投”判断，并给出与人工判断的一致率。
结论
career-ops 的价值不在于让你投得更多，而在于让你投得更少、更准。
它把判断放在行动之前，把决定权留给人，把数据留在本地。证据主要来自一位作者的个案和社区故事，需要审慎看待，但思路清晰，门槛很低：一条 npx 命令，一个你今晚本来要投的职位，就能试出它是否对你有用。