wehub-resource-sync
242 lines
14 KiB
Markdown
242 lines
14 KiB
Markdown
# 模式: 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 等）。
|
||
- 该公司在行业内的薪酬声誉（如公积金是否全额、是否有避税风险、年终奖兑现率等）。
|
||
- 该职位的市场需求趋势（是急招岗位还是常态化挂靠储备）。
|
||
|
||
在解释薪资数字前，必须先判断公司类型。公开薪资区间不能直接等同于合同固定 base 或稳定到手。
|
||
|
||
**公司类型分类（必填）：**
|
||
|
||
将招聘主体归入最接近的一类，并给出置信度：
|
||
|
||
| 公司类型 | 典型薪资可信度 | 识别信号 |
|
||
|---|---|---|
|
||
| 大厂 / 成熟科技公司 | 高到中 | 上市公司、职级体系清晰、工程团队规模大、招聘流程规范 |
|
||
| 成长期创业公司 / 已融资创业公司 | 中 | 有融资或收入增长，薪资可能混合 base、期权、奖金 |
|
||
| 早期初创企业 / 未盈利创业公司 | 中到低 | 团队小、岗位边界模糊、期权承诺多、薪资 band 不清晰 |
|
||
| 传统企业 / 大型集团 | 中 | HR 流程正式，固定薪资较稳定，但奖金可能浮动 |
|
||
| 外包 / 咨询 / 乙方服务商 | 中到低 | 项目制、客户派驻、billability 压力、项目奖金不稳定 |
|
||
| 本地中小企业 / 服务业公司 | 低 | 小公司、HR 不规范、常见“综合薪资”写法 |
|
||
| 销售 / 提成驱动型公司 | 低，除非 base 写清楚 | OTE、上不封顶、底薪加提成、业绩 KPI |
|
||
| 猎头 / 第三方招聘岗位 | 低到中 | 第三方发布，薪资可能是客户预算而非最终 offer |
|
||
| 政府 / 高校 / 非营利组织 | 中到高 | 薪级或等级公开，但市场竞争力可能偏低 |
|
||
| 开源社区 / 教育社区 | 中到低 | 社区型组织、协会/基金会/学校/合作方承接、实际用工主体不清 |
|
||
|
||
如果品牌方和实际招聘/签约主体不同，优先按**实际合同主体 / 用工主体**分类，再说明品牌关系。例如“Datawhale 社群”岗位如果由协会、学校、外包公司或合作方发布，应按实际招聘主体判断，而不是只按 Datawhale 品牌判断。公司类型不确定时，标记为 `Unknown`，薪资可信度默认使用保守的正式等级：`低`。
|
||
|
||
**薪资可信度（必填）：**
|
||
|
||
先检查 JD 本身是否存在薪资 / 补偿信息。若 JD 没有任何公开薪资数字，也没有“综合薪资”“底薪+提成”“含绩效”“含全勤”“最高可达”等模糊补偿表述，本节在需求趋势后只输出两行：
|
||
|
||
- **公司类型：** {类别或 `Unknown`} — {置信度 + 一个证据短语}
|
||
- **薪资可信度：** {等级} — JD 未提供薪资 / 补偿信息；跳过薪资组成拆分、详细市场数据表和 HR 核验问题
|
||
|
||
当 JD 明确写出薪资数字，或仅出现“综合薪资”“底薪+提成”“含绩效”“含全勤”“最高可达”“上不封顶”等模糊补偿表述时，进入完整薪资可信度路径，并拆分以下五项：
|
||
|
||
- **公开薪资区间：** JD 原文写出的薪资，必须逐字保留。
|
||
- **可能的合同固定 base：** 对劳动合同中固定薪资的保守估计。
|
||
- **浮动 / 条件性现金组成：** 绩效、全勤、提成、补贴、加班费、年终奖、项目奖金等现金项。
|
||
- **预计稳定现金收入：** 大概率稳定发放的现金部分。除非本地数据足够，否则默认按税前口径说明；不要把福利算入稳定现金。
|
||
- **非现金福利：** 期权、五险一金、餐补、交通、培训预算、设备等不等同于固定现金的福利。
|
||
|
||
可信度分级：
|
||
|
||
| 等级 | 含义 |
|
||
|---|---|
|
||
| 高 | 明确写为固定 base，或有公开薪级/多方一致数据支撑 |
|
||
| 中 | 区间大体可信，但薪资组成未完全拆开 |
|
||
| 低 | 公开数字很可能包含绩效、全勤、提成、补贴或“最高可达”部分 |
|
||
| Unknown | 没有可用薪资数据 |
|
||
|
||
遇到以下表达，除非固定 base 单独写清楚，否则默认按低可信处理：“综合薪资”“最高可达”“上不封顶”“底薪+提成”“包含补贴”“含绩效”“含全勤”“KPI 奖金”“13薪已包含”或跨度异常大的薪资区间。
|
||
|
||
当 JD 明确写出薪资数字，或出现模糊补偿表述时，必须给出 3-6 个 HR 核验问题，例如：
|
||
|
||
- 劳动合同上写明的固定 base 是多少？
|
||
- 公开薪资是否包含绩效、全勤、提成、补贴、加班费或年终奖？
|
||
- 试用期薪资是否打折？五险一金是否足额缴纳？
|
||
- 哪些组成是每月固定发放，哪些取决于考勤、KPI 或公司利润？
|
||
- 如果包含期权或奖金，归属周期、历史兑现率和实际预期价值是多少？
|
||
|
||
当 JD 明确写出薪资数字，或出现模糊补偿表述时，以表格形式展示查询数据并标明信息源。如果除了 JD 原文外没有查到可靠数据，如实说明，切勿捏造。
|
||
除非来源明确支持，否则不要把招聘广告薪资当作真实到手。
|
||
|
||
---
|
||
|
||
## 维度 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)`（注意：合并脚本会将其自动格式化）
|