career-ops 的 takdeem 模式：在浏览器表单前为每道求职问题生成可粘贴答案的阿语实时助理

career-ops 是一个本地运行的开源 AI 求职系统：扫描职位门户、把岗位评估成 A–H 结构化报告（含 1–5 分全局评分）、定制简历并跟踪申请进度。modes/ar/takdeem.md 是其阿拉伯语模式集中的「即时申请助理」——当候选人正对着浏览器里的申请表单发愁时，该模式读取屏幕上的内容、载入该职位此前的评估报告，然后为表单里的每一道问题生成个性化、可直接复制粘贴的阿语答案。读完本篇，你将理解这个模式的完整八步工作流、每一步背后的仓库支撑（报告区块 H、set-status.mjs 状态机、followup-seed.mjs 跟进排程），以及它如何与阿语模式目录 modes/ar/ 的其余文件协同工作。

什么是 takdeem，它属于哪个模式集

takdeem.md（阿拉伯语「تقديم」，意为"提交/申请"）是一个交互式模式文件：它不是一段可执行的代码，而是写给 AI 编码 CLI（Claude Code、Codex、OpenCode 等）的"操作剧本"，在候选人边填表边与 Agent 对话时被加载执行。

根据 modes/ar/README.md 的模式对照表，takdeem.md 是英文原版 modes/apply.md（Live Application Assistant）的阿拉伯语本地化版本：

文件	翻译自	职责
modes/ar/_shared.md	modes/_shared.md (EN)	共享上下文、职能原型（Archetypes）、通用规则、阿语法律术语
modes/ar/fursah.md	modes/oferta.md (ES)	对岗位公告的 A–G 全面深度评估
modes/ar/takdeem.md	modes/apply.md (EN)	填写求职表单时的即时应答助理
modes/ar/pipeline.md	modes/pipeline.md (ES)	批量处理候选链接队列

阿语模式集的启用方式有两种：会话中临时告知 Agent「使用 modes/ar/ 的模式」，或在 config/profile.yml 中持久化配置 language.modes_dir: modes/ar（注意 profile.example.yml 中的注释：modes_dir 选择的是市场词汇域，与 language.output 等人类可读输出语言相互独立）。其余以命令行工具为主的模式文件保持英文，因为它们依赖与语言无关的脚本调用。

前置条件：Playwright 可见模式 vs 截图回退

takdeem.md 明确了两档运行前提：

• 首选：Playwright 可见模式（Visible Mode）——候选人能亲眼看到浏览器窗口，Agent 可以直接与页面交互、读取页面内容；
• 无 Playwright 时：候选人分享表单截图（Agent 可从图像中读取文字），或手动把问题复制粘贴进对话。

这一点与英文版 apply.md 的 Step 1 完全一致：有 Playwright 时对活动页面做快照（标题、URL、可见内容）；没有则请候选人三选一——分享截图（Read 工具可识图）、粘贴问题文本、或口述公司+职位名让系统去查历史报告。

核心工作流：八步交互路径

takdeem.md 定义了模式的完整执行序列，这是理解整个模式的骨架：

1. 检测 (DETECT)     ← 读取浏览器活动标签页（截图/链接/标题）
2. 识别 (IDENTIFY)   ← 从页面提取公司名和职位名称
3. 搜索 (SEARCH)     ← 与 reports/ 目录中的既有报告做匹配
4. 载入 (LOAD)       ← 读取完整报告，并回顾 H 区块（申请答案草稿）
5. 比对 (COMPARE)   ← 校验屏幕上的职位与之前评估过的职位是否一致
6. 分析 (ANALYZE)    ← 识别表单中所有可见问题
7. 生成 (GENERATE)   ← 基于简历和报告为每个问题撰写个性化、有说服力的答案
8. 呈现 (PRESENT)    ← 以格式化输出供候选人直接复制粘贴

英文版 apply.md 的对应工作流额外包含 PREFLIGHT 活性校验（黑名单检查、跨渠道重复申请检查、ATS 重复申请提醒）与 PERSIST（把最终答案写回报告）两个环节，并内置了 Ashby/Lever/Workable/Workday 等 ATS 的实战怪癖处理；阿语版保留了核心八步主线，把防御性门控简化为「比对+生成」两步。下面按 takdeem.md 自身的步骤展开。

步骤 1 — 检测职位与表单（Detect the job）

使用 Playwright 时：对活动标签页截屏，自动读取标题、URL 和页面文本。

无 Playwright 时，要求候选人提供以下之一：

• 表单截图（Agent 可从图片中提取文字）；
• 把表单问题作为纯文本粘贴进对话；
• 报出公司名和职位名，让系统去历史报告中检索。

这一步的关键在于"信息源降级链"：完整的浏览器 DOM > 图像 OCR > 手动文本 > 关键词检索，保证模式在无浏览器自动化的最简环境下依然可用。

步骤 2 — 识别机会并唤起上下文（Identify and search）

这是模式中最体现 career-ops 架构设计的环节——表单填写永远不凭空发生，而是站在既有评估报告之上：

1. 从页面精确提取公司名与职位名；
2. 在 reports/ 目录中按公司名做大小写不敏感的 grep 搜索（报告命名遵循 reports/{###}-{company-slug}-{YYYY-MM-DD}.md 约定，由 modes/ar/fursah.md 定义）；
3. 命中后完整加载该报告；
4. 若报告含 H 区块 —— Draft Application Answers（申请答案草稿，在 fursah.md 的评估后流程中生成，且仅在匹配评分 ≥ 4.5 时写入），则把这些既有草稿作为"坚实底座"加载；
5. 若没有任何匹配报告，提醒候选人，并建议先对该职位运行一次自动评估流水线（Auto-Pipeline，见 modes/auto-pipeline.md）再生成答案。

H 区块是评估阶段（fursah.md）与申请阶段（takdeem.md）之间的数据契约：评估报告在 ## H) Draft Application Answers 下预先草拟答案，本模式则在其上精修。英文版还额外提供 application-answers.mjs 严格读取器（--read --strict 读取 ## Application Answers、--read-draft 读取 H 区块），避免把已提交答案当散文误读——仓库中 application-answers.mjs 与 tests/application-answers-block-h.test.mjs 验证了这套读取逻辑。

步骤 3 — 检测岗位要求变更（Detect changes）

当屏幕上展示的岗位要求与此前存入报告的评估不一致时，模式要求立即中断并询问候选人，给出两条路径：

"职位名称或机会细节已从 [X] 变为 [Y]。您希望我完全重新评估该职位，还是直接把答案适配到新称呼？"

• 适配（Adapt）：仅调整答案措辞以匹配新称呼与新要求，不重写整份报告；
• 重新评估（Re-evaluate）：执行完整的 A–G 评估（对应 fursah.md 的七个区块），更新报告并重新生成全套答案草稿；
• 更新跟踪表：必要时在 applications.md 中更新职位名称与状态。

这条"变更感知"逻辑保证了报告上下文与实际表单的一致性，是从源码结构看整个 career-ops「报告即单一事实来源」理念的典型体现。

步骤 4 — 分析申请表单问题（Analyze form questions）

模式要求先盘点并分类表单中所有可见输入面，再决定每个问题的答案来源：

表单元素类型	典型例子
自由文本字段	求职信、"为什么想加入我们？"、"介绍一个代表性项目"
下拉列表	"如何得知我们的？"、工作许可
二元是/否问题	是否接受 relocation、是否需要签证担保
薪资与财务预期字段	薪资下限、总期望薪资
文件上传字段	定制简历、PDF 版求职信

随后把每个问题二分为：

• H 区块草稿已覆盖的问题 → 复用既有措辞并针对当前表单字段打磨；
• 全新的问题 → 立即基于完整评估报告 + 候选人简历文件 cv.md 生成专业、有说服力的答案。

英文版 apply.md 在此步骤还定义了严格的字段契约（field_type、required、limit、options、needs_candidate_confirmation），并规定法律、人口统计、工作许可、签证、薪资等敏感字段绝不虚构答案，若 config/profile.yml 中无记录则标记为"需候选人确认"。这一"prepare-don't-submit"纪律同样源自 modes/ar/_shared.md 的通用规则：系统永不代候选人提交，永远只做准备。

步骤 5 — 生成与措辞答案（Generate responses）

takdeem.md 为答案生成规定了四条质量标准：

1. 依托上下文与报告：使用评估中提炼的强证据点（B 区块——匹配分析）与按 STAR 结构记录的面谈故事（F 区块——面试计划）；
2. 善用既有草稿：若 H 区块存在预置草稿，以其为起点打磨润色，而非从零撰写；
3. 专业、自信、直接的语气：摒弃空洞的公司黑话与冗长套话，聚焦"为何偏偏是这家公司"，并基于精确信息表达加入意愿；
4. 嵌入 JD 具体细节：答案中须指向屏幕上这份岗位公告明确写出的技术栈或真实职责。

生成结果必须采用如下固定版式呈现（此版式直接继承自原文档）：

## 建议答案 — 申请表：[公司] — [职位]

基于：评估报告 #{###} | 综合评分：{X.X/5} | 职能原型：[检测到的原型]

---

### 1. [表单中逐字呈现的问题原文]
> [可直接复制粘贴的完整答案]

### 2. [下一个问题]
> [生成的答案]

...

---
给候选人的备注与指引：
- [关于岗位要求变化或申请条件的观察]
- [提醒候选人提交前需自行核对或补充的事项]

这种「引用报告编号 + 评分 + 原型」的头部设计，让每份答案输出都可回溯到其证据来源；而末尾的备注区则把"系统生成"与"人工负责"的边界交代清楚。

步骤 6 — 提交后动作（Post-apply）

当候选人确认已成功提交申请，模式执行三步收尾，其中每一步都有对应的仓库脚本支撑：

1. 通过官方 CLI 更新状态：node set-status.mjs <report#> Applied——文档明确禁止手工编辑 applications.md 表格。查看 set-status.mjs 的头部注释可知这是刻意的架构决策：跟踪表有多个读写者，单一规范写入路径（配合 tracker-utils.mjs 的共享锁与原子替换）比多个 Agent 各自手改 Markdown 更安全；状态还须通过 templates/states.yml 严格校验（Applied 是其中规范状态之一），且每次真实状态变更都会追加一行到 status-log.tsv 迁移台账。若提交发生在非当天，应加 --on YYYY-MM-DD 记录真实发生日期；
2. 归档最终答案：把候选人实际采用的最终回答存回报告的 H 区块，供后续面试准备时回溯"我当时是怎么回答的"；
3. 建议下一步：直接引导候选人运行 /career-ops contacto 模式（见 modes/contacto.md）——按人物画像（招聘官/用人经理/同侪/面试官）套用三句话框架，生成用于 LinkedIn 联系请求的阿语定制消息。

从源码结构看，英文版的 post-apply 还会调用 followup-seed.mjs（followup-seed.mjs）为该行写入跟进节奏（默认 cadence）的下一条跟进日期——其注释解释了动机：若标记 Applied 后不自动排程跟进，data/follow-ups.md 会长期为空，整个跟进节奏功能"生来即死"。该脚本幂等，重复运行安全，可通过 --date 传入真实提交日期。

与阿语模式集其他文件的协作关系

takdeem.md 并非孤立存在，它是 modes/ar/ 四文件协作链条上的第二环：

• 上游 fursah.md（对应英文 oferta.md）：产出 A–G 评估报告——A 角色摘要、B 简历匹配（含按六种 AI 职能原型 FDE/SA/PM/LLMOps/Agentic/Transformation 的差异化要点）、C 层级策略、D 薪酬调研、E 定制计划、F 面试计划（6–10 条 STAR+R 故事）、G 公告真实性——外加 Risk Summary 与评分 ≥ 4.5 时的 H 答案草稿。takdeem.md 的"LOAD"步骤消费的就是这份产物；
• 共享层 _shared.md：定义真相源（cv.md 永远要读、config/profile.yml 提供候选人身份与目标）、1–5 分评分体系（4.5+ 强烈建议申请、< 3.5 建议放弃）、六大阿拉伯语工作法律术语表，以及"绝不虚构、绝不代提交"的硬性规则；
• 下游 pipeline.md：批量处理 data/pipeline.md 中收藏的链接队列，其处理流程与 takdeem 的"无报告时建议先跑自动评估"互为补集；
• 收尾 contacto（保持英文原版，因以工具调用为主）：提交后的 LinkedIn 触达，完成"评估 → 填写 → 提交 → 触达"的闭环。

术语处理上，takdeem.md 遵循 modes/ar/README.md 的本地化原则：cv.md、report、score、Applied、Interview、Offer 等跟踪表状态与工具名保留英文以确保与脚本兼容，而叙述性内容使用自然的职业阿拉伯语，杜绝生硬机翻。

小结：takdeem 模式的工程要点

modes/ar/takdeem.md 的价值在于把"填写申请表"这一求职中最琐碎、最耗神的环节变成了一个有状态、有记忆、可回溯的流程：

1. 报告驱动：答案不凭空生成，而是锚定在 reports/ 中已评估的岗位报告与 H 区块草稿上，无报告则先评估——保证了上下文一致性与证据可追溯（每个输出头部都引用报告编号与评分）；
2. 变更感知：屏幕职位与报告不一致时先停下询问（适配 vs 重新评估），避免用旧上下文答新问题；
3. 字段全覆盖：自由文本、下拉、是/否、薪资、上传五类表单元素逐一分析，并按"已有草稿→复用打磨 / 全新问题→基于报告+cv.md 生成"分流；
4. 规范写入：状态变更只走 node set-status.mjs（严格状态校验、共享锁、变更台账），从不手改跟踪表；
5. 闭环衔接：提交后归档最终答案，并立即建议 contacto 模式做 LinkedIn 触达，把单次申请延长为持续跟进。

想继续深入，可从 modes/ar/README.md 了解阿语模式集的完整启用方式，从 modes/apply.md 查看英文版全部防御性门控（黑名单、跨渠道去重、ATS 怪癖），以及从 modes/auto-pipeline.md 看 takdeem 所依赖的上游自动评估流水线如何产出报告。