当前位置：首页 > news >正文

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

news 2026/6/29 17:58:34

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

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

每次往 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 # 后台轮询