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

📅 2026/6/29 17:54: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 还是说了 WHYHOW叙事弧线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.10DeepSeek API任何 OpenAI 兼容接口都行LaTeXlatexmk xelatexWindows / 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-syncMIT 协议。README 有中英文两个版本里面包含完整的配置指南和 LaTeX 标记规范。如果你的简历是 LaTeX 写的而且项目还在频繁更新可以试试看。如果不是 LaTeX 用户可能暂时用不上但评分体系的设计思路或许可以参考。目前主要做 AI Agent 和开发者工具。最近在持续更新四个开源项目欢迎交流。