geekgeekrun/plan/recruiter_chat_page_hr_guide.md

招聘端（给 HR）沟通页使用说明（含 LLM Rubric 详细教程）

适用范围：只使用「招聘BOSS → 沟通」相关功能（以及它依赖的「职位配置」「配置大语言模型」「招聘端调试工具」）。

你只需要按本文档把三件事配置好：登录凭据、职位筛选规则、LLM 模型。然后在「沟通」页启动即可。

本软件会把所有配置保存到你电脑的 ~/.geekgeekrun/ 目录下（重装软件通常不影响配置）。

---

0. 你会用到的页面入口（左侧导航）

• 沟通：只配置“怎么跑”（处理多少未读、是否单轮、两轮间隔），并启动任务
• 职位配置：配置“筛什么人”（城市/学历/年限/薪资 + 简历全文关键词/正则/LLM Rubric）
• 配置大语言模型：配置 LLM 服务商（baseURL、API Key、模型、用途默认模型、测试连接）
• 编辑登录凭据：登录 BOSS 直聘（招聘者身份），保存 Cookie
• 招聘端调试工具：Rubric 生成/评估/测试专用（强烈建议你用它把 Rubric 调顺再去正式跑）

---

1) 第一次使用：先配置“登录凭据”

1.1 登录凭据是什么

软件需要你 BOSS 直聘招聘者身份的登录态（Cookie + localStorage）才能打开沟通页并读取职位列表。

会用到两份本地文件（一般不需要你手动打开它们）：

• ~/.geekgeekrun/storage/boss-cookies.json：招聘端 Cookie（最关键）
• ~/.geekgeekrun/storage/boss-local-storage.json：招聘端 localStorage

1.2 一键登录（推荐做法）

1. 打开：招聘BOSS → 编辑登录凭据
2. 确认提示里写的是「招聘者身份登录」（很重要）
3. 在弹出的“BOSS 登录助手”窗口里，点击 启动浏览器
4. 用你常用的方式登录（短信/二维码/微信小程序等）
5. 登录完成后等待 5–10 秒：Cookie 会自动出现在输入框
6. 点击右下角 确定 保存
7. 看到“Cookie 保存成功”的提示即可

1.3 常见问题

• 我登录了但 Cookie 没自动出现
  • 在登录助手窗口里按它的说明安装/打开 EditThisCookie 扩展，导出 Cookie 后粘贴到输入框保存
• 我确认登录了但运行时提示未登录/403/拒绝访问
  • 先重新走一遍“编辑登录凭据”
  • 确保账号确实是招聘者身份（能看到招聘端功能）

---

2) 配置 LLM Provider + Model（boss-llm.json）

只要你想用「LLM Rubric 筛选」或「自动生成 Rubric」，就必须配置这一步。

配置入口：招聘BOSS → 配置大语言模型
配置保存到：~/.geekgeekrun/config/boss-llm.json

2.1 你需要填什么

A. 服务商（Provider）

• API Base URL：常见例子
  • SiliconFlow：https://api.siliconflow.cn/v1
  • DeepSeek 官方：https://api.deepseek.com/v1
  • 阿里云百炼（兼容模式）：https://dashscope.aliyuncs.com/compatible-mode/v1
  • Ollama 本地：http://localhost:11434/v1
• API Key：服务商提供的 Key（通常以 sk- 开头）

B. 模型（Model）

每个模型一行（同一服务商下多个模型共享一个 API Key）：

• 启用开关：关闭后该模型不会被使用
• 模型别名（name）：给你自己看的名字，例如“DeepSeek-R1（简历筛选）”
• Model ID（model）：服务商要求的模型标识，例如 deepseek-reasoner、deepseek-chat 等
• 推理模型（可选）：如果你用的是推理模型（例如 R1/Qwen3 推理系列），可以勾选启用并设置预算（常用 2048 起）

C. 测试连接（非常重要）

每个模型旁边点 测试连接：

• 显示“连接成功”才算配置完成
• 如果失败：优先检查 Base URL 是否正确（很多服务商必须带 /v1）、API Key 是否正确、网络是否可达

2.2 “各用途默认模型”应该怎么选

页面下方的“各用途默认模型”，建议至少设置：

• 简历筛选：选择你用于 Rubric 评估的模型（最常用）
• 其他用途（招呼语生成、消息续写、默认）可以先不设置或按需选择

留空时：系统会“跟随第一个启用的模型”。为了可控，建议明确选一下“简历筛选”。

---

3) 职位配置（岗位设置）：筛选条件都在这里

配置入口：招聘BOSS → 职位配置
保存到：~/.geekgeekrun/config/boss-jobs-config.json

3.1 第一步：同步职位列表

进入「职位配置」页面后，先点顶部 同步职位列表。

• 如果提示 NEED_LOGIN：说明登录凭据不对或已过期，回到“编辑登录凭据”重新登录保存 Cookie

同步完成后会显示职位列表，点职位名展开配置。

3.2 你要理解的关键点

• “沟通”页不配置筛选规则
  沟通页只管“怎么跑”；筛选规则按职位配置来执行。
• 一职位一套筛选规则
  你可以给不同岗位设置不同城市/学历/薪资/简历筛选 Rubric。

---

4) “沟通”页：只配置运行策略，然后启动

入口：招聘BOSS → 沟通

这页会保存到 boss-recruiter.json 的 chatPage 配置，但你不需要关心文件。

4.1 每个字段含义与建议值

• 每次最多处理未读会话数

  • 含义：本轮最多处理多少条“未读对话”
  • 建议：先用 10～20 做小流量测试，稳定再加

• 单轮运行完成后停止（不再自动重启）

  • 含义：跑完这一轮就结束，不会过一会儿再跑
  • 建议：你手动跑的时候先勾上，便于观察效果

• 单轮结束后保持浏览器打开（需同时勾选「单轮运行完成后停止」）

  • 含义：本轮跑完不关浏览器，方便你检查页面；你手动把浏览器关掉后任务才算结束
  • 建议：排错时勾选

• 两轮之间的等待间隔（毫秒）

  • 含义：不勾选“单轮停止”时，每轮跑完等多久再跑下一轮
  • 默认：3000（3 秒）
  • 建议：一般保持默认；如果你想更稳、减少触发风控的概率，可以调大（例如 10000）

4.2 两个按钮怎么用

• 仅保存配置：只保存，不启动
• 保存配置，并开始处理沟通页！：保存 + 立刻启动任务

启动后如果要中止，在运行遮罩层里点 结束任务。

---

5) LLM Rubric（AI 简历筛选）详细教程

目标：把“复杂的 criteria”变成一套可重复、可验证、可迭代的配置。

你会做 4 件事：

1. 准备 JD（输入给 LLM）
2. 生成 Rubric（knockouts + dimensions）
3. 用真实简历文本测试 Rubric（通过/不通过是否符合预期）
4. 调整 Rubric 再测试，最后应用到职位配置

5.1 Rubric 的结构是什么（你需要看懂）

Rubric 是一个 JSON，对应三部分：

• knockouts：一票否决项（命中任意一条，直接淘汰）
• dimensions：评分维度列表（每个维度 1/3/5 分标准 + 权重 weight）
• passThreshold：通过分数线（0–100），例如 75 分以上通过

手动 Rubric JSON 的标准格式示例：

{
  "knockouts": [
    "必须统招本科及以上",
    "必须有 3 年以上前端经验"
  ],
  "dimensions": [
    {
      "name": "前端工程化与质量",
      "weight": 35,
      "criteria": {
        "1": "缺乏工程化经验：无构建/规范/CI/CD/测试实践描述",
        "3": "有基础工程化实践：使用过打包工具、Lint、简单 CI，但缺少质量指标或规模化经验",
        "5": "工程化成熟：能落地规范、CI/CD、监控与质量体系；有大型项目治理经验"
      }
    },
    {
      "name": "业务交付与协作",
      "weight": 65,
      "criteria": {
        "1": "主要做简单页面或边缘需求，缺少端到端交付与跨团队协作证据",
        "3": "能独立交付模块：有业务拆解、排期、联调与上线经验",
        "5": "能主导复杂交付：推动关键项目落地，跨团队协作强，能复盘与优化"
      }
    }
  ],
  "passThreshold": 75
}

提醒：weight 建议总和为 100（更直观）。维度分数是 1/3/5，系统会按权重换算成 0–100 总分。

5.2 JD 怎么给（写得好，Rubric 才会准）

5.2.1 最推荐的 JD 输入模板（直接粘贴给 LLM）

把你手里的 JD 改成“能评估”的结构，尽量包含：

• 岗位目标：这个岗位最核心的产出是什么（1–3 句话）
• 必须项（硬门槛）：学历/年限/城市/必须技能/必须行业等（这些应当转成 knockouts）
• 加分项（软偏好）：有更好，没有也能考虑（这些适合做 dimensions 或 3/5 分差异）
• 禁止项（明确不考虑）：例如“必须坐班/不接受远程/不接受频繁跳槽”等（也是 knockouts 候选）
• 评估方式倾向：你希望 LLM 重点看什么证据（项目、成果指标、技术栈、论文、专利、带队等）

示例（你可以复制改）：

岗位：前端工程师（ToB）

岗位目标：
1) 负责核心业务模块交付，提升交付质量与稳定性
2) 推进工程化建设（规范、CI、监控、性能优化）

必须项（硬门槛）：
- 本科及以上
- 3 年以上前端经验
- 熟悉 Vue 或 React 至少一种，并有线上项目经验

加分项（软偏好）：
- 有工程化/组件库/低代码平台经验
- 有性能优化、监控告警、可观测性经验
- 有带新人/小组协作经验

不考虑：
- 频繁跳槽（平均在职 < 10 个月）

评估重点：
- 项目经历是否体现端到端交付（需求拆解、联调、上线、复盘）
- 是否有工程化/质量体系的证据（规范、测试、CI/CD、监控）

5.2.2 常见写法错误（会让 Rubric 变得很玄学）

• 只有“岗位职责”没有“硬门槛/加分项/不考虑”
• 只写“熟悉/精通/良好沟通”这种形容词，没有“证据/行为/产出”
• 把“加分项”当“必须项”写死，导致 knockouts 太多、候选人几乎全被淘汰

5.3 如何生成 Rubric（两种方式）

你可以在两处生成 Rubric：

• 方式 A（推荐）：在「职位配置」页面里生成（生成后就属于该职位）
• 方式 B（更适合调试）：在「招聘端调试工具 → LLM 筛选」里生成（更适合反复试错）

5.3.1 在“职位配置”里生成（最常用）

1. 打开：职位配置 → 展开某个职位
2. 在“简历全文筛选”里勾选：大模型筛选（AI Rubric）
3. 在 Step 1 的 “岗位描述（JD）” 粘贴你的 JD
4. 点 自动生成评分标准
5. 生成后出现：
   • 一票否决项（knockouts）
   • 评分维度（dimensions）
   • 通过分数线（passThreshold）
6. 你可以直接微调（见 5.5），然后点该职位底部 保存。

如果提示“未检测到可用模型”：先去「配置大语言模型」添加并启用至少一个模型，并测试连接成功。

5.3.2 在“招聘端调试工具”里生成（强烈建议先用它把规则跑通）

1. 打开：招聘端调试工具 → Tab B：LLM 筛选
2. 在“区域 1：生成 Rubric”输入 JD
3. 点 生成 Rubric
4. 生成后你可以：
   • 复制 JSON
   • 用于评估（把 JSON 直接带到区域 3）
   • 应用到职位配置（选目标职位 → 一键写入职位配置）

5.4 Rubric 怎么测试（这是最关键的一步）

测试的目标是：让“通过/不通过”的结果符合你的直觉，并且“理由”能解释清楚。

推荐用：招聘端调试工具 → Tab B：LLM 筛选

5.4.1 准备一份真实简历文本（区域 2）

1. 在调试工具顶部点 启动浏览器
2. 浏览器打开到 BOSS 沟通页后，你在左侧会话列表手动点击一条会话（让右侧候选人信息显示出来）
3. 回到调试工具，点 📄 提取当前简历文本
4. 成功后会显示简历文本长度（多少字），并自动填到区域 3 的“简历文本”里

说明：它会自动打开“在线简历”，用 Canvas hook 把文字提取出来，所以能得到较完整的简历文本。

5.4.2 运行 Rubric 评估（区域 3）

区域 3 有两种 Rubric 来源：

• 从职位配置读取：适合验证“某个职位”现在的配置是否好用
• 手动填写 JSON：适合快速试错（比如刚生成的 Rubric）

操作流程（推荐手动 JSON）：

1. 在区域 1 生成 Rubric 后点 用于评估（会把 JSON 填入区域 3）
2. 确认区域 3 里“简历文本”有内容（来自区域 2，或你手动粘贴）
3. 点 🤖 运行 LLM 评估
4. 查看结果：
   • ✅/❌ 是否通过
   • 总分（如 78/100）
   • 各维度得分（1–5 分）
   • 原因（reason）

5.4.3 你应该怎么判断“Rubric 好不好”

用 3 个候选人做最小验证：

• 明显不合格：应当稳定不通过（最好被 knockouts 或低分维度卡住）
• 明显合格：应当稳定通过（总分高，关键维度 4–5 分）
• 边界候选人：通过与否取决于你希望的标准（用它来调 passThreshold/权重）

如果 3 个样本的结果都符合预期，再开始正式跑沟通页。

5.5 Rubric 怎么修改（让它更像“你的判断标准”）

你主要会改 4 类东西：

A. knockouts（硬门槛）

适合放“真的不能谈”的条件：

• 学历硬门槛（如必须本科）
• 年限硬门槛（如必须 3 年以上）
• 必须证书/必须行业/必须到岗方式等

不建议放：

• 软偏好（如“更偏好大厂”“最好做过组件库”）——放到维度更合理

B. dimensions 的 name（维度名称）

维度名称要“可评估”，不要写空话。好例子：

• “工程化与质量体系”
• “业务交付与跨团队协作”
• “算法建模与实验设计”

不好的例子：

• “综合匹配度”“整体优秀”“符合岗位需求”

C. criteria（1/3/5 分标准）

这是你觉得“复杂”的地方，但你只要记住一句话：

criteria 不是形容词，是证据。

写法建议：

• 1 分：缺少关键证据（没做过/没体现过/只有名词无案例）
• 3 分：有证据但不够强（参与过、做过模块、缺少规模/指标/主导）
• 5 分：证据很强（主导过、规模化、可量化成果、影响面大）

典型可用“证据关键词”：

• “主导/负责/推动/落地/设计”
• “从 0 到 1 / 从 1 到 N”
• “指标：耗时降低 X%、崩溃率降低 X、性能提升 X”
• “规模：DAU、QPS、组件数量、团队人数”

D. weight（权重）与 passThreshold（分数线）

建议调参顺序：

1. 先把维度写清楚（criteria 能拉开差异）
2. 再调权重：让你最关心的能力占更大比重
3. 最后调通过线：
   • 你觉得“通过的人太多” → 提高 passThreshold
   • 你觉得“好的人被误杀” → 降低 passThreshold 或放宽 knockouts

5.6 生成出来的 Rubric 不靠谱怎么办（最常见原因）

• 原因 1：JD 太泛
  • 解决：按 5.2 的模板补齐“必须项/加分项/不考虑/评估重点”
• 原因 2：knockouts 太多导致全淘汰
  • 解决：只保留真正的硬门槛；软偏好放维度
• 原因 3：criteria 写成“部分符合/完全符合”这种废话
  • 解决：改成“证据标准”（项目/指标/产出/职责范围）
• 原因 4：模型不稳定/经常超时
  • 解决：换一个更稳定的 provider/model；先用“测试连接”确认连通

---

6) 最推荐的落地流程（照着做就行）

1. 编辑登录凭据：确保招聘者身份 Cookie 保存成功
2. 配置大语言模型：至少 1 个可用模型，测试连接成功；用途默认模型设置“简历筛选”
3. 职位配置：
   • 同步职位列表
   • 给目标职位开启“LLM Rubric”
4. 招聘端调试工具：
   • 生成 Rubric → 提取 3 份真实简历文本 → 运行评估 → 调整 Rubric → 直到结果符合预期
   • 一键“应用到职位配置”
5. 沟通：
   • 设置每轮处理未读数（先 10）
   • 勾选“单轮运行完成后停止”先跑一轮观察
   • 点击“保存配置，并开始处理沟通页！”

---

7) 常见错误提示对照表

• 同步职位列表失败：NEED_LOGIN

  • 去“编辑登录凭据”重新登录保存 Cookie（招聘者身份）

• 运行沟通页后提示登录无效

  • Cookie 过期了，重新登录保存即可

• LLM 生成/评估失败：请检查 LLM 配置

  • 去“配置大语言模型”测试连接
  • 检查 baseURL 是否正确（尤其是否包含 /v1）
  • 检查该模型是否启用