Markdown 简历——维护一份源文件，按需导出每种格式

1. 真正的痛点不是写简历，而是反复排版

找工作里最耗人的环节很少是「写」——你做过什么，你自己清楚。痛从重新打开那份 简历.docx 开始：安静躺了一年，两行总结变成三行，缩进漂了位置，这台电脑的字体和文件当初用的差了一点，半小时消失在调行距里，实质内容一个字还没动。更糟的是版本：技术版把系统放在前面，管理版先讲团队和预算，每个变体从复制 Word 开始、各自漂移——你在一份里改了错的日期，另外几份悄无声息地保持错误。求职高峰几周下来，文件夹里躺着十几个文件，文件名是它们唯一的版本管理。

第三重挤压是交付：投递入口只收 .docx，内推的朋友要 PDF「免得在我屏幕上串行」，个人网站要网页版。每条要求都不离奇，合在一起就意味着同一份内容要同时存在于三种格式里——在 Word 工作流里，那就是三份各自维护的文档。简历的内容一年只变几次，格式要求却按投递次数变化，这个错位才是真正的问题——它首先是个格式问题，其次才是写作问题。

2. 单一源：简历的 Markdown 文件怎么组织

解法是别再把简历当「文档」，把它当「源文件」。Markdown——README、笔记软件和大多数 AI 输出背后的纯文本语法，我们在 Markdown 是什么里完整讲过——恰好把内容和表现分开：文件只记录每一行「是什么」，渲染成什么样由渲染器决定。写出的简历是一个 .md 文件，任何编辑器都能打开、纯文本可读；需要的语法一屏放得下，一份带可复制示例的 Markdown 速查表全部覆盖。

三个约定能干掉大部分维护活，没有一个超出基础语法：

1. 联系人信息放在 YAML 头里。 姓名、邮箱、电话和链接放在文件顶部的一小块元数据里，而不是排好版的文字。它是数据而非排版，任何导出都原样保留，模板系统还能程序化读取。
2. 每段经历用同一种形状。 一个 ## 标题，一行装下职位、公司和时间，底下跟两到四条成果 bullet。结构一致，文件才能逐行 diff，导出结果才可预期。
3. 定制靠注释，不靠删除。 完整经历始终留在文件里；把某一版用不上的 bullet 用 <!-- ... --> 注释掉，长版本一秒钟就能恢复，按公司定制才便宜而不是冒险。

这些约定都不高明，而这正是重点：六个月后打开文件它还是同一个读法，定制版之间 diff 出来的只有内容差异，任何工具看到的都是可预测的结构，而不是排版残留物。

一条最小条目长这样：

---
name: Alex Chen
email: [email protected]
links: [github.com/alexchen, alexchen.dev]
---

## 高级工程师 — 某科技公司 · 2021–2026

- 把构建迁到带缓存的流水线，部署时间缩短 40%
- 主导计费服务向事件驱动架构迁移

如果简历目前是网页——旧个人站、About 页、能另存为 HTML 的档案——先过一遍 HTML 转 Markdown：标题、时间、列表的结构都能保住，清理几分钟就完事，然后你就有了整套流程依赖的那份源文件。

3. 一份完整的 Markdown 简历模板，逐段走查

上一节的三个约定，拼成一个完整的文件才好验证，这一节就走查一份完整模板。它刻意保持很小——一个 YAML 联系块、两段同形状的经历条目、一行的技能区、一段教育经历——里面没有任何东西在追求设计感，因为设计决策属于导出层，不属于源文件。把它粘进编辑器，替换成你自己的经历，一次坐下就得到一份可用的源文件。

---
name: Alex Chen
email: [email protected]
phone: +1 555 0100
links: [github.com/alexchen, alexchen.dev]
---

## 高级工程师 — 某科技公司 · 2021–2026

带四人团队负责支付平台，期间完成两次架构迁移。

- 把构建迁到带缓存的流水线，部署时间缩短 40%
- 主导计费服务向事件驱动架构迁移
- 设计的重试策略把支付失败率压到 0.1%

## 工程师 — 某创业公司 · 2018–2021

- 交付第一个移动客户端，目前月活 20 万
- 把 CI 从手跑脚本迁到托管流水线

## 技能

Go · Python · PostgreSQL · Kubernetes · Terraform

## 教育

计算机学士 — 某大学 · 2014–2018

毕业论文：批处理流水线的调度算法

从上往下读：YAML 头装的是所有「身份而非论点」的字段——姓名、邮箱、电话、链接——因为它们在任何导出里都原样保留，模板系统还能程序化读取。每段经历以一个 ## 标题开头，职位、公司、时间装在同一行；较近的一段在 bullet 之上加一句范围描述，较老的一段直接进 bullet，职业越长这越是常态。技能区保持一行词语而不是满格的进度条，解析器和扫读的人读词语列表都比读图形快。教育经历用同样的「标题加一行」收尾，只有论文与目标岗位相关时才写那一行——而注释块，就是从这份文件派生定制版却不删任何东西的办法。

4. 分块写作：总结、经历 bullet 与教育

结构是骨架，决定招聘者是否继续读下去的却是里面的句子，而重量几乎全压在三个块上。每块都有典型的失败形态：谁都能用的总结、只记录职责不记录产出的 bullet、在应届简历里唱主角却在资深简历里消失的教育区。修法是机械的而不是艺术性的，所以值得写成明说的对照——先弱后强，差别一眼可见。

总结必须在最多两行里点名专业、规模和结果，bullet 则要给出招聘者能横向比较的证据；下表把弱版本和更强版本并排放在一起。

更强的那些 bullet 共用一个公式——动词、产出、数字——数字是规模、百分比或时间跨度，不是装饰。不是每条 bullet 都能带硬数字，有些工作真的没有指标，但每条 bullet 都必须有一个产出：一件因为你而在的东西，或一个因为你而不同的行为。「负责」是弱版本的标志，因为它放进任何岗位描述都不用改，所以也就什么都没描述。

教育与研究沿用与工作条目相同的形状，重量随职业阶段移动。早期简历可以把毕业论文、课程设计项目和研究助理经历升格为完整条目——标题带职位和时间、一句范围、公式化 bullet——因为这些常常是最强的证据。资深简历把教育压到底部一行，让工作历史去说话；而任何形式的研究产出——从论文到已上线的开源项目——都进同一个「动词、产出、数字」公式：做了什么、给谁用、到什么规模。

5. 同一份文件的三条导出路径

内容进了 Markdown，求职季要的任何格式都是机械劳动。三条路径按上手成本排序，而不是按能力上限：浏览器零门槛，命令行装一次换来可重复，社区模板要构建工具链、换来现成排版。下表是速览版。

最常见的情况——一份简历、改得勤、交 PDF——浏览器路径连安装都省了。打开 Floatboat 的免费 Markdown 工具，对着实时预览改，改完即导出打印级 PDF：按纸张分页，不是浏览器窗口的截图。渲染用的就是机器上已有的字体，预览即成品，从改掉错别字到能发出去按秒计；面试季总结一周改两次时，这个「改完即导出」的循环就是全部产品。

导出要可重复——或者门户非要 Word——命令行开始值回票价。按 pandoc 官方手册的说法，一份源文件能转出 PDF、DOCX、HTML 等几十种格式；从 pandoc 的安装页装好，两条命令覆盖整个求职季：

pandoc resume.md -o resume.pdf --pdf-engine=typst
pandoc resume.md -o resume.docx --reference-doc=corp-template.docx

PDF 引擎、字体、模板样式那一整套是另一个话题，我们在 Markdown 转 PDF 的完整拆解里按折腾程度排过序。简历场景只提醒一件事：DOCX 样式来自 --reference-doc 模板，门户收到的 Word 可以带着你自己调的字体和页边距——因为那个模板就是你编辑过的 Word 文档。

想继承设计而不是自己做一个，GitHub 上的 pandoc_resume 项目——标题就叫「The Markdown Resume」——用 Markdown 配 pandoc 和 ConTeXt 构建链，产出排版讲究的 PDF 和 HTML；MIT 协议，截至 2026 年 9 月约 1.8k stars，提供 Docker 方式，本地不装工具链也能构建。代价也说明白：你接受别人的设计和一个构建依赖，换来第一天就有成品。

在线简历构建器占剩下的角落，一句实话的评价：想要有人带着做设计，它们好用——代价是简历住在别人的数据库里，而不是一份由你持有、可版本化、随处导出的文件。

6. 导出 QA：投递前的四查

导出不是文件出现在文件夹里就算完成，而是四项检查全部通过才算完成，四项加起来不到五分钟。它们存在的原因是：简历文件的每种常见死法——文本不可选中、字体被替换、第二页只剩一行孤行、文件名查无此人——在产出文件的这台机器上都看不见，只在别人的屏幕上现形。按下表顺序执行，先抓最致命的问题。

四查都跑在导出的成品上而不是源文件上，这个习惯值得保持：源文件可以完美，导出照样出错，所以受检的是文件本身。哪一项不过，就回去改 Markdown 重新导出，不要直接编辑 PDF——这样修复才留在源里，被之后的每一次导出继承。四查加起来，就是「我导出了一个文件」和「我知道对方会看到什么」的差距。

7. 拿到 JD 后的 15 分钟定制

这套工作流最见回报的时刻，是一份具体岗位摆在面前：定制不再是重写，而是一次十五分钟、形状固定的过检——先把 JD 的要求映射到你的证据，再重排映射出来的内容，最后导出并核对。三个阶段都不要求你发明新内容，每段都有明确的停止点。如果一次定制花掉一个晚上，说明结构在某处漂了，先修结构。

第一阶段是关键词映射。把 JD 读一遍，写下六到十个真正命名了要求的词——跳过填充词——逐个对照文件：已经有、有但埋着、真没有。这也是唯一适合把活交给软件的阶段：把 JD 和简历一起粘给新的 AI 工作区智能体，要一张映射表——但每一行都要自己核，因为机器读两份文本比你快，却完全不能替你判断哪些是你能诚实认领的。没有 bullet 撑腰的关键词是噪音，用噪音填简历，读起来就是噪音。

第二阶段只重排，不发明：每段经历内部，把回应 JD 头部要求的 bullet 挪到最上面，把这版用不上的注释掉，总结行改成以映射出的专业开头。第三阶段机械且不可省——导出一次，跑上一节的四查，然后带着公司名 commit，让下一节的历史记下出门的到底是哪一版。十五分钟后，申请发出去了，主文件在底下原封不动。

8. Git：让版本库替你记住投出去的每一版

纯文本简历最不被宣传的好处，是它变成可 diff 的历史。文件进了仓库，每次实质修改都是一个 commit——「按那家金融公司定制：风控经历前置」「内推用 PDF，压到一页」「补上 Q3 项目」——而在按岗位微调侧重的季节里，最吓人的问题（「12 号那天我发的是哪一版？」）不再是考古，而是一条带时间戳的 git log。习惯很小：投递前 commit 一次，message 里写上公司名，历史自己长出来。

收益在查询之外继续累积：diff 两次投递，你能看到自己在技术岗和管理岗之间怎么调整了侧重；读起来很怪的定制实验可以回滚；改事实错误时，一次编辑加一次 commit，修正就进入之后每一次导出，而不是只落在碰巧打开的那份文件里。入门命令在 Git 官方文档里查得到，也就几条，和管理其他文本用的是同一套。

一条诚实的边界：Git 有学习曲线，从没用过的话，按日期命名的导出副本也能拿到大部分可追溯性；本来就写代码的话，简历进仓库不额外花成本——还是那个习惯，多管一个重要的文本文件而已。

9. ATS 到底在读什么——Markdown 能保证什么、不能保证什么

招聘系统（ATS）解析的是文本，而 Markdown 导出的 PDF 带真实、可选中、可复制的文本层——这正是解析器需要的属性。这句话两半都值得说精确，因为简历圈在两个方向上都爱超售。ATS 把简历文本抽成结构化字段供招聘者筛选；它经典的翻车对象是重图像或被压平的设计——文本到达时已是碎片甚至没到——以及藏在图标里的内容，那些从头到尾就没变成过文本。

Markdown 的优势是结构性的。浏览器打印管线和 pandoc 产出的 PDF 都带内嵌文本层——用光标选中文字复制出来，就是「解析器看到什么」的粗糙但可靠的代理——单栏排版让文本有线性阅读顺序。从 Markdown 出发的简历，天然就是解析器最容易处理的保守形状：标准的小节标题、纯文本日期、列表式成果、关键内容不锁在侧栏或表格单元里。

任何格式都不能承诺的，是某个具体解析器一定能优雅处理你的具体文件：带文本层的 PDF 也会被多栏排版、承载关键信息的表格、被误读的页眉页脚搞乱——所以「ATS 防弹」没人该说，本文也不说。站得住的版本更窄：Markdown 默认让内容处于解析器最友好的形状，从不把内容困在图片里；门户要 Word 时，同一份源就能导出它要的 DOCX。验证办法很直接：打开导出的 PDF，全选、复制、粘进纯文本编辑器——粘出来的就是你的简历，解析器也有公平的机会。

10. 同源衍生：求职信与 LinkedIn 档案

求职很少只靠简历一件文件，而两位常驻配角——求职信和 LinkedIn 档案——通常被当成游离文件维护，和简历渐行渐远。日期在这里改了、在那里忘了，重心在这边调过、在那边没跟上，漂移要等到招聘者把 PDF 和档案对着看的那天才现形。让它们和简历住在一起，几乎不花成本，从根上除掉漂移。

求职信的做法：在 resume.md 旁边建一个 cover-letter.md，放进同一个仓库，复用同一个 YAML 联系块，让身份字段只存在一处。每次申请只重写中间那几段——为什么是这家公司、这个岗位——每封信以公司名单独 commit，招聘者实际收到的那封就和简历一样可回溯。走同一条导出管线，求职信继承同一套排版，两份文件安静地成套。

LinkedIn 的做法：档案的经历区直接从同一批 bullet 粘贴而不是另写，指标修正、职务更名都只发生一次，向外流向招聘者可能看的每个页面。给网页留一个不注释、不限长的变体——LinkedIn 没有一页限制，完整记录才是那边正确的源——PDF 则继续做修剪过的、按岗位定制的投递件。一份文件，两种渲染，让简历诚实的那个纪律，同样让档案和它保持一致。

11. 结论

这套工作流要求的观念转换很小：简历不是一份你维护的文档，而是一个你编译的源。一个 Markdown 文件装着完整记录；YAML 承载联系块；一致的条目让文件可 diff；注释块让定制变便宜；导出按需产出 PDF、DOCX 或 HTML；Git 记住谁在什么时候收到了哪个侧重。工具栈里没有新奇的东西——一个编辑器、一个网址或一条命令，可选地再加一个仓库。

如果你正在找工作，第一步只花一个晚上：把简历搬进 .md，导出一次 PDF，再把导出的文本读回来。如果这一来一回保住了你想说的一切，你以后再也不会去重排那份 Word——下一次「今晚能发我一份 PDF 吗」，是一个两分钟的差事，不是一个报废的晚上。