三无应届生简历工程化：Markdown+Git导出与自检

每年校招季，被问得最多的一类问题不是"面试怎么准备"，而是"我什么都没有，简历该怎么写"。没有实习、没有竞赛奖项、没有能拿得出手的项目，这三个"没有"叠在一起，很多人第一反应是去找一份"通用模板"，把姓名学校一填就投出去。结果往往是投了两百份，面试邀约个位数，还找不到问题出在哪。

先说结论：三无背景本身不是致命伤，致命伤是简历没有可验证的信息结构。HR 看一份应届生简历的平均时间以秒计，筛选逻辑并不是"这个人有多优秀"，而是"这个人有没有把事情做完过、能不能被快速判断"。一份排版花哨但信息空洞的简历，和一份排版朴素但每条经历都能追问的简历，通过率差距远大于多数人的想象。

所以这篇文章不打算只给你一份可以复制粘贴的模板。我要给的是一套可维护的简历工程方案：用 Markdown 或 HTML+CSS 作为唯一数据源，用 Git 做版本管理，用命令行一键导出 PDF，用脚本做提交前的自动检查。这样你改一版简历的成本从"重排一次版"降到"改几行文本"，投不同岗位时只需要换一份配置，而不是复制出十个文件名叫"简历最终版3"的文档。

读完你能拿到三样东西：一份结构经过验证的应届生简历内容框架，一套可以本地跑通的模板代码，一份投递前的自检清单。如果你是三无背景，第 8 节的内容填充方法比模板本身更重要；如果你只是想解决排版和导出问题，第 5、6 节可以直接抄。

1. 这篇文章真正要解决的问题

先把痛点说清楚。应届生简历的问题通常集中在三个层面，而且很多人会把它们混在一起，导致改了排版还是没面试。

第一层是内容层：不知道自己有什么可写。三无同学最容易犯的错是把"没有大厂实习"等同于"没有经历"，于是整份简历只剩教育背景和自我评价。但在招聘方眼里，课程设计、毕业设计、自学项目、开源 issue、社团活动、兼职、线上课程作业，都是可以写的事实材料，区别只在于你有没有把它写成"问题—动作—结果"的结构。

第二层是结构层：信息顺序和密度不对。同样一段经历，写成"参与了 XX 系统的开发，负责部分功能"，和写成"用 Spring Boot 实现订单查询接口，把分页查询响应从 1.2 秒优化到 300 毫秒以内，覆盖 8 个查询条件"，信息量差了一个数量级。结构层的核心不是文采，而是让读者在三秒内定位到"教育背景在哪、项目在哪、技能在哪"。

第三层是工程层：维护成本太高。用 Word 排版的人都有一个共同体验——加一行内容，整个版面塌掉，页码跑到第二页，表格错位，导出 PDF 字体变了。于是很多人干脆不敢改，一份简历投遍所有岗位。而不同岗位的关键词差异很大，一份简历通投，本质上是在赌筛选者愿意替你做匹配。

这篇文章主要解决第二层和第三层，同时给第一层提供一套可执行的内容填充方法。判断标准很简单：读完之后，你应该能在一个晚上做出自己的第一版，并且在后续两周内以很低的成本迭代五六次。如果你追求的是"下载一个 Word 文件改改就投"，本文的工程部分你可以跳过，但第 2 节和第 8 节建议认真看，那两部分决定了简历能不能过初筛。

需要提前说明的是适用边界：这套方案面向应届生和毕业两年内的求职者，岗位以技术、产品、运营、设计等通用职能为主。如果你投的是需要作品集的设计岗、需要附研究经历的科研岗，简历只是材料之一，模板的权重会明显下降。

2. 简历模板的核心概念与结构原理

2.1 简历到底在传递什么信息

把简历理解成一份"高密度结构化摘要"会更准确。它的读者有两类：机器和人。机器指简历筛选系统（ATS，Applicant Tracking System），它会把 PDF 或 Word 解析成文本，抽取姓名、电话、邮箱、学校、专业、公司、时间段、技能关键词等字段；人指 HR 和面试官，他们快速扫描关键词和结构，判断是否值得花 30 秒细看。

这两类读者的偏好并不一致。机器喜欢规整的版式、标准的栏目名、可提取的纯文本；人喜欢重点突出、有层次、读起来不费劲。很多花哨模板满足了人，却让机器解析失败——比如用文本框承载内容、用图片做标题、用两栏布局导致读取顺序错乱、把关键信息放在页眉页脚。结果就是简历在系统里被拆成一堆乱码字段，连岗位关键词都没匹配上。

所以一个合格的应届生模板，第一原则是"结构优先于装饰"。栏目名用最通用的那几个：教育背景、专业技能、项目经历、实习经历、校园经历、荣誉奖项。不要去发明"我的成长轨迹""关于我"这类文艺标题，机器不认识，人也需要多花时间理解。

2.2 常见模板类型对比

从这张表能看出一个不太符合直觉的结论：对绝大多数应届生来说，最优解不是"最好看的模板"，而是"修改成本最低的模板"。因为应届生的简历在秋招期间会改十几版，每一次投递都可能需要调整关键词顺序、增删项目、更换技能栏。修改成本高的模板，最终会导致你放弃优化。

2.3 一页原则与信息密度

应届生简历默认一页，这不是审美偏好，而是筛选场景决定的。面试官在候场间隙翻简历，两页意味着需要翻页，翻页意味着有一段内容会被漏看。一页的物理约束反过来会逼你做减法：哪些经历值得占三行，哪些只值一行关键词。

信息密度的判断标准是"每行是否携带新信息"。"熟练掌握 Office 办公软件"这类表述携带的信息接近于零，占了一行却没有任何区分度；"用 Python 的 pandas 处理 3 万行销售数据，输出月度环比报表"占同样一行，但可以被追问、可以被验证。

一个实用的密度检查方法：把简历上每一行的动词和数字圈出来，如果没有动词或者没有可量化的对象，这一行大概率可以删掉或者合并。

2.4 时间倒序与关键词匹配

时间一律倒序，最近的放最上面，这是通用惯例，不要为了突出某段经历打乱顺序。时间格式统一成 2023.09 - 2024.06 这种样式，不要混用"2023年9月""23.9""去年九月"，机器解析时间段时对格式一致性很敏感。

关键词匹配是过初筛的实际抓手。做法不是堆砌，而是对齐：把目标岗位 JD 里出现频次高的技术名词、工具名、业务词抄出来，检查你的简历里是否出现了同义表达。JD 写"熟悉 MySQL 索引优化"，你简历写"用过数据库"，匹配度就低；写"为订单表添加联合索引，把慢查询从 2 秒降到 200 毫秒"，既有关键词又有结果。

3. 环境准备与前置条件

这套方案的依赖非常轻，一台普通笔记本就够，不需要装 IDE 之外的重型工具。

操作系统方面，Windows、macOS、Linux 都可以。Windows 用户建议把项目放在非中文路径下，避免转换工具处理中文路径时出现编码问题。文本编辑器推荐 VS Code，理由是内置 Markdown 预览、支持保存时自动格式化、终端集成方便；如果你更习惯 Typora 这类所见即所得工具也可以，它本质还是在编辑同一个 .md 文件。

运行时依赖分两条路线，按需选择：

• 纯 Markdown 路线：只需要一个 Markdown 编辑器和浏览器。导出 PDF 有两种方式，一是编辑器自带的导出功能，二是用 Pandoc 转换。Pandoc 是可选的，装了可以脚本化，不装也能手动导出。
• HTML + CSS 路线：需要浏览器（Chrome 或 Edge 的打印功能足够），不需要 Node.js 构建链。想自动化可以用 Node 的 puppeteer，但对简历这个场景属于过度设计。

版本号这里不做硬性规定，因为各工具的版本更新较快，本文重点演示通用思路和文件结构，具体版本请以你本地实际安装的为准。需要提醒的是，如果你用 Pandoc 转换中文 PDF，字体配置是最大的坑，第 7 节会专门讲。

Git 建议一定要装。不是为了协作，而是为了版本管理。简历这种高频修改的文档，用 git log 能看到每次改了什么，回退成本几乎为零。如果你还没有 GitHub 账号，注册一个，用私有仓库存简历源文件，比把文件散落在桌面安全得多。

最后准备一份目标岗位的 JD 文本，存在项目里的 jd/ 目录。这不是形式主义，第 5 节的脚本会用它做关键词覆盖检查。

4. 模板工程的文件结构与核心流程拆解

4.1 目录结构设计

先看整体结构。这个结构的设计原则是"内容与样式分离、单一数据源、可增量扩展"，你完全可以根据自己的习惯调整命名，但分层逻辑建议保留。

bash复制resume/
├── README.md                # 项目说明与投递记录
├── data/
│   └── profile.yaml         # 个人信息、教育背景等结构化字段
├── src/
│   ├── resume.md            # Markdown 版简历正文（主数据源）
│   ├── resume.html          # HTML 版简历模板
│   └── style/
│       └── resume.css       # 打印样式
├── jd/
│   └── backend-2025.txt     # 目标岗位 JD 原文
├── scripts/
│   ├── check.sh             # 提交前自检
│   └── match.py             # JD 关键词覆盖检查
└── dist/                    # 导出产物，加入 .gitignore

分层的意义在于：src 里只放内容和样式，data 放容易变的个人信息，dist 放生成物并且不进版本库。很多人把导出的 PDF 也提交到仓库，几次之后仓库里全是二进制文件，diff 完全看不出改了什么。

4.2 核心流程拆解

整个流程可以拆成五步，每一步都有明确的输入输出，做错都会在下一环节暴露。

第一步，填写 data/profile.yaml。这一步只做一次，后面基本不动。关键点是手机号和邮箱的格式要规范，手机号写成 138-0000-0000 这种带分隔符的形式，部分解析器会识别失败，统一用连续 11 位数字。

第二步，编辑 src/resume.md。这是日常改得最多的文件。写作时按第 8 节的结构来，每条经历控制在两到四行。这一步最容易出的问题是越写越长，看到第二页就停不下来。建议在编辑器里打开字符统计，正文超过 3500 字基本就压不住一页了。

第三步，本地预览。Markdown 用编辑器的预览功能，HTML 用浏览器打开。预览时要按 A4 纸的实际宽度看，不要在全屏宽窗口下看，宽窗口下看起来舒服的排版，打印出来往往行太长。

第四步，导出 PDF。Markdown 路线用 Pandoc 或编辑器导出，HTML 路线用浏览器的"打印—另存为 PDF"，注意在打印设置里把页边距设成"无"或者自定义，缩放设成 100%，不要勾选"页眉页脚"。

第五步，自检与投递。运行 scripts/check.sh 检查页数、字符数、链接有效性，运行 scripts/match.py 检查关键词覆盖率，都通过之后再投。投递记录写进 README.md，记下公司、岗位、投递日期、简历版本号，两周后回看能发现哪类岗位回复率低。

4.3 为什么建议内容与样式分离

如果只看表面，很容易误以为这是程序员的强迫症。实际原因是，简历的样式需求会随投递场景变化：投国企可能要正式一点，投创业公司可以简洁现代一点，投外企可能需要英文版。如果内容和样式耦合在一起（比如 Word 里到处是手动加粗和空格对齐），每次换样式都要重排一遍，而你永远不知道重排之后会不会挤到第二页。

分离之后，换样式只是换一个 CSS 文件或者换一个 Pandoc 模板，内容一行不动。这个收益在秋招这种高强度投递场景里非常明显。在实际项目中，更推荐的做法是把"内容"沉淀成稳定的资产，把"样式"当成可替换的皮肤。

5. 完整模板代码实现

5.1 结构化个人信息配置

先写配置文件。这一步的目的是把容易出错、格式要求严格的字段集中管理，避免在正文里手写出错。

yaml复制# 文件路径：data/profile.yaml
name: 张明
gender: 男
phone: "13800000000"
email: "zhangming@example.com"
city: 杭州
job_title: Java 后端开发工程师

education:
  school: 某某大学
  major: 计算机科学与技术
  degree: 本科
  period: "2021.09 - 2025.06"
  gpa: "3.6/4.0（专业前 20%）"
  courses:
    - 数据结构与算法
    - 数据库系统原理
    - 计算机网络
    - 操作系统

links:
  github: "https://github.com/yourname"
  blog: "https://yourname.github.io"

这里有几个细节值得说。手机号用引号包起来，是因为 YAML 里以 0 开头的纯数字串在部分解析器里会被当成八进制或者被截断；邮箱用引号同理，避免 @ 被特殊处理。GPA 只在确实有优势的时候写，如果排名靠后就不要放这一栏，留白比暴露短板好。GitHub 和博客链接只在仓库里有真实内容时才写，放一个空仓库的链接是负分。

5.2 Markdown 版简历正文

这是主数据源，也是最值得反复打磨的文件。下面这份模板的结构按应届生常见情况设计，你按自己的实际材料替换即可。

markdown复制# 张明

男 | 13800000000 | zhangming@example.com | 杭州 | 求职意向：Java 后端开发工程师

GitHub：https://github.com/yourname 　 博客：https://yourname.github.io

## 教育背景

**某某大学** | 计算机科学与技术 | 本科 | 2021.09 - 2025.06

- GPA 3.6/4.0（专业前 20%），主修课程：数据结构与算法、数据库系统原理、计算机网络、操作系统
- 校级奖学金二等奖（2023 学年）

## 专业技能

- 语言：Java（熟悉集合、并发基础）、Python（能写脚本处理数据）、SQL
- 框架：Spring Boot、MyBatis，了解 Spring MVC 请求处理流程
- 数据库：MySQL，理解索引原理与执行计划，能定位慢查询
- 工具：Git、Maven、Linux 常用命令、Postman、Docker 基础操作

## 项目经历

**校园二手交易平台** | 个人项目 | 2024.03 - 2024.06

- 技术栈：Spring Boot + MyBatis + MySQL + Thymeleaf
- 背景：校内二手交易依赖微信群，信息无法检索，成交后帖子仍留在群里
- 实现：设计商品、订单、用户三张核心表，实现商品发布、关键词检索、下单、订单状态流转四个模块，共 12 个接口
- 优化：商品列表接口初期全表扫描耗时约 1.8 秒，为分类字段和创建时间添加联合索引后降至 200 毫秒以内
- 结果：本地部署后邀请同班 15 名同学试用，累计发布商品 60 余条，整理出 8 条体验问题并完成 5 项修复

**学生成绩管理系统** | 课程设计 | 2023.10 - 2023.12

- 技术栈：Java + Swing + MySQL
- 负责数据库设计与成绩统计模块，实现按班级、科目两个维度的平均分与及格率统计
- 用 JDBC 批处理替换逐条插入，导入 2000 条成绩记录的耗时从约 12 秒降至 1.5 秒

## 校园经历

**计算机协会技术部 干事** | 2022.09 - 2023.06

- 负责协会公众号技术类文章排版与发布，累计发布 18 篇，单篇最高阅读 800+
- 组织 2 场面向新生的 Git 入门分享，参与人数约 40 人，独立完成讲义编写与现场演示

## 自我评价

（建议删除，改为在技能栏和项目栏体现）

这份模板里有几个刻意的设计。第一，教育背景放在最上面，因为应届生的学校是主要筛选信号之一，不要把它藏在最后。第二，项目经历放在实习经历的位置，三无同学本来就没有实习，不需要留一个空栏目占位，留空反而暴露短板。第三，每条项目经历都按"背景—实现—优化—结果"四段式写，这是为了让面试官有追问的抓手，也是让机器能抓到技术关键词。

关于"自我评价"这一栏，我的建议是直接删掉。这一栏的绝大多数内容是"学习能力强、吃苦耐劳、有责任心"这类无法验证的形容词，占了三到五行却零信息量。如果你的空间确实有富余，把它换成"开源贡献""技术博客"这类有链接可查的内容，收益高得多。

5.3 HTML 版模板与打印样式

如果你对版式有要求，或者 Markdown 转换出来的中文排版不理想，可以直接用 HTML + CSS。关键在于打印样式，屏幕样式和纸张样式是两套逻辑。

html复制<!DOCTYPE html>
<html lang="zh-CN">
<head>
  <meta charset="UTF-8">
  <title>张明 - Java 后端开发工程师</title>
  <link rel="stylesheet" href="style/resume.css">
</head>
<body>
  <main class="page">
    <header class="header">
      <h1 class="name">张明</h1>
      <p class="meta">男 | 13800000000 | zhangming@example.com | 杭州</p>
      <p class="meta">求职意向：Java 后端开发工程师</p>
      <p class="meta">GitHub：github.com/yourname | 博客：yourname.github.io</p>
    </header>

    <section class="section">
      <h2 class="section-title">教育背景</h2>
      <div class="item">
        <div class="item-head">
          <span class="item-title">某某大学</span>
          <span class="item-date">2021.09 - 2025.06</span>
        </div>
        <p class="item-sub">计算机科学与技术 | 本科</p>
        <ul class="item-list">
          <li>GPA 3.6/4.0（专业前 20%），主修课程：数据结构与算法、数据库系统原理、计算机网络、操作系统</li>
          <li>校级奖学金二等奖（2023 学年）</li>
        </ul>
      </div>
    </section>

    <section class="section">
      <h2 class="section-title">专业技能</h2>
      <ul class="item-list">
        <li><strong>语言：</strong>Java（熟悉集合、并发基础）、Python（能写脚本处理数据）、SQL</li>
        <li><strong>框架：</strong>Spring Boot、MyBatis，了解 Spring MVC 请求处理流程</li>
        <li><strong>数据库：</strong>MySQL，理解索引原理与执行计划，能定位慢查询</li>
        <li><strong>工具：</strong>Git、Maven、Linux 常用命令、Postman、Docker 基础操作</li>
      </ul>
    </section>

    <section class="section">
      <h2 class="section-title">项目经历</h2>
      <div class="item">
        <div class="item-head">
          <span class="item-title">校园二手交易平台</span>
          <span class="item-date">2024.03 - 2024.06</span>
        </div>
        <p class="item-sub">个人项目 | Spring Boot + MyBatis + MySQL</p>
        <ul class="item-list">
          <li>设计商品、订单、用户三张核心表，实现发布、检索、下单、状态流转四个模块共 12 个接口</li>
          <li>商品列表接口初期全表扫描耗时约 1.8 秒，添加联合索引后降至 200 毫秒以内</li>
          <li>邀请 15 名同学试用，累计发布商品 60 余条，整理 8 条体验问题并完成 5 项修复</li>
        </ul>
      </div>
    </section>
  </main>
</body>
</html>

对应的样式文件重点是页面尺寸、字号和分页控制。下面这份 CSS 只做必要的事，不引入任何外部框架。

css复制/* 文件路径：src/style/resume.css */
* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}

body {
  font-family: "PingFang SC", "Microsoft YaHei", "Source Han Sans SC", sans-serif;
  font-size: 13px;
  line-height: 1.6;
  color: #222;
  background: #f5f5f5;
}

.page {
  width: 210mm;
  min-height: 297mm;
  padding: 14mm 16mm;
  margin: 10mm auto;
  background: #fff;
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.12);
}

.header {
  border-bottom: 2px solid #222;
  padding-bottom: 8px;
  margin-bottom: 12px;
}

.name {
  font-size: 22px;
  font-weight: 700;
  letter-spacing: 2px;
  margin-bottom: 4px;
}

.meta {
  font-size: 12px;
  color: #444;
}

.section {
  margin-bottom: 12px;
}

.section-title {
  font-size: 14px;
  font-weight: 700;
  color: #1a1a1a;
  border-left: 3px solid #1a1a1a;
  padding-left: 8px;
  margin-bottom: 8px;
}

.item {
  margin-bottom: 10px;
}

.item-head {
  display: flex;
  justify-content: space-between;
  align-items: baseline;
}

.item-title {
  font-weight: 700;
  font-size: 13px;
}

.item-date {
  font-size: 12px;
  color: #666;
}

.item-sub {
  font-size: 12px;
  color: #555;
  margin: 2px 0 4px;
}

.item-list {
  list-style: none;
  padding-left: 0;
}

.item-list li {
  position: relative;
  padding-left: 12px;
  font-size: 12.5px;
  margin-bottom: 3px;
}

.item-list li::before {
  content: "·";
  position: absolute;
  left: 2px;
  font-weight: 700;
}

@media print {
  body {
    background: #fff;
  }

  .page {
    width: auto;
    min-height: auto;
    margin: 0;
    padding: 0;
    box-shadow: none;
  }

  .section {
    page-break-inside: avoid;
    break-inside: avoid;
  }

  @page {
    size: A4;
    margin: 14mm 16mm;
  }
}

这里真正容易踩坑的地方是 @page 和 .page 的双重边距。如果你在 .page 上设了 14mm 内边距，又在 @page 上设了 14mm 页边距，打印出来会变成 28mm，内容被挤成一团。正确的做法是二选一：要么在打印媒体查询里把 .page 的 padding 归零、只保留 @page 的 margin；要么反过来。上面这份 CSS 采用的是前者。

page-break-inside: avoid 也很关键。没有它，一个项目的最后一行很容易被切到第二页，出现"孤行"，视觉上非常刺眼。

5.4 导出与自检脚本

导出用 Pandoc 是最省事的方案，一行命令生成 PDF。注意中文字体必须显式指定，否则容易出现方框乱码。

bash复制# 使用 Pandoc 从 Markdown 生成 PDF（需要本地已安装 LaTeX 或 wkhtmltopdf 等 PDF 引擎）
pandoc src/resume.md \
  -o dist/张明-Java后端开发工程师.pdf \
  --pdf-engine=xelatex \
  -V CJKmainfont="Source Han Sans SC" \
  -V geometry:margin=1.6cm \
  -V fontsize=10pt \
  -V colorlinks=true

如果你不想折腾 LaTeX 引擎，用浏览器打印 HTML 版本更稳妥，命令行也能触发：

bash复制# macOS / Linux，用 Chrome 无头模式把 HTML 打成 PDF
chrome --headless --disable-gpu \
  --print-to-pdf="dist/张明-Java后端开发工程师.pdf" \
  --no-pdf-header-footer \
  src/resume.html

导出之后一定要写个检查脚本，把"投出去才发现问题"变成"投之前就发现问题"。下面这个脚本只用了 pdfinfo 和 grep 这类常备工具，没有额外依赖。

bash复制#!/usr/bin/env bash
# 文件路径：scripts/check.sh
set -euo pipefail

PDF="dist/张明-Java后端开发工程师.pdf"
SRC="src/resume.md"

if [ ! -f "$PDF" ]; then
  echo "[FAIL] 未找到导出文件：$PDF，请先执行导出命令"
  exit 1
fi

PAGES=$(pdfinfo "$PDF" | awk '/^Pages:/ {print $2}')
echo "[INFO] 总页数：$PAGES"
if [ "$PAGES" -gt 1 ]; then
  echo "[FAIL] 简历超过一页，请压缩内容或调整行距"
  exit 1
fi

# 检查 PDF 内文字是否可提取，可提取才说明不是图片式 PDF
CHARS=$(pdftotext "$PDF" - | tr -d '[:space:]' | wc -m)
echo "[INFO] 可提取字符数：$CHARS"
if [ "$CHARS" -lt 500 ]; then
  echo "[FAIL] 提取字符数过低，PDF 可能是图片，ATS 无法解析"
  exit 1
fi

# 检查必填字段
for KEY in "13800000000" "zhangming@example.com" "教育背景" "项目经历" "专业技能"; do
  if ! grep -q "$KEY" "$SRC"; then
    echo "[FAIL] 源文件中缺少关键字段或栏目：$KEY"
    exit 1
  fi
done

echo "[PASS] 自检通过，可以投递"

这段脚本检查四件事：页数、文字可提取性、必填联系方式、标准栏目名。第二条是最容易被忽略的——很多在线工具导出的 PDF 本质是整页图片，人看着没问题，机器一个字段都抽不出来，白投。

5.5 JD 关键词覆盖检查

投不同岗位时，最值得做的一件事是对齐关键词。用 Python 标准库写个小脚本就够了，不需要任何第三方依赖。

python复制# 文件路径：scripts/match.py
import re
from pathlib import Path

STOPWORDS = {
    "的", "了", "和", "与", "或", "等", "熟悉", "了解", "掌握",
    "负责", "参与", "优先", "具备", "能力", "经验", "相关", "以上",
}


def load_tokens(text: str) -> list[str]:
    # 中文按连续汉字切块，英文与数字按单词切，保留技术名词原形
    zh = re.findall(r"[\u4e00-\u9fa5]{2,}", text)
    en = re.findall(r"[A-Za-z][A-Za-z0-9+#.]*", text)
    tokens = []
    for item in zh + en:
        token = item.strip().lower()
        if token in STOPWORDS or len(token) < 2:
            continue
        tokens.append(token)
    return tokens


def main() -> None:
    jd_text = Path("jd/backend-2025.txt").read_text(encoding="utf-8")
    resume_text = Path("src/resume.md").read_text(encoding="utf-8").lower()

    jd_tokens = load_tokens(jd_text)
    # 去重并保留原顺序
    seen = set()
    unique_jd = []
    for t in jd_tokens:
        if t not in seen:
            seen.add(t)
            unique_jd.append(t)

    hit = [t for t in unique_jd if t in resume_text]
    miss = [t for t in unique_jd if t not in resume_text]
    rate = len(hit) / len(unique_jd) * 100 if unique_jd else 0

    print(f"JD 关键词总数：{len(unique_jd)}")
    print(f"已覆盖：{len(hit)}，覆盖率：{rate:.1f}%")
    print("\n未覆盖关键词（按需补充，不要硬塞）：")
    print("、".join(miss[:60]))


if __name__ == "__main__":
    main()

运行方式和预期输出：

bash复制python scripts/match.py

text复制JD 关键词总数：86
已覆盖：61，覆盖率：70.9%

未覆盖关键词（按需补充，不要硬塞）：
消息队列、redis、分布式锁、单元测试、jvm、垃圾回收、linux、shell

覆盖率不是越高越好，70% 左右是个合理区间。剩下未覆盖的词，只有在你真的接触过的情况下才补进简历。硬塞"精通 Redis"然后在面试里被追问持久化机制，代价远大于少一个关键词。

6. 运行结果与效果验证

生成完 PDF 不要直接投，先做四个维度的验证，每个维度都有明确的通过标准。

第一个维度是视觉。把 PDF 在 100% 缩放下从头翻一遍，检查三件事：内容是否完整落在一页、是否有孤行被切到下一页、标题栏和正文的层级是否一眼可辨。如果你在手机上打开这份 PDF，姓名和求职意向应该在第一屏内出现。

第二个维度是机器可读。用 pdftotext dist/xxx.pdf - 把内容抽出来看一眼，如果抽出来是一堆乱码或者空白，说明字体嵌入或文字层有问题。抽出来的文本里应该能按顺序看到姓名、电话、邮箱、学校、项目名。顺序错乱通常是因为用了绝对定位或者多栏布局。

第三个维度是链接。如果简历里放了 GitHub 和博客链接，在 PDF 里点一下，确认能跳转。很多人复制粘贴时带上了不可见字符，链接在 PDF 里看着正常，点开是 404。

第四个维度是关键信息校验。对着 check.sh 的输出逐条确认：页数 1、字符数大于 500、必填字段齐全。这三项过了，基本不会出现"投出去才发现电话写错一位"的低级事故。

如果验证失败，第一步应该看哪里？先看源文件。简历的问题 90% 出在内容太长而不是样式太差，把 src/resume.md 的行数数一遍，超过 90 行基本压不住一页。其次看 CSS 的 @page 边距，边距设置过大会显著压缩可用高度。最后才看字体，字体问题通常表现为整体变宽，而不是内容变多。

7. 常见问题与排查思路

表格里的第一行是最常见的问题。很多人以为是模板不好，其实是内容超了。判断方法很简单：把项目经历里每条 bullet 的最后一句删掉，如果还是两页，说明需要整段合并；如果刚好一页，说明你的问题不在模板，在于没做减法。

第三行和第七行是隐藏最深的问题。图片式 PDF 和栏目名不规范，都不会在你自己打开时暴露，只有到了筛选系统那里才出问题。这也是为什么第 5 节要写自检脚本——把不可见的失败变成可见的报错。

8. 三无背景的内容填充方法与最佳实践

8.1 把"没有经历"翻译成"有事实"

三无同学最大的认知偏差是认为只有"公司实习"才算经历。实际筛选逻辑里，招聘方关心的是你有没有完整做过一件事、遇到问题怎么解决、结果如何。课程设计、毕业设计、自学项目、开源仓库、社团活动、竞赛参与（哪怕没获奖）、兼职、线上课程的大作业，都满足这个条件。

关键在于翻译方式。以课程设计为例，原始描述通常是"完成了一个学生成绩管理系统，实现了增删改查"。这句话的问题不是假，而是没有任何区分度，因为同班三十个人都这么说。改写路径是补三样东西：规模、难点、结果。规模指数据量、接口数、模块数；难点指你真正卡住过的地方；结果指可验证的变化，比如耗时降低、覆盖场景增加、用户反馈数量。

改写后可能变成："负责数据库设计与成绩统计模块，实现按班级、科目两个维度的平均分与及格率统计；用 JDBC 批处理替换逐条插入，导入 2000 条记录耗时从约 12 秒降至 1.5 秒。"同样一件事，信息量完全不同，而且每一句都能被追问，追问也答得出来。

8.2 技能栏怎么写才不空洞

技能栏最常见的写法是列一串名词加"熟悉/了解"，这种写法的问题是无法区分深浅。更有效的做法是分组加限定：语言一组、框架一组、数据库一组、工具一组，每组后面用括号补充你能做到什么程度。

比如"MySQL"这一项，写"了解"没有信息量，写"理解索引原理与执行计划，能定位慢查询"就有明确的边界，面试官会顺着这个边界提问，你答得上来就是加分。反过来，写"精通 MySQL"但答不出聚簇索引和回表，就是给自己挖坑。

技能栏还有一个原则：只写能在项目经历里找到对应证据的技能。技能栏写了 Redis，项目里必须有一处用到 Redis 的描述；如果项目里没有，要么补一个练手项目，要么把这一项删掉。技能与经历对不上，是面试里最容易被戳穿的地方。

8.3 量化与命名的工程规范

量化不是编数字，是把已有的数字写出来。可量化的对象包括：数据规模（表数量、记录条数、接口数）、性能指标（响应时间、导入耗时）、覆盖范围（支持的查询条件数、页面数）、协作规模（试用人数、参与人数）、时间投入（周期长度）。如果一个数字都想不出来，说明这件事你做得太浅，考虑换一个项目写。

命名和时间格式必须统一。日期统一 2024.03 - 2024.06，技术名词统一大小写（Spring Boot 不要一会儿 springboot 一会儿 SpringBoot），学校名和专业名用官方全称。这些细节不影响理解，但影响"这个人是否严谨"的第一印象，而这个印象在几秒的筛选里权重很高。

文件命名也建议规范。投递用的 PDF 命名成 姓名-岗位-学校-手机号.pdf，比如 张明-Java后端开发工程师-某某大学-13800000000.pdf。HR 下载下来是一堆"简历.pdf"的时候，命名规范的那份会被优先打开。

8.4 用 Git 管理简历版本

把简历放进 Git 仓库，收益比想象中大。第一，每次修改都有记录，能回退；第二，可以为不同岗位开分支，比如 main 是通用版，feat/backend 是后端岗定制版，feat/data 是数据岗定制版；第三，投递记录可以写进 README.md，形成可复盘的数据。

推荐的工作流是这样的：主分支保持一份通用版，投递前从主分支拉一个短期分支，改关键词、调项目顺序，导出 PDF，投完把这个分支合回去或者删掉。这样做的好处是定制成本很低，而且不会出现"改了十版之后忘了哪版最好"的情况。

.gitignore 至少要包含这几行，避免把生成物和隐私文件提交上去：

bash复制# 文件路径：.gitignore
dist/
*.pdf
*.aux
*.log
.DS_Store
jd/*.private.txt

隐私方面要特别注意。简历里不要写身份证号、家庭住址、紧急联系人，这些信息在初筛阶段没有任何作用，一旦泄露风险却是实打实的。手机号和邮箱建议用专门的求职邮箱，不要用带生日和昵称的私人邮箱。GitHub 仓库设成私有，除非你确实想把它当作品集展示。

8.5 一岗一版的定制策略

通投一份简历是效率最高但转化率最低的做法。合理的做法是维护一份"母版"，每次投递做三处微调：调整技能栏顺序，把 JD 里出现频次最高的技术放到最前面；调整项目顺序，把和目标岗位最相关的项目提到第一；替换关键词表述，把 JD 的原词替换进你的描述里。

这三处调整加起来不超过十分钟，但对关键词匹配率的提升非常明显。前面那个 match.py 脚本就是为这个环节服务的：改之前跑一次看覆盖率，改之后跑一次看提升，能直观判断这次定制有没有效果。

需要提醒的边界是：定制不等于编造。JD 要求的东西你没做过，就不要写进技能栏冒充。更稳妥的策略是"靠近"——JD 要求消息队列，你项目中确实没用过，但你可以补一个用消息队列解耦的小练习项目，写进去，这属于真实经历；直接写"精通 Kafka"就属于另一回事了。

9. 后续迭代方向与长期维护建议

第一版简历做完只是起点，真正拉开差距的是后续两到三周的迭代。建议每投出十份就回看一次：哪类岗位有回复、哪类完全没有、面试中被追问最多的是哪一段。被追问最多的那段说明写得最可信，可以考虑往前放；完全没有回复的那类岗位，大概率是关键词没对上，跑一次 match.py 就能看出问题。

技术上还有几个可以继续深化的方向。如果你需要英文版简历，Markdown 路线的优势会非常明显——同一份结构换一个模板就能输出，不需要重排。如果你有多个项目想展示，可以考虑把简历仓库和 GitHub Pages 结合，做一个在线的项目索引页，简历里只放一个短链接，比塞满屏幕的描述更清爽。如果你投的是需要作品集的岗位，把简历当成索引页，把详细内容放到作品集里，两层结构会比一份长简历更专业。

最后一个提醒：简历的终极目标不是"好看"，而是"减少对方的判断成本"。所有优化都应该围绕这一条展开——栏目清晰是为了减少定位成本，量化结果是为了减少验证成本，一页排版是为了减少阅读成本，标准命名是为了减少解析成本。想清楚这一点，你就不会在配色和图标上纠结太久，而是把时间花在把每条经历写清楚上。

如果只能记住一句话，那就是：三无背景不可怕，可怕的是简历读完，对方说不出你到底做成过什么。把这句话当成每次修改后的自检问题，比任何模板都管用。