Boss Hiring Assistant
执行优先级
龙虾执行本 skill 时，必须按下面的优先级理解规则：
- 阻断式前置条件
- 浏览器路由硬规则
- 当前服务文档
- 发送 recipe
- 其他补充文档
如果低优先级内容与高优先级内容冲突，一律以高优先级内容为准。
目标
这个 skill 只做三类服务，并且三类服务必须分开理解、分开执行：
boss-screening只负责读取岗位、读取候选人、筛选、分类、汇报。boss-chat只负责 BOSS 站内沟通。boss-scheduling只负责候选人已确认时间后的飞书约面。
如果用户没有明确指定服务类型，默认先进入 boss-screening。 不要把三类服务混在同一轮里自由串行。
首次安装后的介绍
用户首次安装这个 skill 后，必须先用中文向用户做一个简短介绍，再进入任何具体执行。
介绍内容至少包含：
- 这个 skill 分成三类独立服务：
- boss-screening：简历筛选和周期汇报 - boss-chat：BOSS 站内沟通 - boss-scheduling：飞书 bot 约面
- 推荐用户先从
boss-screening开始 - 后两类服务按需启动，不必首次安装时一起配置
- 在任何浏览器接管开始前，必须先让用户在 Chrome 或 Chromium 浏览器里打开并登录 BOSS 直聘招聘者页面
boss-screening可覆盖的候选人范围：
- 主动进入聊天列表或主动投递中的未读候选人 - BOSS 推荐页面里的本轮未处理候选人 - 搜索页面里的本轮未处理候选人（当账号具备搜索权益时）
boss-screening的核心规则是：按每个 JD 的每日目标候选人数来筛选，而不是机械按小时运行- 新一轮筛选默认只处理“未读/未处理候选人”，不重复重扫已经处理完成的旧候选人，除非满足重扫条件
- 如果用户不指定每日目标人数，就先让用户为每个 JD 设定目标；时间窗口和汇报节奏只是辅助设置
- 启动方式：
- 用户说“先帮我做简历筛选”时进入 boss-screening - 用户说“帮我联系这些候选人”时进入 boss-chat - 用户说“帮我给这些候选人约面”时进入 boss-scheduling
如果用户没有明确选择，默认建议先从 boss-screening 开始。
在这一步没有完成前，不要：
- 直接进入 Boss 页面读取
- 直接开始筛选
- 直接开始发消息
- 直接开始飞书约面
顶层硬规则
1. 浏览器访问只允许走 web-access
BOSS 页面上的所有读取、点击、切换线程、打开详情、发送消息，都必须先遵守：
这是一条硬规则，不是建议。
对于 web-access 的 eval 能力，必须先做最小探针验证请求写法正确，再执行复杂逻辑。 不要在 eval 传参方式未确认时直接跑复杂脚本。
对于 Boss 聊天页中的在线简历读取，默认优先走“左侧点击候选人卡片 + 右侧简历面板提取”的路径，不要先假设会跳转到独立 URL。
在 Boss 任务中，默认只允许操作用户当前已经登录的 Boss tab。 不要为了进入招聘后台或职位管理而新建 tab、新建窗口或新建浏览器上下文。
如果当前已登录 tab 存在，就必须复用它的 targetId 和同一 browserContextId。 不要通过 web-access /new 直接新开 Boss 页面再尝试进入后台。
如果 targetId 变化，不要立即要求用户确认登录状态。 必须先按 browser-routing.md 中的规则自动重新绑定 Boss target，并做低成本登录态探针。
1.1 截图默认彻底禁止
在 BOSS 页面读取中，截图、OCR、图像理解默认彻底禁止。
如果 web-access 读取失败：
- 允许在同一路径内最多再尝试
2次 - 如果仍失败，不允许自动切换到截图路径
- 必须先向用户说明：
- web-access 已尝试失败 - 现在可以改走截图等异常方案 - 这些方案可能增加 token 消耗，也可能提高 BOSS 风控或网页登录强退风险 - 默认更建议继续坚持 web-access
- 只有用户明确同意后，才允许临时启用截图等异常方案
2. BOSS 站内发消息必须走固定 recipe
只要进入 BOSS 站内消息发送，必须先读取并执行：
不要把该文档当参考说明。 不要再自行重新设计 DOM 路径、前端事件路径、子代理方案。
如果候选人线程都没有成功打开，就不得继续做输入框查找和发送动作。 但在暂停前，必须先把“自动打开候选人线程”的标准路径和有限备用路径走完。 不要一失败就要求用户代为点击候选人。
如果标准路径失败，下一步必须优先走低 token 的分层自动诊断，而不是直接进入长时间试错或大段脚本探索。
发送 Boss 站内消息时，必须做候选人身份校验，避免把给 A 的消息发给 B。
发送按钮点击路径也必须受控：
- 默认优先使用
web-access clickAt - 其次才是底层 CDP 鼠标事件
- DOM
btn.click()只允许作为一次性兜底，不得作为默认主路径
特别是在批量打招呼时，不允许把 DOM click 当成标准实现。
对于“索要附件简历”类消息，发送后还必须继续跟进：
- 候选人是否已发送简历
- 是否出现“同意/接收”按钮
- 是否已点击完成接收
如果是批量打招呼或批量推进消息，还必须额外遵守：
- 小批量分轮发送
- 相邻发送之间加入短暂停顿
- 每发送 2 到 3 人做一次轻量状态校验
- 触发验证码、异常验证、登录态波动、页面异常跳转时立即停止整轮发送
如果首条打招呼发生在推荐页，还必须额外遵守：
- 禁止用 XPath 或 DOM 序号点击“第 N 个按钮”
- 必须先绑定稳定候选人标识，再点该候选人卡片内按钮
- 如果没有唯一 ID，必须先用 eval 给目标按钮临时写入
data-*标记，再用 CSS selector 调clickAt或click - 必须按“一人一事务”执行，不要先识别一批人再回头批量点按钮
- 优先在当前推荐页完成成功确认，不要每打一人就默认跳聊天页确认
- 如果前几个候选人成功、后续连续失败，必须优先判断当日推荐牛人沟通权益是否耗尽
- 如果疑似权益耗尽，进入
paused_for_boss_contact_quota_exhausted，保留已筛选候选人，等待权益恢复或用户开通更多权益
2.1 默认不要把 Boss 浏览器控制下放给子代理
Boss 相关浏览器控制默认应由主执行流完成。
不要为了普通页面读取、进入后台、读取 JD、读取候选人列表、发送标准消息，而默认启动子代理接管浏览器。
只有在用户明确要求，或主执行流已经卡在非页面业务逻辑问题时，才允许考虑子代理。
3. 服务按入口执行
简历筛选：
站内沟通：
飞书约面：
阻断式前置条件
在介绍完三类服务之后，再告诉用户该服务对应的强制前置条件。
所有服务共用的强制前置条件：
- 由龙虾代为禁用或移除会抢占浏览器访问的 skill，包括但不限于
browser-use。 - 由龙虾代为安装
web-access。
- GitHub 链接：https://github.com/eze-is/web-access
- 先要求用户在真实 Chrome 或 Chromium 浏览器里打开并登录 BOSS 直聘招聘者页面。
- 把当前任务切换到
web-access。 - 验证
web-access已经接管当前 BOSS 任务。 - 确认当前 Chrome / Chromium 中确实存在已登录的 Boss tab。
此外，对于 boss-screening，还有一个额外阻断条件：
- 必须先确认每个 JD 的每日目标候选人数。
如果这些通用前置条件没有完成，禁止继续：
- 读取在线岗位
- 读取 JD
- 查看候选人
- 发站内消息
- 创建飞书日程
如果用户还没有先在 Chrome 中登录 Boss 招聘者页面，也禁止开始“接管浏览器”这一步。
如果 boss-screening 的每日目标人数未明确，也禁止开始筛选。
不要自行搜索 web-access 的安装来源。 默认由龙虾先尝试代为安装；只有代装失败、权限不足或环境阻塞时，才让用户手动安装，并直接提供上面的 GitHub 链接。
对于 browser-use 等浏览器 skill，也默认由龙虾先代为禁用或移除。 不要先反问用户“是否已经禁用”。 完成后直接向用户汇报“已禁用/已移除”，只有在代办失败时才再向用户说明阻塞原因。
服务专属前置条件必须按需引导，不要一次性全部抛给用户：
boss-screening：只需要通用前置条件boss-chat：需要通用前置条件，以及用户已明确批准哪些候选人进入沟通boss-scheduling：需要通用前置条件，以及用户已选择候选人进入约面；飞书 bot 的配置和授权只在第一次真实创建日程时再引导
不要跳过这些条件自行脑补默认答案。
policy 缺失时的默认处理
如果当前环境里缺少：
company-policy.yamlapproval-policy.yaml
不要直接反问用户“筛选标准是什么”。
正确顺序必须是：
- 先读取当前在线岗位和 JD
- 基于 JD 自动生成一版默认筛选标准
- 把这版默认标准当作初始 policy
- 只向用户确认或补问“哪些地方要覆盖默认标准”
默认标准的第一来源是 JD。 用户补充的是：
- 公司特有的人才观
- 硬性淘汰条件
- 审批边界
- 必须人工复核的情况
筛选服务的目标制规则
boss-screening 的核心不是“每小时扫一次”，而是：
- 每个 JD 每天要筛选出多少个符合要求的候选人
龙虾应当围绕这个目标去筛选全渠道候选人，包括：
- 主动聊天/主动投递中的未读候选人
- 推荐页面中的本轮未处理候选人
- 搜索结果中的本轮未处理候选人（若账号具备搜索权益）
首次进入 boss-screening 时，必须优先确认：
- 每个 JD 的每日目标候选人数
- 若用户有多个 JD，分别为每个 JD 设目标
如果用户没有给出目标人数，龙虾必须主动追问，而不是直接按固定时间节奏开始跑。
如果用户只给了时间节奏、没有给每日目标人数，仍然视为信息不完整，必须继续确认每日目标人数。
未读候选人优先原则
新一轮筛选默认主对象不是“当前可见候选人”，而是“当前仍未处理的未读候选人”。
默认应优先覆盖：
- 左侧列表中带未读气泡的候选人
- 本轮新进入聊天列表但尚未处理的候选人
- 本轮新出现回复的候选人
- 上一轮发现但未成功读到简历的候选人
默认不进入新一轮扫描范围：
- 已被 HR 人工读过并完成筛选的候选人
- 已被龙虾读过并完成筛选、且本轮没有新未读消息的候选人
只有在这些条件下才允许重扫旧候选人：
- 用户点名要求重新评估
- 候选人出现新的未读回复
- 上一轮状态是未完成或待补读
- 候选人状态发生明显变化
对于不同来源，判断依据也不同：
inbound_chat：以页面未读信号为主，任务记忆为辅recommended_feed：以任务记忆为主，页面信号为辅search_results：以任务记忆为主，页面信号为辅
对于 recommended_feed，还要额外注意：
- 如果推荐页上的候选人卡片已经稳定显示，就应直接读取当前 DOM
- 不要默认把推荐页误判为“页面还没加载完成”
- 不要默认等待很久、做截图快照分析、或先要求用户确认页面是否加载完成
- 推荐页的核心任务是“读取当前卡片 + 用本地记忆判断哪些本轮未处理”，不是反复做页面加载安全推断
执行窗口与汇报节奏
时间相关规则现在是辅助规则，不是主规则。
可配置项包括：
- 每天允许执行筛选的时间窗口
- 多久向用户汇报一次进度
- 是否只在工作日运行
如果用户没有指定这些辅助规则，可采用默认值：
- 周一到周五
- 本地时间
09:00-17:00 - 每
60分钟汇报一次
但无论是否采用默认时间规则，筛选服务都必须围绕“每日目标候选人数”推进。
进度汇报的固定要求
每次汇报至少要包含：
- 每个 JD 的每日目标人数
- 当前已筛出多少个符合要求的候选人
- 距离目标还差多少
- 本周期内新增或更新的候选人分类结果
- 每位候选人的分类原因
- 建议继续沟通的候选人
- 建议进入约面的候选人
- 需要用户确认的动作
- 本轮发现的未读候选人数
- 本轮已成功更新的未读候选人数
- 本轮仍未补齐的未读候选人数及原因
每次汇报都要分别向用户确认：
- 哪些候选人可以继续推进站内沟通，例如索要附件简历
- 哪些候选人可以进入约面路径
如果用户尚未确认推进动作，不要自行把候选人推进到 boss-chat 或 boss-scheduling。
飞书边界
飞书只允许走 bot 路径。
用户负责：
- 去飞书开放平台创建应用或 bot
- 获取
App ID和App Secret - 按提示去 bot 聊天里完成真正可用的日历授权
龙虾负责：
- 接收用户提供的
App ID/App Secret - 完成本地配置
- 调用 bot 创建日程
龙虾不得：
- 主动打开飞书开放平台网页
- 替用户点击开放平台后台
- 自由尝试 API、OAuth、网页版三套路径
第一次真的要创建飞书日程时，才去确认 bot 是否已配置、授权是否已完成。
失败处理
所有强约束动作失败后，都必须进入“可恢复暂停态”，而不是继续长时间试错。
暂停时必须告诉用户：
- 失败的是哪一步
- 已经按最小快路径尝试过
- 最可能原因
- 用户现在最小需要做什么
- 用户做完后如何恢复
不得把“继续试试看”当成默认策略。
阅读顺序
- 先读 browser-routing.md
- 再按当前服务读取：
- boss-screening-service.md - boss-chat-service.md - boss-scheduling-service.md
- 如需发 BOSS 站内消息，再读 boss-send-recipe.md
- 如需读取推荐页，再读 boss-recommend-read-recipe.md
- 如需发送首条打招呼，再读 boss-greet-recipe.md
- 其他补充文档：