career-ops 印地语模式（modes/hi）：面向印度求职市场本地化的评估、申请与谈判指令集

modes/hi/ 是开源项目 career-ops 针对印度求职者与印地语/印度招聘平台场景提供的一套完整本地化「模式」（modes）目录。它以自然、地道的印地语技术表达（Hinglish）重写了角色评估、简历匹配、申请表实时应答与求职管道管理四类核心指令，并内置 CTC 与 In-hand 工资换算、PF/EPF、Gratuity、Notice Period buyout、Bond 条款、ESOPs、HRA/LTA 等印度特有的薪酬合同知识。读完本文，你将掌握这套目录何时启用、如何通过会话指令或 config/profile.yml 永久开启、各翻译文件对应的工作流，以及如何在此基础上按词汇表继续自定义扩展。

什么是语言模式（Language Modes），modes/hi 位于体系中的位置

career-ops 的默认模式存放在仓库根目录的 modes/（英语），而市场化的模式集则按市场分目录存放。根据 AGENTS.md 中 "Language Modes" 一节的说明，每个市场模式集都固定包含四类文件：一份 _shared.md（共享上下文）、一个评估模式、一个申请模式，以及一份 pipeline.md，用于向 Agent 注入该市场特有的本地词汇与本地化评估规则。表中对印地语市场（India）的登记为：

市场	目录	评估 / 申请	本地词汇（示例）
Hindi (India)	modes/hi/	naukri / aavedan	CTC vs. in-hand, PF/EPF, Notice period/buyout, ESOPs

也就是说，modes/hi/ 不是一套独立运行的新程序，而是让同一个「扫描职位 → A-F 块结构化评估 → 定制简历 → 跟踪申请」流水线，在印度市场语境下用印地语自然语言输出的指令集。其余功能命令（扫描、PDF 生成、tracker 管理、批处理）本身是语言无关的，仍由仓库根目录的 Node.js 工具（如 generate-pdf.mjs、scan.mjs、merge-tracker.mjs）提供支撑。

何时启用 modes/hi

modes/hi/README.md 明确给出了启用条件——只要满足以下任意一条，就应当切换到印地语模式：

• 你主要针对印地语或印度本地的职位列表投递，例如 Naukri.com、Instahyre、Cutshort、Wellfound India、LinkedIn India 上的职位；
• 你的 CV 是印地语的，或你会根据 offer 在 Hindi/English 之间切换；
• 你需要自然的印地语技术表达生成回复与求职信——而非生硬的机器翻译；
• 你需要处理印度特有的合同条款：CTC 与 In-hand 工资、PF/EPF、Gratuity、Notice period/buyout、Bond 条款、ESOPs、HRA/LTA 等。

反过来，如果你的绝大多数职位列表是英语的，那么继续使用默认的 modes/ 英语模式即可。这与 AGENTS.md 中「When NOT to switch market modes」的规则一致：即使对方是印度公司，只要职位是英语的，默认仍走英语市场模式——除非你在会话中显式要求切换，或已在 config/profile.yml 中设置了 language.modes_dir（显式用户偏好优先于职位语言推断）。

如何启用：会话级与持久级两种方式

Option 1 — 会话级启用

在会话开始时显式告诉 Agent，例如：

"अब से modes/hi/ के हिन्दी मोड्स use करो।"（从现在开始使用 modes/hi/ 下的印地语模式。）

或更具体地：

"Evaluation और applications हिन्दी में करो — modes/hi/_shared.md और modes/hi/naukri.md use करो।"（用印地语做评估和申请——使用 modes/hi/_shared.md 和 modes/hi/naukri.md。）

此后 Agent 会改读该目录下的文件，而不是默认的 modes/。

Option 2 — 通过 profile 永久启用

在个人配置文件 config/profile.yml 中添加语言偏好。该字段是约定而非强制 schema，示例模板中的 language: 区块同时展示了两条正交的轴：

language:
  primary: hi
  modes_dir: modes/hi

注意：config/profile.yml 中还存在另一组语义。参考 config/profile.example.yml 与 AGENTS.md：

• language.output 控制面向人的正文语言（报告、tracker 备注、PDF、求职信、外联消息、表单答案等所有用户可见 prose），缺省为 en；
• language.modes_dir 控制市场词汇与本地评估规则（例如 modes/de 注入 DACH 市场概念）。

组合规则是：language.output 对正文拥有最终权威，modes_dir 只提供市场上下文——「英语正文 + DACH 词汇」「法语正文 + 日本市场词汇」等任意组合都是合法的。因此一份更贴近仓库实际配置的示例更常写作：

language:
  output: hi      # 面向用户的报告/求职信等正文语言
  modes_dir: modes/hi   # 印地语市场词汇与本地评估规则

设置完成后，在首次会话中提醒 Agent 查看该设置（"profile.yml में देखो, मैंने language.modes_dir set किया है"——请看 profile.yml，我已设置 language.modes_dir），之后 Agent 会自动使用印地语模式。

从源码层面看，modes_dir 会被运行时的评估入口实际读取并校验。在 gemini-eval.mjs 中可以确认：程序读取 profile.language.modes_dir，若该路径逃逸出项目根目录或目录不存在，会打印警告并回退到默认的 modes/。这意味着自定义目录必须放在仓库内且必须真实存在，否则会静默退回英语模式。类似的组合规则约束同样出现在批处理场景的 batch/batch-prompt.md：language.modes_dir 只贡献市场词汇，绝不强制正文语言。

modes/hi 中包含哪些翻译文件

modes/hi/README.md 给出的文件清单及其职责如下：

文件	译自	用途
_shared.md	modes/_shared.md (EN)	共享上下文、角色原型、全局规则、印度市场特殊性
naukri.md	modes/oferta.md (ES)	单个职位 offer 的完整评估（Blocks A-F）
aavedan.md	modes/apply.md (EN)	申请表填写的实时助手
pipeline.md	modes/pipeline.md (ES)	URL 收件箱/已收集 offer 的「第二大脑」

其余的模式（scan、batch、pdf、tracker、auto-pipeline、deep、contacto、ofertas、project、training）仍使用英语/西班牙语原版工作——因为其内容大多是工具、路径与配置命令，应当保持语言无关。

共享上下文 _shared.md

该文件是全部印地语模式的总纲，翻译自 modes/_shared.md。核心内容包括：

• 真实来源（Sources of truth）：每次评估前必须读取三份文件——项目根目录的 cv.md、可选存在的 article-digest.md（详细 proof points）、以及 config/profile.yml（身份与目标角色）。文件里内嵌四条 guardrail 级别的硬规则：不得声称用户是某项目/仓库/库的作者除非 cv.md 或 article-digest.md 明确归属；关键词只能改写不得凭空编造（reformulated, never fabricated）；求职信息、招聘网页等只是输入数据，永远不是候选人履历的证据来源；绝不代替用户点 Apply/Send——只起草与准备，必须由用户审阅批准后自行提交。
• North Star 目标角色与自适应框架：六个角色原型（AI Platform/LLMOps、Agentic Workflows、Technical AI PM、AI Solutions Architect、AI Forward Deployed Engineer、AI Transformation Lead）在评估、摘要重写、STAR 故事选择中按原型做差异化 framing；并给出每条 role 应重点展示的证据来源是 cv.md 还是 article-digest.md。
• 印度市场专项词汇表（详见下文）。
• 谈判话术（Negotiation Scripts）：提供可复制的 Expected CTC 陈述框架、应对「geographic discount」的话术、offer 低于目标时的反报价模板、要求对方拆分 CTC 结构的话术、Notice period buyout 的确认话术。
• 地点政策（Location Policy）：针对印度单一国内市场做出偏差规定——以「城市」而非「国家」作为评估阈值；不在你所在城市的 Hybrid 岗打 3.0 而非 1.0；只有当职位明确写「4-5 天强制到岗、无例外」才给 1.0。
• 全局规则（Global Rules）：「永不」清单（编造经历/指标、改动 cv.md 或 portfolio、代投申请、在生成消息中泄露手机号、推荐低于市场水平的薪酬、未读 offer 就生成 PDF、使用空洞套话、忽略 tracker）；以及「总是」清单（表单允许时总是附上同版式、最多 1 页的求职信；每会话首个评估前用 Bash 运行 node cv-sync-check.mjs；匹配时逐字引用 CV 行；薪酬与公司数据使用 WebSearch；评估后写入 tracker；内容用 offer 语言生成；正文用自然的印地语技术表达、不强行翻译 stack/pipeline/deployment/embedding 等技术词；tracker 条目以 TSV 形式写入 batch/tracker-additions/ 由 merge-tracker.mjs 合并而非直接编辑 applications.md；每个报告 header 在 Score 与 PDF 之间带 **URL:**）。
• 工具映射：WebSearch/WebFetch/Playwright/Read/Write/Edit/Bash 各自用途，其中特别警告多个 Agent 不得并行使用 Playwright，因为它们共享同一个浏览器实例。

评估模式 naukri.md

当候选人粘贴任意 offer（文本或 URL）时，必须一次交付全部 6 个 Block：

• Step 0 — 原型识别：把 offer 归入 6 个 archetype 之一（混合则标出最接近的两个），它决定 Block B 优先哪些 proof points、Block E 如何改写摘要、Block F 准备哪些 STAR 故事。
• Block A — 角色摘要：以表格呈现检测到的原型、领域、职能、资历级别、远程类型、团队规模及一句话 TL;DR。
• Block B — 与 CV 的匹配：读 cv.md，把 offer 的每条要求映射到 CV 原文行；对每个 gap 给出四问缓解策略（hard blocker 还是 nice-to-have？能否展示相邻经验？有无 portfolio 项目覆盖？具体的缓解计划）。
• Block C — 级别与策略：对比 offer 检测级别与候选人在该原型上的自然级别；「不撒谎地卖出 Senior」计划与「若被降级」计划（薪酬合理则接受、协商 6 个月 review、索要明确的晋升标准）。
• Block D — 薪酬与需求：用 WebSearch 检索该角色当前薪资（Glassdoor、AmbitionBox、Naukri、Levels.fyi、LinkedIn Salary）与公司薪酬口碑，制作带数据与来源的表格；查不到就明确说明，绝不发明数据。其中内置了 10 项「印度市场强制检查」：CTC 与 In-hand 是否都给出并协助换算、Variable pay 是否保证、ESOPs/RSUs/joining bonus 的归属时间表与流动性、PF 雇主供款占比、Gratuity 是否含 5 年归属、Bond 违约金金额与时长、Notice period 与 buyout、HRA 是否区分 metro/non-metro、医疗保险覆盖个人还是家庭、WFH/灵活办公政策。
• Block E — 个性化计划：以「序号/板块/现状/拟改/理由」表格输出对 CV 的 Top 5 改动与 LinkedIn 的 Top 5 改动。
• Block F — 面试计划：按 offer 要求映射 6-10 条 STAR+R 故事（多一个 Reflection 反思列，用于体现资历信号——初级只描述发生了什么，高级从中提炼教训）；若存在 interview-prep/story-bank.md 则先查重再入库；另含 1 个推荐的 case study 与 red-flag 问题应对（如「你没有履行 notice period？」）。
• 评估后处理：报告保存到 reports/{###}-{company-slug}-{YYYY-MM-DD}.md（编号用 node reserve-report-num.mjs 原子分配、写毕用 node reserve-report-num.mjs --release {###} 释放哨兵）；报告格式为固定模板——头部含 Date/Archetype/Score/URL/PDF，其后 A-G 七个分节，其中 Block G 只在 score ≥ 4.5 时才生成申请表草稿，文末附 15-20 个供 ATS 优化的关键词列表。随后总是向 data/applications.md 以表格（| # | Date | Company | Role | Score | Status | PDF | Report |）记录，状态为 Evaluated，Report 列写入相对链接如 001。

申请模式 aavedan.md

这是候选人正在 Chrome 中填写申请表时的交互模式：读取屏幕内容、加载既有 offer 评估上下文、为每个问题生成个性化答复。前置条件中，Playwright 可见模式为理想形态（Agent 可与页面交互）；无 Playwright 时由候选人截图或手动粘贴问题。工作流为 8 步：DETECT → IDENTIFY → SEARCH → LOAD → COMPARE → ANALYZE → GENERATE → PRESENT。关键机制：

• 从 reports/ 按公司名大小写不敏感地检索既有报告并加载 Block G 作底稿；若无匹配则提醒候选人并建议快速 auto-pipeline；
• 角色变更检测：屏幕上的职位与被评估角色不同时必须告警，并区分「仅按新头衔调整回复」与「完整重跑 A-F 评估并更新报告与 Block G」两条路径，必要时同步修正 applications.md 中的角色名；
• 表单问题分类：优先复用 Block G 已有回答，新问题则基于报告与 cv.md 现场生成；
• 输出按「问题原文 → 可直接复制粘贴的回复」组织，并附角色观察与需候选人核实的个性化建议。

该模式还内置了印度特有表单字段指导：Current CTC 报真实数字（近期加薪则报现薪+加薪）、Expected CTC 从 profile.yml 取年度 CTC 区间并附「negotiable based on overall package」、工作授权填「Indian Citizen, no visa required」、海外远程岗明确 timezone 重叠与可用性、意向城市明确列出（Bengaluru, Hyderabad, Pune, Gurugram, Chennai, Mumbai）、语言栏填 English 与 Hindi 等。提交确认后（可选）：把 applications.md 状态从 Evaluated 改为 Applied、以最终答复更新报告 Block G、建议下一步用 /career-ops contacto 对 hiring manager 做 LinkedIn 外联。表单滚动超屏时，按轮次请候选人提供更多截图或粘贴剩余问题，直至覆盖完整表单。

管道模式 pipeline.md

处理积累在 data/pipeline.md 中的 URL「收件箱」：候选人随时追加 URL，再用 /career-ops pipeline 一次性处理。流程要点：

1. 读取 data/pipeline.md 中 Pending/लंबित 分区里所有 - [ ] 项（分区头对多语言保持弹性：Pending/Pendientes/Offen/En attente/लंबित 任一写法都认，写入时沿用现有风格）；
2. 对每个待处理 URL：先用 node reserve-report-num.mjs 原子预占编号（写毕 release），再用 Playwright 抽取 offer（依次回退 WebFetch → WebSearch）；URL 不可访问则标 - [!] 后继续；可访问则跑完整 auto-pipeline：A-F 评估 → 报告 .md → score ≥ 3.0 时生成 PDF → 写入 tracker；
3. 处理完成后把条目移入 Processed/संसाधित 分区，格式化为 - [x] #NNN | URL | Company | Role | Score/5 | PDF 有/无；
4. 若积压 3+ 条 URL，用 run_in_background 并行拉起多个 Agent 提速；结束前输出汇总表（| # | Company | Role | Score | PDF | Recommended Action |）。

其中还包含 URL 智能抽取的细节：SPA 用 browser_navigate + browser_snapshot（亦可配置 scan.extractor: cli 改用 node browser-extract.mjs <url> --mode jd 以更低 token 拿到紧凑 {"url","title","text"}，工具不可用则静默回退）；LinkedIn 需登录就标 [!] 请候选人贴文本；指向 PDF 的 URL 用 Read 直接读；local: 前缀（如 local:jds/naukri-pm-ai.md）读取本地文件；Naukri.com/Instahyre/Cutshort 通常由 Playwright 处理 cookie 弹窗，LinkedIn India/Wellfound India 页面结构良好、WebFetch 往往够用。处理任何 URL 前先跑 node cv-sync-check.mjs 做源同步检查，发现不同步先告警再继续。

印度市场专项覆盖：本地化词汇的实质内容

_shared.md 对印度 offer 与谈判中特有的、英语/西语市场不存在的概念做了逐条解释并给出对评估的影响。以下要点是这套模式最核心的领域知识：

术语	含义与评估影响
CTC（Cost to Company）	雇主承担的全部成本，通常比 In-hand 高 20-40%；评估时必须同时索取 CTC 与 In-hand，切勿只按 CTC 横向比较
In-hand / Net Salary	扣除 PF、职业税、所得税后的真实到账金额，才是真正的参考数
PF / EPF	员工与雇主各按基本工资约 12% 缴入 EPFO；雇主缴款计入 CTC 但被锁定
Gratuity	依据《1972 年 Gratuity 支付法》，服务满 5 年后离职时才应得；计入 CTC 但存在 5 年兑现门槛
Notice Period	常见 30/60/90 天，IT 服务公司 90 天普遍；需确认 buyout 选项（通常为 1-3 个月薪水）
Probation	常见 3-6 个月，期间雇佣条款可能不同；超过 6 个月要标记，确认转正日是否等于调薪日
Variable Pay / Performance Bonus	固定 CTC 的 10-30%，KPI 挂钩、不保证；必须区分「多少固定 + 多少浮动」并核实浮动部分
ESOPs / RSUs	初创 ESOP 常见 4 年分批归属（1 年 cliff）；未上市 ESOP 缺乏流动性，需追问；上市公司 RSU 与 ESOP 不是一回事
HRA	按基本工资 40%（非都会）/50%（都会）计，支付房租时可免税；metro 与 non-metro 的区别重要
LTA	旅行免税项，每 4 年区块内可申报 2 次
Bond / Service Agreement	IT 服务业常见，离职时追讨培训费（通常 ₹1-3 万）；出现在资深岗位上是 red flag，必须问清金额、时长与违约金
Relieving / Experience Letter	离职时的正式文件，背景核实必需；口头确认接受 offer 后会提供
Moonlighting Policy	部分公司（尤其 Infosys、Wipro 一类）禁止双重雇佣；有自由职业要查政策
Labour Codes 2020	4 部新劳动法正在重构工资定义、工时与福利；各邦实施进度不一，可能影响 CTC 结构

配合这一知识表，文件还给出「市场薪酬智能」建议：WebSearch 取 Glassdoor、Levels.fyi、Naukri、AmbitionBox、LinkedIn Salary 的现时数据；按职位头衔而非技能定薪资带；在印度做远程岗可利用地理套利（更低生活成本 = 更优净收入）。

什么内容刻意保持英语

modes/hi/ 有意不翻译的内容遵循一条清晰边界——保留标准的行业英语技术词汇：

• cv.md、pipeline、tracker、report、score、archetype、proof point 等产品术语；
• 工具名（Playwright、WebSearch、WebFetch、Read、Write、Edit、Bash）；
• tracker 状态值（Evaluated、Applied、Interview、Offer、Rejected）；
• 代码片段、文件路径与命令。

其指导原则是使用班加罗尔、海得拉巴、浦那与古尔冈真实工程团队中实际使用的印地语技术表达：印地语散文 + 已成标准的英语技术词，而不是把「Pipeline」生硬译成「पाइपलाइन」、把「Deploy」叫成「तैनाती」。

词汇表：扩展与维护一致的语气

当你要定制或扩展这套模式时，应遵循下面的参考词汇表（词典），以保证语气前后一致。此处保留仓库原表，并补充中文释意：

English	हिन्दी（本仓库内）	中文释意
Job posting	नौकरी की पोस्टिंग / जॉब पोस्टिंग	职位发布
Application	आवेदन	申请
Cover letter	Cover letter / परिचय पत्र	求职信
Resume / CV	CV / बायोडेटा	简历
Salary	वेतन / सैलरी	薪水
Compensation	मुआवज़ा / Package	薪酬
Skills	कौशल / Skills	技能
Interview	साक्षात्कार / Interview	面试
Hiring manager	Hiring Manager	用人经理
Recruiter	Recruiter / HR	招聘人员/HR
AI	AI (Artificial Intelligence)	AI
Requirements	आवश्यकताएं	任职要求
Career history	करियर इतिहास / Work experience	职业经历
Notice period	Notice period / नोटिस अवधि	离职通知期
Probation	Probation / परिवीक्षा अवधि	试用期
Annual leave	Annual leave / वार्षिक छुट्टी	年假
Gratuity	Gratuity / ग्रेच्युटी	遣散补偿金（离职金）
Provident Fund	PF / EPF / भविष्य निधि	公积金
Cost to Company	CTC	公司总用人成本
In-hand salary	In-hand / Net salary / Take-home	到手工资
Variable pay	Variable pay / Performance bonus	浮动薪资/绩效奖金
Stock options	ESOPs / RSUs	股权激励
Bond clause	Bond / Service agreement	服务期/违约金条款
Buyout	Notice period buyout	买断通知期
Work from home	WFH / Work from home	居家办公
Remote work	Remote / दूरस्थ कार्य	远程办公
Hybrid	Hybrid	混合办公
Health insurance	Health insurance / Medical insurance	健康保险
Permanent employment	Permanent / Full-time	永久/全职雇佣
Contract employment	Contract / Contractual	合同制雇佣
Freelance	Freelance	自由职业

参与贡献的约束

如果你要改进既有翻译或新增模式，modes/hi/README.md 规定的流程是：

1. 依据 CONTRIBUTING.md 开 Issue；
2. 严格遵循上文词汇表以保持语气一致；
3. 不做逐词直译——目标是地道、自然的印地语；
4. 结构性元素（Blocks A-F、表格、代码块、工具指令）必须原样保留；
5. 提 PR 前，用一个真实的印度职位（Naukri.com、Instahyre 或 LinkedIn India）做一次端到端测试。

总结：modes/hi 的适用边界

modes/hi/ 是 career-ops 语言模式体系中针对印度市场的完整落地方案：它把「结构化评估 + 简历定制 + 申请表协助 + 管道收件箱」四大工作流全部翻译为符合印度工程团队实际表达习惯的印地语，并注入 CTC/PF/Gratuity/Notice period/Bond/ESOP/HRA 等本土薪酬合同知识。启用方式灵活（会话级或 config/profile.yml 的 language.modes_dir），且运行时入口（gemini-eval.mjs、batch/batch-prompt.md）会以「正文语言与市场词汇正交组合」的规则约束其行为。如果你的求职主战场在印度、需要地道的印地语技术表达与本地合同条款判断力，modes/hi/ 就是该场景下应优先启用的指令目录。