boss-hiring-assistant

分类: 工具与效率 | 上传者: waltonwang-debug | 下载: 0 | 版本: v1.0（最新）
面向 BOSS 直聘招聘流程的中文 skill。默认先做简历筛选，也支持站内沟通和飞书约面。
更新日志: Source: GitHub https://github.com/waltonwang-debug/boss-hiring-assistant-skill
目录结构

当前层级: tree/main/
📁 agents/
- 📄 openai.yaml 1.7 KB
📁 assets/
- 📄 approval-policy.example.yaml 1.9 KB
- 📄 candidate-profile.example.json 764 B
- 📄 company-policy.example.yaml 1.1 KB
- 📄 default-message-templates.zh-CN.yaml 2.6 KB
- 📄 message-templates.example.yaml 417 B
📁 references/
- 📄 boss-chat-service.md 4.2 KB
- 📄 boss-scheduling-service.md 1.5 KB
- 📄 boss-screening-service.md 11.9 KB
- 📄 boss-send-recipe.md 8.3 KB
- 📄 boss-workflow.md 641 B
- 📄 browser-execution.md 387 B
- 📄 browser-routing.md 5.6 KB
- 📄 chat-templates.md 2.3 KB
- 📄 lobster-capabilities.md 541 B
- 📄 onboarding-flow.md 5.3 KB
- 📄 policy-schema.md 4.0 KB
- 📄 task-memory.md 2.9 KB
- 📄 trial-run.md 2.2 KB
📄 .gitignore 16 B
📄 LICENSE 1.0 KB
📄 README.md 5.6 KB
📄 SKILL.md 13.8 KB
SKILL.md

---
name: boss-hiring-assistant
description: 面向 BOSS 直聘招聘流程的中文 skill。默认先做简历筛选，也支持站内沟通和飞书约面。
---

# Boss Hiring Assistant

## 执行优先级

龙虾执行本 skill 时，必须按下面的优先级理解规则：

1. 阻断式前置条件
2. 浏览器路由硬规则
3. 当前服务文档
4. 发送 recipe
5. 其他补充文档

如果低优先级内容与高优先级内容冲突，一律以高优先级内容为准。

## 目标

这个 skill 只做三类服务，并且三类服务必须分开理解、分开执行：

1. `boss-screening`
只负责读取岗位、读取候选人、筛选、分类、汇报。
2. `boss-chat`
只负责 BOSS 站内沟通。
3. `boss-scheduling`
只负责候选人已确认时间后的飞书约面。

如果用户没有明确指定服务类型，默认先进入 `boss-screening`。
不要把三类服务混在同一轮里自由串行。

## 首次安装后的介绍

用户首次安装这个 skill 后，必须先用中文向用户做一个简短介绍，再进入任何具体执行。

介绍内容至少包含：

1. 这个 skill 分成三类独立服务：
   - `boss-screening`：简历筛选和周期汇报
   - `boss-chat`：BOSS 站内沟通
   - `boss-scheduling`：飞书 bot 约面
2. 推荐用户先从 `boss-screening` 开始
3. 后两类服务按需启动，不必首次安装时一起配置
4. 在任何浏览器接管开始前，必须先让用户在 Chrome 或 Chromium 浏览器里打开并登录 BOSS 直聘招聘者页面
5. `boss-screening` 可覆盖的候选人范围：
   - 主动进入聊天列表或主动投递中的未读候选人
   - BOSS 推荐页面里的本轮未处理候选人
   - 搜索页面里的本轮未处理候选人（当账号具备搜索权益时）
6. `boss-screening` 的核心规则是：按每个 JD 的每日目标候选人数来筛选，而不是机械按小时运行
7. 新一轮筛选默认只处理“未读/未处理候选人”，不重复重扫已经处理完成的旧候选人，除非满足重扫条件
8. 如果用户不指定每日目标人数，就先让用户为每个 JD 设定目标；时间窗口和汇报节奏只是辅助设置
6. 启动方式：
   - 用户说“先帮我做简历筛选”时进入 `boss-screening`
   - 用户说“帮我联系这些候选人”时进入 `boss-chat`
   - 用户说“帮我给这些候选人约面”时进入 `boss-scheduling`

如果用户没有明确选择，默认建议先从 `boss-screening` 开始。

在这一步没有完成前，不要：

- 直接进入 Boss 页面读取
- 直接开始筛选
- 直接开始发消息
- 直接开始飞书约面

## 顶层硬规则

### 1. 浏览器访问只允许走 web-access

BOSS 页面上的所有读取、点击、切换线程、打开详情、发送消息，都必须先遵守：

- [browser-routing.md](./references/browser-routing.md)

这是一条硬规则，不是建议。

对于 `web-access` 的 eval 能力，必须先做最小探针验证请求写法正确，再执行复杂逻辑。
不要在 eval 传参方式未确认时直接跑复杂脚本。

对于 Boss 聊天页中的在线简历读取，默认优先走“左侧点击候选人卡片 + 右侧简历面板提取”的路径，不要先假设会跳转到独立 URL。

在 Boss 任务中，默认只允许操作用户当前已经登录的 Boss tab。
不要为了进入招聘后台或职位管理而新建 tab、新建窗口或新建浏览器上下文。

如果当前已登录 tab 存在，就必须复用它的 `targetId` 和同一 `browserContextId`。
不要通过 `web-access /new` 直接新开 Boss 页面再尝试进入后台。

### 1.1 截图默认彻底禁止

在 BOSS 页面读取中，截图、OCR、图像理解默认彻底禁止。

如果 `web-access` 读取失败：

1. 允许在同一路径内最多再尝试 `2` 次
2. 如果仍失败，不允许自动切换到截图路径
3. 必须先向用户说明：
   - `web-access` 已尝试失败
   - 现在可以改走截图等异常方案
   - 这些方案可能增加 token 消耗，也可能提高 BOSS 风控或网页登录强退风险
   - 默认更建议继续坚持 `web-access`
4. 只有用户明确同意后，才允许临时启用截图等异常方案

### 2. BOSS 站内发消息必须走固定 recipe

只要进入 BOSS 站内消息发送，必须先读取并执行：

- [boss-send-recipe.md](./references/boss-send-recipe.md)

不要把该文档当参考说明。
不要再自行重新设计 DOM 路径、前端事件路径、子代理方案。

如果候选人线程都没有成功打开，就不得继续做输入框查找和发送动作。
但在暂停前，必须先把“自动打开候选人线程”的标准路径和有限备用路径走完。
不要一失败就要求用户代为点击候选人。

如果标准路径失败，下一步必须优先走低 token 的分层自动诊断，而不是直接进入长时间试错或大段脚本探索。

发送 Boss 站内消息时，必须做候选人身份校验，避免把给 A 的消息发给 B。

发送按钮点击路径也必须受控：

- 默认优先使用 `web-access clickAt`
- 其次才是底层 CDP 鼠标事件
- DOM `btn.click()` 只允许作为一次性兜底，不得作为默认主路径

特别是在批量打招呼时，不允许把 DOM click 当成标准实现。

对于“索要附件简历”类消息，发送后还必须继续跟进：

- 候选人是否已发送简历
- 是否出现“同意/接收”按钮
- 是否已点击完成接收

如果是批量打招呼或批量推进消息，还必须额外遵守：

- 小批量分轮发送
- 相邻发送之间加入短暂停顿
- 触发验证码、异常验证、登录态波动、页面异常跳转时立即停止整轮发送

### 2.1 默认不要把 Boss 浏览器控制下放给子代理

Boss 相关浏览器控制默认应由主执行流完成。

不要为了普通页面读取、进入后台、读取 JD、读取候选人列表、发送标准消息，而默认启动子代理接管浏览器。

只有在用户明确要求，或主执行流已经卡在非页面业务逻辑问题时，才允许考虑子代理。

### 3. 服务按入口执行

简历筛选：

- [boss-screening-service.md](./references/boss-screening-service.md)

站内沟通：

- [boss-chat-service.md](./references/boss-chat-service.md)

飞书约面：

- [boss-scheduling-service.md](./references/boss-scheduling-service.md)

## 阻断式前置条件

在介绍完三类服务之后，再告诉用户该服务对应的强制前置条件。

所有服务共用的强制前置条件：

1. 由龙虾代为禁用或移除会抢占浏览器访问的 skill，包括但不限于 `browser-use`。
2. 由龙虾代为安装 `web-access`。
   - GitHub 链接：`https://github.com/eze-is/web-access`
3. 先要求用户在真实 Chrome 或 Chromium 浏览器里打开并登录 BOSS 直聘招聘者页面。
4. 把当前任务切换到 `web-access`。
5. 验证 `web-access` 已经接管当前 BOSS 任务。
6. 确认当前 Chrome / Chromium 中确实存在已登录的 Boss tab。

此外，对于 `boss-screening`，还有一个额外阻断条件：

7. 必须先确认每个 JD 的每日目标候选人数。

如果这些通用前置条件没有完成，禁止继续：

- 读取在线岗位
- 读取 JD
- 查看候选人
- 发站内消息
- 创建飞书日程

如果用户还没有先在 Chrome 中登录 Boss 招聘者页面，也禁止开始“接管浏览器”这一步。

如果 `boss-screening` 的每日目标人数未明确，也禁止开始筛选。

不要自行搜索 `web-access` 的安装来源。
默认由龙虾先尝试代为安装；只有代装失败、权限不足或环境阻塞时，才让用户手动安装，并直接提供上面的 GitHub 链接。

对于 `browser-use` 等浏览器 skill，也默认由龙虾先代为禁用或移除。
不要先反问用户“是否已经禁用”。
完成后直接向用户汇报“已禁用/已移除”，只有在代办失败时才再向用户说明阻塞原因。

服务专属前置条件必须按需引导，不要一次性全部抛给用户：

- `boss-screening`：只需要通用前置条件
- `boss-chat`：需要通用前置条件，以及用户已明确批准哪些候选人进入沟通
- `boss-scheduling`：需要通用前置条件，以及用户已选择候选人进入约面；飞书 bot 的配置和授权只在第一次真实创建日程时再引导

不要跳过这些条件自行脑补默认答案。

## policy 缺失时的默认处理

如果当前环境里缺少：

- `company-policy.yaml`
- `approval-policy.yaml`

不要直接反问用户“筛选标准是什么”。

正确顺序必须是：

1. 先读取当前在线岗位和 JD
2. 基于 JD 自动生成一版默认筛选标准
3. 把这版默认标准当作初始 policy
4. 只向用户确认或补问“哪些地方要覆盖默认标准”

默认标准的第一来源是 JD。
用户补充的是：

- 公司特有的人才观
- 硬性淘汰条件
- 审批边界
- 必须人工复核的情况

## 筛选服务的目标制规则

`boss-screening` 的核心不是“每小时扫一次”，而是：

- 每个 JD 每天要筛选出多少个符合要求的候选人

龙虾应当围绕这个目标去筛选全渠道候选人，包括：

- 主动聊天/主动投递中的未读候选人
- 推荐页面中的本轮未处理候选人
- 搜索结果中的本轮未处理候选人（若账号具备搜索权益）

首次进入 `boss-screening` 时，必须优先确认：

1. 每个 JD 的每日目标候选人数
2. 若用户有多个 JD，分别为每个 JD 设目标

如果用户没有给出目标人数，龙虾必须主动追问，而不是直接按固定时间节奏开始跑。

如果用户只给了时间节奏、没有给每日目标人数，仍然视为信息不完整，必须继续确认每日目标人数。

## 未读候选人优先原则

新一轮筛选默认主对象不是“当前可见候选人”，而是“当前仍未处理的未读候选人”。

默认应优先覆盖：

- 左侧列表中带未读气泡的候选人
- 本轮新进入聊天列表但尚未处理的候选人
- 本轮新出现回复的候选人
- 上一轮发现但未成功读到简历的候选人

默认不进入新一轮扫描范围：

- 已被 HR 人工读过并完成筛选的候选人
- 已被龙虾读过并完成筛选、且本轮没有新未读消息的候选人

只有在这些条件下才允许重扫旧候选人：

- 用户点名要求重新评估
- 候选人出现新的未读回复
- 上一轮状态是未完成或待补读
- 候选人状态发生明显变化

对于不同来源，判断依据也不同：

- `inbound_chat`：以页面未读信号为主，任务记忆为辅
- `recommended_feed`：以任务记忆为主，页面信号为辅
- `search_results`：以任务记忆为主，页面信号为辅

对于 `recommended_feed`，还要额外注意：

- 如果推荐页上的候选人卡片已经稳定显示，就应直接读取当前 DOM
- 不要默认把推荐页误判为“页面还没加载完成”
- 不要默认等待很久、做截图快照分析、或先要求用户确认页面是否加载完成
- 推荐页的核心任务是“读取当前卡片 + 用本地记忆判断哪些本轮未处理”，不是反复做页面加载安全推断

## 执行窗口与汇报节奏

时间相关规则现在是辅助规则，不是主规则。

可配置项包括：

- 每天允许执行筛选的时间窗口
- 多久向用户汇报一次进度
- 是否只在工作日运行

如果用户没有指定这些辅助规则，可采用默认值：

- 周一到周五
- 本地时间 `09:00-17:00`
- 每 `60` 分钟汇报一次

但无论是否采用默认时间规则，筛选服务都必须围绕“每日目标候选人数”推进。

## 进度汇报的固定要求

每次汇报至少要包含：

1. 每个 JD 的每日目标人数
2. 当前已筛出多少个符合要求的候选人
3. 距离目标还差多少
4. 本周期内新增或更新的候选人分类结果
5. 每位候选人的分类原因
6. 建议继续沟通的候选人
7. 建议进入约面的候选人
8. 需要用户确认的动作
9. 本轮发现的未读候选人数
10. 本轮已成功更新的未读候选人数
11. 本轮仍未补齐的未读候选人数及原因

每次汇报都要分别向用户确认：

- 哪些候选人可以继续推进站内沟通，例如索要附件简历
- 哪些候选人可以进入约面路径

如果用户尚未确认推进动作，不要自行把候选人推进到 `boss-chat` 或 `boss-scheduling`。

## 飞书边界

飞书只允许走 bot 路径。

用户负责：

- 去飞书开放平台创建应用或 bot
- 获取 `App ID` 和 `App Secret`
- 按提示去 bot 聊天里完成真正可用的日历授权

龙虾负责：

- 接收用户提供的 `App ID` / `App Secret`
- 完成本地配置
- 调用 bot 创建日程

龙虾不得：

- 主动打开飞书开放平台网页
- 替用户点击开放平台后台
- 自由尝试 API、OAuth、网页版三套路径

第一次真的要创建飞书日程时，才去确认 bot 是否已配置、授权是否已完成。

## 失败处理

所有强约束动作失败后，都必须进入“可恢复暂停态”，而不是继续长时间试错。

暂停时必须告诉用户：

1. 失败的是哪一步
2. 已经按最小快路径尝试过
3. 最可能原因
4. 用户现在最小需要做什么
5. 用户做完后如何恢复

不得把“继续试试看”当成默认策略。

## 阅读顺序

1. 先读 [browser-routing.md](./references/browser-routing.md)
2. 再按当前服务读取：
   - [boss-screening-service.md](./references/boss-screening-service.md)
   - [boss-chat-service.md](./references/boss-chat-service.md)
   - [boss-scheduling-service.md](./references/boss-scheduling-service.md)
3. 如需发 BOSS 站内消息，再读 [boss-send-recipe.md](./references/boss-send-recipe.md)
4. 其他补充文档：
   - [policy-schema.md](./references/policy-schema.md)
   - [task-memory.md](./references/task-memory.md)
   - [trial-run.md](./references/trial-run.md)
登录后下载/点赞/收藏 ❤ 5 | ★ 0
boss-hiring-assistant

目录结构

SKILL.md

举报内容

提示
