init
This commit is contained in:
commit
d295c7f139
1527 files changed
+270726
No files matched your search
@@ -0,0 +1,77 @@
|
||||
# career-ops — 中文模式 (`modes/zh/`)
|
||||
|
||||
此目录包含主要 career-ops 模式的中文翻译,适用于针对中国大陆市场(或使用中文职位描述)的求职者。
|
||||
|
||||
## 何时使用这些模式?
|
||||
|
||||
如果满足以下条件之一,请使用 `modes/zh/`:
|
||||
|
||||
- 你主要申请的是**中文职位描述**(如拉勾、BOSS直聘、猎聘、脉脉或公司官网中文版)。
|
||||
- 你的**简历语言**是中文,或者你需要在中英文简历之间进行切换。
|
||||
- 你需要撰写**自然的中文技术交流文本**(如求职信、LinkedIn 沟通话术等)。
|
||||
- 你需要处理**中国大陆市场特有的合同与福利条款**:五险一金、个税计算、年终奖、股票期权/RSU、试用期、竞业限制、应届生 vs 社招、996/弹性工作制、税前/税后薪资、落户政策等。
|
||||
|
||||
如果你的大部分职位描述都是英文的(即使是在中国的外企),建议保留使用 `modes/` 下的默认英文模式。
|
||||
|
||||
## 如何启用?
|
||||
|
||||
启用中文模式有两种方式:
|
||||
|
||||
### 方式 1:按会话临时启用
|
||||
|
||||
在会话开始时,明确告诉 AI 助手:
|
||||
|
||||
> "从现在开始使用 `modes/zh/` 下的中文模式。"
|
||||
|
||||
或者:
|
||||
|
||||
> "请使用 `modes/zh/_shared.md` 和 `modes/zh/oferta.md` 进行中文岗位的评估和申请。"
|
||||
|
||||
### 方式 2:在个人配置中永久设置
|
||||
|
||||
在 `config/profile.yml` 中添加语言偏好设置,例如:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: zh
|
||||
modes_dir: modes/zh
|
||||
```
|
||||
|
||||
在第一次会话时,提醒助手遵守此字段即可。
|
||||
|
||||
## 翻译了哪些文件?
|
||||
|
||||
首批翻译覆盖了四个最高频、高价值的模式:
|
||||
|
||||
| 文件名 | 基础模板 | 用途 |
|
||||
|---|---|---|
|
||||
| `_shared.md` | `modes/_shared.md` | 共享上下文、画像检测、全局规则及中国大陆市场特性 |
|
||||
| `oferta.md` | `modes/oferta.md` | 完整的职位评估(Block A-F + G 真实性评估) |
|
||||
| `apply.md` | `modes/apply.md` | 网页表单填写实时助手 |
|
||||
| `pipeline.md` | `modes/pipeline.md` | URL 收件箱 / 收集职位的第二大脑 |
|
||||
|
||||
其他工具相关的模式(如 `scan`、`batch`、`pdf`、`tracker` 等)仍将使用默认的英文版本,因为它们主要包含命令行参数、系统路径和配置指令,保持语言一致性有助于工具稳定运行。
|
||||
|
||||
## 常用词汇表
|
||||
|
||||
为保持语气的一致性,在修改或扩展模式时请遵循以下词汇对照:
|
||||
|
||||
| 英文 | 中文 (本仓库规范) | 说明 |
|
||||
|---|---|---|
|
||||
| Job posting | 职位描述 / 岗位需求 | 通常简称 JD |
|
||||
| Application | 投递 / 申请 | |
|
||||
| Cover letter | 自荐信 / 求职信 | |
|
||||
| Resume / CV | 简历 | |
|
||||
| Salary / Compensation | 薪资 / 薪酬包 / 总包 | 总包通常包含基本薪资、奖金和期权等 |
|
||||
| Interview | 面试 | |
|
||||
| Hiring manager | 业务负责人 / Hiring Manager | |
|
||||
| Recruiter | HR / 招聘人员 | |
|
||||
| AI | AI / 人工智能 | |
|
||||
| Requirements | 岗位要求 / 任职资格 | |
|
||||
| Notice period | 离职通知期 / 离职周期 | 通常为 1 个月 |
|
||||
| Probation | 试用期 | |
|
||||
| Non-compete | 竞业限制 / 竞业协议 | |
|
||||
| Social insurance | 五险一金 | 社保及住房公积金 |
|
||||
| Year-end bonus | 年终奖 | |
|
||||
| Stock options / RSU | 股票期权 / 限制性股票 | 简称期权/RSU |
|
||||
| Hukou / Talent policy | 落户指标 / 人才政策 | |
|
||||
@@ -0,0 +1,185 @@
|
||||
# 系统上下文 -- career-ops (中文版)
|
||||
|
||||
<!-- ============================================================
|
||||
此文件由系统自动更新,请勿在此处填写个人隐私数据。
|
||||
|
||||
你的个性化配置应写入 modes/_profile.md 中(绝不会被自动覆盖)。
|
||||
本文件包含系统规则、评分逻辑和工具配置,并在后续版本中持续优化。
|
||||
============================================================ -->
|
||||
|
||||
## 真实数据来源 (Sources of Truth)
|
||||
|
||||
| 文件 | 路径 | 读取时机 |
|
||||
|---|---|---|
|
||||
| 简历 | `cv.md` (项目根目录) | 始终读取 |
|
||||
| 项目/文章摘要 | `article-digest.md` (如果存在) | 始终读取 (包含详细的量化指标与项目证明) |
|
||||
| 个人偏好配置 | `config/profile.yml` | 始终读取 (候选人个人身份、目标薪资与地点偏好) |
|
||||
| 个人定制策略 | `modes/_profile.md` | 始终读取 (自定义画像偏好、求职叙事、谈判话术) |
|
||||
| 写作样本目录 | `writing-samples/` | 仅在生成候选人外发文本时 — 先检查 `_profile.md` 中缓存的 `## 写作风格`,缺失时再扫描此目录 |
|
||||
|
||||
**规则:严禁硬编码项目/文章的量化指标。** 必须在评估时从 `cv.md` 和 `article-digest.md` 中动态读取。
|
||||
**规则:对于文章和项目指标,`article-digest.md` 的优先级高于 `cv.md`。**
|
||||
**规则:始终在此文件之后读取 `_profile.md`。`_profile.md` 中的用户自定义内容将覆盖此处的默认值。**
|
||||
|
||||
---
|
||||
|
||||
## 评分系统 (Scoring System)
|
||||
|
||||
岗位评估共包含 6 个维度 (Block A-F),最终折算为 1-5 的综合评分:
|
||||
|
||||
| 维度 | 衡量内容 |
|
||||
|---|---|
|
||||
| 简历匹配度 (Match con CV) | 技能、经验与量化成果的匹配度 |
|
||||
| 职业方向契合度 (North Star alignment) | 职位与候选人在 `_profile.md` 中定义的目标角色的契合程度 |
|
||||
| 薪酬竞争力 (Comp) | 职位薪资与市场水准的对比 (5=顶尖, 1=远低于市场) |
|
||||
| 文化信号 (Cultural signals) | 公司文化、增长性、稳定性以及远程/考勤政策 |
|
||||
| 红线警告 (Red flags) | 潜在的风险点、扣分项 (负向调整) |
|
||||
| **综合评分 (Global)** | 以上维度的加权平均分 |
|
||||
|
||||
**分数解读:**
|
||||
- 4.5+ → 极佳匹配,强烈建议立即投递
|
||||
- 4.0-4.4 → 良好匹配,值得投递
|
||||
- 3.5-3.9 → 一般匹配,仅在有特殊理由时考虑投递
|
||||
- 3.5 以下 → 匹配度低,不建议投递 (参见 AGENTS.md 中的“道德使用”规范)
|
||||
|
||||
## 职位真实性评估 (Block G)
|
||||
|
||||
维度 G 用于评估招聘岗位的真实性和活跃度。它**不影响** 1-5 分的综合评分,是一项独立的定性评估。
|
||||
|
||||
**三个评级:**
|
||||
- **高置信度 (High Confidence)** -- 真实且活跃的招聘岗位 (大部分信号为积极)
|
||||
- **谨慎推进 (Proceed with Caution)** -- 存在混合信号,需要留意风险
|
||||
- **疑似虚假/已过期 (Suspicious)** -- 存在多个“幽灵职位”特征,建议候选人先进行核实
|
||||
|
||||
---
|
||||
|
||||
## 角色画像检测 (Archetype Detection)
|
||||
|
||||
将每个 JD 分类为以下一种或两种混合画像:
|
||||
|
||||
| 画像角色 | JD 关键特征信号 |
|
||||
|---|---|
|
||||
| **AI 平台 / LLMOps 工程师** | "可观测性", "评测", "流水线/pipelines", "监控", "高可用" |
|
||||
| **Agent / 自动化工程师** | "Agent/智能体", "HITL/人机协同", "编排", "工作流", "多智能体" |
|
||||
| **技术型 AI 产品经理 (PM)** | "PRD", "路线图", "需求定义/Discovery", "利益相关者", "产品经理" |
|
||||
| **AI 解决方案架构师** | "架构设计", "企业级/Enterprise", "集成/Integrations", "系统设计" |
|
||||
| **AI 前线交付工程师 (FDE)** | "交付", "客户对接", "原型开发", "快速上线", "现场支持" |
|
||||
| **AI 转型专家 / 顾问** | "变革管理", "AI 落地/Adoption", "赋能", "业务转型" |
|
||||
|
||||
检测到画像后,读取 `modes/_profile.md` 中候选人针对该画像的特定表达框架与项目佐证。
|
||||
|
||||
---
|
||||
|
||||
## 中国大陆市场 -- 特别说明(重要)
|
||||
|
||||
评估中国大陆的职位描述、薪酬或合同条款时,需要特别关注以下本土特有概念,并在评估报告中加以分析:
|
||||
|
||||
| 关键概念 | 含义及说明 | 评估影响与处理原则 |
|
||||
|---|---|---|
|
||||
| **五险一金** | 养老、医疗、失业、工伤、生育保险及住房公积金。 | 正式员工的基本社保福利。公积金比例(企业与个人最高各12%)是薪酬包的重要部分。对比自由职业/合作合同时,需扣除个人/企业缴纳部分。 |
|
||||
| **个税计算** | 中国实行 3% - 45% 的综合所得超额累进税率。 | 评估高总包 offer 时,需关注税后实际到手(Take-home pay),特别是年终奖单独计税和期权/RSU 的计税规则。 |
|
||||
| **年终奖** | 相当于 1-6 个月或更多月薪的年终奖金,与公司及个人绩效挂钩。 | 需核实是写进合同的固定发放(如16薪中的4个月年终),还是纯浮动的绩效奖金。总包计算:月薪 * (12 + 预期年终奖月数)。 |
|
||||
| **股票期权 / RSU** | 长期激励计划,通常分 4 年归属(Vesting),有 1 年的 Cliff(崖)。 | 初创公司期权需评估兑现可能性与估值;上市公司 RSU 视同现金评估,但需关注回购机制和解禁税率。 |
|
||||
| **试用期** | 通常为 1-6 个月。试用期工资不得低于正式合同约定工资的 80%。 | 评估时需确认试用期工资是否全额发放(100%),以及试用期五险一金是否足额缴纳。 |
|
||||
| **竞业限制** | 离职后不得去竞争对手公司工作,公司需按月支付补偿金(一般不低于离职前平均工资的30%)。 | 潜在红线/风险点。需评估竞业范围是否过宽、竞业期限(最长2年)以及补偿金比例是否合规合理。 |
|
||||
| **应届生 vs 社会招聘** | 应届生看重潜力和学历,有专门落户指标和校招通道;社招看重即战力和项目经验。 | 评估时必须明确岗位是校招还是社招,确保简历框架对齐。 |
|
||||
| **996 / 弹性工作制** | 996 (朝九晚九周六工作),或弹性上下班。 | 严重加班是文化信号(Cultural signals)的关键扣分项。需评估是否有加班费或调休,调休是否能落实。 |
|
||||
| **税前/税后薪资** | 招聘时通常沟通税前月薪/年薪,但求职者更关注税后实际到手。 | 评分 Comp 时,默认以税前为准进行市场竞争力对比,但必须向求职者提供税后实得预估。 |
|
||||
| **人才引进 / 落户政策** | 各地(如北京、上海、深圳)的落户政策、人才租房或税收补贴。 | 一些企业能提供落户指标或地方人才补贴,这是重要的加分项,需在文化/附加福利(Cultural signals)中体现。 |
|
||||
|
||||
---
|
||||
|
||||
## 全局规则 (Global Rules)
|
||||
|
||||
### 严禁事项 (NEVER)
|
||||
|
||||
1. 虚构候选人的工作经历或量化指标。
|
||||
2. 直接修改 `cv.md` 或项目作品库源文件。
|
||||
3. 代表候选人直接提交求职申请或点击最终发送/投递按钮。
|
||||
4. 在生成的沟通话术中直接透露电话号码等过度隐私数据。
|
||||
5. 建议候选人接受低于市场合理水平的薪资。
|
||||
6. 在没有完整读取 JD 的情况下生成简历 PDF。
|
||||
7. 使用官腔官调或空洞的公文语言(Corporate-speak)。
|
||||
8. 忽视 tracker 登记(每个评估过的职位都必须登记到 tracker 中)。
|
||||
|
||||
### 必须事项 (ALWAYS)
|
||||
|
||||
0. **自荐信 (Cover Letter):** 如果投递表单允许,始终提供一份。视觉设计与简历保持一致,将 JD 关键字/需求一一映射到简历中的量化指标,篇幅控制在 1 页以内。
|
||||
1. 在开始评估职位前,先阅读 `cv.md`、`_profile.md` 和 `article-digest.md`(如果存在)。
|
||||
2. 在每个会话的第一次评估前运行 `node cv-sync-check.mjs`。如果发现同步警告,提示候选人。
|
||||
3. 准确识别岗位角色画像,并根据 `_profile.md` 中的策略调整表达重点。
|
||||
4. 匹配岗位要求时,标明对应简历的具体行号进行印证。
|
||||
5. 使用 WebSearch 工具查询市场薪酬水准和公司背景(如裁员/冻结招聘等)。
|
||||
6. 完成评估后,及时记录到 tracker 登记簿。
|
||||
7. 生成内容与 JD 的语言保持一致(默认使用英文,中文 JD 使用中文)。
|
||||
8. 生成中文技术文本(自荐信、LinkedIn 话术等)时:使用自然地道的中文技术交流习惯。多使用短句、主动语态,避免西式生硬的被动句式。常见的通用行业术语(如 stack, pipeline, deployment, embedding)无需强行生硬汉化,保留英文即可。
|
||||
9. **向 tracker 添加新记录时必须使用 TSV 格式** -- 严禁直接编辑 `applications.md`,将 TSV 文件写入 `batch/tracker-additions/` 目录,由 `merge-tracker.mjs` 统一合并。
|
||||
10. **在每份评估报告的头部,必须包含 `**URL:**` 字段。**
|
||||
|
||||
---
|
||||
|
||||
## 写作风格校准 (Writing Style Calibration)
|
||||
|
||||
**首先检查 `_profile.md`。** 如果其中已存在 `## 写作风格` 部分,请直接套用其定义 — 无需重新扫描写作样本文件。只有当加入新样本或用户明确要求重新校准时,才需要重新读取样本。
|
||||
|
||||
**校准应用范围:** 适用于生成一切要求符合候选人口吻的外发文本(如自荐信、LinkedIn 沟通话术、表单开放性问答等)。不适用于内部评估报告(Block A-G 评分及分析)。
|
||||
|
||||
**若 `_profile.md` 中没有缓存写作风格:** 读取 `writing-samples/` 目录下的所有文件(**跳过任何名为 `README.md` 的文件**)。如果未找到写作样本,则跳过此校准,并温和提示候选人可以添加样本以帮助我们更好地模仿其人声声线。如果存在样本,提取以下风格特征,并写入到 `_profile.md` 的 `## Writing Style` 块下,供未来会话直接使用。
|
||||
|
||||
### 风格提取要素
|
||||
|
||||
**语气与寄存器 (Tone & Register)**
|
||||
- 正式 vs. 口语化
|
||||
- 自信笃定 vs. 留有余地 (关注诸如 "我以为", "或许", "有些" 等限定词)
|
||||
- 亲切热情 vs. 事务性
|
||||
- 自我推介的程度 — 是谦逊内敛,实事求是,还是高调突出成就?
|
||||
|
||||
**句子结构 (Sentence Structure)**
|
||||
- 平均句子长度 — 短小精悍还是长句嵌套?
|
||||
- 是否使用无主句或祈使句进行强调
|
||||
- 从句嵌套的复杂度
|
||||
- 句子的开头方式 — 主语开头、动词/行动开头,还是背景/语境开头?
|
||||
|
||||
**标点习惯 (Punctuation Habits)**
|
||||
- 破折号、括号还是逗号用于插入语?
|
||||
- 是否严格使用中文标点符号?
|
||||
- 省略号和叹号的出现频率?
|
||||
- 使用分号还是句号来连接关联紧密的意群
|
||||
|
||||
**词汇偏好 (Vocabulary)**
|
||||
- 技术术语的密度 — 每个段落包含多少专业行话?
|
||||
- 动词偏好 (例如“构建” vs “开发” vs “设计”)
|
||||
- 候选人习惯高频使用的词汇或短语
|
||||
- 从未在样本中出现的违和词汇 — 避免在生成文本中引入
|
||||
|
||||
**段落与逻辑排布 (Paragraph & Structure)**
|
||||
- 段落长度 — 单句成段还是多句组合的大段落?
|
||||
- 偏好列表排版还是行文叙述?
|
||||
- 观点的推进顺序 — 问题 → 解决方案,成果优先,还是时间线顺序?
|
||||
|
||||
**声音标识 (Voice Signatures)**
|
||||
- 第一人称模式 — “我领导了”, “我们构建了”, “团队……”
|
||||
- 主动语态与被动语态的比例
|
||||
|
||||
---
|
||||
|
||||
## 专业写作与 ATS 兼容性
|
||||
|
||||
这些规则适用于生成的所有外发文本:
|
||||
|
||||
### 避免陈词滥调 (Cliché)
|
||||
- “充满热情的” / “以结果为导向的” / “深厚的行业背景”
|
||||
- “赋能 / 杠杆” (直接指明使用的具体工具或行动)
|
||||
- “牵头 / 挂帅” (使用“负责”、“带领”或“主导”)
|
||||
- “在当今快速发展的世界中 / 闭环”
|
||||
|
||||
### ATS 字符兼容性
|
||||
- 避免使用非常规的 Unicode 字符(如特殊圆点或装饰性符号),生成普通的 ASCII/UTF-8 文本即可。
|
||||
|
||||
### 句式多样化
|
||||
- 列表不要以相同的动词开头。
|
||||
- 交替使用长短句,避免单调的句式重复。
|
||||
|
||||
### 细节优先于抽象
|
||||
- “将 p95 延迟从 2.1 秒降低到 380 毫秒”远好于“显著提升了系统性能”。
|
||||
- “使用 Postgres + pgvector 实现了针对 1.2 万份文档的检索”远好于“设计了高扩展的 RAG 架构”。
|
||||
@@ -0,0 +1,119 @@
|
||||
# 模式: apply — 实时表单填写助手
|
||||
|
||||
当候选人在 Chrome 浏览器中填写职位投递表单时,此实时助手能读取当前屏幕内容、调取该职位的历史评估报告,并为表单中的每一个开放性或选择性问题生成个性化的高质量回答草稿。
|
||||
|
||||
## 运行要求
|
||||
|
||||
- **首选使用 Playwright 显式模式**:在此模式下,候选人能直观看到浏览器窗口,且 AI 助手能够直接与表单页面进行元素交互和状态提取。
|
||||
- **不使用 Playwright 时**:候选人需要提供包含表单问题的截图,或者手动将表单问题复制粘贴发送给助手。
|
||||
|
||||
## 实时工作流
|
||||
|
||||
```text
|
||||
1. 捕获 (DETECT) → 读取当前 Chrome 活动标签页 (截图/URL/网页标题)
|
||||
2. 识别 (IDENTIFY) → 从页面中提取公司名称与职位名称
|
||||
3. 检索 (SEARCH) → 匹配 reports/ 目录下已保存的评估报告
|
||||
4. 载入 (LOAD) → 读取对应的评估报告及 H 部分的拟答草稿 (若存在)
|
||||
5. 校准 (COMPARE) → 比对当前屏幕上的职位是否与之前评估的职位完全一致。若有变动,进行提示
|
||||
6. 解析 (ANALYZE) → 识别出页面上所有可见的表单提问输入框
|
||||
7. 生成 (GENERATE) → 结合报告背景与简历 cv.md,为每个问题生成定制草稿
|
||||
8. 呈现 (PRESENT) → 输出可供直接复制粘贴的格式化文本
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 步骤 1 — 捕获当前职位表单
|
||||
|
||||
**使用 Playwright**:对活动页面进行快照截图,并读取网页标题、URL 以及页面主体文本。
|
||||
|
||||
**不使用 Playwright**:提示候选人执行以下操作之一:
|
||||
- 发送当前表单页面的屏幕截图(Read 工具能识别并分析图片)。
|
||||
- 手动复制表单上的问题并贴在对话框中。
|
||||
- 直接说出公司名称与职位名称,以便助手从本地历史中搜索。
|
||||
|
||||
---
|
||||
|
||||
## 步骤 2 — 检索历史报告
|
||||
|
||||
1. 提取屏幕或输入信息中的公司名称与职位名称。
|
||||
2. 在 `reports/` 目录下搜索对应的评估报告文件(执行大小写不敏感的模糊检索)。
|
||||
3. 如果匹配成功,载入完整的评估报告内容。
|
||||
4. 检查报告中是否有“维度 H (开放性问题拟答草稿)”,如果有,将其作为回答的基础模板。
|
||||
5. 如果未匹配到任何历史报告,告知候选人,并询问是否需要针对此链接快速运行一次 `auto-pipeline` 自动评估流程。
|
||||
|
||||
---
|
||||
|
||||
## 步骤 3 — 校验岗位一致性
|
||||
|
||||
如果表单上显示的职位细节(如职级、所属部门)与历史报告存在偏差:
|
||||
- **向候选人进行提示**:表现为:“检测到当前的职位已从 [X] 变为 [Y]。需要我重新为您进行一次快速评估,还是直接在当前话术基础上微调适配新职位?”
|
||||
- **若选择微调适配**:直接根据新职位名称调整生成词汇,不重新打分。
|
||||
- **若选择重新评估**:运行完整的 A-G 评估,生成新报告并覆盖旧报告。
|
||||
- **更新 Tracker**:如果需要,在 `applications.md` 中同步更新该行记录的职位名称。
|
||||
|
||||
---
|
||||
|
||||
## 步骤 4 — 分析表单问答框
|
||||
|
||||
定位并解析当前页面上所有的表单输入项:
|
||||
- 开放性问答框(如“你为什么想加入我们?”、“描述一次你解决棘手技术问题的经历”等)。
|
||||
- 下拉选择框(如求职渠道、是否需要工作签证支持等)。
|
||||
- 单选/复选框(如是否接受出差、地点偏好等)。
|
||||
- 薪资期望框(期望范围、薪酬构成)。
|
||||
- 文件上传框(上传简历 PDF、自荐信 PDF)。
|
||||
|
||||
对每个问题进行归类:
|
||||
- **已在维度 H 中有拟答** → 提取并根据当前表单的精细要求进行润色。
|
||||
- **新提问** → 根据报告背景分析、STAR故事及 `cv.md` 的量化指标现场撰写。
|
||||
|
||||
---
|
||||
|
||||
## 步骤 5 — 生成定制答案
|
||||
|
||||
在生成每个问题的回答草稿时,必须严格遵守以下原则:
|
||||
|
||||
1. **立足报告背景**:融入维度 B 的量化成果佐证与维度 F 的 STAR 面试故事。
|
||||
2. **调和声线风格**:如果 `_profile.md` 中已经配置了候选人的 `## 写作风格`,必须以候选人的口吻进行语气拟合。
|
||||
3. **“双向奔赴”的语气**:回答既表现出对该职位的浓厚兴趣,又通过具体指标展现出解决他们核心痛点的能力。
|
||||
4. **细节决定成败**:在段落中提及 JD 里提到的具体系统架构或业务模式,证明自己认真研究过该岗位。
|
||||
|
||||
**输出格式示例:**
|
||||
|
||||
```text
|
||||
## [公司名称] — [职位名称] 表单拟答草稿
|
||||
|
||||
关联报告: #NNN | 综合评分: X.X/5 | 检测画像: [类型]
|
||||
|
||||
---
|
||||
|
||||
### 问题 1: [表单上的原始问题描述]
|
||||
> [为候选人准备的无缝复制粘贴的精修中文/英文回答]
|
||||
|
||||
### 问题 2: [表单上的下一个原始问题描述]
|
||||
> [回答]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
投递建议提示:
|
||||
- [此处填入需要候选人手动确认的个人信息,例如期望薪资、最早入职时间等]
|
||||
- [提醒候选人在此处上传之前定制好的简历 PDF]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 步骤 6 — 投递后动作
|
||||
|
||||
当候选人确认已经成功点击“提交申请/投递”后,执行以下清理与建档工作:
|
||||
1. 将 `data/applications.md` 中该职位的状态从 `Evaluated` 修改更新为 `Applied`。
|
||||
2. 将最终实际提交的表单回答归档并更新至该报告的维度 H 模块中,以便后续面试对照。
|
||||
3. 推荐下一步行动:引导候选人使用 `/career-ops contacto` 指令生成 LinkedIn 招聘负责人直达勾兑话术。
|
||||
|
||||
---
|
||||
|
||||
## 长表单滚动处理
|
||||
|
||||
如果表单提问较多,单次截图无法完整覆盖:
|
||||
- 指导候选人向下滚动页面,并发送下一部分的截图或文本。
|
||||
- 采用迭代处理模式,逐屏识别并记录问答项,直至表单所有问题处理完毕。
|
||||
@@ -0,0 +1,185 @@
|
||||
# 模式: job — 完整的 A-G 维度评估
|
||||
|
||||
当候选人输入职位描述(JD文本或URL链接)时,**始终**输出以下七个维度的深度评估结果(A-F 评估 + G 真实性):
|
||||
|
||||
## 步骤 0 — 岗位画像识别
|
||||
将该职位划分为 6 种画像之一(参见 `_shared.md`)。如果是混合型,标明最接近的 2 种。这决定了:
|
||||
- 在维度 B 中优先匹配哪些量化佐证(Proof points)。
|
||||
- 在维度 E 中如何改写简历的专业总结。
|
||||
- 在维度 F 中优先准备哪些 STAR 故事。
|
||||
|
||||
---
|
||||
|
||||
## 维度 A — 岗位概览 (Role Summary)
|
||||
输出包含以下信息的表格:
|
||||
- 检测到的角色画像 (Archetype detected)
|
||||
- 技术领域 (Domain - 平台/Agentic/LLMOps/机器学习/企业级等)
|
||||
- 岗位职能 (Function - 架构/研发/管理/交付/转型等)
|
||||
- 资深程度 (Seniority)
|
||||
- 工作模式 (Remote - 全远程/混合/现场)
|
||||
- 团队规模 (Team size - 若JD中提及)
|
||||
- 一句话总结 (TL;DR)
|
||||
|
||||
---
|
||||
|
||||
## 维度 B — 简历匹配分析 (Match with CV)
|
||||
读取 `cv.md`。创建一个对照表格,将 JD 中的各项硬性/软性要求一一映射到简历中的具体行号和量化表述上。
|
||||
|
||||
**针对不同岗位画像的分析侧重点:**
|
||||
- **AI 前线交付 (FDE)** → 侧重交付速度、全栈开发及直接对接客户的成果。
|
||||
- **解决方案架构师 (SA)** → 侧重系统架构设计、复杂集成及企业级高可用。
|
||||
- **技术产品经理 (PM)** → 侧重产品需求定义 (Discovery)、路线图制定、业务指标及利益相关者沟通。
|
||||
- **LLMOps 工程师** → 侧重评测 (Evals)、可观测性、数据/训练流水线、线上稳定性。
|
||||
- **Agent 编排 (Agentic)** → 侧重多智能体编排、人机协同 (HITL)、高容错和智能体工程。
|
||||
- **AI 转型专家 (Transformation)** → 侧重变革管理、AI 工具在组织内的推行、团队赋能与业务重塑。
|
||||
|
||||
**能力差距 (Gaps) 与弥补策略:**
|
||||
针对识别出的每一项能力差距,提供以下应对方案:
|
||||
1. 这是一项硬性门槛(Blocker)还是加分项(Nice-to-have)?
|
||||
2. 候选人是否有其他相近或可迁移的经验来作等价替换?
|
||||
3. 是否可以通过一个快速的项目作品或文章来填补此空白?
|
||||
4. 具体的弥补行动指南(如在自荐信中如何避重就轻、准备怎样的话术)。
|
||||
|
||||
---
|
||||
|
||||
## 维度 C — 级别判断与求职策略 (Level and Strategy)
|
||||
1. **JD 所对应的实际职级** vs **候选人针对该画像的自然职级**。
|
||||
2. **“包装资深度(实事求是)”计划**:提供针对该画像的特定自荐话术,突出体现资深度的具体成就,以及如何将创业/自由职业经历转化为竞争优势。
|
||||
3. **“如果对方给的级别偏低”预案**:如果综合包合理是否接受、是否在合同中约定 6 个月后重新评估职级、以及明确的晋升标准。
|
||||
|
||||
---
|
||||
|
||||
## 维度 D — 薪酬竞争力与市场需求 (Comp and Demand)
|
||||
使用 WebSearch 工具查询:
|
||||
- 该职位的当前市场薪酬范围(可参考拉勾、猎聘、脉脉、Glassdoor、Levels.fyi、Blind 等)。
|
||||
- 该公司在行业内的薪酬声誉(如公积金是否全额、是否有避税风险、年终奖兑现率等)。
|
||||
- 该职位的市场需求趋势(是急招岗位还是常态化挂靠储备)。
|
||||
|
||||
以表格形式展示查询数据并标明信息源。如果没有查到可靠数据,如实说明,切勿捏造。
|
||||
|
||||
---
|
||||
|
||||
## 维度 E — 针对性定制方案 (Customization Plan)
|
||||
创建一个表格,列出为最大化匹配度而建议对简历和 LinkedIn 页面进行的 Top 5 修改方案:
|
||||
|
||||
| # | 简历模块 | 当前描述 | 建议修改为 | 修改原因 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 专业总结 | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
---
|
||||
|
||||
## 维度 F — 面试备考计划 (Interview Plan)
|
||||
根据 JD 的具体要求,从候选人的工作经验中筛选并重新包装 6-10 个 STAR+R 故事(STAR + **Reflection/反思**):
|
||||
|
||||
| # | 对应 JD 需求 | 故事名称 | 情境 (S) | 任务 (T) | 行动 (A) | 结果 (R) | 反思与总结 (Reflection) |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
|
||||
在**反思**列中,务必提炼出学到的核心教训或如果重新来过会如何改进。这对于体现资深度至关重要——初级候选人只描述过程,资深候选人能提炼方法论。
|
||||
|
||||
**故事库同步:** 如果存在 `interview-prep/story-bank.md`,检查这些故事是否已在故事库中。如果不存在,将其追加进去,以便随着评估逐渐建立一个可随时调用的“黄金面试故事库”。
|
||||
|
||||
**根据画像进行故事包装:**
|
||||
- **FDE** → 强调极限交付时间、应对客户紧急多变的需求。
|
||||
- **SA** → 强调架构权衡、技术栈选型背后的逻辑。
|
||||
- **PM** → 强调指标驱动、产品权衡(Trade-offs)与业务增长。
|
||||
- **LLMOps** → 强调指标优化、评测体系的建立、大模型线上成本控制。
|
||||
- **Agentic** → 强调智能体幻觉控制、编排系统稳定性设计、人机协同的设计。
|
||||
- **Transformation** → 强调组织落地率、人员接受度、流程改造效率。
|
||||
|
||||
同时包含:
|
||||
- **核心项目演示推荐**:推荐候选人在面试中演示哪个特定作品,以及演示的侧重点。
|
||||
- **防防线陷阱问答**:针对 JD 潜在的痛点或候选人简历中的弱点(例如“为什么离职”、“如何看待加班工作制”),设计高情商的拟答。
|
||||
|
||||
---
|
||||
|
||||
## 维度 G — 职位真实性评估 (Posting Legitimacy)
|
||||
深入分析职位的发布状态与外围信号,判断其是否为活跃招聘职位,帮助求职者避开只挂不招的“幽灵职位”或收集简历的虚假通道。
|
||||
|
||||
**中国大陆市场特有信号分析:**
|
||||
1. **发布时间与更新频率** (通过 Playwright 网页快照或 WebSearch 辅助):
|
||||
- BOSS直聘等平台的“活跃/今日活跃/刚刚在线”状态。
|
||||
- 职位首次发布日期及最近一次刷新日期(挂靠超过3个月且频繁刷新的岗位需警惕)。
|
||||
2. **职位描述的具体与详实度**:
|
||||
- 岗位职责是否具体(是否提到了公司具体的业务线或产品细节)。
|
||||
- 任职资格是否写实(如“精通 langchain”与“10年以上大模型经验”这种不切实际要求的矛盾点)。
|
||||
- 薪资范围的张力(如“15k - 45k”这种跨度过大的薪酬区间,通常预示着实际给薪会偏低,或者岗位只是虚挂)。
|
||||
3. **外围招聘信号** (通过 2-3 个 WebSearch 查询):
|
||||
- 查询 `"{公司名称}" 裁员 2026` 或 `"{公司名称}" 劳动纠纷`。
|
||||
- 查询该公司的近期融资状态或经营危机报道。
|
||||
- 若近期发生大规模裁员,评估该岗位所属部门是否受到波及。
|
||||
4. **历史重合度检测** (通过 `scan-history.tsv`):
|
||||
- 检查该公司是否在过去 90 天内重复挂牌相同职能但不同链接的岗位。
|
||||
|
||||
### 输出评级:
|
||||
- **高置信度 (High Confidence)** -- 多个信号印证岗位确实处于紧缺且活跃的招聘状态。
|
||||
- **谨慎推进 (Proceed with Caution)** -- 存在部分混合信号(如公司刚裁员但该业务线为新设立的增长点),建议投递前通过人脉确认。
|
||||
- **疑似虚假/已过期 (Suspicious)** -- 存在大量幽灵岗位指标,建议不要盲目花费大量时间定制简历。
|
||||
|
||||
---
|
||||
|
||||
## 评估后处理流程 (Post-evaluation)
|
||||
|
||||
**在生成 Block A-G 的评估结果后,必须无条件执行以下两个步骤:**
|
||||
|
||||
### 1. 保存报告 markdown 文件
|
||||
将完整的评估内容保存到本地路径 `reports/{###}-{company-slug}-{YYYY-MM-DD}.md` 中。
|
||||
|
||||
- `{###}` = 顺序递增的 3 位数字(如 001, 002)
|
||||
- `{company-slug}` = 公司英文或拼音缩写,全小写,空格用连字符 `-` 代替
|
||||
- `{YYYY-MM-DD}` = 评估当天的日期
|
||||
|
||||
**报告文件格式模板:**
|
||||
|
||||
```markdown
|
||||
# 评估报告: {公司名称} — {职位名称}
|
||||
|
||||
**Date:** {YYYY-MM-DD}
|
||||
**URL:** {职位原链接}
|
||||
**Archetype:** {检测到的画像分类}
|
||||
**Score:** {X/5}
|
||||
**Legitimacy:** {高置信度 | 谨慎推进 | 疑似虚假}
|
||||
**PDF:** {CV生成状态,如 ❌ 或 ✅}
|
||||
|
||||
---
|
||||
|
||||
## A) 岗位概览
|
||||
(此处填入维度 A 表格与TL;DR)
|
||||
|
||||
## B) 简历匹配分析
|
||||
(此处填入维度 B 对照表及能力差距弥补策略)
|
||||
|
||||
## C) 级别判断与求职策略
|
||||
(此处填入维度 C 的分析与话术)
|
||||
|
||||
## D) 薪酬竞争力与市场需求
|
||||
(此处填入维度 D 的薪资数据及参考源)
|
||||
|
||||
## E) 针对性定制方案
|
||||
(此处填入维度 E 的简历修改表格)
|
||||
|
||||
## F) 面试备考计划
|
||||
(此处填入维度 F 的 STAR 故事表及防线问答)
|
||||
|
||||
## G) 职位真实性评估
|
||||
(此处填入维度 G 的详细信号分析)
|
||||
|
||||
## H) 开放性问题拟答草稿
|
||||
(仅在综合评分 >= 4.5 且申请表单有问答框时生成)
|
||||
|
||||
---
|
||||
|
||||
## ATS 关键词提取
|
||||
(列出 15-20 个从该 JD 中提取的高频核心技术/业务关键词,用于简历优化)
|
||||
```
|
||||
|
||||
### 2. 登记到 Tracker 记录簿
|
||||
在 `data/applications.md` 的末尾追加此条记录:
|
||||
- 顺序 ID 编号
|
||||
- 日期
|
||||
- 公司名称
|
||||
- 职位名称
|
||||
- 评分(如 4.2/5)
|
||||
- 状态(无脑填写为 `Evaluated`)
|
||||
- PDF 状态(默认为 ❌)
|
||||
- 报告链接:根目录相对路径 `[###](reports/###-company-YYYY-MM-DD.md)`(注意:合并脚本会将其自动格式化)
|
||||
@@ -0,0 +1,64 @@
|
||||
# 模式: pipeline — 待处理 URL 收件箱 (第二大脑)
|
||||
|
||||
用于批量处理记录在 `data/pipeline.md` 中的职位 URL 链接。候选人可以随时向待处理列表中追加抓取的岗位链接,然后运行 `/career-ops pipeline` 一键自动化评估所有待投递机会。
|
||||
|
||||
## 实时工作流
|
||||
|
||||
1. **读取数据**:分析 `data/pipeline.md` 文件,找出 "Pending" 模块下所有标记为 `- [ ]` 的待处理项目。
|
||||
2. **循环遍历处理**:对每一个未处理的 URL:
|
||||
a. **计算新报告编号**:扫描 `reports/` 目录,找出当前最大的三位数字前缀并加 1,作为 `REPORT_NUM`。
|
||||
b. **抓取职位描述 (JD)**:首选 Playwright (通过 `browser_navigate` + `browser_snapshot`) 渲染网页抓取,备选 `WebFetch` 提取静态文本,最后使用 `WebSearch` 搜索同名岗位快照。
|
||||
c. **异常处理**:若链接因权限、失效等原因完全无法打开,将该项标记为 `- [!]`,附加错误描述,并继续处理下一个。
|
||||
d. **执行一键管道评估**:运行 A-F 维度评估 → 保存为报告 `.md` 文件 → 根据设定生成简历 PDF(若评分达到阈值)→ 自动记录至 tracker。
|
||||
e. **将记录从“待处理”移入“已处理”**:更新状态为 `- [x] #NNN | 职位链接 | 公司名称 | 职位名称 | 评分/5 | PDF 状态`。
|
||||
|
||||
**关于自动生成 PDF 的分流控制 (Configurable):**
|
||||
系统将读取个人配置 `config/profile.yml` 中的 `auto_pdf_score_threshold`(自动生成 PDF 评分阈值)。如果该配置项不存在,则默认阈值为 `3.0`。
|
||||
如果本次岗位的评估得分低于该阈值,系统将**跳过**简历 PDF 的生成步骤(照常撰写评估报告,并在报告头部标明 `**PDF:** not generated — run /career-ops pdf {company-slug} to create on demand`,同时在 tracker 的 PDF 列登记为 ❌)。
|
||||
如果评分等于或高于该阈值,则照常自动生成量身定制的简历 PDF。
|
||||
|
||||
*注:此机制可以大幅节省批量扫描时的 Playwright 渲染排版开销(每次渲染需要 30-60 秒)。候选人可在后续通过执行命令单独生成心仪岗位的 PDF。*
|
||||
3. **并发加速**:如果待处理的 URL 达到 3 个及以上,建议以并发方式(在后台启动子 Agent)并行执行评估,以实现最大处理效率。
|
||||
4. **输出批处理总结**:处理完毕后,输出一份汇总清单表格:
|
||||
|
||||
```text
|
||||
| 编号 | 公司名称 | 岗位名称 | 综合评分 | PDF 状态 | 投递建议 |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## `pipeline.md` 语法规范
|
||||
|
||||
```markdown
|
||||
## Pending
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | 某某科技 | 资深 AI 产品经理
|
||||
- [!] https://private.url/job — 错误:需要登录后查看
|
||||
|
||||
## Processed
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | 极客科技 | AI 研发工程师 | 4.2/5 | PDF ✅
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | 某大厂 | 解决方案架构师 | 2.1/5 | PDF ❌
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 智能解析 URL 职位描述
|
||||
|
||||
1. **Playwright (首选)**:`browser_navigate` + `browser_snapshot`。能够稳定处理所有单页面应用 (SPA)。
|
||||
2. **WebFetch (备选)**:适用于静态页面,或在 Playwright 环境不可用时作为后备。
|
||||
3. **WebSearch (最终手段)**:在第三方招聘聚合平台上查找同名职位的快照。
|
||||
|
||||
**特殊情况处理:**
|
||||
- **LinkedIn**:可能会触发强登录校验拦截。若多次失败,标记为 `[!]` 并引导候选人直接粘贴 JD 文本。
|
||||
- **PDF 文件**:如果 URL 链接直接指向一份 PDF 文档,使用 Read 工具读取二进制文档。
|
||||
- **本地文件前缀 `local:`**:如果是本地路径,直接读取对应文件。例如:`local:jds/linkedin-pm-ai.md` 指向读取本地的 `jds/linkedin-pm-ai.md` 文件。
|
||||
|
||||
---
|
||||
|
||||
## 数据一致性校验
|
||||
|
||||
在启动处理之前,先执行以下脚本检查简历与配置的同步状态:
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
如果检测到简历或个人偏好数据存在脱节风险,在继续执行前向求职者发出警示。
|
||||
Reference in new issue
Block a user