程序员维护简历的现状：每次更新打开 Word，复制旧版本，改一遍，导出 PDF，重命名 resume_v3_final_final.docx。两个月后想知道”3 月份改了哪一条”——不知道。中英双版同步——一周后发现内容偏差。换模板——重新排版 4 小时。
这些痛点本质都是没用版本控制。把简历当代码项目对待，git + YAML 一次解决全部。
Word 维护简历的 5 个工程性痛点
| 痛点 | Word | YAML + git |
|---|---|---|
| 历史可追溯 | final_v3_v4.docx 文件名打架 | git log 一眼看每次改动 |
| 内容 diff | 二进制无法 diff | 一行 diff 看清改动 |
| 多版本管理 | 多个 docx 副本，容易投错 | 分支 / tag 隔离 |
| 双语同步 | 改一份忘一份 | git diff 强制提醒 |
| 模板与内容耦合 | 内容嵌在排版里，改模板要重排 | 数据 / 渲染分离 |
最后一条最关键——Word 简历里的”内容”和”排版”是焊死的。换主题 = 重新做一份。YAML 简历里字段名是稳定接口，喂给不同模板渲染器即可。
YAML + git 的标准工作流
仓库结构：
resume/
├── resume.zh.yaml # 中文主版
├── resume.en.yaml # 英文主版
├── README.md # bio 概述 + 项目链接
├── exports/ # 历史 PDF (.gitignore 进 exports/*.pdf)
└── .gitignorecommit 规范（仿 conventional commits）：
git commit -m "feat(experience): add Doubao MoE pretraining role"
git commit -m "docs(skills): bump from Webpack to Vite"
git commit -m "fix(date): correct internship end month"
git commit -m "refactor(summary): tighten phrasing for senior pitch"半年后用 git log --oneline 能一目了然每次改动的意图。
多版本投递——用分支：
git checkout -b branch/anthropic
# 强化 LLM alignment 经历，淡化早期 Web 项目
git commit -am "tailor for Anthropic Member of Tech Staff"
# 投递使用这条分支生成 PDF不同岗位拉不同分支，main 保持基线，cherry-pick 通用改动。
把简历放公开 GitHub 的隐私边界
完全公开仓库 = 任何人能扒到联系方式 → 爬虫 / 骚扰电话 / 已知漏洞针对。
3 种处理策略：
| 策略 | 适合 | 牺牲 |
|---|---|---|
| 完全 public + 脱敏 | 主动求职、想被 HR 主动联系 | 当前在职信息暴露 |
| public 概述 + private 完整 | 大多数情况 | 投递时要切仓库 |
| 完全 private | 在职被动求职 | 失去 social proof |
脱敏推荐做法：
basics:
name: Lin Zixuan
email: linzixuan.public@gmail.com # 不用工作邮箱
phone: "" # 留空，需要时邮件索取
location: 北京 # 城市级别即可，不写区README.md 里直接写：“完整简历请发邮件至 X”——主动权在你手里。
额外信号：维护良好的 GitHub 简历仓库本身是”会用 git / 重视工程素养”的证明，比简历里写”熟练使用 git”强 10 倍。
用 GitHub Actions 自动构建 PDF
每次 push → 自动出 PDF → 投递时拉 release：
# .github/workflows/build-resume.yml
name: build-resume-pdf
on: { push: { paths: ['resume.*.yaml'] } }
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
- run: npx playwright install chromium
- run: node scripts/render-pdf.js # 调用浏览器打开工具页 → print to PDF
- uses: actions/upload-artifact@v4
with: { name: resume-pdf, path: '*.pdf' }每次 commit 都有最新 PDF 可下载，避免”投递前忘了导出新版”。
不同岗位的简历重点
突出 弱化
前端工程师 性能 / 可访问性 / 设计系统 后端服务设计
后端工程师 系统设计 / 高并发 / DB 优化 UI 细节
DevOps 可观测 / SLO / 故障复盘 业务功能
全栈工程师 端到端 product 思维 单一深度
ML / 算法工程师 量化指标 / 论文 / 模型规模 Web 框架知识
DevRel OSS 影响 / 社区 / 写作产出 内部业务系统
独立开发者 / SaaS ARR / 用户量 / 端到端交付 团队协作经验同一份基线 YAML，针对不同岗位 cherry-pick 不同 highlights：
# branch/frontend
experience:
- company: 字节跳动
highlights:
- 主导抖音电商前端基建升级，构建时长 9min → 3.5min
- 推动 SSR 改造，落地页 LCP 3.2s → 1.4s
# branch/devops
experience:
- company: 字节跳动
highlights:
- 设计前端 CI 流水线，构建时长 9min → 3.5min，并发 build 队列时间 -70%
- 推动可观测体系建设，前端 SLO 制定 + 故障定位时间 4h → 25min同一段经历不同切片——HR 拿到的是岗位最相关的版本。
开发者简历的 6 个加分项
- 项目 URL 必填——HR 真的会点。
name: 我的开源框架没 URL = 不存在 - 量化代替形容词——
持续维护→380 PRs / 38 contributors / 月均 12 个 issue closed - 挑岗位匹配的 15-20 个技能，不堆 50 个名词——堆砌反而显得”会得多但都不深”
- 写「PR 数」代替「项目数」——前者证明你”能融入工程流程”，后者只证明你”能 setup repo”
- 链接到博客 / 个人站——HR 真的会读，写作能力是隐形加分
- GitHub contribution graph 截图（可选）——绿格密度本身是 signal
ATS 兼容的 PDF 输出
PDF 输出方式简表（详见另一篇 AI 简历教程）：
- ✅ 浏览器打印 → PDF（本工具采用）：矢量、文字层完整、ATS 可解析、文件 < 100KB
- ✅ LaTeX → PDF（RenderCV 走这条路）：同上 + 印刷级排版，但需要本地 LaTeX 环境
- ⚠️ Word → 导出 PDF：可用，但中文字体替换风险
- ❌ html2canvas / jspdf 截图模式：一张大图，ATS 完全读不到 → 海外大厂秒拒
测试方法：PDF 阅读器里 Ctrl+F 搜公司名 / 技能名 → 能高亮 = ATS 能解析。
最后：工程师”应该”用工程方法做事
写简历是一次自我”推销”——但本质也是数据维护问题。把它当代码项目对待：版本控制、双版同步、CI 自动化、模板换皮，每个环节都用程序员熟悉的工具解决。
1 小时初始化 git 仓库 + YAML 写法 = 此后每次更新只花 5 分钟，远少于 Word 拖拽改格式的时间。