wehub-resource-sync
218 lines
14 KiB
Markdown
218 lines
14 KiB
Markdown
# 系统上下文 -- 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)** -- 存在多个“幽灵职位”特征，建议候选人先进行核实
|
||
|
||
## 公司类型与薪资可信度
|
||
|
||
公开薪资只是招聘信号，不等于合同固定薪资或稳定到手。解释任何薪资数字前，必须先判断公司类型和实际签约主体。
|
||
|
||
**公司类型分类：**
|
||
|
||
| 公司类型 | 典型薪资可信度 | 识别信号 |
|
||
|---|---|---|
|
||
| 大厂 / 成熟科技公司 | 高到中 | 上市公司、职级体系清晰、工程团队规模大、招聘流程规范 |
|
||
| 成长期创业公司 / 已融资创业公司 | 中 | 有融资或收入增长，薪资可能混合 base、期权、奖金 |
|
||
| 早期初创企业 / 未盈利创业公司 | 中到低 | 团队小、岗位边界模糊、期权承诺多、薪资 band 不清晰 |
|
||
| 传统企业 / 大型集团 | 中 | HR 流程正式，固定薪资较稳定，但奖金可能浮动 |
|
||
| 外包 / 咨询 / 乙方服务商 | 中到低 | 项目制、客户派驻、billability 压力、项目奖金不稳定 |
|
||
| 本地中小企业 / 服务业公司 | 低 | 小公司、HR 不规范、常见“综合薪资”写法 |
|
||
| 销售 / 提成驱动型公司 | 低，除非 base 写清楚 | OTE、上不封顶、底薪加提成、业绩 KPI |
|
||
| 猎头 / 第三方招聘岗位 | 低到中 | 第三方发布，薪资可能是客户预算而非最终 offer |
|
||
| 政府 / 高校 / 非营利组织 | 中到高 | 薪级或等级公开，但市场竞争力可能偏低 |
|
||
| 开源社区 / 教育社区 | 中到低 | 社区型组织、协会/基金会/学校/合作方承接、实际用工主体不清 |
|
||
|
||
如果品牌方和实际招聘/签约主体不同，优先按**实际合同主体 / 用工主体**分类，再说明品牌关系。公司类型不确定时，标记为 `Unknown`，薪资可信度默认使用保守的正式等级：`低`。
|
||
|
||
**薪资可信度分级：**
|
||
|
||
| 等级 | 含义 |
|
||
|---|---|
|
||
| 高 | 明确写为固定 base，或有公开薪级/多方一致数据支撑 |
|
||
| 中 | 区间大体可信，但薪资组成未完全拆开 |
|
||
| 低 | 公开数字很可能包含绩效、全勤、提成、补贴或“最高可达”部分 |
|
||
| Unknown | 没有可用薪资数据 |
|
||
|
||
当 JD 明确写出薪资数字时，必须拆分：公开薪资区间、可能的合同固定 base、浮动 / 条件性现金组成、预计稳定现金收入、非现金福利。若 JD 没有写薪资数字，薪资分析压缩为两行：公司类型和薪资可信度。除非来源明确支持，否则不要把招聘广告薪资当作真实到手。
|
||
|
||
---
|
||
|
||
## 角色画像检测 (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 架构”。
|