最近，我和 AI 一起做了一个招聘助手。
起因很普通：公司有一个岗位要招人，招聘量不大，却总有些零碎事要处理。看看简历，回答工作地点，确认关键资质，再找个合适的时间继续聊。每件事都不大，凑在一起，还挺占心思。
尤其是你忙着别的事，或者已经下班的时候，求职者刚好发来一条消息。回吧，手头事情被打断；不回吧，又怕错过一个不错的人。
我想做的小帮手，就是在这些时候接一接球。最初只打算做个本地实验，后来一点点长出了后台、云端运行和主动沟通能力。回头看，最有意思的，恰恰是那些在实际使用中才冒出来的小问题。
先说这次开发是怎么组织的。我用的开发工具是 Codex——我授权它作为编程助手直接参与开发，版本号也由它和我一起定。我们约定了一套简单的规则：
- 大版本（A1、A2……）：一次重大功能变化。能力层面的跃迁——能记住事情、能上云端、能真实发送、能主动开口，每一步都值得单独记一笔。
- 小版本（A5.1、A5.2……）：大版本之内的中间优化。界面调整、细节修复，不改变核心阶段。
后面出现的 A1、A2、A5 都是这个意思，文章会按这个顺序讲。
还有一件绕不开的事要先交代：这家头部招聘平台没有提供公开 API。所以整个开发没法走“查文档、调接口”的正路，基本是复用了之前做简道云时沉淀下来的开发 skill——尤其是那套“CDP 抓包试报文”的方法——一步步把平台真实的请求报文、字段和返回结构试出来的。这个前提决定了后面很多开发的节奏：能做什么、不能做什么，很多结论不是查来的，是试出来的。
一、A1：先让它记住事情，别急着让它“聪明”
第一步不是写一段神奇提示词，而是让它在国内某头部招聘平台上，真的找到人、读到资料，并且记得住。
同一个人今天搜到、明天又搜到，不能算成两个候选人。一次搜索只返回十几个人，也得弄清下一批怎么获取。岗位描述更不能靠我的记忆临时口述，得从自己已发布的岗位里读取，保存原文和版本。
这些听起来不够炫，却是助手能不能靠得住的基础。否则，模型再会说话，也可能围着过时的岗位信息认真发挥。
做到 A1 时，它已经有了一个可以登录的后台：岗位、候选人、启停控制，以及用来试话术的小实验室。这里的 A1，是产品治理的第一条正式基线；此前的搜索实验也被归档进去，而不是把所有早期工作抹掉重来。
我还发现，招聘对话不能只追求“回答得很礼貌”。比如这个岗位有一个重要资质要求——建筑安全 B 证。求职者问有没有机会，助手如果只是连着说几句“感谢关注”，聊完双方也没多知道什么。
更有用的做法是先接住问题，再顺势问一句：您目前是否持有相关证书？而且要记住已经问过，别每一轮都重新问。
这一阶段解决的是：它知道我们在招什么，也能把找到的人和聊过的事记下来。
二、A2：把本地小实验，搬成不必守着电脑的云端助手
很快就遇到了一个现实问题：如果要让它在我不方便处理的时候帮忙，总不能要求我的电脑一直开着，浏览器一直摆在那里。
云端化，就是这件事从“我开着电脑玩一下”，走向“它可以独立执行”的转折。
这里没有重新造一套系统。服务器上已经有可用的浏览器和虚拟显示环境，先实测兼容，再建立招聘项目自己的运行目录、浏览器身份和登录状态。我在手机上扫码，登录的是云端那份浏览器，而不是把本机整套浏览器资料硬搬过去。
最早还专门做了一次浏览器和服务的进程重启验证：重启后，登录状态还能恢复，真实搜索也能继续。后来再由服务器的服务管理机制负责启动和异常恢复，让 SSH 窗口不再成为程序的“生命线”。
数据也跟着分工：本地实验留下的轻量数据库保留；正式后台复用服务器已有的数据库服务，使用独立数据库。既不浪费此前的验证成果，也不为一个招聘助手额外养一整套基础设施。
另一个巧思，来自以前做的日报、研报项目。那个项目已经探索过：Agent 负责生成，服务器负责接收结果、记录状态和实际执行。这个经验给了我一个很清楚的分工——模型负责理解和建议，程序负责决定能不能执行。
不过，经验能借，链路不能想当然地照搬。研报可以等，聊天不适合依赖一个需要人驻守、定时扫接口的云电脑任务。因此，对话改用直接调用的 DeepSeek API；豆包云电脑保留为按需信息处理方向，尚未接入招聘运行链路。这不是宣称两条模型链路都已经跑通。
到了 A2，模拟对话和真实会话都有了持久记录，云端开始只读采集，人工也能接管。它先在旁边看、记、生成内部草稿，暂时不把草稿当成已发送。
A2 值得升大版本，是因为它从一次性的实验，变成了能在服务器上持续运行、记住上下文的助手。
图 1：真实后台的运行控制与统计。详细记录已隐藏；图中状态仅代表截图时点。
三、A3 和 A4：会写一句话，还不等于应该发出这句话
从草稿到真实回复，距离比想象中大。
模型生成成功，不代表消息发出去了；按钮点过，也不代表对方收到了。如果网络慢了一下，程序没看见回执，就重新发一遍，候选人可能会收到两条一模一样的话。
A3 专门补上了这一环：先用指定的真实测试会话验证，把发送尝试和平台实际确认分别记录。只有在真实历史里确认了消息，才算回复成功；不知道是否发出，就停下来核实，不自作主张重发。人工在手机上接过话，系统也得识别到，别两个人同时抢着回答。
所以 A3 的大版本变化，不是“文案更像人了”，而是它第一次进入真实受控发送阶段，开始为发出去的话负责。
接着，A4 把问题往前挪了一步：在沟通之前，先核对岗位需要的事实。
后台可以用普通话写要求，让模型整理成规则，再由人工确认。它不是一台自动淘汰机：资料与要求存在明确差异，留给人工复核；资料没写清楚，可以先问一次。
开发中一个很大的转弯，就是放弃了“资料缺失就打低分”的冲动。
简历没写证书，不等于没有证书。好多候选人评分都是零，看上去像系统很严格，实际上可能只是它没有足够信息。把“未知”当成“不行”，既耽误招聘，也让助手变成制造人工待办的机器。
我们还读入了平台提供的办公区域、沟通时间等偏好资料。这里也有坑：中国不同城市可能有同名的区。如果只有一个区名，就不能因为岗位在某座城市，顺手认定候选人也偏好那里。模型做语义理解，还得结合行政区划依据；信息不够，就老老实实标记待核实，不编一个漂亮的通勤距离。
A4 值得升大版本，是因为业务顺序变了：先核对岗位事实，再决定怎么沟通，依据和人工复核也有了自己的记录。
图 2：先选需要监测的岗位，再查看岗位详情和维护要求。开关控制监测范围，不替代助手总启停。
四、A5：不光接住来信，也会挑合适的人、在合适的时候开口
如果只能被动等消息，这个小帮手还是少了一半作用。
A5 开始支持自动主动招呼：先看岗位相关条件，再参考工作经历、在职状态和办公区域偏好。已经有过沟通的人不重复打扰；资料不完整但相关经历明确的人，可以用中性的邀请先联系，再问关键资质。
话术不必花哨，大意就是：我们正在招聘这个职位，您是否有兴趣了解？它不能替招聘负责人承诺录用，更不能自动说出淘汰话术。
时机也很重要。候选人有沟通时间偏好，就与后台允许的时段一起判断；偏好缺失，再按人工设置安排。主动任务调整为每 30 分钟一轮，晚上 10 点到次日早上 7 点停止主动采集和打招呼，新来信回复则保留原有处理规则。
每日上限目前配置为 50 人，但“上限”不是每天必须完成的指标。平台剩余额度、实际可联系对象和沟通窗口都会限制执行，程序不会为了凑数乱发。
A5 升大版本，是因为它从收到消息后回应，扩展到了自主准备、排序和发起沟通。这多出来的一步，背后也多了额度记录、一次招呼去重和发送回执控制。
后续 A5.1 到 A5.5，则是把这一阶段磨顺：候选人列表前置、会话与待办分栏、设置休息时段，以及修复页面加载慢导致的误判。它们没有再次改变产品的核心阶段，因此继续保留 A5 大版本。
有一次，程序报“岗位界面不能唯一确认”，第一反应很容易是登录失效。实际检查发现，页面只是还没加载完：等待一秒多时什么也没有，几秒后就正常了。后来改成在有限时间内等待真实页面出现，并继续核对页面来源和内容。
这个教训很朴素：网页慢一点，不等于账号掉线；界面打开了，也不等于业务已经成功。
图 3：会话、自动队列和人工待办分开查看。公开截图隐藏了个人资料，未展示求职者消息正文。
五、最让我省心的，是它会报平安，也会说自己遇到了问题
云端运行之后，还有一个问题：我总不能隔一会儿就打开后台，看看它是不是还活着。
于是又复用了以前早报机器人的经验。服务器上已有钉钉工具和通知能力，招聘助手沿用这条链路，登录异常继续告警，每六小时再发一份运行简报：采集是否正常、最近任务怎么样、新增了多少候选人、确认发出了多少消息、还有多少事情待人工处理。
这次没有再搞一个依赖本机开着的通知程序，也没有为简报额外叠一套定时器，而是复用服务器原有的巡检节奏。一次异常不反复轰炸，历史异常也不能冒充眼下还在故障。
我很喜欢这个小设计。它让助手从一个“得靠我去检查的页面”，变成了一个会主动交代工作情况的小同事。
当然，目前还在真实运行中观察。早期指定测试会话已经验证过真实回复；自动主动沟通的首条实际回执和后续效果，仍要继续看，不能把“功能开启”写成“已经招到了合适的人”。招聘效果，更需要时间验证。
这几轮开发给我最大的感受，是 AI 应用的价值往往藏在细节里：记住问过什么，分清未知和不符合，不重复发消息，挑一个合适的时间开口，知道什么时候把事情留给人。
最初只是一个岗位、一堆零碎事。现在，它逐渐成了一个可以暂停、可以接管、会留下记录，也会汇报近况的招聘小帮手。
我想，这就是我希望 AI 帮我做的事：把重复的小事接过去，让人能把精力留给值得认真聊的那个人。