每天在三个网站上刷同样的职位太费时间，所以写了一个服务替我做第一轮筛选。

它做什么

• 定时从 Seek、LinkedIn 和 Indeed 抓取堪培拉的新 IT 职位，并补全广告正文。
• 先跑便宜的确定性规则：地点、跨网站去重、明显不满足的硬性要求。过不了这关的职位不会调用付费 API。
• 剩下的连同简历和求职偏好一起交给大模型，返回结构化 JSON：能否申请、匹配分数、一句话概述、匹配点和差距。
• 一个小网页按分数列出所有职位，高分的直接推送到手机。

做下来发现真正重要的

限流。 所有调用共用一个节奏窗口：遇到 HTTP 429 间隔翻倍，遵守 Retry-After，成功后再慢慢恢复。一次限流会让整轮放慢，而不是每个职位各自去撞墙。配额耗尽这类不会自己好的错误，直接中止本轮。

无声的失败。 抓取被封时很少直接报错，而是拿到验证页、空列表，或者正文页 403。现在每个数据源每轮都会记录自己看到了什么，状态一变就推送一次，24 小时后还没好再提醒一次，恢复时再说一声。

提示词缓存。 系统提示词、个人资料和简历每次调用都一样，大约 2,700 token。服务商默认的缓存断点落在职位广告后面，于是每次都按更高的价格把整段写进缓存，却从来读不到。把消息拆开、只在固定部分后面打断点之后，除第一次外每次调用都命中缓存，单次输入成本降了大约 60%。

技术栈

Python、SQLite、OpenAI 兼容的大模型 API、Telegram 和 ntfy 推送，用 Docker Compose 跑在家里的服务器上。它会从我自己的 Git 服务器拉取更新，代码变了自动重启。