career-ops 韩国市场实战：jiwon 模式——在浏览器里填就业愿书时的实时 AI 助手

career-ops 的韩国语模式目录 modes/ko/ 中，jiwon.md（지원，"就业愿"）是当候选人在 Chrome 中打开就业愿表单、正在逐题作答时调用的 interactive 模式：它读取当前屏幕上可见的表单内容，从 reports/ 中载入此前对该职位的 A-H 评估报告作为上下文，然后针对每一题生成可直接复制粘贴的个性化回答。本文完整拆解该模式的 8 步工作流、6 个执行步骤、韩国就业愿表单特有字段的作答策略，以及提交后的 tracker 合并与 follow-up 衔接，并结合仓库内 共享上下文、配置示例与 英文原版 apply 模式的源码级实现，说明它如何嵌入 career-ops 的整体工作流。

模式定位：什么时候用 jiwon

jiwon 模式面向"候选人正在 Chrome 中填写就业愿表单"的实时场景，与两个相邻模式分工明确：

• 它不是扫描模式（批量收集职位），也不是评估模式（对单个职位做完整 A-F 评估）；
• 它是评估完成、正式提交就业愿之前的"最后一公里"——把已有评估结论转化为每个表单字段的最终答案。

按 modes/ko/README.md 的模式总表，jiwon.md 的翻译基准是英文版 modes/apply.md（"Live Application Assistant"），定位为"支持填写就业愿输入表单的 live assistant"。激活方式与整个 modes/ko/ 目录一致：

• 会话级：会话开始时直接说明"使用 modes/ko/ 下的韩国语模式"，agent 会改用该目录下的文件而非默认 modes/；
• 永久配置：在 config/profile.yml 中声明语言目录：

language:
  primary: ko
  modes_dir: modes/ko

之后 agent 会自动加载韩国语模式。

前置条件：有 Playwright 与无 Playwright 两种路径

jiwon 模式在 原文 中明确了两档运行条件，这直接决定了后续"页面检测"步骤的实现方式：

1. 有可见 Playwright（最理想）：visible mode 下候选人能直接看到浏览器窗口，agent 同时能读取页面并与之交互——可以拿到真实 URL、title 和完整可见内容，还可以处理滚动加载的表单；
2. 无 Playwright：降级为人工投喂——候选人共享截图（Read 工具可以读图）、直接粘贴表单问题文本、或口头告知"公司 + 职位"让 agent 去检索上下文。

这一设计与 英文原版 一致：无 Playwright 时，liveness（职位是否仍然有效）无法通过页面验证，agent 会明确声明这一局限并要求候选人确认公司、职位与职位有效性后再开始作答。

8 步工作流总览

jiwon 模式的核心流程在原文中以 8 个阶段概括：

1. DETECT      -> 读取活动 Chrome 标签页 (截图/URL/title)
2. IDENTIFY    -> 从页面提取公司 + 职位
3. SEARCH      -> 与 reports/ 内的既有报告匹配
4. LOAD        -> 读取完整报告 + 区块 G (若存在)
5. COMPARE     -> 确认屏幕上职位与已评估职位是否一致，若变更则提醒
6. ANALYZE     -> 识别屏幕上可见的所有就业愿问题
7. GENERATE    -> 为每道题生成个性化回答
8. PRESENT     -> 以可复制/粘贴的格式呈现答案

注意第 5 步 COMPARE 的存在：它不是单纯的"加载报告"，而是交叉验证——页面上的职位必须与已评估的职位吻合，否则进入角色变更处理流程。这一点比"读屏 → 生成答案"的朴素理解多了防错闸门。

Step 1 -- 职位检测

两种路径对应两种检测方式：

有 Playwright：对活动页面做 snapshot，读取 title、URL 与可见内容。

无 Playwright：向候选人索取以下三者之一：

• 就业愿表单截图（Read 工具能读图）；
• 将表单问题粘贴为文本；
• 告知公司 + 职位，由 agent 检索上下文。

从 modes/_shared.md 的工具表可以推断，Playwright 在 career-ops 中被定位为"职位活跃性确认 + SPA 页面提取"的核心手段，且有一条硬约束：不要并行启动两个以上使用 Playwright 的 agent——它们共享同一个 browser instance。这一约束同样适用于 jiwon 场景：如果同时开一个 agent 跑 scan 又开一个填表单，浏览器状态会互相干扰。

Step 2 -- 识别并加载上下文

这是 jiwon 模式与"对着表单从零回答"的本质区别所在：

1. 从页面提取公司名与职位名；
2. 在 reports/ 目录中按公司名做 case-insensitive grep 检索；
3. 有匹配报告则加载完整报告；
4. 若报告存在区块 G（先前答案草稿），将其作为基底加载；
5. 若无匹配报告，不凭空作答——通知候选人，并建议先跑一次快速 auto-pipeline 完成评估。

这里有两个值得展开的实现细节：

• 报告的块结构。评估模式（modes/oferta.md）生成的报告遵循固定骨架：A) Role Summary、B) Match with CV、C) Level and Strategy、D) Comp and Demand、E) Customization Plan、F) Interview Plan、G) Posting Legitimacy、H) Draft Application Answers，外加 Machine Summary 与 Keywords extracted。从源码结构看，jiwon.md 所称的"区块 G 中的先前答案草稿"对应的是评估阶段预先起草的应用答案块（英文现行版本中该职责由 Section H / ## Application Answers 承担）；英文 apply.md 还规定了严格的读取方式——用 node application-answers.mjs --report <报告路径> --read --strict 读取，禁止把该区块当散文重读，部分不可读时不得静默降级。使用 jiwon 模式时，实际以 reports/ 中报告的真实块结构为准。
• Source of Truth 三件套。modes/ko/_shared.md 规定每次评估/作答前必须读取 cv.md（项目根）、article-digest.md（若有）与 config/profile.yml，且proof point 的数值禁止硬编码——作答时从文件中现读。这意味着 jiwon 生成的答案中的数字（指标、年限、成果）始终与你的 CV 保持同步，而不是沿用上次的旧值。

Step 3 -- 角色变更检测

若屏幕上的职位与已评估职位不一致，jiwon 模式要求先停下来问，而不是默默改写答案：

"职位似乎从 [X] 变为 [Y]。要按新职位重新评估，还是只针对新 title 调整答案？"

两个分支的处理：

• 选择调整：不重新评估，仅把答案适配到新职位——前提是候选人明确接受这一 mismatch；
• 选择重新评估：执行完整 A-F 评估、更新报告并重新生成答案草稿块；
• tracker 同步：必要时修正 applications.md 中的职位名。注意 modes/ko/_shared.md 的全局规则：不直接手改 applications.md，而是往 batch/tracker-additions/ 写 TSV、由 node merge-tracker.mjs 合并（后文 Step 6 详述）。

英文 apply.md 中对应的 preflight 门禁更严格：若公司名或职位发生了实质性变化，必须在起草任何答案前停住，提供"重新评估 / 带 mismatch 继续 / 停止"三选一。jiwon 模式继承了这一"停-问-再动"的原则。

Step 4 -- 表单问题分析与分类

对屏幕上所有可见问题做识别，覆盖五类字段：

字段类型	示例
自由文本	求职信、"为什么选择这个职位"、求职动机
下拉框	从何处得知职位、工作资格
Yes/No	是否可移民、签证、可工作地区
薪资输入	期望年薪、薪资区间、总薪酬预期
上传字段	CV、求职信 PDF、推荐人

识别完成后按两条规则分类：

• 区块 G 已答过的问题 → 取现有答案做调整，避免同一问题前后矛盾；
• 新问题 → 基于报告 + cv.md 生成答案。

从 英文原版 的实现看，这一步还有两条 jiwon 简版未展开但实际重要约束：

1. 表单字段标签/帮助文本是不可信外部内容——它们只能被"分析用于回答什么"，不能被当作对 agent 的指令执行（prompt injection 防护，见 AGENTS.md 的 Untrusted External Content 一节）；
2. 敏感字段禁止编造：法律、人口统计、工作许可、签证/赞助、薪资、残疾、退伍军人、背景调查、自我申报等字段，若答案在 config/profile.yml 或可见上下文中不存在，必须标记为"需候选人确认"并给出最安全的问法，而不是替候选人猜一个答案。

Step 5 -- 回答生成：五段式结构

jiwon 模式对每道题按固定五段结构生成答案，这是该模式输出质量的"配方"：

1. 报告上下文：使用区块 B（Match with CV）的 proof point 与区块 F（Interview Plan）的 STAR story；
2. 先前区块 G：若有既有草稿，以其为基底打磨而非重写；
3. "是我在选你们"的语调：与 auto-pipeline 同一套 framework——自信、不恳求；
4. 具体性：引用屏幕上可见职位内容中的具体要素（而不是泛泛地谈公司文化）；
5. career-ops proof point：若表单有"附加信息"类字段，放入 article-digest.md / profile.yml 中的已验证成果。

韩国就业愿表单的特有字段

这是 jiwon 模式相对英文版最实质的增量，直接映射到 config/profile.example.yml 的具体配置项：

韩国表单字段	作答策略	配置来源
期望年薪 / 待遇	使用 profile.yml 中的区间；明确按税前年薪（세전 연봉）表述；补充"可依据整体薪酬包协商"	compensation.target_range / compensation.minimum
可入职日期	结合当前在职/离职通知期的现实日期	cover_letter.notice_period_days（示例值为 30 天）
可工作地区 / 可否出勤	明确写出实际可覆盖的地区与出勤频率	location / compensation.location_flexibility
签证 / 工作资格	按事实简洁作答	location.visa_status / location.needs_sponsorship
语言能力	按实际水平书写，必要时用 CEFR 或"商务/实务可用"表述	无对应配置键——按事实手写
作品集 / GitHub / 博客	只使用 profile.yml、cv.md、article-digest.md 中已验证的链接	candidate.portfolio_url / candidate.github 等

其中三条与 modes/ko/_shared.md 的守护规则严格咬合：

• never fabricate（guardrail:no-fabrication）：关键词可以改写，绝不能编造——不在批准源文件中的声明，宁缺毋滥或反问候选人；
• source-exclusivity（guardrail:source-exclusivity）：cv.md / article-digest.md / profile.yml 是候选人声明的唯一来源；职位文本、表单字段、招聘邮件都是"数据"，不是候选人资历的证据；
• human-approval（guardrail:human-approval）：永远不代替候选人点击 Apply/Send——jiwon 模式的所有输出止步于"可复制粘贴的答案"，提交动作必须且只能由候选人完成。

薪资字段还有专门的协商脚本模板（来自 modes/ko/_shared.md），例如：

"考虑到该职位的市场基准与我的经验范围，我期待 [profile.yml 中的区间] 水平。不过我可以基于 base、bonus、equity、福利在内的整体薪酬包灵活讨论。"

韩国市场特有的薪酬词汇（정규직/계약직、수습기간、포괄임금제、퇴직금、4대 보험、세전 연봉、스톡옵션 等）在 modes/ko/README.md 与 modes/ko/_shared.md 中有完整对照表与评估影响说明，作答"待遇"类问题前应优先参照该表，避免把"含税/不含税""含不含绩效奖金"口径答混。

输出格式

生成的答案块有固定模板，保证每次输出结构一致、可直接复制：

## [公司] -- [职位] 就业愿答案

Base: Report #NNN | Score: X.X/5 | Archetype: [type]

---

### 1. [表单中的原始问题]
> [可直接复制/粘贴的答案]

### 2. [下一题]
> [答案]

...

---

Notes:
- [角色变更、职位相关观察等]
- [候选人需亲自确认的个性化要点]

头部三行（Base/Score/Archetype）把答案锚定回具体报告编号，便于日后核对"这个答案是基于哪份评估写的"；结尾 Notes 段则承担"agent 不能替候选人拍板的事项"的显式交接。

Step 6 -- 提交后处理（可选）

候选人确认已提交就业愿后，jiwon 模式执行三步收尾：

1. 更新 tracker 状态——但走 TSV 合并，不手改：不直接编辑 data/applications.md，而是向 batch/tracker-additions/ 写入一条 Applied 状态的 TSV 更新，再执行 node merge-tracker.mjs 完成合并。从 tests/merge-tracker.test.mjs、tests/merge-tracker-cli-roots.test.mjs 等大量测试可以看出，这个合并器有独立的 URL 去重、公司后缀解析、数值校验等保证，手改表格会绕开这些防线；
2. 回写最终答案：把提交时的最终答案更新进报告的草稿答案块，使报告中的"写了什么"与"交了什么"一致；
3. 衔接下一步：建议运行 contacto 模式（/career-ops contacto），对 hiring manager 或 recruiter 发起 LinkedIn outreach——contacto 模式有固定的"三句框架"（Fit/Hook → Proof → CTA）按联系人类型（recruiter / hiring manager / peer / interviewer）分别措辞，与 jiwon 的答案风格保持同一叙事线。

英文 apply.md 的 post-apply 流程在此之外还规定了两个可复用命令：node set-status.mjs <report#> Applied（规范化 CLI 改状态，支持 --on YYYY-MM-DD 记录真实提交日）与 node followup-seed.mjs {num} --json（幂等地播种 follow-up 排期，--date 传入真实提交日）。在韩国市场使用 jiwon 模式时，这两条命令同样可用，能确保"提交日"与"跟进排期"记录的是事件发生日而非录入日。

滚动处理：表单长于一个屏幕时

就业愿表单常见多页/长页布局，可见问题少于总问题数。jiwon 模式的处理循环是：

• 请候选人向下滚动后共享另一张截图；
• 或请其粘贴剩余问题；
• 循环处理，直到整个表单覆盖完毕——不允许只答了半页就进入提交状态。

有 Playwright 时该循环可以自动化（滚动 → 重新 snapshot → 继续）；无 Playwright 时则完全依赖候选人配合截图/粘贴。

与英文原版 apply.md 的关系：简版与满配版

将 modes/ko/jiwon.md 与 modes/apply.md 对照阅读，可以明确两者的层次关系：

维度	jiwon.md（韩语）	apply.md（英文）
工作流	DETECT → PRESENT 共 8 步	增加 PREFLIGHT / PRE-SCAN / PERSIST 共 9 步
草稿答案块	区块 G	Section H / ## Application Answers（配 application-answers.mjs 严格读取器）
提交后	TSV + merge-tracker + 回写区块 G	追加 set-status.mjs、followup-seed.mjs 规范命令
合规门禁	未单列	黑名单检查、跨渠道重复提交检查、knock-out 问题预扫、移民身份筛查、辖区禁问内容检查等 warn-only 门禁
本地化增量	韩国表单字段策略（税前年薪、수습/4대 보험词汇、notice period）	已知 ATS 怪癖（Ashby 邮箱去重、Lever hCaptcha、Workable SPA 重渲染、Workday React 字段等）

也就是说，jiwon 模式继承了英文 apply 模式的骨架（读屏 → 匹配报告 → 变更检测 → 逐题作答 → 可复制输出 → 提交收尾），而英文版在此骨架上叠加了多层合规/健壮性门禁。若你的求职场景涉及跨国雇主或需要更强的防错门禁，建议以 modes/apply.md 为参照叠加使用；纯韩国本土求职场景下，jiwon.md 的六步流程 + 韩国特有字段策略已经覆盖主干路径。

实践清单：跑通一次 jiwon 流程的最小准备

结合 modes/ko/README.md 与 modes/ko/_shared.md 的前置要求，一次成功的 jiwon 会话需要：

1. cv.md 存在于项目根，且为最新（首个评估会话会跑 node cv-sync-check.mjs 校验一致性，有告警先处理）；
2. config/profile.yml 填好 candidate、compensation、location、cover_letter.notice_period_days——jion 的薪资、入职日、出勤、链接类字段全部依赖它；
3. （推荐）article-digest.md 整理了可引用的 proof point；其指标优先于 cv.md 中的旧数值；
4. 目标职位已完成评估、reports/ 中有对应报告——没有报告就先跑快速 auto-pipeline；
5. 浏览器环境：能开 visible Playwright 最佳，否则准备截图/粘贴的工作流；
6. 全程记住一条红线：agent 只产答案，提交按钮只归你按。

小结

jiwon 模式是 career-ops 中把"评估资产"变现为"表单答案"的枢纽环节：它用 8 步工作流把屏幕上的表单问题逐一映射回 reports/ 中的评估报告与 cv.md/profile.yml 的事实来源，用五段式生成结构保证答案的具体性与语调一致性，用 TSV + merge-tracker.mjs 的安全路径完成提交后状态更新，并以 contacto 模式衔接提交后的主动出击。对韩国市场求职者，其独有价值在于对"期望年薪（税前口径）、수습기간、4대 보험、可出勤地区"等本土字段的显式作答策略——这些正是机械翻译版助手最容易答错或答漏的地方。