career-ops：用 AI 编码 CLI 反向重构求职流水线的开源工具

career-ops用 AI 编码 CLI 反向重构求职流水线的开源工具核心观点这不是AI 帮你投简历的老套路而是一个哲学翻转公司长期用 ATS简历过滤系统筛掉候选人作者 Santiago 的回答是——把同等智能交给求职者让求职者来筛公司。更关键的一点career-ops 明确反对海投它是一个过滤器而非批量投递机器。这让它与市面上绝大多数同类工具在设计哲学上处于对立位置。技术定位处于什么阶段career-ops 目前处于个人工具公开化 → 社区产品的早期阶段。它的 GitHub 仓库在发布后迅速获得 5.6 万 Star来自知乎报道Discord 社区一周内超过 1000 人。这不是一个经过商业打磨的 SaaS而是一位有16年创业经验的半路转行者用 6 周时间vibe coding出来的工具并且他本人用它实际完成了一次从零到 Head of Applied AI 的职业转型。理解它的正确参照系不是 LinkedIn、Greenhouse也不是 Careerflow而是可编程的职业顾问脚手架——你需要一定的 CLI 使用能力才能驾驭它。最核心的机制A-G 评分体系 人在回路整个系统的灵魂在于A-G 评估模块A-F 块角色摘要、简历匹配度、级别策略、薪酬调研、个性化度、面试准备STARR 方法G 块独立存在不影响 1-5 分制总分帖子真实性判断专门识别幽灵职位和诈骗招聘这个设计有一个巧妙之处G 块不参与最终评分这避免了职位是假的但其他维度得分高导致的误导。系统强烈建议只申请 4.0 分以上的职位而 Santiago 自己从 740 个职位中筛出 66 个命中率约 9%最终拿到 12 个面试落地一个目标职位。另一个关键设计是**human-in-the-loop原则**AI 评估、推荐但永远不自动提交申请每一步都需要人类确认。这与 LazyApply、Sonara 等全自动投递工具形成直接对比——后者走量不走质。与同类工具的横向对比工具核心逻辑用户干预程度定位哲学career-ops筛公司 定制简历高CLI 本地运行质量优先反海投LazyApply多平台自动批量投递低需盯着屏幕走量Sprout智能匹配 移动端 Swipe中体验优先Sonara全自动抓取投递极低彻底托管Careerflow简历建设 职业指导高职业发展career-ops 的差异化不在于更快而在于**更挑剔**。它的设计者认为海投不仅浪费自己的时间也浪费招聘方的时间——这是一种少见的双边视角。关键功能速览快速安装npx santifer/career-ops init cd career-ops claude # 或使用 OpenCode、Codex 等兼容 CLI主要工作流命令从 README 推断# 评估一个职位 /career-ops eval URL # 生成封面信 /career-ops cover # 深度公司研究 /career-ops deep # 联系人发现生成 ≤300 字的 LinkedIn 消息 /career-ops contacto # 批量处理并行子代理 claude -p / opencode run评分维度A-F 加权系统基于你的简历与职位描述做语义推理非关键词匹配这是它区别于传统 ATS 关键词堆砌套路的根本点。交叉验证信源一Business Insider 专访2026年4月Business Insider 对 Santiago 本人做了深度报道证实了以下数据740 个职位评估、66 个推荐、12 个面试、最终落地 Head of Applied AI。还原了他从 16 年实体手机维修创业者转型的完整故事。BI 的叙事角度是building in public is the new résumé——工具本身就是作品集。这与原文观点高度吻合属于一手信源背书。信源二Sprout Blog《2025年最佳求职自动化工具》评测该文章对比了 Sprout、LazyApply、Careerflow、AIApply、Sonara 五款工具均未提及 career-ops。这有两层含义一方面说明 career-ops 的受众圈层开发者 / CLI 用户与主流求职者市场存在隔阂另一方面该文对高质量 vs. 高数量的讨论实际上支持了 career-ops 的核心立场——文章明确指出75% 的候选人已在使用 AI 工具但大多数工具仍在走通用批量申请的老路这恰恰是 career-ops 反对的方向。两者并不矛盾而是站在同一个判断起点上。边界与局限不能无条件唱赞歌学习曲线真实存在需要 Node.js 环境、Claude Code 或类似 CLI、会配置 Playwright非技术背景用户几乎无法自行上手。第一批评估不会好是作者自己承认的系统需要大量投喂你的个人背景信息冷启动阶段效果有限对于急于求职的人不友好。模型依赖性本质上是 Claude Code及兼容 CLI的 prompt 工程封装模型能力上限即工具上限且对 API 费用有隐性消耗。landed a dream role的样本量是 1作者的成功故事具备显著的幸存者偏差他的技术背景 工具本身作为作品集的组合效应不适用于大多数非 AI 岗位求职者。Playwright 抓取的法律灰色地带自动扫描 Greenhouse、Ashby、Lever 等职位平台在某些平台服务条款下存在合规风险。个人启发这对你意味着什么具体决策对开发者 / AI 从业者这是一个值得立刻克隆并运行的工具。关键不只是用它找工作更是理解它的架构——一个以本地 AI CLI 为执行引擎、以结构化评分体系为决策核心的 agentic pipeline这套思路可以复用到任何需要大量评估 个性化输出的场景里。对正在求职的普通人如果你有 CLI 基础建议花半天时间配置好把 20-30 个意向职位跑一遍感受评分 理由的反馈质量再决定是否深度使用。不要指望它替代你思考它的最大价值是把你从盯着 JD 发呆的低效循环中解放出来迫使你主动定义自己的求职标准。对招聘侧 / HR这类工具的普及意味着高质量的量身定制简历会越来越多ATS 关键词过滤的信噪比会持续下降。未来的筛选压力将转移到更高维度的判断上作品集、实际案例、异步测试等。推演接下来会怎样career-ops 目前的形态本质上是可编程的工作流 AI 推理引擎其竞争护城河不在代码本身代码是开源的而在于社区生态和 Prompt 工程的积累。可以预判短期内会出现垂直化 fork针对特定行业法律、医疗、金融的定制化版本评分维度会针对行业特性调整。中期威胁来自 CLI 工具本身如果 Claude Code、Codex 这类工具原生集成求职助手功能career-ops 的技术壁垒会快速消解但社区和 manifesto 的品牌效应仍有价值。求职者筛公司的逻辑会反向影响招聘方当越来越多候选人用评分系统筛职位那些得分持续偏低的公司薪酬不透明、JD 模糊、文化危险信号会被集体回避这对雇主品牌是一个新的压力来源。延伸思考A-F 评分体系的维度设计本身就是一份隐藏的求职哲学——它迫使你在申请前先想清楚什么对我重要。这套评分框架是否适用于中国市场的求职环境国内职位薪酬不透明程度更高、职位描述水分更大G 块的幽灵职位检测可能需要完全重写。build in public is the new résumé——Santiago 的成功本质上是把工具当成了作品集。在 AI 工具泛滥、人人都会 vibe coding的时代这条路径是否仍然有效还是说这个窗口期已经在快速关闭Career-ops 的human-in-the-loop设计是刻意的克制它永远不自动提交申请。随着 AI Agent 能力越来越强这条线会不会被下一代工具打破届时真正的责任边界应该划在哪里——工具设计者、使用者还是招聘平台 参考来源GitHub - santifer/career-ops: Open-source AI job search: scan job portals, evaluate listings with a structured A-F rubric into a 1.0-5.0 score, tailor your CV, track applications — runs locally in your AI coding CLI (Claude Code, Codex, OpenCode, Antigravity…) · GitHub