career-ops 自动化测试实战：从 doctor 到 verify，把求职流水线做成可回归系统
很多人现在都在用 AI 做“求职自动化”：自动抓岗位、自动评估匹配度、自动生成定制简历、自动维护投递看板。思路很好，但我最近看到的最大问题不是“功能不够多”，而是“流程很容易悄悄坏掉”。
比如你前天还能正常扫 Greenhouse，今天目标站点改了 DOM；比如你的批处理产出 TSV 里状态写法不统一，后面看板统计直接失真；再比如报告文件和 tracker 链接对不上，最后你以为自己投了 30 家，其实有 8 条已经是脏数据。
这篇我不讲概念，直接拿 career-ops 这类基于 Claude Code 的求职流水线工具，拆一套我自己会落地的自动化测试方案。目标很直接：把“能跑”升级成“可回归、可验证、可长期维护”。
为什么这类工具最需要“流水线级测试”
传统项目里你可能只盯单元测试或接口测试，但求职自动化工具有三个明显特征：
- 依赖外部页面：岗位站点一改版就会连锁影响抓取与评估。
- 跨多种产物：同一次运行会产生报告、PDF、tracker 记录，任何一个环节错位都会污染结果。
- 强依赖状态一致性：
Evaluada / Aplicado / Entrevista这类状态一旦混乱，后续决策就不可信。
所以我现在的做法是：把测试目标从“某个函数是否正确”升级成“整条求职流水线是否健康”。
我会先把测试面拆成 4 层
在 career-ops 里，这 4 层都能找到对应脚本或规则，不需要你自己硬造框架：
- 环境层：
doctor.mjs检查 Node、依赖、Playwright、cv.md、profile.yml等前置条件。 - 脚本层：
test-all.mjs对主要.mjs脚本做语法和执行级回归。 - 数据层：
verify-pipeline.mjs/normalize-statuses.mjs/dedup-tracker.mjs保证 tracker 可用。 - 批处理层：
merge-tracker.mjs+batch/batch-runner.sh保证多 worker 输出可安全合并。
这套拆法的好处是：你不需要等“结果明显错了”才发现问题，而是可以在每次批处理前后把风险提前拦下来。
实操：我现在固定跑的 7 个测试步骤
下面这 7 步，都是仓库里已经存在的脚本能力，可以直接跑。
1）先跑环境体检
1 | |
这一步会检查依赖是否安装、Playwright chromium 是否就绪、关键目录是否存在。对这类工具来说，环境没过关，后面所有测试结论都不可信。
2）做一次快速回归，再做一次全量回归
1 | |
--quick 适合你日常频繁改动后的快速闸门；全量跑法会包含 dashboard 构建与更多完整性检查，适合合并前。
3）验证流水线健康度（最关键）
1 | |
这一步对应 verify-pipeline.mjs，会检查：
- 状态值是否属于规范集合
- 是否有重复岗位
- 报告链接是否存在
- score 格式是否正确
- tracker 行格式是否损坏
对求职自动化来说，这比“某个脚本是否成功执行”更重要，因为它直接决定你的看板是不是还能做决策。
4）先 dry-run 再做状态归一化
1 | |
我强烈建议先 --dry-run 看映射结果，再正式写回。这样你能防止把少量特殊状态错误覆盖掉。
5）去重前先预览
1 | |
dedup-tracker.mjs 是按公司 + 角色相似度去重，不是简单删重复行。先预览可以避免误删“看起来像重复、实际是不同岗位”的条目。
6）批量合并后立即验证
1 | |
批处理最容易出现“每个 worker 都没报错，但合并后数据错了”的情况。--verify 让你在合并完成后立刻触发健康检查，而不是第二天才发现统计不对。
7）把链接存活检测单独拉出来
1 | |
check-liveness.mjs 内置了过期页面特征和 apply 按钮信号判断。这个很实用：你可以在批量处理前先踢掉明显失效岗位，减少无效评估。
我会怎么把它接进日常：本地 + CI 双闸门
如果你只是一个人维护这个系统，最小落地方案其实很轻：
本地闸门（提交前）
npm run doctornode test-all.mjs --quicknpm run verify
CI 闸门（合并前）
node test-all.mjsnpm run verify- （如有批处理产物）
node merge-tracker.mjs --verify
这样做的好处是分工清楚：本地保证“我这次改动没有明显破坏”，CI 保证“主干分支保持长期可用”。
和常见“只写功能、不测数据”的差别
很多人做自动化工具时会犯一个错：只盯功能演示，忽略数据契约。career-ops 在这块给了很好的范式：
- 用
DATA_CONTRACT.md明确区分 system layer 和 user layer。 - 用脚本持续校验 tracker 的规范性，而不是靠人工目测表格。
- 用批处理状态文件 + 合并脚本，保证并行 worker 输出最终可收敛。
这三个点叠加起来，才是“能长期跑”的关键。否则再炫的 Agent 工作流，最后也会倒在脏数据和不可追踪的状态上。
总结：先把“正确性”做出来，再追求“自动化规模”
我现在对这类工具的原则很简单：
- 没有稳定测试闸门，不扩大自动化范围。
- 先守住 tracker 正确性，再谈多 worker 并行提速。
- 所有会改写数据的脚本，先 dry-run 再落盘。
如果你也在做 Claude Code / OpenClaw 方向的求职自动化，不妨先照这 7 步跑一轮。你会很快发现，真正让系统“耐用”的，不是多一个花哨功能，而是每次更新后你都能确定：这条流水线仍然可信。
支付宝打赏
微信打赏
如果文章对你有帮助，欢迎点击上方按钮打赏作者，更多功能请访问博客站