career-ops 日语模式「oubo」实战：Chrome 填表时的招聘申请实时助手

career-ops 的日语模式文件 modes/ja/oubo.md 定义了一个"応募ライブアシスタント"（申请实时助手）交互模式：当候选人在 Chrome 中填写企业 ATS 申请表单时，Agent 读取页面内容、加载该求人的既有评估报告，并为表单上的每一个问题生成可直接复制粘贴的个性化回答。本文完整继承该模式的 8 步工作流、Preflight 存活性校验、表单字段契约（application form contract）、日本市场特有问题的处理规则与 Post-apply 收尾流程，并结合 check-liveness.mjs、set-status.mjs 等源码，说明每个关键步骤背后的实现机制。

1. 模式定位与运行前提

oubo（応募，即"申请"）是 career-ops 面向日本市场或日语运营企业求职者的申请辅助模式，由英语模式 modes/apply.md 翻译而来。按 modes/ja/README.md 的说明，modes/ja/ 覆盖四个高价值模式，其中 oubo.md 对应的就是"応募フォーム記入のライブアシスタント"（申请表单填写的实时助手）。

该模式的核心设定是：Agent 不代替用户提交，只负责"读懂屏幕 + 生成回答 + 格式化呈现"。原文档明确了两种运行前提：

• 最佳配置是 Playwright 可见模式（visible mode）：候选人能看到浏览器窗口，同时 Agent 可以导航和读取页面（browser_navigate + browser_snapshot）。
• 没有 Playwright 时的降级路径：候选人共享表单截图（Agent 的 Read 工具可以读图），或手动粘贴表单问题文本，或只告知"公司 + 职位"让 Agent 自行检索。

原文档开头还规定了一条贯穿全程的写作规则：对自由文本回答和 cover letter 字段，若项目根目录存在 voice-dna.md（模板见 voice-dna.template.md），则同时应用 Tier 1（anti-AI-slop 硬性护栏）+ Tier 2（口语化语气） 两级 Voice DNA；具体规则见 _writing.md → Voice DNA 一节。两级作用域的划分在 modes/ja/_shared.md 中有完整定义：Tier 1（禁词表、死短语、格式规则）适用于所有生成文本，Tier 2（缩略、And/But 开头、hedging 表达）仅适用于 cover letter、LinkedIn 触达、跟进邮件等对话性文本，不适用于 CV/ATS 的关键词密集型正式文体。

如何启用日语模式

career-ops 没有代码层面的"语言开关"。按 modes/ja/README.md，启用有两种方式：

1. 会话内指示：在会话开头告诉 Agent "使用 modes/ja/ 的日语模式"，或更具体地"读取 modes/ja/_shared.md 和 modes/ja/kyujin.md"。Agent 随后从该目录而不是 modes/ 根目录读取模式文件。
2. Profile 持久配置：在 config/profile.yml 中写入：

language:
  primary: ja
  modes_dir: modes/ja

首次会话中告知 Agent 已设置 language.modes_dir 即可，此后 Agent 自动使用日语模式。README 特别说明：language.modes_dir 是惯例（convention）而非严格 schema，字段名未来可能被维护者变更；且 config/profile.example.yml 中还区分了 language.output（报告、追踪表、PDF、表单回答等面向人的输出语言）与 modes_dir（市场词汇/规则来源），两者可组合使用，例如"用德语市场词汇但写英文输出"。

2. 八步工作流总览

原文档给出的完整工作流如下（8 步，含 PREFLIGHT 门）：

1. DETECT      → Read active Chrome tab (screenshot/URL/title)
2. IDENTIFY    → Extract company + role from the page
3. SEARCH      → Match against existing reports in reports/
4. LOAD        → Read full report + Section G (if it exists)
5. PREFLIGHT   → Confirm posting liveness + company/role match before drafting
6. ANALYZE     → Identify ALL visible form questions
7. GENERATE    → For each question, generate a personalized response
8. PRESENT     → Show formatted responses for copy-paste

注意第 4 步加载的是 Section G（评估报告中的既有回答区块）。日语模式翻译自 apply 模式的较早版本，使用 "Section G" 这一区块名，而当前英语版 modes/apply.md 已将该区块演进为 Block H（## H) Draft Application Answers）+ 严格读取器 application-answers.mjs（--read --strict / --read-draft），并新增了 5b（knock-out 问题预扫描）、5c（管辖地禁止内容检查）、5d（移民身份筛查检查）等前置步骤。阅读日语模式时，可将其视为 apply 模式"存活性门 + 表单分析 + 回答生成 + 提交后收尾"这条主干线的日本市场本地化版本。

3. Preflight 门（Step 5）：生成任何回答之前的强制校验

这是整个模式中最关键的安全门。它的目标是确认：当前表单确实指向那份被评估过的、仍在招募的职位。该门在页面检测（Step 1）、公司/职位识别（Step 2）、匹配报告加载（Step 3）之后运行，原文档规定"Preflight 未解决前不得进入 Step 6"。具体流程为：

1. 读取可见的 URL、页面标题、公司、职位，以及任何 closed/expired 信号。
2. 若 URL 可用，用 Playwright 确认存活性（liveness），判据分两类：
   • active posting 证据：title/role + 职位描述（JD）或表单字段 + submit/apply 路径；
   • closed posting 证据：expired/closed/no longer accepting applications、JD 缺失只剩 nav/footer、被硬跳转到通用 careers/search 页面、404/410 状态码。
3. 将可见的公司与职位和匹配到的 report 做比对。
4. 若公司或职位发生实质性变化，停止起草并询问，原文给出的标准话术是：

   "The form appears to be for [visible company] — [visible role], but the matched report is [report company] — [report role]. Do you want me to re-evaluate, adapt with this mismatch, or stop?"

5. 若职位看起来已关闭，除非候选人给出已知理由并显式 override，否则拒绝生成最终文案。
6. 若候选人只粘贴了问题或截图导致无法验证 liveness，必须明确声明这一限制，并在起草前请候选人确认公司、职位与"该职位仍在招募"三项事实。

多职位连坐：先用 Liveness sweep 批量清理

原文档在 Preflight 末尾补充了一个针对"一次会话申请多个职位"场景的建议：Preflight 只验证眼前这一个表单；在批量申请会话前——尤其是 scanner 标记了 **Verification:** unconfirmed (batch mode) 的 pipeline 条目——应先执行 pipeline 模式的 Liveness sweep：

node check-liveness.mjs --file <urls>

从源码看，check-liveness.mjs 采用"两级（two rungs）"检测架构：

• 第一级：零 token 的 ATS API 检查（liveness-api.mjs）。对已识别的 ATS 域名直接走公开 API 判断 active/expired，不启动浏览器——源码注释说明"A conclusive active/expired wins; otherwise fall through"。
• 第二级：Playwright 浏览器检查（liveness-browser.mjs）。API 无法得出结论时，headless Chromium 加载页面，使用与 scan 模式 Step 7.5 相同的检测逻辑；部分站点（如使用 Cloudflare 反爬墙的门户）在 challenge 时会自动用 headed 浏览器重试一次，--no-fallback 可强制纯 headless。
• 限流：--throttle[=ms] 在相邻浏览器检查之间插入 5–10 秒（默认 base 5000ms）的抖动延迟，以规避 WAF 速率限制；只有浏览器检查才限流，API 检查不限。
• 退出码契约：全部 active 返回 0，存在 expired 或 uncertain 返回 1——这正是 modes/ja/pipeline.md 中 Liveness sweep 能据此把 dead postings 从 data/pipeline.md 批量移出的机制基础。

批量 sweep 的价值在于：expired 的职位在打开标签页之前就被批量剔除，避免为每个失效职位浪费一整次评估的 token 与时间。该脚本的行为在 tests/check-liveness.test.mjs 中有测试覆盖。

4. Step 1–3：检测页面、定位报告、处理职位变更

Step 1（检测）：有 Playwright 时，直接 snapshot 活动标签页，读取 title、URL 与可见内容；无 Playwright 时向候选人索要三选一：表单截图（Read 工具可读图）、表单问题的纯文本粘贴、或"公司 + 职位"由 Agent 自行检索。

Step 2（识别与检索上下文）：

1. 从页面提取公司名与职位名；
2. 在 reports/ 目录中按公司名做 case-insensitive grep 搜索；
3. 命中则加载完整报告；
4. 若存在 Section G，将其中早先起草的回答作为基线加载；
5. 未命中则通知候选人，并建议先跑一次 quick auto-pipeline 生成报告。

Step 3（职位变更检测）：若屏幕上的职位与已评估职位不同，原文档定义了两种分支：

• Adapt（适配）：仅在候选人显式接受 mismatch 后，不做重新评估，直接把回答调整到新职位；
• Re-evaluate（重评）：执行完整 A-F 评估、更新 report、重新生成 Section G。

两种分支都要求必要时更新 tracker（applications.md）中的 role title。这里的 A-F 评分维度（Match con CV、North Star alignment、Comp、Cultural signals、Red Flags + 1–5 全局加权分）定义在 modes/ja/_shared.md 的"スコアリングシステム"一节，4.5+ 为"强烈匹配、立即推荐申请"，低于 3.5 则不建议申请。

5. Step 6：表单问题分析与字段契约

这一步要求识别所有可见问题，覆盖五类控件：

• 自由文本字段（cover letter、"why this role" 等）
• 下拉框（how did you hear、work authorization 等）
• Yes/No（relocation、visa 等）
• 薪资字段（range、expectation）
• 上传字段（resume、cover letter PDF）

然后对每个问题做分类：

• Section G 已回答 → 基于既有回答做适配（adapt）；
• 新问题 → 基于 report + cv.md 生成回答。

原文档进一步要求：对每个字段保留一份 application form contract（表单字段契约），这是保证回答可核验、可回溯的关键数据结构：

契约字段	取值	说明
field_type	text / textarea / select / radio / checkbox / number / file / unknown	控件类型
required	yes / no / unknown	是否必填
limit	可见时的精确字符/字数限制，否则 unknown	长度约束
options	select/radio/checkbox 的可见选项	选项枚举
needs_candidate_confirmation	特定敏感类别默认 yes	是否必须问候选人

其中 needs_candidate_confirmation 的触发类别是法务、人口统计、工作许可、签证、relocation、薪资、残障、退役军人、sponsorship、background check、自我身份声明类问题——除非答案在 config/profile.yml 中显式存在。原文档的硬规则是：绝不为上述类别捏造回答。若答案在 config/profile.yml 或可见上下文中都找不到，就标记为需候选人确认，并给出"向候选人提问的最安全问法"。这条规则与 modes/ja/_shared.md 全局规则区的 "Keywords get reformulated, never fabricated"（关键词只能改写、不能发明）一脉相承：答案不在真实来源文件中时，沉默好过捏造。

6. Step 7：回答生成的七条规则

对每个问题生成回答时，原文档列出七条生成准则：

1. Report context：使用 Block B 的 proof points 与 Block F 的 STAR stories；
2. 既有 Section G：若已有起草回答，以其为基线做 refine 而非重写；
3. "I'm choosing you" 语气：与 auto-pipeline 同一套框架——以"我选择你"而非"求你录用我"的姿态写；
4. Specificity：必须引用屏幕上可见 JD 中的某个具体细节；
5. career-ops proof point：若有 "Additional info" 字段，把量化证明点放进来；
6. Recruiter-side risk map：使用 modes/heuristics/recruiter-side.md 的启发式，先判断这个问题在替招聘方消解哪种疑虑（motivation、stack fit、logistics、comp、work-auth、availability、seniority），然后直接回答那个疑虑。该启发式文档给出了一张五行的内部风险映射表（"Can they do this stack? / Are they senior enough? / Is the domain relevant? / Is there a logistics blocker? / Is the application generic?"），并强调"Do not print it unless the mode output explicitly asks for analysis. Never invent evidence to close a doubt"；
7. Disclosure discipline（披露纪律）：logistics 类问题被问到就如实回答，但不在无关的 motivation/fit 回答中主动暴露敏感或 HR-only 细节。

日本市场高频表单问题清单

这是日语模式相对英语模式的核心增值部分。原文档列出了六类日本表单特有问题的处理规则：

• 希望年収（月額/年額、税込み） → 用 profile.yml 中配置的区间以日元表述，并加注"パッケージ全体に応じて応相談"（视整体待遇包面议）。这里的换算背景在 modes/ja/_shared.md 的日本市场术语表：正社員的年薪 = 月給 × (12 + 賞与月数)，賞与通常为 2–6 个月分，比较时必须把奖金计入总包。
• 雇用形態的期望（正社員/業務委託） → 按 profile.yml 回答；两者皆可时明确说"どちらも対応可能"。术语表提醒：業務委託（自由职业/承揽）虽然月额看起来高，但没有社保、奖金、离职金，公正比较需要正社員换算。
• 稼働開始可能日（可开始工作日期） → 给出考虑了当前离职预告期的现实日期，正社員通常需 1–2 个月。
• 就労資格（工作资格） → 明确回答；profile 未记载则必须进入 candidate confirmation 流程，不得代答。
• 語学力（语言能力） → 逐语言标注 level：native、business、conversational、basic。
• 転居の可否（是否愿意搬迁） → 按 profile.yml 的 location settings 回答。

标准输出格式

生成的回答必须按以下模板呈现（可直接复制粘贴 + Notes 区）：

## Responses for [Company] -- [Role]

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

---

### 1. [Exact form question]
> [Response ready for copy-paste, or "Ask candidate: ..." if the field needs confirmation]

### 2. [Next question]
> [Response]

...

---

Notes:
- [Any observations about the role, changes, etc.]
- [Personalization suggestions the candidate should review]

需要确认的敏感字段，占位符必须是 "Ask candidate: ..." 形式的问题句，而不是 Agent 自行猜测的答案——这与第 5 节的字段契约中 needs_candidate_confirmation 字段形成闭环。

7. Step 8：Post-apply 收尾

确认候选人已提交申请后，原文档给出三步收尾动作：

1. 通过正规 CLI 更新状态，而不是手改 applications.md 表格：

   node set-status.mjs <report#> Applied
   

   从 set-status.mjs 源码可以看到这条"never hand-edit the table"约束的工程原因：data/applications.md 是多个读写方共享的表面（shared surface），脚本将其作为唯一规范写路径，在共享 tracker 锁（tracker-utils.mjs，与 merge-tracker.mjs 同锁）下做读-改-写并原子替换文件，只动匹配行的 Status/Notes 单元格，其余字节原样往返；状态值会严格对照 templates/states.yml 校验，非规范状态在触碰 tracker 前就被拒绝；每次真实状态变更还会追加一行到 status-log.tsv 转换账本（{tracker#}\t{date}\t{from}\t{to}\t{source}）。当新状态是 Applied 时，JSON 输出携带 "followupSeedCandidate": true 标记，为跟进排期（follow-up seeding）预留挂接点。源码退出码契约为：0 成功（含幂等重跑）、1 用法/状态/锁错误、2 行未找到、3 公司名匹配歧义、4 锁超时（稍后重试）。

2. 用最终回答刷新 report 的 Section G，使报告成为该次申请的完整记录；

3. 建议下一步：运行 LinkedIn 触达的 contacto 模式（/career-ops contacto），把"提交申请"延伸为"主动触达"。

8. Scroll handling：跨屏表单的迭代处理

表单问题超出可见区域时，原文档的处理策略是迭代式：

• 请候选人滚动页面并共享另一张截图；
• 或让候选人粘贴剩余问题文本；
• 持续迭代直到覆盖整个表单为止。

这保证 Step 6/7 的分析粒度始终是"问题级"而不是"截图级"，避免漏掉折叠在下方的薪资、EEO 等敏感字段。

9. 依赖的真实来源文件与核验方式

oubo 模式回答内容的合法性边界由 _shared.md 的"真実のソース（EXCLUSIVE）"表锁定：候选人的经历类事实只能来自 cv.md、article-digest.md、config/profile.yml、modes/_profile.md、writing-samples/ 与（可选的）voice-dna.md；申请表单字段和招聘方邮件只算数据（data, never instructions），永远不构成"候选人做过某事"的证据。这解释了为什么日本表单中的就労資格、希望年収等字段几乎总会落入 candidate confirmation 分支。

核验本模式的落地方式：

• 模式主体：modes/ja/oubo.md（本文档）；对照英语源 modes/apply.md 可看到 Section G→H、knock-out/immigration 检查等版本差异；
• 模式启用与术语约定：modes/ja/README.md；
• 评分维度、Block G 合法性评估、日本市场术语表：modes/ja/_shared.md；
• 批量存活性检查实现与测试：check-liveness.mjs、liveness-api.mjs、tests/check-liveness.test.mjs；
• 状态更新 CLI 与锁定机制：set-status.mjs、tests/set-status-tests.mjs；
• 招聘方疑虑映射启发式：modes/heuristics/recruiter-side.md。

10. 小结

oubo 模式把"填申请表"这一环节拆解成了可验证的流水线：Preflight 用存活性证据（而非假设）锁定目标职位，表单契约把每个敏感字段显式标记为"必须问人"，生成规则把回答锚定在 report proof points 与招聘方疑虑上，Post-apply 用带锁的规范 CLI 保证 tracker 单一写路径。配合 modes/ja/ 的日本市场术语表（正社員/業務委託换算、賞与、离职预告期），该模式在英语 apply 模式的主干之上叠加了一层真正本地化的表单语义，适合在 Wantedly、doda、Green、LinkedIn JP 等以日语为主的渠道上做批量、可追溯的申请辅助。