我用灵犀把"每天的重复机械工作"做成了一款简单易用的事业单位招聘公告采集器

一、背景：一位招聘公众号编辑的日常

本人负责运营多个招聘信息类公众号，每天的工作是：

1. 到深圳及各城市政府官网、人社局网站上找最新招聘/招考公告；

2. 把公告正文复制出来，整理成公众号文案；

3. 用微羽助手排版，定时群发给求职者。

听起来不难，但每天重复下来痛点很明显：

• 官网又多又乱：市、区两级几十个部门网站，页面结构各不相同，每天需要打开各个网站，查找是否有最新的招聘，一套流程下来，也要花不少时间；

• 复制粘贴全是体力活：找到最新的招聘公告，正文里混着导航栏、版权信息、"分享到"、页脚链接，每篇都要手动清理；

• 格式不统一：附件、报名方式、截止日期东一块西一块，排版全靠手工。

一篇公告从查找到发布，顺利也要十几分钟，遇到结构奇怪的网站半小时都下不来。我想：这件事为什么不能自动化？

二、初衷：让"找公告→成文案"变成一键生成

我的目标很明确：输入一个政府官网地址，软件自动找公告、筛招聘、提正文、清垃圾、排好版，最后连数据一起存进金山多维表。

我给这个流程定了三条铁律（也是后面所有开发的准则）：

• 列表页只扫第 1 页，标题 + 日期预筛选，通过筛选才打开详情页（省时间也少打扰对方网站）；

• 标题含"招聘/招考/招录/聘用/编外"才收，"面试/笔试/公示/成绩"等一律跳过；

• 清洗后的正文直接生成排版 HTML，同步写入多维表存档。

三、开发过程：三步走

第 1 步：定时任务 + 采集技能（灵犀原生形态）

最开始我直接用灵犀的定时任务：每天早上自动跑一次"采集深圳招聘公告"，生成排版好的 HTML 文件。这一步让我快速验证了整条链路可行，也沉淀出第一套采集规则和 HTML 排版规范。

第 2 步：从"脚本"到"软件"

但定时任务只能在我的灵犀环境里跑，同事用不了。于是我让它把能力"落地"成软件：

• 用 Flask 做本地 Web 应用（不用纯 HTML 是因为浏览器 JS 跨域抓政府网站会被 CORS 硬限制）；

• 用 PyInstaller 打成 exe，双击即用，不依赖 Python 环境；

• 多维表写入走 api.wps.cn 标准 HTTPS API，用户只需要粘贴一次 wps_sid；

• 遇到 JS 渲染的反爬页面，就起一个独立的浏览器子进程兜底。

第 3 步：从"深圳"到"全国"，两个软件合成一个

深圳跑顺之后，我把模式复制到广州、佛山、北京、上海、成都、重庆、武汉、惠州……最终覆盖 22 个城市、700+ 个采集源，数据统一写入多维表"全国汇总"。

最近又把"事业单位招聘文案生成器"和"全国招聘采集器"合并成一个软件：平时一键采集，临时看到一条公告也能直接贴网址采集生成，还加了效果预览、带样式一键复制、一键把新网站加入采集源三个按钮。

全国招聘采集器合并版界面

四、踩过的坑（这部分最想分享给大家）

做了 36 个版本（v3.1x → v3.36），每一版背后都是一次真实的翻车：

1. 政府网站集体"搬家"

深圳、广州、佛山、惠州的政府部门域名先后批量迁移，几十个源一夜之间 DNS 全部失效。我总结出"DNS 诊断法"：批量失败先查 DNS，再建新旧域名映射表，比逐个猜快得多。

2. 反爬：无头浏览器直接被识破

有的网站（瑞数防护）用 requests 返回 412，用无头浏览器返回空白页。最终方案是有头浏览器 + 2 秒等待，一次通过。教训：防护检测的不只是"是不是机器人"，还有"像不像人"。

3. 浏览器和多线程的兼容性

Playwright 的 sync API 基于线程绑定，在 Flask 线程池里怎么加锁都报错。最后改成独立子进程跑浏览器，每次隔离，彻底根治。

4. 一个词毁掉半篇文章（印象最深的一个 bug）

某篇公告只采集到一半。排查了很久才发现：正文里有一句"能进行无障碍跨文化沟通"，而我的清洗规则里恰好有个过滤词"无障碍"（本意是过滤页脚的"无障碍浏览"链接）。规则一旦命中，后面的正文全部被当成页脚丢掉。修复思路：裸词换成精确短语，并且宁可漏过滤，不可误伤正文。

5. 看不见的"旧实例"

最玄学的一次：明明修好了，用户实测还是老问题。最后发现端口上同时挂着三个软件实例——两个旧版、一个新版，请求全被先启动的旧版接走了。教训：改完代码必须先查端口占用的进程路径，再谈验证。

6. 一个空格都不能信

正文容器的闭合标签定位、HTML 实体（“ 之类）、.wps 扩展名、日期后的附件归属……每一个细节都能翻车。所以后来我给每次修复都加了"打包后解包验证"的固定动作。

灵犀在开发过程的部分回答

五、与金山多维表结合：不只是存数据

多维表在这个项目里扮演了四个角色：

• 数据库：22 城公告统一写入"全国汇总"，按城市/日期筛选；

• 共享采集源库：700+ 采集源存在表里，同事启停源、加源，所有人实时同步，不用重新发软件；

• 排重引擎：一个 COUNTIFS 公式按标题排重，跨城市重复公告直接标记；

• 同事的取数入口：每条记录带"复制 HTML"按钮，同事不采集也能直接复制排版代码发公众号。

对应多维表中的采集记录

对应多维表中的采集源

六、投入产出：这笔账值不值

值不值？我每天省下的采集 + 清理 + 排版时间以小时计，同事直接复用软件和多维表，公众号的更新速度和准确率都上了一个台阶。最关键的是：整个过程我没有写过一行"传统意义上的开发"——我负责说清楚要什么、验收结果，代码全部由灵犀完成。遇到使用问题，直接截图画红框告诉灵犀需要如何优化。

七、给想做同类事情的朋友三条建议

1. 先把流程跑通，再考虑做成软件。 我先用定时任务验证了采集规则，才决定打包成 exe——顺序反了会浪费很多精力。

2. 给每个 bug 留一条"踩坑记录"。 我维护了一份经验清单（域名迁移映射表、反爬对策、验证清单），后面 20 个城市的扩展几乎是照着清单抄作业。

3. 凡是交付，必验证。 打包完要解包检查、启动后要实测接口、修完 bug 要回归旧场景。AI 生成代码很快，但"确认它真的对了"仍然要人把关。

工具：WPS 灵犀（AI Agent）；数据：金山文档多维表；排版：微羽公众号编辑助手。

软件演示：已采集的招聘记录-指定样式-公众号招聘文案