recruiter: enhance chat page processing, boss browse flow, and UI improvements

- Improve chat-page-processor with better candidate handling and filtering - Update chat-page-resume extraction logic - Add new constants to constant.mjs - Enhance boss auto browse main flow with verification detection and multi-job sequence support - Expand boss chat page main flow with HR guide features - Update BossAutoSequence and BossChatPage Vue components - Add plan docs: current_status and recruiter_chat_page_hr_guide Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-09-06 16:07:17 +08:00 · 2026-03-20 19:07:59 +08:00
parent 95c1e54c66
commit 3fb7089c9e
10 changed files with 1454 additions and 546 deletions
@@ -0,0 +1,101 @@
+# 当前状况（2026-03-18）
+
+本文档用于记录 **招聘端（BOSS）当前已实现能力、已知问题、以及下一步修复/测试计划**，方便在打包测试前统一对齐。
+
+> 结论先行：**沟通页流程总体正常**；主要欠账在「推荐牛人」的状态判定与流程闭环（已读/已打招呼/已处理/去重不够精确），以及 Webhook 功能尚未做端到端验证与“功能安排”完善。
+
+---
+
+## 1. 已实现（可用能力）
+
+### 1.1 Worker / UI 入口
+
+- **BossAutoBrowseAndChat / BossAutoSequence**：推荐牛人 + 沟通页串联（复用同一 browser）
+- **BossRecommend / BossChatPage**：两段可分别单独跑（用于调试）
+- **WebhookIntegration**：Webhook 配置页（启用、URL、Headers、Payload options、测试发送/手动触发）
+
+### 1.2 数据持久化（SQLite）
+
+- `CandidateInfo`：候选人基础信息（用于去重与状态追踪的基础）
+- `CandidateContactLog`：联系记录（用于判断“是否已联系/已处理”的依据）
+- 迁移：`AddCandidateTables`
+
+### 1.3 自动化核心（boss-auto-browse-and-chat）
+
+- **推荐牛人页**：解析候选人列表、筛选、点击打招呼、处理弹窗、主循环翻页/滚动加载
+- **沟通页**：解析会话列表（unread 优先）、打开在线简历（Canvas hook）、可请求附件简历/下载 PDF（按配置）
+- **反爬/拟人**：ghost-cursor 人类轨迹、随机 delay、stealth/laodeng 等插件栈
+
+---
+
+## 2. 已知问题（需要修复/补齐）
+
+### 2.1 推荐牛人：状态判定不够精确（优先级最高）
+
+你提到的核心痛点是 **“哪些已读、哪些已打招呼、哪些已经处理过”** 没有被准确识别和闭环，导致：
+
+- **重复处理**：同一候选人被多次进入流程（浪费配额/触发风控风险）
+- **漏处理**：本应处理的候选人因为状态误判被跳过
+- **UI 展示与实际行为不一致**：页面上看似“已读/已沟通”，但本地状态未落库或落库不一致
+
+#### 需要补齐的“状态模型”（建议落库维度）
+
+- **viewed（已读/已查看详情）**：是否点击过候选人卡片进入详情弹窗
+- **greeted（已打招呼）**：是否成功触发并完成“打招呼”链路（含弹窗确认）
+- **processed（已处理）**：本轮流程是否已经对该候选人做完“筛选 →（可选）打招呼/不感兴趣 → 记录”闭环
+- **skippedReason（跳过原因）**：如重复推荐/命中屏蔽名/学历不符/工作年限不符/薪资不符/技能不符/日限已满等
+
+> 备注：上述状态不一定都需要新表字段；也可以通过 `CandidateContactLog` 的 action/type + timestamp 来推断。但目前推断链路不够稳，建议明确化并保证写入时机一致。
+
+#### 可能的根因方向（便于定位修复点）
+
+- **DOM 层状态标识不稳定**：推荐列表/卡片上的“已读/已沟通/已打招呼”可能是 class/图标变化，当前解析没有覆盖或覆盖不全
+- **打招呼成功条件定义不一致**：点击按钮 ≠ 实际送达；需要用弹窗、toast、按钮状态变化、或网络请求成功作为确认信号
+- **去重 key 不统一**：`geekId` / `encryptGeekId` / DOM data 属性在不同阶段使用不一致，导致写库与判断对不上
+- **写库时机缺口**：只在某些节点写 `CandidateInfo/ContactLog`，导致“已读但未落库/已打招呼但未落库”的灰状态
+
+### 2.2 Webhook：尚未端到端测试 + 功能安排不完善
+
+当前实现已经包含配置、mock 测试与触发入口，但缺少：
+
+- **真实 run 的联动验证**：推荐/沟通真实跑一轮后，是否能正确汇总候选人数据并发送
+- **错误与重试体验**：网络失败/4xx/5xx 时的日志、重试、以及失败队列（若开启）是否可用
+- **payload 与下游契合**：JSON / multipart 两种模式的边界，以及简历字段（path/base64）在不同配置下是否符合预期
+- **“功能安排”**：比如 realtime/batch 两种 sendMode 与 UI/日志/存储的配套是否完善、默认值是否合理
+
+### 2.3 沟通页：目前认为正常（仅保留回归点）
+
+你反馈沟通页正常，这里只建议在打包测试时做最小回归：
+
+- unread 会话能按预期被识别与逐条处理
+- 在线简历 Canvas 提取正常
+- 附件简历下载/跳过下载配置（`skipDownload`）行为符合预期
+
+---
+
+## 3. 打包前的测试计划（本次目标）
+
+### 3.1 推荐牛人（重点验证）
+
+- **状态一致性**：同一候选人连续运行两次，不应重复“已打招呼”的人
+- **去重有效**：刷新/翻页/滚动加载后，已处理候选人不会再次进入队列
+- **打招呼确认**：出现弹窗/按钮变灰/提示信息时均能稳定判定成功或失败，并落库
+
+### 3.2 Webhook（最小可行验证）
+
+- 在本地起一个临时接收端（或用现成 request bin）接收 webhook
+- 用 UI 的 **保存并测试发送** 验证接口可达
+- 真实跑一轮推荐/沟通后，验证自动触发 payload（batch 模式）确实发送且内容合理
+
+### 3.3 沟通页（回归）
+
+- 选 3-5 个 unread 会话跑一轮，确认不崩、不重复、能落库
+
+---
+
+## 4. 下一步修复建议（按优先级）
+
+1. **先把推荐牛人的“状态模型”落地**：明确 viewed/greeted/processed/skippedReason 的来源与写入点
+2. **统一去重 key**：全链路统一使用同一种 `geekId`（或明确映射），避免 DB 与 DOM key 不一致
+3. **把 Webhook 做一次真实跑通**：补齐失败重试/日志，并把 payload 与配置默认值调整到“开箱可用”
+
@@ -0,0 +1,423 @@
+# 招聘端（给 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 的标准格式示例：
+
+```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 重点看什么证据（项目、成果指标、技术栈、论文、专利、带队等）
+
+示例（你可以复制改）：
+
+```text
+岗位：前端工程师（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`）
+  - 检查该模型是否启用
+