痛点:一个反复出现的问题
研二开始准备实习,发现自己陷入了一个循环:
每次往 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 和开发者工具。最近在持续更新四个开源项目,欢迎交流。