OpenJob 复盘：
把求职串成一条可审阅的流水线

集中找工作那段时间，我发现一个尴尬的事实：占用时间的全是重复劳动，而真正决定成败的全是判断。翻页、去重、筛岗位是重复的；"这个岗位值不值得投"没法外包。把同一份简历改出五个版本是重复的；"这版该突出什么"没法外包。于是就有一个很自然的分工问题——哪些交给机器，哪些留给自己。

OpenJob 是我给出的答案：一个运行在自己电脑上的 AI 求职工作台，把"找岗位、去重、评分、改简历、准备招呼语、盯回复"串成一条流水线。它不是代投服务，更不是无人值守的海投机器人。

01设计哲学：三条分工铁律

整个项目都建立在这三句分工上：

• 机器做重复的：翻页采集、去重入库、逐条打分、按 JD 改简历文字、定时盯回复；
• 我做判断的：投不投、确认每一条发出的消息、决定简历最终版本；
• 机器不许碰的：任何对外发送动作。所有打招呼、发简历、回复 HR 都先进确认队列，我放行才发——代码层面不存在绕过路径。

第三条最容易被质疑"何必这么死板"。但用了之后我反而确定：确认制不是效率的敌人，是信任的基础。正因为知道机器绝不会替我发出任何一句话，我才敢让它在前面放开跑。

02五个环节，各自的巧思

采集：只做入口，不做黑箱

岗位来自 BOSS 直聘的搜索结果，关键词和城市完全由我配置，支持搜索流、推荐流和针对目标公司的定向猎捕三条路。所有岗位统一去重入库，实习岗和正式岗在采集阶段就能识别过滤。到点的定时任务只做"采集 + 评分"，错过时段就记录跳过，绝不补跑——宁可少采一轮，不做失控的事。

评分：让 AI 说人话，也说真话

五维评分里"职责匹配"占 40 分、"证据强度"占 25 分。我特意加了一条"弱迁移封顶"：没有直接证据的技能，不允许 AI 因为"看起来相关"就打高分。黑名单和一票否决词命中直接出局。整个评分阶段零页面访问——纯文本分析，不占平台的风控额度。

简历：改写可以激进，编造绝对不行

简历定制是整条流水线里工程量最大的环节。多方向底稿按岗位方向自动选稿；JD 定向改写采用逐行等长换写——换动词、融入岗位关键词、调语序，但照片、栏目、版式永不改动，保证一页排版零损伤。最有意思的是编造拦截：AI 想新增事实、数字、经历？检测到就生成失败。AI 腔还会被自动清洗掉——"赋能""抓手"这类词活不过终审。

投递：确认队列是唯一的出口

所有对外动作先进队列，逐条放行。招呼语基于 JD 和简历生成，我可以编辑后发送。三重防重复（岗位级 + 会话级 + 历史台账）保证我不会对同一家公司发出尴尬的第二句。每日上限、随机间隔、发送时间窗——机器负责节奏，我负责内容。

监测：让等待也自动化

HR 回复由定时监听发现，桌面通知提醒我去平台回复。跟进间隔可配置，默认关闭——我不想变成骚扰机器人的样子。

03工程化：给自己上的枷锁

一个自己用的工具，最容易死在"随便改改"上。OpenJob 的做法是把工程标准拉满：GitHub Actions 把 Python 测试、静态检查、前端构建和关键 UI 验收作为合并门禁；每日自动备份数据库和简历；数据完全自持在本地。这些约束在添加的时候都让我慢了一点，但每一次重构都没有还过债。

04复盘：学到的三件事

• 配置驱动的价值在"第二份数据"出现时才显现。最初我把关键词写死在代码里，直到第二次换城市搜索才体会到：把数据源、字段映射、评分规则全部抽离成配置，才是可复用的前提。这个思想后来也被我用进了电商增长分析框架。
• 人工确认不是效率的敌人。加确认队列那天我以为自己会烦，结果它成了我最安心的功能——流水线越自动，出口越要收紧。
• AI 最大的风险不是出错，是"看起来对"。弱迁移封顶和编造拦截这两个机制，都是被 AI 的自信教育出来的。它不是在撒谎，它只是在没有证据的时候也敢下结论。