geekgeekrun/plan/STATUS_2026-03-18.md

2026-03-18 阶段性现状（Recruiter / 招聘端）

目标：先阶段性提交到 GitHub，并打包一版用于自测与联调。

1. 当前可用功能（已跑通）

1.1 沟通页（Chat Page）

• 流程状态：整体可用（你反馈“沟通部分是正常的”）。
• 核心能力：
  • 读取会话列表，按未读/条件筛选并逐个处理
  • 在线简历（Canvas/WASM）提取文本
  • 附件简历下载 PDF（或按配置跳过下载仅索取）
  • 关键词/LLM 两种筛选模式（由配置决定）
  • SQLite 持久化：候选人信息 + 联系日志

2. 已实现但需要修复/补齐的点（高优）

2.1 推荐牛人（Recommend Page）状态判断不精确

当前问题集中在“已读 / 已打招呼 / 已处理”的精确判定与去重策略上，导致：

• 重复扫描：列表滚动/刷新后同一候选人可能再次进入候选集合
• 误判：UI 上看起来“已读/已沟通”的项，程序未必能稳定识别并跳过
• 流程不闭环：未通过筛选的候选人虽可点“不感兴趣”移除，但与“已处理”的统一标准需要收敛

建议修复方向（后续实现）：

• 以 encryptGeekId 做强去重：以 DB 的 CandidateInfo + CandidateContactLog 为准，而不是仅依赖 DOM class
• 明确三类状态并落库：
  • viewed（已查看过该卡片/详情）
  • greeted/contacted（已发起打招呼/已在沟通列表出现）
  • processed（本轮已筛选/已触发过动作：打招呼/不感兴趣/跳过原因）
• 推荐页“已读”判断统一：将 DOM class（如 has-viewed）作为辅助信号，最终以 DB 的处理记录兜底

2.1.1 状态定义（建议统一口径）

为避免 UI 信号不稳定导致误判，建议在推荐页/沟通页统一以下状态口径（按强度从弱到强）：

• seen（看过卡片）：本轮在推荐列表中“见过”该候选人（只要 parse 到就算）
• viewed（点开详情）：本轮实际点击过卡片，弹出简历详情 dialog
• greeted（已打招呼动作发起）：本轮点击过 btn-greet（无论是否出现“知道了”提示）
• contacted（沟通关系建立）：候选人出现在沟通列表 / 能打开对话（强信号，跨轮有效）
• processed（本轮已处理闭环）：本轮对该候选人做过“打招呼 / 不感兴趣 / 明确跳过原因”中的任一动作

其中：

• 跨轮去重：以 contacted + greeted（落库）作为主去重条件
• 本轮去重：以 seen/processed（内存 Set + 可选落库）作为本轮兜底，防止滚动加载重复出现

2.1.2 判定信号（优先级建议）

• 强信号（优先）：
  • DB：CandidateContactLog（已发起打招呼/已建立联系/已处理原因）
  • 沟通页：会话列表里能定位到该 geekId（若能取到）/ 或者能够打开会话窗口
• 弱信号（仅辅助）：
  • 推荐列表 DOM class（如 has-viewed/已沟通样式）
  • 按钮文案变化（“继续沟通/已打招呼”等）与 tooltip

原则：弱信号只能用来“提前跳过”提升效率，不能作为“唯一依据”防止重复打招呼。

2.1.3 需要补齐的落库字段/记录（文档层面建议）

当前已引入 CandidateInfo / CandidateContactLog 两张表。为了让“推荐页状态闭环”更稳，建议后续补齐：

• CandidateInfo（建议）：
  • encryptGeekId / geekId（至少一个可稳定取到的唯一标识）
  • lastSeenAt / lastViewedAt（可选）
• CandidateContactLog（建议）：
  • action: greet | not_interested | skip | contacted
  • reason: 不感兴趣原因 / skip 原因（如 “重复推荐”“已联系”“日限已达”）
  • runId: 本轮 run 标识（用于 webhook/batch 汇总）

2.1.4 验收标准（修复完成的判定）

• 不重复打招呼：同一 encryptGeekId 在跨轮运行中不会重复点击 greet（除非用户手动清库）
• 状态可追溯：任意一个被跳过/打招呼/不感兴趣的候选人，都能在 DB 中找到对应记录与原因
• 滚动加载不抖动：列表滚动/翻页后重复出现的 card 不会触发重复处理

2.2 Webhook：功能已接入但未完整测试 & 功能安排待完善

• 现状：
  • UI 有 Webhook 配置页（保存 / 测试发送 / 手动触发）
  • 主进程已提供 IPC：fetch/save/test/trigger
  • 顺序执行 worker 在轮次结束具备触发点（按设计收集本轮候选人后发送）
• 未完成/风险点：
  • 真实环境联调未验证：接口返回码、鉴权、网络失败重试、multipart/JSON 兼容
  • 触发策略待定：batch / realtime 的行为与页面提示需要一致
  • 数据来源一致性：候选人数据字段（简历路径/base64、LLM 结论、筛选理由）在不同路径（推荐页/沟通页）是否都能填充需要校验

最小测试清单（打包后自测）：

• 配置保存/读取：重启后配置仍存在
• 测试发送（Mock）：test-webhook 成功返回并展示响应体
• 手动触发（Mock + 真实数据）：当 DB 有数据时能构建 payload；无数据时回退 Mock
• 失败重试：断网/返回 500 时日志与 UI 提示符合预期

3. 本次阶段性提交包含内容（范围说明）

• 新增 recruiter 自动化核心：packages/boss-auto-browse-and-chat
• 新增 recruiter headless 入口：packages/run-core-of-boss-auto-browse
• SQLite plugin 扩展：新增 CandidateInfo / CandidateContactLog 表与 handler
• UI 扩展：
  • 招聘端身份入口、路由与页面（推荐/沟通/顺序/调试/Webhook/LLM 配置）
  • RunningOverlay 招聘端进度展示（推荐页/沟通页进度 + worker 日志）
  • 招聘端日志面板（主界面右侧可拖拽）
• Windows 控制台中文编码修复：main 进程日志文件统一 utf8

4. 近期修复优先级（建议）

1. 推荐页状态判定/去重落库（避免重复打招呼/重复处理）
2. Webhook 真实联调 + 文档对齐（完成闭环，尤其 payload 字段与失败策略）
3. 推荐页与沟通页的“已处理”统一协议（本轮处理、跨轮去重、UI 展示）

5. 打包自测建议（本次提交后）

• 推荐牛人：
  • 连续运行 2 次，确认不会对同一候选人重复触发 greet
  • 触发一次“不感兴趣”，确认该候选人从列表消失且 DB 有记录
• 沟通页：
  • 未读会话筛选与处理数量上限生效
  • 在线简历/附件简历两种路径至少各跑通 1 次
• Webhook：
  • 用可控的 echo server（如本地/测试环境）跑通 test 与手动触发
  • 断网/返回 500 时，重试次数与 UI 提示符合预期（至少能看到失败原因）