geekgeekrun/plan/current_status_2026_03_18.md

当前状况（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 与配置默认值调整到“开箱可用”