求职申请助手

它解决什么问题

海投最常见的浪费有三种：同一份简历投所有岗位、每个招聘站的表单字段名都不一样、投完就忘了投到哪。结果回复率低，也复盘不出是哪一步掉的。这个技能把找工作变成一条可观测的流水线：一份母版简历，N 份按 JD 定制的版本，每次投递都走完 抓取 → 定制 → 填表 → 提交 → 记录，并且把每轮踩到的坑沉淀成文件。

核心工作方式

触发 Apply for jobs 或 run my job hunt 后默认进入 Autonomous Application Loop，步骤之间不停下来问，只在硬停止条件出现时暂停。指定渠道（如 SOC roles、Hackney only）会覆盖默认的 board 顺序。

• 渠道适配：sites/<board>/NOTES.md 记录已验证的站点怪癖与登录配方，结构化怪癖写入 quirks.jsonl，用 quirks.py get 读取。
• 简历定制：按 JD 关键词 + 成果对齐，拒绝通用投递；封面信、冷启动私信、内推请求都能按同一上下文生成。
• 表单引擎：atsform.py 用字段可见 label 的子串定位，一套交互阶梯统一驱动 Greenhouse、Lever、Ashby、SmartRecruiters 等 react-select 变体。筛题渲染为 combobox，必须配置在 select 下，写成 radios/checkboxes 会静默失效。
• 浏览器层：所有导航走 camofox（cfx.sh / cfx.py），不使用宿主原生 browser_* 工具；导航一律 cfx.goto(url)，它会校验页面已渲染。
• 先查后写：动手写脚本前先看 references/tool-manifest.md，多数能力已有现成工具，重复造轮子是最浪费的一步。
• 持续学习：脚本和笔记是唯一的记忆载体，跑完一轮必须把新发现立刻写回 NOTES.md 或 CAPABILITY-GAPS.md，跨站点的问题不塞进单个站点笔记。

适用边界

• 依赖本地运行的 camofox REST 服务，curl -fsS http://localhost:9377/health 才是真正的存活信号，不是"标签页能不能打开"。
• 必须串行、单标签页：多个并行驱动进程会把引擎卡死（500 / browser was restarted），逐个 board 审核也必须一个一个跑，中间重新持久化新标签页。
• 上传文件只能是已暂存在 uploads/ 下的裸文件名，带目录或绝对路径一律 404。
• 组件点不动属于能力缺口，用 probe_widget.py 排查并记录可行策略，而不是写成"结构限制"；唯一合法的停止点是「无法如实回答的资格题」。
• 后端降级（空白渲染、innerText 为空、eval 挂起）时得出的 blocked / exhausted 结论不可信，需要 verdicts.py stamp 标记后恢复再验。
• 环境变量只持久化 CFX_KEY + CFX_TAB；手工写 CFX_URL / CFX_USER 会覆盖内置默认值，导致所有 import cfx 脚本直接报错。