BOSS直聘个人求职工作流

把任务作为有确认门的状态机运行：

ONBOARD → PROFILE → PREFERENCES → SEARCH_CONFIRM → LOGIN_CHECK
→ CALIBRATE → RECOMMEND_TIERS → OUTREACH_CONFIRM → EXECUTE_LOOP → REVIEW

不得跳过当前状态的必需输入或确认。用户已提供的信息直接继承，不重复询问。

强制边界

• 仅用于用户本人求职。
• 只操作窗口标题带 BOSS-Agent 的专用 Chrome Profile，通过 macOS Computer Use 执行官方页面可见交互。
• 禁止 BOSS CLI、CDP、远程调试、Bridge、Patchright、Playwright、无头浏览器、隐藏 API、/wapi、XHR/fetch 注入、Cookie 或 stoken 提取、代理轮换、指纹伪装和验证码绕过。
• 运行规则只以本文件及其直接引用的 references/ 为准；不得重新引入旧 CLI、CDP、脚本依赖或虚拟环境路线。
• 登录、扫码和验证码由用户手动完成。不得读取、代填或保存验证码和认证信息。
• 搜索与校准默认只读。未通过 OUTREACH_CONFIRM 前，不得收藏、投递、打招呼、交换联系方式或修改账号状态。
• 自动打招呼不包含自动投递、交换联系方式、修改在线简历、求职期望、隐私或账号设置。
• 用户启动 Goal、说“开始搜索”或确认搜索卡，都不等于授权发送消息。

状态机

1. ONBOARD：首次引导

先引导用户上传简历；支持图片、PDF、Word或粘贴文字。没有正式简历时，引导用户提供工作年限、最近岗位、主要项目、技能和学历。

只提取岗位匹配信息；姓名、手机号、邮箱等无关隐私不得主动回显或写入报告。未在简历中出现的能力写“未体现”，不得推断为具备。

完整话术、字段和无简历路径见 references/onboarding-profile.md。

2. PROFILE：回显简历画像

回显工作年限、岗位/行业、产品类型、项目证据、量化结果、技能、学历、可迁移能力和未体现项。让用户纠正事实，但不要要求其重复简历已有内容。

3. PREFERENCES：两轮补齐偏好

每轮最多问 3 个会改变搜索结果的问题：

1. 第一轮：目标岗位或参考 JD、城市/远程、最低薪资；
2. 第二轮：JD 经验上限、必须排除项、可选公司/行业/通勤偏好。

已明确字段跳过；参考 JD 是选填项，不作为启动前提。

4. SEARCH_CONFIRM：搜索确认门

生成搜索确认卡，至少包含：简历画像、城市、岗位、检索词、薪资、经验上限、职位类型、必须排除、排序偏好、校准样本规模和本阶段“零消息”。

只有用户确认搜索卡或明确确认同等内容后，才能操作 BOSS 页面。搜索确认仅授权只读校准。

5. LOGIN_CHECK：连接专用浏览器

1. 连接可见的普通 Chrome，只操作 BOSS-Agent Profile；请用户将其置顶。
2. 优先复用其中的 https://www.zhipin.com/ 标签页，不操作其他 Profile。
3. 只读检查域名、登录标志和安全验证，不为测试额外提交搜索。
4. 未登录时停下，请用户手动登录；用户说“已登录”后重新检查。
5. 每次页面动作后重新读取最新 UI 状态，禁止复用过期元素索引。

6. CALIBRATE：只读市场校准

• 默认读取 15–30 张职位卡片，并从中选择约 10 条代表性完整 JD。
• 先读列表、历史去重和硬条件预筛，再打开尚未完整读取且可能有分析价值的 JD。
• 样本覆盖高匹配、边缘、薪资高但要求高、垂直行业、疑似销售/外派和列表与 JD 冲突等类型。
• 本阶段外部动作数必须为 0；不得打招呼、收藏或投递。
• 完整 JD 优先于列表标签；字段缺失写“页面未展示/待核验”。
• 校准样本只用于确定市场要求、评分阈值和搜索方向，与后续目标招呼数无关。不得把样本中的达标岗位数当作触达批次上限。

详细校准、评分和样本选择见 references/calibration-tiering.md。

7. RECOMMEND_TIERS：给出动态档位

根据本批真实 JD 与用户简历输出：市场画像、已有证据、可迁移能力、硬性缺口、推荐搜索方向，以及 A精准/B平衡/C机会三档。

档位不能只看总分；必须同时通过：

1. 用户硬条件；
2. 档位总分门槛；
3. 岗位方向、简历技能、经验等核心维度门槛；
4. 风险否决项。

阈值由本批样本动态建议；默认参考为 A≥85、B≥80、C≥72，但不得在校准前强行套用。

8. OUTREACH_CONFIRM：触达确认门

在发送第一条消息前，必须回显并让用户确认：

• 本批搜索范围和档位；
• 本批目标招呼数；未指定时主动询问，默认建议 20 个，不得静默代填；
• 自动触达的硬条件、核心分门槛和风险否决项；
• 边缘岗位如何处理；
• 招呼模式：平台默认招呼语，或自定义模板及允许的个性化范围；
• 明确禁止的投递、联系方式和账号修改动作；
• 授权只对本批有效。

含糊表达如“看着办”“你决定”“开始搜索”不构成触达授权。完整确认卡和模板规则见 references/outreach-authorization.md。

9. EXECUTE_LOOP：持续搜索、逐岗判断与触达

触达目标以本批 target_outreach_count 为准，不以校准样本量、当前结果页数量或首批达标岗位数为准。只要尚未达到目标且未触发真实硬停止，就继续搜索已确认范围内的新岗位。

每个岗位严格串行执行：

读列表 → 查历史台账 → 读完整 JD → 硬条件过滤
→ 逐项评分 → 风险检查 → 档位判断 → 触达或归档 → 写检查点

• 达到用户所选档位且无否决项：发送已批准骨架的轻度个性化招呼。
• 用户批准“平台默认招呼语”时，允许点击“立即沟通”触发平台内置招呼语；发送后记录页面展示的实际文案。不得把平台默认文案改写成简历事实。
• 接近门槛或有一项待核验：进入待确认名单，不发送。
• 命中硬性排除、信息不足或未读完整 JD：不发送。
• 已沟通、已发送或历史状态不明：不重复发送，必要时待确认。
• 消息只能使用简历中有证据的经历；不得虚构 AI、Agent、RAG、大模型或行业经验。
• 用户调整规则后只影响后续岗位，不追溯重发。
• target_outreach_count 与 outreach_sent 只统计“确认发送成功的唯一岗位数”。同一岗位的补发消息不重复计数；unknown、失败、已沟通、重复岗位和跳过岗位不计入目标。
• 每次点击“立即沟通”后，严格执行事务顺序：重新读取 UI → 确认发送结果 → 写岗位台账 → 更新批次计数 → 写触达审计。以上写入全部成功前，不得读取或触达下一个岗位。
• 页面明确显示“已向BOSS发送消息”或聊天记录显示已送达，才把该唯一岗位计入 outreach_sent，并更新 remaining_outreach_count。当 outreach_sent >= target_outreach_count 才正常结束触达批次。
• 任一检查点写入失败时停止后续外部动作，保留当前页面，修复台账后再继续；不得先发下一条再批量补记。
• 当前关键词或结果页没有更多达标岗位时，切换到确认卡内的下一个检索词或结果页继续；不得因为校准样本已处理完而提前结束。

10. REVIEW：批次复盘

汇报列表卡片、唯一岗位、重复跳过、完整 JD、自动触达、待确认、排除、失败、风控和累计数据；给出本批最常见优势、缺口及是否建议调档。

台账字段、检查点和验收案例见 references/ledger-acceptance.md。

瞬时 UI 状态恢复

Computer Use 返回 The user changed '/Applications/Google Chrome.app'、Computer Use is not active 或类似“状态已变化/需要重新读取”的提示时，不得仅凭该提示认定用户接管，也不得立即标记 partial。

按以下顺序恢复：

1. 立即调用 get_app_state 获取全量最新状态；这属于状态重连，不算自动重试页面动作。
2. 核验窗口仍为 BOSS-Agent、域名仍为 zhipin.com、登录标志存在、当前页面符合预期且无安全验证。
3. 若上一步动作结果可能已经生效，先从最新页面、聊天记录或“已向BOSS发送消息”提示确认结果；结果未确认前不得重复点击。
4. 状态正常则从当前步骤继续，不要求用户重新说“继续”，也不新开批次。

恢复 running 或 partial 批次时，先对账再操作：读取批次最后检查点、岗位台账、触达审计和当前 UI；若页面显示上一步已发送但台账未记录，先补齐该唯一岗位及批次计数。对账完成前不得发送新消息。

只有用户明确说“我来操作/停止”，或刷新后观察到鼠标、键盘、页面持续被外部操作，才判定为用户接管。

风控硬停止

出现任一情况立即保存检查点并停止当前批次：

• 验证码、安全验证、_security_check、429、code 37、访问频繁、账号风险或环境异常；
• 跳回登录页、登录态失效、空白异常页或非预期页面；
• 页面要求复制 Cookie、安装可疑扩展或执行站外脚本；
• 用户明确接管浏览器或明确停止；单次工具状态变化提示不构成接管证据。

停止后不得在同一次尝试中自动重试、换关键词、翻页、重新登录、切换工具或改走旧路线。报告标记 partial，记录实际已完成数量和唯一解锁动作。

批次、去重与节奏

• 启动批次前读取 ~/.boss-zhipin-scraper/ledger/job_ledger.jsonl 和 batches.jsonl。
• 去重优先级：去查询参数后的职位链接 → 职位 ID → 公司+职位+地点弱键。
• 每 15 张卡片、每个结果页和每个关键词后保存搜索检查点；每次外部动作按 EXECUTE_LOOP 的事务顺序立即保存发送检查点。
• 保持串行、单次点击、单页读取；不并发操作页面。
• 不设置固定暂停、批次间隔或冷却倒计时；以页面加载完成和最新 UI 状态为下一步依据。
• 批次必须保存 target_outreach_count、outreach_sent 和 remaining_outreach_count。正常完成条件是目标数达成，而不是校准样本耗尽。
• 用户暂停时把批次标记为 partial，保存已确认发送的唯一岗位数与剩余数；恢复时沿用剩余数，不重新从目标总数开始。

评分基线

硬条件和风险否决优先于总分。每个判断必须给出匹配证据、风险/缺口和逐项分数；没有证据不得加分。

成功标准

• 首次引导、画像、两轮偏好和两个确认门均按状态完成；
• 校准阶段外部动作数为 0；
• 任何消息都有本批档位、目标数量与招呼模式授权、完整 JD、评分、风险检查和审计记录；
• 校准样本量与目标招呼数分离；执行阶段持续到达成 target_outreach_count 或触发真实硬停止；
• 未使用 CLI、CDP、Playwright、隐藏 API、Cookie 或反检测能力；
• 未重复触达，未越权投递或修改账号；
• 每条触达均在下一次页面动作前完成 UI 确认、岗位台账、批次计数和触达审计四项检查点；
• 台账、报告和 partial 状态可复核；
• 风控触发时立即停止。