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依赖用于发送封包。 - 完成两轮构建验证,产物正常输出。
- 保持现有功能不回退,重点保证“首条招呼真实送达”这条主链。
今天学到了什么
-
自动化最容易“看起来成功” 只有把“状态变化”和“真实副作用(消息送达)”分开验证,才算完成闭环。
-
对照成熟实现能大幅缩短排障路径 与其盲猜接口参数,不如直接找已验证方案做结构对齐。
-
复杂流程必须引入队列思维 页面跳转、弹层阻断、异步时序都可能导致消息丢失;有队列才能稳。
今天的感悟
今天最重要的不是“修了一个 bug”,而是把标准再次拉齐:
业务自动化必须以真实结果为准,不以 UI 显示为准。
这条标准以后会继续沿用到所有“看似成功”的场景里。
明天的计划
- 用真实投递批次做回归,验证不同公司/岗位下的首条消息成功率。
- 给发送链路加更细的埋点(入队、出队、发送成功、失败原因)。
- 增加失败重试策略分级,区分“目标未就绪”和“通道不可用”。
- 梳理一份自动投递可靠性清单,固化为后续开发标准。
一句话总结
今天把自动投递从“状态正确”推进到了“结果正确”:真正把打招呼文本发出去了。
