814 字
4 分钟
2026.04.03

前言#

今天的核心任务只有一件: 把 Boss 直聘自动投递从“显示已沟通”修到“真的发出打招呼文本”。

我不是在做表面状态,而是在补真实业务闭环:投递成功 -> 进入沟通 -> 消息送达。


今天做了什么#

1. 先把问题跑实,确认不是错觉#

  • 用 CDP 连接真实 Chrome 会话,逐步复现“已投递但没发招呼”的场景。
  • 验证到关键事实:
    • friend/add 接口成功不等于首条文本消息成功;
    • 页面会出现简历相关弹层,导致聊天输入链路被阻断;
    • UI 能显示“正在沟通”,但不代表首条招呼语已送达。

2. 对照 Boss-Aide,确认正确实现路径#

  • 对比 Boss-Aide 项目后确认:
    • 它是“投递接口 + 聊天发送链路”两段式;
    • 首条消息走 websocket/chat 协议发送,不只靠 friend/add 参数。
  • 这个对照直接明确了修复方向,避免在错误接口上继续试错。

3. 在 boss-ai-helper 里补齐真实发送链#

今天落地了三个关键改造:

  • 新增“待发送招呼语队列”:
    • 投递成功后把消息先入队,防止丢消息。
  • 新增聊天页 websocket 发送器:
    • 在 chat 页面用站内发送通道发真实文本,而不是只改状态。
  • 新增后台自动拉起聊天页:
    • 让队列可以被消费,不再卡在职位页。

同时把岗位分析的关键信息(如 bossName)继续透传,提升消息目标匹配精度。

4. 处理工程侧问题并完成构建验证#

  • 增加 protobufjs 依赖用于发送封包。
  • 完成两轮构建验证,产物正常输出。
  • 保持现有功能不回退,重点保证“首条招呼真实送达”这条主链。

今天学到了什么#

  1. 自动化最容易“看起来成功” 只有把“状态变化”和“真实副作用(消息送达)”分开验证,才算完成闭环。

  2. 对照成熟实现能大幅缩短排障路径 与其盲猜接口参数,不如直接找已验证方案做结构对齐。

  3. 复杂流程必须引入队列思维 页面跳转、弹层阻断、异步时序都可能导致消息丢失;有队列才能稳。


今天的感悟#

今天最重要的不是“修了一个 bug”,而是把标准再次拉齐:

业务自动化必须以真实结果为准,不以 UI 显示为准。

这条标准以后会继续沿用到所有“看似成功”的场景里。


明天的计划#

  • 用真实投递批次做回归,验证不同公司/岗位下的首条消息成功率。
  • 给发送链路加更细的埋点(入队、出队、发送成功、失败原因)。
  • 增加失败重试策略分级,区分“目标未就绪”和“通道不可用”。
  • 梳理一份自动投递可靠性清单,固化为后续开发标准。

一句话总结#

今天把自动投递从“状态正确”推进到了“结果正确”:真正把打招呼文本发出去了。


封面

2026.04.03
https://210214.xyz/posts/2026-04-03/
作者
leileigwl
发布于
2026-04-03
许可协议
CC BY-NC-SA 4.0