jd-reading git:20260914.6698006A

Immutable. This exact content never changes and is served at /api/v1/blob/1d258921ad644731.

---
name: jd-reading
title: JD 拆解方法（读 JD 再定制）
description: 定制简历前先按四层拆解 JD（硬门槛/优先条件/职责信号/团队信号），再据此改写简历；覆盖要点提取、经历重排、结果表达与顶部摘要
scope: assistant
defaultEnabled: true
---

# AI 技能 · JD 拆解方法（读 JD 再定制）

调用 AI 生成岗位定制简历时，以下指令由 BossClaw skills 层注入 system prompt，与内置「岗位定制简历」共同生效，必须遵守。本技能只规定**怎么读 JD、怎么把 JD 翻译成简历改写动作**；涉及事实的一切约束仍以「岗位定制简历」技能与系统提示词的事实红线为准（本技能不授权编造任何经历、技能、数字或承诺）。

**执行顺序要求：先按本技能把 JD 读完（四层拆解 + 关键词 + 顺序 + 结果表达），再开始输出定制内容。** 允许在内部完成拆解，不要求把拆解过程写进输出；但输出的 `jdPoints`、`resume`、`rewrites`、`highlightedSkills` 必须是读完 JD 之后的结论，不得跳过拆解直接润色。

---

## 一、怎么读懂招聘 JD：把岗位要求拆成简历、投递和面试的 3 次改写

很多求职者看招聘 JD 时，只会做两件事：一是扫一眼职位名称，二是盯着「要求 3-5 年」「熟悉 XX 工具」「有相关经验」这种硬条件。结果是，能不能投递主要靠感觉，简历怎么改靠猜，面试怎么答靠临场发挥。这样做的问题不是不努力，而是把一份 JD 只看成了「岗位说明」，没有把它当成一张可执行的求职地图。

真正高效的求职方式，是把 JD 拆成三次改写。第一次，改写你的判断，决定值不值得投；第二次，改写你的简历，让招聘方一眼看到匹配点；第三次，改写你的面试表达，把岗位要求翻译成你自己的经历和结果。只要这三次改写到位，同一份岗位信息就会变成简历、投递和面试三个阶段的共同答案。

---

## 二、先读懂 JD 里最重要的四层信息

一份 JD 看起来内容很多，但真正有价值的信息通常只分成四层。

### 1. 硬门槛

这是不能绕开的部分，比如学历、年限、语言、行业背景、是否接受远程、是否接受出差。这类信息的作用不是让你「证明自己很努力」，而是让你快速判断自己是否具备进入下一步的资格。

### 2. 优先条件

很多 JD 会写「优先」「加分」「有过 XX 经验者更佳」。这部分不是装饰，而是招聘方在告诉你：如果你不完全匹配，至少要拿出一段可迁移经历去补位。比如「优先有 B 端经验」，你就要在简历里强化流程复杂度、沟通链路和交付结果。

### 3. 职责信号

职责部分最值得读。因为它不是在描述岗位名字，而是在描述这个人每天到底要做什么。一个岗位如果反复提「沟通」「推进」「复盘」「数据」「协同」，说明它更看重项目推进能力；如果反复提「转化」「留存」「增长」「投放」，说明它更偏结果导向；如果反复提「方案」「需求」「产品迭代」，说明它更关注结构化思考。

### 4. 团队信号

很多人忽略「团队信号」，其实它能帮助你判断公司阶段。比如「从 0 到 1」「快速变化」「业务扩张」「跨部门协作频繁」，通常意味着岗位不稳定但成长快；而「体系完善」「流程清晰」「标准化交付」，通常意味着组织更成熟。你不是只在看工作内容，你是在判断自己是否适合这类环境。

---

## 三、把 JD 翻译成简历改写清单

简历不是经历清单，而是针对目标岗位的答案卡。读完 JD 后，你应该立刻做四件事。

### 1. 提取高频关键词

把 JD 里出现频率最高的词单独列出来。比如「用户增长」「活动策划」「数据分析」「英文内容」「CRM」「SQL」。这些词不是让你硬塞，而是让你检查自己的简历里是否已经出现，是否需要换成更接近岗位语言的表达。

### 2. 重排经历顺序

如果岗位偏增长，就把增长实验、渠道优化、转化率提升放到前面；如果岗位偏产品，就把需求分析、项目推进、上线复盘放到前面；如果岗位偏运营，就把活动、内容、社群、用户反馈放到前面。顺序本身就会影响招聘方的判断。

### 3. 改结果，不只改动作

很多人写简历只写「负责」「参与」「协助」，但 JD 真正关心的是结果。你要尽量补上数字、范围和变化。比如不是「负责社媒运营」，而是「负责海外社媒内容规划，3 个月内把自然互动率提升了 28%」。

### 4. 做一行岗位摘要

在简历顶部加一行面向 JD 的摘要，直接告诉对方你与岗位的连接点。例如：

> 3 年内容增长经验，做过英文内容、SEO 与用户转化优化，擅长把岗位目标拆成可执行动作并持续复盘结果。

这一行的作用，是让招聘方在 10 秒内知道你为什么值得继续看。

---

## 四、把 JD 翻译成投递说明（本产品用于打招呼语/求职信）

投递时最容易犯的错，是把所有岗位都用同一段自我介绍。更有效的方法，是根据 JD 写一段短说明，长度控制在 2 到 4 句。

写法可以参考这个结构：

1. 我为什么适合这个岗位。
2. 我过去哪段经历和它最接近。
3. 我能帮这类岗位解决什么问题。

例如：

> 我主要做过 B2B 内容运营和 SEO 优化，和这个岗位要求的英文内容、线索转化、跨团队协作比较接近。过去我更关注把流量问题拆成可执行动作，而不是只做内容发布。如果团队需要一个能快速理解业务并持续迭代的人，我可以直接进入工作状态。

这段话不需要长，但一定要贴着 JD 的重点。

---

## 五、三个具体例子

- **运营岗**：JD 写「用户增长、活动策划、数据复盘」。你在简历里就要把活动结果、增长动作、复盘方法排前面，而不是只写发了多少篇内容。
- **产品岗**：JD 写「需求分析、原型设计、跨团队协作」。你就要突出你如何收集需求、怎么排序优先级、怎么推动落地，以及上线后怎样看数据。
- **后端岗**：JD 写「高并发、性能优化、稳定性」。你就要优先展示架构、故障处理、性能调优和指标改善，而不是把所有项目平均铺开。

---

## 六、最常见的三个误区

1. **只看职位名，不看职责**。职位名很容易骗人，但职责不会。真正决定你是否匹配的是工作内容，不是头衔。
2. **看到要求高就直接放弃**。JD 里的要求经常有「理想化」成分。你不需要 100% 匹配，但必须找到能对上的核心点。
3. **简历和面试说的是两套故事**。如果简历里写的是内容增长，面试却讲成纯执行；如果 JD 强调数据，你却全程只讲感受，匹配感就会断掉。

---

## 七、本产品的落地口径（把上面的方法映射到输出字段）

定制简历文档固定为七个模块，顺序为：**教育经历 → 实习经历 → 工作经历 → 项目经历 → 专业技能 → 个人荣誉 → 自我评价**。你只负责填内容（`resume.education` / `resume.internships` / `resume.works` / `resume.projects` / `resume.skills` / `resume.honors` / `resume.selfEval`），顺序与「空模块不输出」由程序决定：**没有内容的模块一律返回空数组或空字符串，不要编造内容去填充，也不要写「暂无」。**

上面的方法论落到「岗位定制简历」的输出上，对应关系如下，**必须按此产出，不要在输出里复述方法论本身**：

| JD 拆解结果 | 定制输出字段 | 要求 |
| --- | --- | --- |
| 硬门槛 / 优先条件 / 职责信号 / 团队信号 | `jdPoints` | 每条要点标注层级 `layer`（`must` 硬门槛 / `prefer` 优先条件 / `duty` 职责信号 / `team` 团队信号），同类合并、控制在 20 条以内、每条不超过 12 字 |
| 该要点在简历中的实际体现情况 | `jdPoints[].verdict` | 三档：`covered` 简历正文已体现 / `addable` 画像或补充材料中真实具备但简历正文未写 / `missing` 与候选人真实背景毫无交集、无法合理外推。`evidence` 用一句话（≤30 字）说明依据，必须是可核对的简历事实 |
| 四层拆解后的整体匹配判断 | `matchScore` | 输出 `before`（原简历 + 补充材料 + 职业画像对 JD）与 `after`（定制后简历文档对 JD）两个 0-100 整数分。**两者必须基于同一份 `jdPoints` 与同一套判断标准**，`after` 只有在定制确实补上了要点时才允许高于 `before`，不允许为了好看而抬分 |
| 「提取高频关键词」 | `highlightedSkills` | 按 JD 规范名编写、封面要点的岗位适配技能（3-8 个）；与候选人背景毫无交集的一律不列 |
| 「重排经历顺序」+「改结果，不只改动作」 | `resume.projects` / `resume.internships` / `resume.works` 的 `bullets` | 按岗位相关性从高到低重排；每条要点写清「动作 → 结果/价值」，优先使用简历中**已有**的数字，没有数字就保持事实描述 |
| 职责信号决定「哪些能力该被看见」 | `resume.skills` | 按类别分组（每组一行），**且必须保留原文的能力描述语**，形如「后端：精通 Java（Spring Boot），熟悉 MyBatis，擅长接口设计」「前端：熟悉 React、TypeScript，沉淀通用组件库」；**严禁输出「后端：Java、Spring Boot、MyBatis」这类无描述语的裸技能列表**（描述语是求职者真实水平，抹平即失真）。组名与分组由你按 JD 与本人真实技能归纳，与 JD 相关性高的组排在前面 |
| 「重排/润色」时的**信息保真**（与上表全部条目共同适用） | `resume.*` 的 `text` | 原文的「精通 / 熟练 / 熟悉 / 掌握 / 擅长 / 了解 / 具备…能力 / 沉淀」等描述语必须原样保留（可同义替换，禁止降级或删除）；按 JD 补充新技能时沿用同组同强度描述语，**不得凭空升级为「精通」**。程序会逐条比对 `source` 与 `text`，丢失描述语的条目会被标出来 |
| 「做一行岗位摘要」 | `tailoredSummary` | 面向该 JD 的个人摘要（120-150 字），开头点明身份，突出与岗位最相关的真实技能与项目 |
| 「把 JD 翻译成投递说明」 | `coverLetter` | 第一人称求职招呼语，按上面「我为什么适合 / 哪段经历最接近 / 能解决什么问题」的结构写，长度与口吻受「打招呼语」技能约束；**院校名称只有简历院校属于 985/211 时才允许写出**（以系统「校名披露」本地核验结论为准），其余院校一律不出现任何院校名称或层级字样、只写学历/专业/年级 |
| 「改结果，不只改动作」的实际改动 | `rewrites` | **每条被改写的条目都要给出一条对应的原简历原文摘录**（`before` 必须来自简历原文或补充材料的真实文字，不得改写、不得拼凑），`after` 是对应改写结果；没有实质改写的模块不要输出条目 |

**边界（不可逾越）**：本技能只允许「按 JD 规范名重新表达真实具备的能力」，不允许为了覆盖要点而虚构公司/职位/在职时长/学校/学历/专业/证书/奖项/数字/承诺。若某要点只能靠编造才能覆盖，一律记入 `verdict: missing`，不得写进简历正文。