求职期间项目一直在更新,简历总是忘了改——于是我写了一个自动同步工具

求职期间项目一直在更新,简历总是忘了改——于是我写了一个自动同步工具

痛点:一个反复出现的问题

研二开始准备实习,发现自己陷入了一个循环:

每次往 GitHub push 代码后,简历上的项目描述就过期了。打开 Overleaf 想更新,脑子里几个声音打架——「这次改了啥来着?」「上一版写的好像也不太行」「算了先不改了,下次再说」。

一周 push 四五次,改不了两次。拖久了简历上的描述越来越虚,面试被问到项目细节时也接不上。

这个问题我琢磨了一下,本质是:

代码和简历是同一件事的两种表达,但它们之间没有连接。代码是你真正做了什么,简历是你告诉别人做了什么。两者永远不同步,因为同步的成本太高——每次改代码都要手动去改简历,而改简历又涉及「回忆变更 → 组织语言 → 排版编译」三个步骤。

所以我想:能不能改成代码 push 之后,只需要看一眼 diff,点一下确认,简历就能自动更新?

为什么选择 LaTeX + LLM 这个组合

这里有个先决条件:我的简历是用 LaTeX 写的(Overleaf 编辑)。

LaTeX 有个好处——它是纯文本源码。这意味着 LLM 可以精准地找到标记块、替换内容,而不会像 Word 那样有格式兼容问题。我在.tex文件里加了标记注释:

% RESUME_PROJECT_START: my-project \item \textbf{项目描述:} ... % RESUME_PROJECT_END: my-project

这样工具就知道哪里能改、哪里不能碰。

至于 LLM,一开始的想法很简单——把git diff丢给 LLM,生成几句描述。但试过之后发现一个问题。

核心难点:LLM 写的简历 bullet,一眼就能看出是 AI 写的

之前试过直接让 LLM 写简历,出来的东西通常是两种极端:

  • 虚高型:「大幅提升了系统性能」——提升了多少?怎么衡量的?不知道

  • 流水账型:「修改了 checkpoint.py 的 backup 方法」——HR 不知道你在说什么

真正的痛点不是「生成文字」,而是「生成的文字要能经得起面试官追问」

换句话说是:面试官看到这条 bullet 说「你怎么衡量的」,你能立刻在脑子里定位到代码里的证据。

怎么解决的:三件事

1. 不是只让 LLM 写,而是写完之后打分

生成完一条 bullet 之后,不直接输出,而是由一个独立的Reviewer按 10 个维度打分:

维度权重它问的问题
量化硬度1.5有数字吗?是实测的还是编的?
个人贡献区分度1.5能看出来是你做的还是团队做的吗?
技术深度1.2说了 WHAT 还是说了 WHY+HOW?
叙事弧线1.0有「问题→方案→结果」吗?
对抗性追问存活率1.5「你怎么衡量的?」「你的贡献比例?」——能回答吗?
简洁度与可扫描性1.2单句 ≤ 80 字?HR 扫 2 秒能抓重点吗?
LaTeX 合规1.0特殊字符转义了吗?
动词强度0.8「参与」「使用」还是「主导」「从零构建」?
规模感1.0读者能感知项目体量吗?
冗余度0.8相邻 bullet 是不是在说同一件事?

加权总分不到 8.5 就打回重写。每个扣分项必须有具体原因和建议,不是随便打个分。

这 10 个维度的设计逻辑是——它们对应的是面试中真正会被问到的点。量化硬度不够?面试官问「这个 50% 是怎么算出来的?」你答不上来。个人贡献区分度模糊?面试官怀疑「这真的是你做的吗?」

2. 生成完之后,Reviewer 挑刺,Reviser 改

单次 LLM 调用的质量波动很大,同一段 diff 有时生成的很好,有时很敷衍。

改成了三轮管线:

Generator(生成初稿) ↓ Reviewer(质疑者)→ 10 维评分 ├── 总分 ≥ 8.5 且所有维度 ≥ 5 分?→ 通过 └── 不满足 → 列出具体问题,交给下一轮 ↓ Reviser(裁决者)→ 只改有问题的条目,不动已通过的 ↓ 回到 Reviewer 重新评分,最多 3 轮

这里的核心设计是Reviser 只改有问题的地方,不是全部重写。因为全量重写会引入新的问题,而且浪费 token。

3. 不需要新 commit 也能优化已有描述

有时候不是代码改了,而是觉得之前的 bullet 写得不好。加了一个Polish 模式

Polish 模式的改动规则: ├── 拆文字墙(单句 > 80 字 → 拆分) ├── 信息优先级裁剪(每 bullet ≤ 1 核心主张 + 2 支撑数据点) ├── 括号去嵌套 └── 相邻 bullet 说同一件事 → 合并

Polish 走的是独立的审查管线,5 个可读性维度(文字墙、括号嵌套、可扫描性、信息冗余、信息密度),评审标准比内容生成时更侧重于表达结构。

和 Agent-hub 的联动(额外加上的)

这个项目后来成了我的多 Agent 系统 Agent-hub 的一个节点,但这不是一开始设计好的,而是后来发现的一个自然延伸——

当 Agent-hub 调度 resume-sync 去更新简历时,resume-sync 会自动读取 Agent-hub 的agent.yaml,发现它是调度系统 → 在 LLM 生成 prompt 中注入子项目关系上下文。这样 LLM 生成的描述不再是一个个独立的项目,而是一套有系统层级感的表达:

没有调度感知有调度感知
"开发了 Agent Hub,一个多 Agent 调度系统""设计了一套多 Agent 协同调度框架,统一调度 3 个异构 Agent(代码生成、质量诊断、简历同步),通过 CLI Bridge 实现零侵入集成"

这个「调度关系感知」目前只是一个可选功能——有agent.yaml就自动启用,没有就跳过,不影响正常使用。

安全性

因为这个工具会修改 LaTeX 源码,所以几个安全措施是必须的:

  • 标记块隔离:只改% RESUME_PROJECT_START/END之间的内容,其余部分不碰

  • 每次写入前自动备份.bak_{时间戳}副本

  • 后台模式只通知不自动改:daemon 默认会弹 Windows Toast 提示你,不会擅自改文件

  • API Key 走环境变量:不在 config.yaml 写明文

技术栈和代码

  • Python 3.10+

  • DeepSeek API(任何 OpenAI 兼容接口都行)

  • LaTeX(latexmk + xelatex)

  • Windows / Ubuntu / macOS 都能跑(只有 Windows Toast 通知是平台特有的)

src/ ├── cli.py # 命令行入口 ├── checker.py # Git 变更检测 + 状态管理 ├── generator.py # LLM 生成管线(10 维评分 + 三轮审查) ├── updater.py # LaTeX 标记块解析与替换 ├── builder.py # latexmk 编译 + PDF 输出 ├── notifier.py # Windows Toast 通知 └── daemon.py # 后台轮询

关于 AI 辅助开发

这个项目 90% 的代码是和 Claude Code 协作完成的。我的角色是:

  • 定义需求边界(评分维度该不该从 8 个扩展到 10 个?)

  • 审查关键设计决策(三轮审查够不够?Reviewer 和 Reviser 要不要共享上下文?)

  • 调试和验证边界 case

为什么这件事本身值得提——这个项目展示了「人类定义问题框架和约束条件,AI 负责实现」的工作模式。那 10 个评分维度、三轮审查管线的结构、安全性的设计考量,这些不是 AI 能主动想出来的,它来自对「简历评审」这个真实场景的分析。

仓库

👉 github.com/xianyu-sheng/resume-sync

MIT 协议。README 有中英文两个版本,里面包含完整的配置指南和 LaTeX 标记规范。

如果你的简历是 LaTeX 写的,而且项目还在频繁更新,可以试试看。如果不是 LaTeX 用户,可能暂时用不上,但评分体系的设计思路或许可以参考。


目前主要做 AI Agent 和开发者工具。最近在持续更新四个开源项目,欢迎交流。