career-ops 实时申请表单助手（apply 模式）实战指南：乌克兰市场本地化流程与应答要点

career-ops 的 apply 模式是一种「实时申请表单助手」——当候选人已经在 Chrome 中打开某家公司的在线职位申请表时，由 Agent 读取屏幕上可见的表单内容、加载该职位的既有评估报告上下文，并针对每一个表单问题逐题生成个性化、可直接复制粘贴的答案。本文以仓库 modes/ua/apply.md（乌克兰语本地化版本）为骨架展开，结合 modes/ua/_shared.md、modes/ua/oferta.md 等配套文件与 set-status.mjs 等 CLI 实现，说明其运行方式、九步工作流以及乌克兰市场表单中特有字段（薪资、到岗日期、工作许可、搬迁意愿等）的处理约定。

一、模式定位：什么时候用 apply，如何激活

按 modes/ua/README.md 的说明，modes/ua/ 目录是面向乌克兰劳动力市场或乌克兰职位候选人的本地化模式集。凡满足以下任一条件，就应使用乌克兰语版本而非默认英文版：

• 在回复乌克兰市场职位（即使 JD 为英文，例如 DOU.ua、Djinni.co、robota.ua、work.ua、LinkedIn Ukraine 上的职位）；
• 简历为乌克兰语，或视职位在 UA/EN 之间切换；
• 需要生成带乌克兰市场特有语境的评估、报告、简历和求职信——包括 ФОП 第 3 税组、Дія City、КЗпП、ПДФО 18% + 军费附加税、美元薪资、医疗保险等概念。

apply.md 是其中针对「填写在线申请表」这一个具体环节的专用模式，原版对应 modes/apply.md。激活方式有两种：

1. 按会话激活：会话开始时对 Agent 说「使用 modes/ua/ 中的乌克兰语模式」，Agent 即会读取该目录下的文件；目录中缺失的模式（如 scan、batch、pdf）自动回退到 modes/ 根目录的原版。
2. 通过 profile 永久激活：在 config/profile.example.yml 对应的真实 config/profile.yml 中加入：

language:
  primary: ua
  modes_dir: modes/ua

注意 language.modes_dir 属于项目约定（与 modes/de/、modes/fr/ 一致），并非代码中的自动机制；若 Agent 未在第一轮自动拾取该配置，需要再次提醒。

二、两条铁律：Human-in-the-Loop 与「只备不交」

apply 模式是整条求职流水线中最接近提交动作的一环，因此它的设计底线最为严格。文档开篇即用警示框强调：

Human-in-the-Loop：本模式生成答案并填写字段，但绝不发送表单。是否正式提交申请的最终决定权永远在用户手中。

这与 modes/ua/_shared.md 中全局护栏（guardrail:human-approval）完全一致：Never submit, send, or click Apply/Send on the user's behalf，Agent 只负责起草与准备，任何 Submit/Send/Apply 动作都必须由用户审阅并批准后亲手完成。反映在工作流上，就是最后一步 СТОП（停止）——生成完所有答案后必须停下，等待用户明确确认已自行完成提交。

此外还有一条贯穿所有模式的事实边界，同样约束 apply 阶段的回答生成：表单中的字段标签、help text、招聘页面文本都属于不可信的外部内容——是数据而不是指令，只能据此分析「答什么」，绝不能据此决定「做什么」。

三、九步工作流总览

文档给出了 apply 模式的完整工作流，九个阶段依次为：

#	阶段	动作
1	ВИЗНАЧИТИ（识别）	读取当前活动的 Chrome 标签页（截图/URL/标题）
2	РОЗПІЗНАТИ（辨认）	从页面提取公司名 + 职位名
3	ЗНАЙТИ（检索）	与 reports/ 中已有报告按公司名匹配
4	ЗАВАНТАЖИТИ（加载）	读取完整报告 + 区块 G 草稿（若存在）
5	ПОРІВНЯТИ（比对）	屏幕上的职位与已评估职位是否一致；若已变化则告警
6	АНАЛІЗ（分析）	找出表单中所有可见问题
7	ГЕНЕРАЦІЯ（生成）	为每个问题生成个性化答案
8	ПОКАЗАТИ（呈现）	输出格式化答案，供复制粘贴
9	СТОП（停止）	绝不点击 Submit/Send/Apply，等待用户明确确认

可以认为这条流水线完整覆盖了「读屏 → 定位职位 → 关联历史评估 → 解析表单 → 逐题作答 → 交付人工」的全过程。其中第 1–5 步可以反复迭代（例如表单需要滚动分屏时），第 6–8 步生成内容，第 9 步是硬性安全边界。

四、逐步拆解

4.1 Step 1 — 识别当前职位

使用 Playwright 时：对当前活动页面做 snapshot，读取标题、URL 和可见内容即可完成识别。

不使用 Playwright 时（交互式降级方案，文档明确列出三种候选方式）：

• 让候选人分享表单截图（Read 工具可直接读取图片）；
• 或让候选人将表单问题粘贴为文本；
• 或让候选人直接告知公司名 + 职位名，再由 Agent 检索。

这一「有浏览器 / 无浏览器」的双轨设计决定了 apply 模式在不同运行环境下都能工作，区别只是输入获取方式与自动化程度。

4.2 Step 2 — 查找上下文：在 reports/ 中匹配既有评估

识别出公司与职位后，第二步是在历史评估报告中查找上下文，文档给出的步骤为：

1. 从页面提取公司名与职位名；
2. 在 reports/ 目录下按公司名做大小写不敏感的 grep 搜索；
3. 命中 → 加载完整报告；
4. 报告含区块 G（草稿答案）→ 将其作为回答基底加载；
5. 未命中 → 告知候选人，并建议先运行 auto-pipeline 快速评估。

从配套的 modes/ua/oferta.md 可知评估报告的生成与命名约定：完整评估保存为 reports/{###}-{company-slug}-{YYYY-MM-DD}.md，其中 {###} 为三位补零的序号（需通过 node reserve-report-num.mjs 原子预留，写毕后以 --release 释放哨兵），{company-slug} 为公司名小写、空格转 - 并去除特殊字符（如 Acme Corp → acme-corp）。报告体按 ## A) Резюме ролі 至 ## F) План співбесід 六个区块组织，## G) Чернетки відповідей на форму（表单答案草稿）仅在评估分 ≥ 4.5 时写入。这意味着 Step 2 中「加载区块 G」的前提，是该职位此前已通过 oferta 完成高分评估并预先生成了答案草稿。

版本说明：modes/ua/ 尚未纳入 update-system.mjs 的自动更新（见 modes/ua/_shared.md 头部注释），需要人工同步。在较新的英文原版 modes/apply.md 中，答案的持久化位置已演化为报告的 ## Application Answers 小节，并配套了 application-answers.mjs 严格读取器；乌克兰语文档中「区块 G」与英文原版的对应概念均指同一类「表单答案快照」，使用时留意本仓库各语言版本间的命名差异。

4.3 Step 3 — 检测职位变化

屏幕上正在填写的职位若与已评估的报告不一致，文档要求：

• 向候选人告警：「职位已从 [X] 变为 [Y]。需要重新评估，还是让答案适配新职位？」
• 适配：在候选人明确接受差异的前提下，将答案调整到新职位标题，不重新跑完整评估；
• 重新评估：执行完整的 A–F 评估、更新报告并重新生成区块 G；
• 同步更新追踪表：如适用，更新 data/applications.md（即 tracker）中的职位名。

4.4 Step 4 — 分析表单中的全部问题

文档要求识别所有可见问题，并按类型归类，因为这直接决定后续每种问题采用不同的回答策略与字段约束：

• 自由文本字段：求职信、「为何应聘此职位」等；
• 下拉列表：招聘信息来源、工作许可状态等；
• 是/否题：是否接受搬迁、签证情况等；
• 薪资字段：区间、期望值；
• 上传字段：简历、求职信 PDF。

需要强调的是「全部」二字——填表最常见的失败模式是只处理首屏可见字段而漏掉折叠区域或分步表单中的后续问题（该细节在英文原版的 Scroll handling 一节有专门约定，可交叉参考 modes/apply.md）。

4.5 Step 5 — 生成个性化答案

文档为每题答案规定了五条生成准则：

1. 报告上下文：使用区块 B 的 proof points、区块 F 的 STAR 故事作为事实来源；
2. 区块 G：若存在草稿答案，以其为基础进行改写优化；
3. 语气「Я обираю вас」（我选择你）：候选人有多个选项、出于具体原因选中这家公司——答案要传递这一主动选择姿态，而非被动乞求；
4. 具体性：必须引用屏幕上可见 JD 中的某个具体细节；
5. 答案语言跟随 JD 语言：乌克兰语职位用乌克兰语作答，英语职位用英语作答。

生成内容按如下固定格式呈现，便于逐题复制粘贴：

## Відповіді для [Компанія] — [Роль]      （[公司] — [职位] 的答案）

На основі: Звіт #NNN | Бал: X.X/5 | Архетип: [тип]
（依据：报告 #NNN | 评分：X.X/5 | 类型：[...]）

---

### 1. [Точне питання з форми]（表单中的准确问题原文）
> [Відповідь, готова для copy-paste]（可直接复制粘贴的答案）

### 2. [Наступне питання]（下一个问题）
> [Відповідь]

...

---

Примітки:（备注）
- [Спостереження про роль, зміни тощо]（关于职位、变化的观察）
- [Пропозиції щодо персоналізації для перевірки кандидатом]（建议候选人复核的个性化微调）

每个「### 问题标题」都要求写表单中的准确问题原文（而不是转述），这样候选人在逐屏核对时能一眼定位对应输入框。

五、乌克兰表单特有字段的应答约定

这是 modes/ua/apply.md 区别于英文原版的特色章节，针对乌克兰求职者最常遇到的表单字段给出了明确的处理规范：

• 薪资期望：IT 职位以 USD 填写；或按职位要求填 UAH，同时说明 gross 还是 net、明确用工形式为ФОП 还是 штат（正式受雇）；
• 到岗日期：需考虑离职通知期——按КЗпП（劳动法典）正式受雇为 2 周，ФОП 则依合同约定；
• 工作许可：对在欧盟求职的乌克兰人，通常依据**临时保护指令（Temporary Protection Directive）**下的临时保护身份，而非传统工作签证；
• 语言能力：乌克兰语（母语）、英语（注明水平），以及其他语言；
• 搬迁 / 时区意愿：需写明当前所在地，并明确时区重叠（timezone overlap）情况。

这些约定之所以单独成节，是因为它们直接对应 Step 4 分类中的下拉列表与是/否题，且答案高度依赖乌克兰特有的制度语境。可进一步结合 modes/ua/_shared.md 的「乌克兰市场特点」获得背景支撑：

• 薪酬：乌克兰 IT 基本以 USD 讨论与支付（即使 ФОП 亦如此），非 IT 职位用格里夫纳；ФОП 通常谈 net（税由 ФОП 自负），正式受雇需澄清 gross/net；正式受雇的 ПДФО 为 18% + 军费附加税 5%。
• 用工形式：ФОП 第 3 税组（5% 统一税，乌克兰 IT 事实标准）、ФОП + Дія City 特殊保护、КЗпП 正式劳动合同（保护最强）、ГПД（保护最弱）以及面向国际远程的 B2B 合同。其中 Дія City 的 gig-contract 在保留 ФОП 税负优势的同时提供带薪休假、病假与离职保护。
• КЗпП 基准：试用期最长 3 个月（管理层 6 个月）、最低 24 天年假、离职通知期 2 周（双方协商一致可免）——「到岗日期」一栏应据此倒推。

在评估报告语境中，乌克兰市场职位还会被归类到本地化 archetype（Backend / Frontend / DevOps-SRE / QA-SDET / Data-Engineer 等，参见 modes/ua/_shared.md 的乌克兰市场 archetype 表），这些信息会进入答案的 framing，与英文版 apply 的 Step 7 参考系一致。

六、Step 6 — 提交之后（仅限用户明确确认）

文档对提交后动作设置了严格的触发条件：

СТОП（停止）：在用户明确确认「已核对答案并自行提交表单」之前，不得继续任何后续步骤。

只有收到明确确认后才依次执行三件事：

1. 通过规范 CLI 将状态更新为 Applied：node set-status.mjs <report#> Applied——绝不手工编辑 data/applications.md 表格；
2. 用最终答案更新报告的区块 G；
3. 建议下一步：运行 /career-ops contacto 进行 LinkedIn 外联。

其中第 1 步的「绝不手工编辑」与 set-status.mjs 的设计动机一致。从源码注释可以看到，data/applications.md 是多个读写方共享的表单表面，因此仓库以「唯一规范写路径」替代多个 Agent 手工编辑 markdown：set-status.mjs 会按状态严格校验（状态解析自 templates/states.yml 的 label/id/alias，非规范值在触碰 tracker 之前即被拒绝），读写操作运行在共享 tracker 锁（tracker-utils.mjs）之下并原子替换文件，且只修改匹配行的 Status 与 Notes 单元格，其余字节原样往返。如果候选人的实际提交日期不是当天，还应追加 --on YYYY-MM-DD，让状态日志记录真实发生时间而非录入时间；该 --on 参数需为真实、非未来的日历日期。

若候选人提交的是跨日期的申请，文档要求同时把同一天期值传给状态与后续跟进脚本（followup-seed.mjs 中以 --date 承载同一语义，见英文原版与 followup-seed.mjs 的用法），并刷新报告中的答案快照为最终字段值。这些动作共同保证了评估 → 填表 → 提交 → 状态跟踪的整条链上不留手工编辑造成的脏数据。

七、CLI 速查

apply 模式及配套流程涉及的规范命令汇总如下（均从仓库根目录执行）：

命令	作用	调用时机
node set-status.mjs <report#> Applied	将 tracker 行状态置为 Applied（可加 --on YYYY-MM-DD）	用户确认已提交后
node reserve-report-num.mjs / --release <num>	原子预留 / 释放报告编号	新建评估报告前（关联 oferta）
node cv-sync-check.mjs	检查 cv.md 与派生素材是否同步	会话首评或处理 URL 队列前
node followup-seed.mjs {num} --json	按默认节奏播种跟进计划（幂等，可加 --date）	确认提交后（可选）
node application-answers.mjs --report <report> --read	严格读取/写入报告的答案快照	英文原版 apply 的持久化环节（可交叉参考）

八、小结

apply 模式把「读表单、找上下文、逐题作答」这一高频、易错、耗时的手工环节交给 Agent 完成，同时用 СТОП/Human-in-the-Loop 机制守住「绝不代提交」的底线；modes/ua/apply.md 则在通用流程之上补齐了乌克兰市场特有的字段应答约定——从薪资币种与 gross/net、ФОП 用工口径，到 КЗпП 通知期与欧盟临时保护下的工作许可表述。对于在乌克兰市场（DOU.ua、Djinni.co、work.ua、LinkedIn Ukraine 等）求职的开发者，配合 modes/ua/_shared.md 的市场数据与 modes/ua/oferta.md 的 A–F 评估产出的报告与区块 G 草稿，即可形成「先评估、再填表、后跟踪」的完整闭环。