该文章古法创作，未使用ai，有耐心看完的请三连！
本人从2022年开始因为一个私活开始研究boss直聘，一晃已经4年过去了，也经历boss网页端的几次升级(具体可以看我博客的其它几篇关于boss直聘的文章)，最早的前端代码可读性还是很强的，甚至于还有中文注释，随着前端框架的升级，现在的代码都是打包压缩后的chunk，甚至还用上wasm，现在又增加开发者工具检测，如果你用playwright之类的无头浏览器去访问，立刻就能被识别，一旦做登录操作，页面就会自动关闭。下面是我遇到一些问题和解决方案。
一、访问
要做自动化操作，无论用代码驱动还是agent驱动，都要一个浏览器，常规的无头浏览器直接放弃，可以使用patchwright或cloakbrowser这类包装过的浏览器，目前实测可以正常打开页面登录等操作。
二、代码注入
目前agent操作网页的插件也有不少，但是它的效率和稳定性还是不如硬编码，要实现高效稳定的操作，接口级别的拦截肯定是最佳方案，这时就需要注入代码，但是注入的代码里不要有console操作，否则也会被检测到。
三、消息
这几年唯一没怎么变的就是消息的结构和mqtt协议，protobuf的存放方式有过调整，但是还是能在代码里找到，这些通过代码注入的方式都能获得，这块代码是我4年以来唯一改动最小的，目前一直稳定运行，收发消息的效率和稳定性远超用ai做网页操作，而且不用烧token。
打招呼
这个功能在有了ai后，确实有了质的提升，以前只能固定几个招呼语，现在可以结合求职者简历针对每个职位自动生成合适的招呼语，相比固定的会更有吸引力。
复聊
没有ai前这块只能按规则关键字匹配去回复一些固定的内容或者交给人工处理，现在有了ai，接入一个轻量的定制agent，然后把交换联系电话微信/发简历都做成agent的工具，接入高德或百度的mcp后甚至当招聘者发送位置信息时，还能自动判断通勤是否方便，目前可以完全做到无人参与了，只需要等招聘方加微信或打电话了。此外开放了agent的提示词，这样求职者可以自己修改回复消息的逻辑。实测这块token的消耗，相比使用openclaw/workbuddy之类的agent要少很多很多。
四、职位列表
职位列表接口变化不大，但是仅限首次加载时能返回数据，如果再次单独调用职位列表接口就会拿不到数据，这时需要借助自动化操作去翻页，然后拦截响应数据。
ai筛选
使用ai对职位信息进行二次过滤，用过boss的都知道，有时列表里会夹杂一些不相关的职位，甚至是外省市的，这时使用ai根据自己喜好再做一个过滤，可以实现更精准的打招呼，毕竟现在一天只有120次机会。
五、职位详情
以前是有单独接口可以获取完整的某个职位信息，现在是服务端渲染了，所以只能解析网页，效率略差，有时职位描述中还会被混入特殊字符，这时也可以借助ai做个简单处理，也用不了多少token。
六、职位筛选
筛选条件在页面加载时都能获得，筛选时组合参数就能实现条件筛选，但是这里要注意的是，这个只对推荐时生效，当切换到某个求职意向后，查询参数就不走页面url了，只会影响接口。
七、简历
这块接口也是比较稳定的，现在有了ai，已经可实现针对每个职位定制一份简历然后再发送，投递的效率会高很多，但是ai优化简历这块烧了我不少token，因为普通的优化润色对于现在的招聘方ai简历筛选毫无意义，所以还需要在求职者许可的范围"适当夸大"，但是大模型受模型本身道德约束，会认为是在造假，所以有时会拒绝修改，有时仅仅是润色，生成的结果还是达不到求职者的要求，为此我做了两个agent，一个是简历修改专家，一个是简历审核专家，让他们互相对抗，烧了接近100元的token，算是得到一个相对满意的方案，用的模型是deepseek-v4.1-flash，性价比最佳，现在还在继续优化中。
结尾
以上介绍肯定算不上详细，一篇文章也很难完全说清楚，同时我也做了招聘端相关的产品，欢迎有兴趣的同行互相交流。