# Resume Crafting

> 简历制作、审改与真实性审计。当用户要写简历、改简历、优化简历、诊断简历、为投递某岗位定制简历，或让你"看看我的简历"时使用。也适用于：从零开始造简历、贴出岗位 JD 问怎么改、基于简历预测面试追问点、把周报或项目文档整理成简历素材、简历翻译。即使用户只说"简历"两个字，或者丢来一个 .docx 文件，也应该用这个 skill。Use this skill whenever the user mentions resume, CV, 简历, 求职, 投递, or shares a resume file — even casually. 泛泛的面试题练习、自我介绍润色、求职邮件撰写不属于本 skill，除非用户明确要求结合简历来做。

- Skill: `lupynow/resume-crafting` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add lupynow/resume-crafting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lupynow/resume-crafting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: lupynow (https://skillmd.com/u/lupynow)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lupynow/resume-crafting

---


# 简历制作与审改

## 核心理念

简历的问题几乎从不出在"没东西写"，而出在**写了但经不起追问**。

一个项目做了两三个月，最后简历上只剩"使用 Redis 缓存热点数据，提高查询效率"——这句话任何一个学过的人都能写。面试官看完不知道你遇到了什么问题、为什么这么设计、这东西是不是你真正做的。

所以这份 skill 的目标不是"把简历写满"，而是**让每一条都扛得住面试官往下追两层**。技术名词本身不值钱，值钱的是你为什么用、怎么做、踩过什么坑、最后效果怎样。

## 第一步：判断走哪条路

问清楚（或从上下文判断）用户属于哪种情况：

| 情况 | 走哪条路 |
|---|---|
| 手里没有简历，或只有一个很粗糙的初稿 | **路径 A：从 0 到 1** |
| 有一份成型简历，想改好 | **路径 B：审改** |
| 有简历，但要投某个具体岗位 | 路径 B + 定向调整 |

两条路都要走**真实性审计**（见下文），这是最容易跳过、但价值最高的环节。

---

## 通用原则

写任何一条经历时，都按这五条来。它们不是格式要求，而是**让内容变得可被追问**的方法。

### 1. 先说业务，再说技术

不要一上来就"技术栈：Spring Boot + Redis + MQ + MySQL"。先告诉读者你在做什么：

> 校园二手交易平台，包含商品发布、订单交易、即时聊天和消息通知，本人负责商品和订单模块。

有了业务背景，后面的技术选择才有意义。**项目开头的背景句不是套话，读者靠它判断你的技术决策合不合理。**

### 2. 写"为什么用"，不写"用了什么"

| 普通写法 | 有信息量的写法 |
|---|---|
| 使用 Redis 缓存商品信息，提高系统性能 | 商品详情属于高频读接口，将商品信息缓存至 Redis；针对不存在的商品设置空值缓存避免穿透，热点 Key 失效时采用互斥重建，避免大量请求同时回源 |
| 使用 RabbitMQ 异步处理订单 | 订单创建后，将消息通知、积分累计等非核心操作通过 MQ 异步处理，减少主链路同步等待；消费端用业务唯一键保证幂等，避免重复消费 |

前者说"我用过"，后者说"我知道为什么用"。面试官关心的是后者。

### 3. 问题 → 方案 → 结果

每条亮点尽量凑齐这三段：

> 订单后台支持多条件查询，数据量上来后深分页明显变慢；**根据高频查询条件调整联合索引，并将大页查询改为游标分页**，接口 P99 由 1.2s 降到 400ms。

**但没有真实数据时，宁可不写结果，也不要编。** 一个"性能提升 80%"被人问测试数据量、机器配置、压测工具、baseline，答不上来，整份简历的可信度都会塌。

### 4. 宁给完整分布，不给满分数字

这条容易反直觉，但很重要。

"检索命中率 100%"听起来漂亮，实际上经不起追问——面试官立刻会问 Top-1 是多少、基准集怎么建的、有没有负样本。而给出**完整分布**（Top-1 66.7% / Top-5 96.3% / MRR 0.78）反而更有说服力，因为它同时证明了你会评测、知道边界、不挑好看的数字。

同理，如果某个指标你自己都觉得虚，主动在面试中交代其局限（"基准规模还小，负样本是我下一步要补的"），比硬撑强得多。

### 5. 一条主线

投技术岗，就让"基础 → 项目 → 具体技术 → 业务问题 → 优化"这条线清清楚楚。不要 Java、Python、Vue、PyTorch、RAG、Agent、K8s 全塞进去。

**什么都会一点 = 什么都不突出。** 如果用户坚持要"技术和产品通吃"，可以照做，但要提醒：两面对不上专业候选人，可能两边都不占优。

### 自检三问

写完每一条，回头问自己：

1. 为什么这么做？
2. 不这么做会有什么问题？
3. 面试官再追两层，我还能不能回答？

三个都答不上来，这条写上去未必加分。

---

## 路径 A：从 0 到 1

### 信息收集

**先收素材，再补缺口**（顺序很重要——直接开始访谈会让用户面对空白页发呆）：

1. 让用户把手边的原始材料丢过来：实习周报、项目文档、课程作业说明、竞赛材料、旧版简历、甚至聊天记录里的工作汇报。有素材就从素材里提取事实，比凭空回忆准确得多。
2. 读完素材，整理出一份**事实清单**（有哪些经历、每条里有哪些具体动作和数字）。
3. 针对缺口逐条追问。**追问要挖到能扛住面试的程度**，见下。

### 追问的深度

不要满足于"我做了数据清洗"。继续问：

- 具体做了什么清洗？（缺失值怎么处理、异常值判定标准）
- 为什么这么处理？（业务约束是什么）
- 结果是什么？（数据量、耗时、准确率，哪怕是"从 12 万条筛到 8000 条"这种朴素数字）

用户答"记不清了"也没关系——**记不清的细节就不写进简历**，这是正常取舍，不是失败。

### 生成初稿

按下面的骨架写，然后用 `scripts/` 里的工具生成 docx：

1. **头部**：姓名 + 目标方向 + 联系方式 + 意向城市
2. **教育背景与荣誉**：学校、专业、时间；竞赛和奖学金单独成行
3. **实习经历**：公司、岗位、时间；3-4 条 bullet
4. **项目经历**：项目名 + 一句话定位；3-4 条 bullet
5. **专业技能**：3-5 条，每条一行，别堆名词

篇幅目标 **1 页**（应届生标准）。内容多到放不下时，砍的优先级是：无关内容 > 罗列型条目 > 套话总结 > 细节。

### 排版

默认使用 `assets/template.docx` 的样式（青绿配色、微软雅黑、A4）。它已经调好，直接 unpack 后替换内容即可。
具体参数和调优方法见 `references/layout.md`。

---

## 路径 B：审改

### 先诊断，别急着改

读原简历（`.docx` 用 pandoc 提取文本，或 unpack 看结构），然后**分类每一条**：

| 类型 | 特征 | 处理 |
|---|---|---|
| 能扛两轮追问 | 有具体数字、有取舍理由 | 保留，微调表达 |
| 只能扛一轮 | 有动作，缺"为什么" | 补设计理由（问用户） |
| 一问就崩 | 全是名词、罗列、套话 | 删除或重写 |

**把这份诊断先给用户看**，让他知道你要动哪里、为什么。直接开改会让人不安。

### 常见病症

- **加粗泛滥**：满篇粗体等于没有重点。检查 XML，加粗应该只用在标签和标题上。
- **术语堆砌**："边缘诊断""平台告警""上下文管理""结构化交付"堆在一起，问哪个都答不实。
- **动作多、结果少**：全是"参与/梳理/整理/协同"，看不到产出。
- **无关内容占位**：跟目标岗位零关系的经历（比如投技术岗写"推进易拉宝制作"），挤掉了硬货。
- **硬货被埋**：金奖、国奖被塞进小字行里。荣誉要单独立行。
- **顶部自我摘要**：一段加粗的"我具备……"大词合集，第一眼就露怯。删掉，或压缩成一行具体事实。
- **数字存疑**：精确到个位的漂亮数字（"命中 21/21""提升 47.3%"）最容易被深挖。逐个核对来源。
- **⚠️ 注意**：判断"加粗泛滥"这类问题**要看 XML，不能只看 pandoc 提取的文本**——pandoc 会把所有粗体标成 `**`，容易误判。从 XML 看 `<w:b w:val="0"/>` 才是真相。

### 改法优先级

1. 删掉无关内容和套话（省下的篇幅留给硬货）
2. 给每条补上"为什么"
3. 把罗列型条目合并或删除
4. 最后才调排版

---

## 真实性审计（强制）

**这是整个流程里最不能省的一步。**

用户写简历时会不自觉地混淆两件事：**方案里设计的** 和 **实际做出来的**。前者写在文档里很漂亮，但没有代码支撑，面试官一追就穿。

### 怎么审

对每一条技术描述，逐条问：

| 问题 | 判断 |
|---|---|
| 这个功能有代码吗？哪个文件？ | 有 → 可写"实现" |
| 跑通过吗？有输出吗？ | 跑通 → 可写具体结果 |
| 有量化数据吗？怎么测的？ | 有测试 → 写数字 |
| 只在方案/文档里？ | **只能写"设计"或"评估后决定不做"** |

### 典型陷阱

- **方案里有、代码里没有**：比如方案写了"缺口改写查询 ≤3 轮"，但代码只规定由 Agent 执行，没有自动循环 → 只能写"由 Agent 继续检查缺口"，不能写"实现自动查询重写"
- **文档指标 ≠ 代码限制**：方案写"4 万 Token 预算"，代码实际是"60000 字符" → 写"字符"
- **逻辑实现了但没生效**：代码里有审核状态加权，但实际数据全是 pending_review → 可以写"实现"，但要准备好回答"生效了吗"
- **只在部分数据上成立**：时间定位只在 14 个切片上有，且有误报 → 不宣称该能力

### 发现不一致时怎么办

**不要自己决定写哪个版本，回去问用户真实情况。** 用户往往能给出精确的边界（"这个落地的，那个只是规范"），而这正是简历最有价值的部分——**知道自己的边界在哪，本身就是能力**。

审计完，把每条降级成"能扛住代码核验"的表述。

---

## 产出物

改完简历后，除了文件本身，按用户需要产出：

### 修改说明
列清楚：删了什么、合并了什么、数字改了什么、为什么。让用户能对照原件理解每一处改动。

### 追问预演
针对简历里**每个可能被深挖的点**，列出：
- 面试官会怎么问（往下追两层）
- 用户手上有什么证据
- 当前表述在什么情况下会崩

### 面试题
按目标岗位生成常见题目（基础八股、场景设计、项目细节），**与追问预演分开**——追问预演针对"你自己写的这几条"，面试题是岗位通用题库。

### 跨版本数字核对
用户往往有多份简历（不同方向的定向版）。**同一个指标在不同文件里必须一致**，否则投出去对不上。
建立一张对照表，列出每个指标在每个文件里的值，标出不一致的。

⚠️ 每次更新数字时，主动检查其他版本是否需要同步。

---

## 技术操作

### 读简历

```bash
# 提取文本（含格式标记）
pandoc "简历.docx" -o extracted.md

# 看真实排版结构（判断加粗、字号、样式）
python <docx-skill>/scripts/office/unpack.py "简历.docx" unpacked/
```

### 改简历

**核心：保留原排版，只改内容和条目增删。** unpack 后编辑 `word/document.xml`：

- **定位段落**：用 `w14:paraId` 作为锚点，它唯一且稳定
- **改文本**：替换 `<w:t>...</w:t>` 里的内容
- **删段落**：匹配从 `<w:p w14:paraId="XXX">` 到 `</w:p>` 的整块
- **插入段落**：复制相邻段落的结构，换一个未使用的 8 位十六进制 paraId
- **改排版**：调 `word/styles.xml` 里的样式定义和 document.xml 的 `<w:pgMar>`
- **⚠️ 绝对不要动 `<w:pStyle w:val="...">`** —— 它的值必须和 `styles.xml` 里的 `w:styleId` 一字不差。模板用的是数字 ID（164-168），看着不像样式名，但完全合法。

  见过这个坑：把 `w:val="167"`"顺手规范化"成 `w:val="bullet"`，结果**所有段落样式断链**。Word 不报错，静默回退到默认样式 —— 文件能正常打开、字数页数都对、渲染出来也像份简历，但**配色、字号、标题下划线全部丢失**，交付的是一张白板。而且这种文件用肉眼看 PDF 很容易漏，因为版式还在，只是变成了黑白的。

  改完务必跑 `scripts/check_residue.py`，它会检查样式断链（`check_style_links`）。

改完用 pack 打包：

```bash
python <docx-skill>/scripts/office/pack.py unpacked/ out.docx --original "简历.docx"
```

**注意**：如果 pack 报 `Failed to parse the XML resource 'http://dublincore.org/...'`，那是校验器联网失败，不是你的改动有问题 —— 用 `--validate false` 跳过，但之后必须自己验证 XML 合法性（`xml.etree` 解析一遍 + 检查 paraId 无重复）。

### 验证（必做）

改完简历必须验证这几件事，缺一不可：

1. **页数** —— 用 `scripts/page_count.py`（走 Word/WPS COM，Windows 上最准）
2. **视觉** —— 渲染成图片目视检查（`scripts/render_pdf.py`），确认没有溢出、挤压、断裂
3. **数字和旧内容残留** —— 提取 PDF 文本，grep 检查：新数字进去了吗？旧数字清干净了吗？
4. **模板占位符** —— 从 `assets/template.docx` 或别人给的模板起稿时，模板自带的占位符必须全部换掉：

   `你的姓名`、`目标方向（2027届）`、`your@email.com`、`https://github.com/your-name/your-repo`、`起止时间`、`【...】`

   **这类残留比技术问题更致命，也最容易被漏掉。** 面试官可能会追问你"Redis 缓存为什么用互斥重建"，但 HR 看到 `your@email.com` 是直接淘汰——连追问的机会都没有。

   发现占位符而用户又没给真实信息时，**替换成显眼的待填标记**（如 `【你的邮箱】`），不要原样留着 —— 原样留着用户很容易滑过去，方括号一定会被注意到。同时在交付说明里单独列出来。

   跑 `scripts/check_residue.py` 会自动检查这些。它直接读 OOXML 取所有文本节点，**能抓到藏在超链接字段里的邮箱和链接** —— 用 pandoc 提取会把这些丢掉，报出"clean"这种最危险的假阴性。

5. **文档属性（docProps）** —— 右键文件「查看属性」就能看到的那些字段：作者、标题、主题、关键词、缩略图。

   **从别人的模板起稿时，这些会原样继承过来**，等于在简历里夹带了一张上一任作者的便签。实测中最典型的情况是：正文全部改好、占位符也换干净了，但 `dc:creator` 还写着原模板主人的名字，`dc:title` 是「XX的简历」，关键词里躺着岗位方向。HR 只要点一下属性就看见了。

   起稿时如果用了别人的模板，检查一遍，把 `docProps/core.xml`、`custom.xml` 换成中性内容，删掉 `thumbnail`。`scripts/check_residue.py` 会把这些报出来。

如果页数超标，调优顺序见 `references/layout.md`：先砍内容，再调段间距，最后才动行距和字号。

**行距不能调到小于字号**（9.5pt 的字，行距乘数低于约 0.87 会重叠）。

### Windows 环境注意

- 所有文件操作显式指定 `encoding='utf-8'`，否则 GBK 会报 UnicodeDecodeError
- 用项目自带的 venv 跑 Python（如 `<项目>\.venv\Scripts\python.exe`），执行前 `export PYTHONIOENCODING=utf-8 && export PYTHONUTF8=1`
- LibreOffice 的 `soffice.py` 脚本在 Windows 上会因 `AF_UNIX` 报错，改用 Word/WPS 的 COM 接口（见 scripts/）
- Word COM 有残留实例时会报 `ComputeStatistics` 失败，改用 `DispatchEx("KWps.Application")` 走 WPS

---

## 保密边界

改简历时经常要处理公司内部信息。**保留方法论，模糊掉具体数值**：

- ✅ "针对同一技术指标存在多种口径，建立冲突清单并列展示、不自行选边"
- ❌ "20Hz–150kHz 是算法上限，4Hz–192kHz 是传感器采样率"（这是公司技术细节）

拿不准时问用户：这个数字可以对外说吗？

---

## 参考文件

- `references/writing-rules.md` —— 写作规则详解与正反例对照
- `references/auditing.md` —— 真实性审计的完整追问清单
- `references/interview-prep.md` —— 追问预演与面试题的生成方法
- `references/layout.md` —— 排版参数、页数调优、常见排版故障
- `scripts/page_count.py` —— 统计页数并导出 PDF
- `scripts/render_pdf.py` —— 把 PDF 渲染为图片
- `scripts/check_residue.py` —— 检查新内容是否写入、旧内容是否残留
- `assets/template.docx` —— 默认简历模板（空白样式）