lupynow 简历制作与审改
核心理念
简历的问题几乎从不出在"没东西写"，而出在写了但经不起追问。
一个项目做了两三个月，最后简历上只剩"使用 Redis 缓存热点数据，提高查询效率"——这句话任何一个学过的人都能写。面试官看完不知道你遇到了什么问题、为什么这么设计、这东西是不是你真正做的。
所以这份 skill 的目标不是"把简历写满"，而是让每一条都扛得住面试官往下追两层。技术名词本身不值钱，值钱的是你为什么用、怎么做、踩过什么坑、最后效果怎样。
第一步：判断走哪条路
问清楚（或从上下文判断）用户属于哪种情况：
| 情况 | 走哪条路 |
|---|---|
| 手里没有简历，或只有一个很粗糙的初稿 | 路径 A：从 0 到 1 |
| 有一份成型简历，想改好 | 路径 B：审改 |
| 有简历，但要投某个具体岗位 | 路径 B + 定向调整 |
两条路都要走真实性审计（见下文），这是最容易跳过、但价值最高的环节。
通用原则
写任何一条经历时，都按这五条来。它们不是格式要求，而是让内容变得可被追问的方法。
1. 先说业务，再说技术
不要一上来就"技术栈：Spring Boot + Redis + MQ + MySQL"。先告诉读者你在做什么：
校园二手交易平台，包含商品发布、订单交易、即时聊天和消息通知，本人负责商品和订单模块。
有了业务背景，后面的技术选择才有意义。项目开头的背景句不是套话，读者靠它判断你的技术决策合不合理。
2. 写"为什么用"，不写"用了什么"
| 普通写法 | 有信息量的写法 |
|---|---|
| 使用 Redis 缓存商品信息，提高系统性能 | 商品详情属于高频读接口，将商品信息缓存至 Redis；针对不存在的商品设置空值缓存避免穿透，热点 Key 失效时采用互斥重建，避免大量请求同时回源 |
| 使用 RabbitMQ 异步处理订单 | 订单创建后，将消息通知、积分累计等非核心操作通过 MQ 异步处理，减少主链路同步等待；消费端用业务唯一键保证幂等，避免重复消费 |
前者说"我用过"，后者说"我知道为什么用"。面试官关心的是后者。
3. 问题 → 方案 → 结果
每条亮点尽量凑齐这三段：
订单后台支持多条件查询，数据量上来后深分页明显变慢；根据高频查询条件调整联合索引，并将大页查询改为游标分页，接口 P99 由 1.2s 降到 400ms。
但没有真实数据时，宁可不写结果，也不要编。 一个"性能提升 80%"被人问测试数据量、机器配置、压测工具、baseline，答不上来，整份简历的可信度都会塌。
4. 宁给完整分布，不给满分数字
这条容易反直觉，但很重要。
"检索命中率 100%"听起来漂亮，实际上经不起追问——面试官立刻会问 Top-1 是多少、基准集怎么建的、有没有负样本。而给出完整分布（Top-1 66.7% / Top-5 96.3% / MRR 0.78）反而更有说服力，因为它同时证明了你会评测、知道边界、不挑好看的数字。
同理，如果某个指标你自己都觉得虚，主动在面试中交代其局限（"基准规模还小，负样本是我下一步要补的"），比硬撑强得多。
5. 一条主线
投技术岗，就让"基础 → 项目 → 具体技术 → 业务问题 → 优化"这条线清清楚楚。不要 Java、Python、Vue、PyTorch、RAG、Agent、K8s 全塞进去。
什么都会一点 = 什么都不突出。 如果用户坚持要"技术和产品通吃"，可以照做，但要提醒：两面对不上专业候选人，可能两边都不占优。
自检三问
写完每一条，回头问自己：
- 为什么这么做？
- 不这么做会有什么问题？
- 面试官再追两层，我还能不能回答？
三个都答不上来，这条写上去未必加分。
路径 A：从 0 到 1
信息收集
先收素材，再补缺口（顺序很重要——直接开始访谈会让用户面对空白页发呆）：
- 让用户把手边的原始材料丢过来：实习周报、项目文档、课程作业说明、竞赛材料、旧版简历、甚至聊天记录里的工作汇报。有素材就从素材里提取事实，比凭空回忆准确得多。
- 读完素材，整理出一份事实清单（有哪些经历、每条里有哪些具体动作和数字）。
- 针对缺口逐条追问。追问要挖到能扛住面试的程度，见下。
追问的深度
不要满足于"我做了数据清洗"。继续问：
- 具体做了什么清洗？（缺失值怎么处理、异常值判定标准）
- 为什么这么处理？（业务约束是什么）
- 结果是什么？（数据量、耗时、准确率，哪怕是"从 12 万条筛到 8000 条"这种朴素数字）
用户答"记不清了"也没关系——记不清的细节就不写进简历，这是正常取舍，不是失败。
生成初稿
按下面的骨架写，然后用 scripts/ 里的工具生成 docx：
- 头部：姓名 + 目标方向 + 联系方式 + 意向城市
- 教育背景与荣誉：学校、专业、时间；竞赛和奖学金单独成行
- 实习经历：公司、岗位、时间；3-4 条 bullet
- 项目经历：项目名 + 一句话定位；3-4 条 bullet
- 专业技能：3-5 条，每条一行，别堆名词
篇幅目标 1 页（应届生标准）。内容多到放不下时，砍的优先级是：无关内容 > 罗列型条目 > 套话总结 > 细节。
排版
默认使用 assets/template.docx 的样式（青绿配色、微软雅黑、A4）。它已经调好，直接 unpack 后替换内容即可。
具体参数和调优方法见 references/layout.md。
路径 B：审改
先诊断，别急着改
读原简历（.docx 用 pandoc 提取文本，或 unpack 看结构），然后分类每一条：
| 类型 | 特征 | 处理 |
|---|---|---|
| 能扛两轮追问 | 有具体数字、有取舍理由 | 保留，微调表达 |
| 只能扛一轮 | 有动作，缺"为什么" | 补设计理由（问用户） |
| 一问就崩 | 全是名词、罗列、套话 | 删除或重写 |
把这份诊断先给用户看，让他知道你要动哪里、为什么。直接开改会让人不安。
常见病症
- 加粗泛滥：满篇粗体等于没有重点。检查 XML，加粗应该只用在标签和标题上。
- 术语堆砌："边缘诊断""平台告警""上下文管理""结构化交付"堆在一起，问哪个都答不实。
- 动作多、结果少：全是"参与/梳理/整理/协同"，看不到产出。
- 无关内容占位：跟目标岗位零关系的经历（比如投技术岗写"推进易拉宝制作"），挤掉了硬货。
- 硬货被埋：金奖、国奖被塞进小字行里。荣誉要单独立行。
- 顶部自我摘要：一段加粗的"我具备……"大词合集，第一眼就露怯。删掉，或压缩成一行具体事实。
- 数字存疑：精确到个位的漂亮数字（"命中 21/21""提升 47.3%"）最容易被深挖。逐个核对来源。
- ⚠️ 注意：判断"加粗泛滥"这类问题要看 XML，不能只看 pandoc 提取的文本——pandoc 会把所有粗体标成
**，容易误判。从 XML 看<w:b w:val="0"/>才是真相。
改法优先级
- 删掉无关内容和套话（省下的篇幅留给硬货）
- 给每条补上"为什么"
- 把罗列型条目合并或删除
- 最后才调排版
真实性审计（强制）
这是整个流程里最不能省的一步。
用户写简历时会不自觉地混淆两件事：方案里设计的 和 实际做出来的。前者写在文档里很漂亮，但没有代码支撑，面试官一追就穿。
怎么审
对每一条技术描述，逐条问：
| 问题 | 判断 |
|---|---|
| 这个功能有代码吗？哪个文件？ | 有 → 可写"实现" |
| 跑通过吗？有输出吗？ | 跑通 → 可写具体结果 |
| 有量化数据吗？怎么测的？ | 有测试 → 写数字 |
| 只在方案/文档里？ | 只能写"设计"或"评估后决定不做" |
典型陷阱
- 方案里有、代码里没有：比如方案写了"缺口改写查询 ≤3 轮"，但代码只规定由 Agent 执行，没有自动循环 → 只能写"由 Agent 继续检查缺口"，不能写"实现自动查询重写"
- 文档指标 ≠ 代码限制：方案写"4 万 Token 预算"，代码实际是"60000 字符" → 写"字符"
- 逻辑实现了但没生效：代码里有审核状态加权，但实际数据全是 pending_review → 可以写"实现"，但要准备好回答"生效了吗"
- 只在部分数据上成立：时间定位只在 14 个切片上有，且有误报 → 不宣称该能力
发现不一致时怎么办
不要自己决定写哪个版本，回去问用户真实情况。 用户往往能给出精确的边界（"这个落地的，那个只是规范"），而这正是简历最有价值的部分——知道自己的边界在哪，本身就是能力。
审计完，把每条降级成"能扛住代码核验"的表述。
产出物
改完简历后，除了文件本身，按用户需要产出：
修改说明
列清楚：删了什么、合并了什么、数字改了什么、为什么。让用户能对照原件理解每一处改动。
追问预演
针对简历里每个可能被深挖的点，列出：
- 面试官会怎么问（往下追两层）
- 用户手上有什么证据
- 当前表述在什么情况下会崩
面试题
按目标岗位生成常见题目（基础八股、场景设计、项目细节），与追问预演分开——追问预演针对"你自己写的这几条"，面试题是岗位通用题库。
跨版本数字核对
用户往往有多份简历（不同方向的定向版）。同一个指标在不同文件里必须一致，否则投出去对不上。 建立一张对照表，列出每个指标在每个文件里的值，标出不一致的。
⚠️ 每次更新数字时，主动检查其他版本是否需要同步。
技术操作
读简历
# 提取文本（含格式标记）
pandoc "简历.docx" -o extracted.md
# 看真实排版结构（判断加粗、字号、样式）
python <docx-skill>/scripts/office/unpack.py "简历.docx" unpacked/
改简历
核心：保留原排版，只改内容和条目增删。 unpack 后编辑 word/document.xml：
定位段落：用
w14:paraId作为锚点，它唯一且稳定改文本：替换
<w:t>...</w:t>里的内容删段落：匹配从
<w:p w14:paraId="XXX">到</w:p>的整块插入段落：复制相邻段落的结构，换一个未使用的 8 位十六进制 paraId
改排版：调
word/styles.xml里的样式定义和 document.xml 的<w:pgMar>⚠️ 绝对不要动
<w:pStyle w:val="...">—— 它的值必须和styles.xml里的w:styleId一字不差。模板用的是数字 ID（164-168），看着不像样式名，但完全合法。见过这个坑：把
w:val="167""顺手规范化"成w:val="bullet"，结果所有段落样式断链。Word 不报错，静默回退到默认样式 —— 文件能正常打开、字数页数都对、渲染出来也像份简历，但配色、字号、标题下划线全部丢失，交付的是一张白板。而且这种文件用肉眼看 PDF 很容易漏，因为版式还在，只是变成了黑白的。改完务必跑
scripts/check_residue.py，它会检查样式断链（check_style_links）。
改完用 pack 打包：
python <docx-skill>/scripts/office/pack.py unpacked/ out.docx --original "简历.docx"
注意：如果 pack 报 Failed to parse the XML resource 'http://dublincore.org/...'，那是校验器联网失败，不是你的改动有问题 —— 用 --validate false 跳过，但之后必须自己验证 XML 合法性（xml.etree 解析一遍 + 检查 paraId 无重复）。
验证（必做）
改完简历必须验证这几件事，缺一不可：
页数 —— 用
scripts/page_count.py（走 Word/WPS COM，Windows 上最准）视觉 —— 渲染成图片目视检查（
scripts/render_pdf.py），确认没有溢出、挤压、断裂数字和旧内容残留 —— 提取 PDF 文本，grep 检查：新数字进去了吗？旧数字清干净了吗？
模板占位符 —— 从
assets/template.docx或别人给的模板起稿时，模板自带的占位符必须全部换掉：你的姓名、目标方向（2027届）、your@email.com、https://github.com/your-name/your-repo、起止时间、【...】这类残留比技术问题更致命，也最容易被漏掉。 面试官可能会追问你"Redis 缓存为什么用互斥重建"，但 HR 看到
your@email.com是直接淘汰——连追问的机会都没有。发现占位符而用户又没给真实信息时，替换成显眼的待填标记（如
【你的邮箱】），不要原样留着 —— 原样留着用户很容易滑过去，方括号一定会被注意到。同时在交付说明里单独列出来。跑
scripts/check_residue.py会自动检查这些。它直接读 OOXML 取所有文本节点，能抓到藏在超链接字段里的邮箱和链接 —— 用 pandoc 提取会把这些丢掉，报出"clean"这种最危险的假阴性。文档属性（docProps） —— 右键文件「查看属性」就能看到的那些字段：作者、标题、主题、关键词、缩略图。
从别人的模板起稿时，这些会原样继承过来，等于在简历里夹带了一张上一任作者的便签。实测中最典型的情况是：正文全部改好、占位符也换干净了，但
dc:creator还写着原模板主人的名字，dc:title是「XX的简历」，关键词里躺着岗位方向。HR 只要点一下属性就看见了。起稿时如果用了别人的模板，检查一遍，把
docProps/core.xml、custom.xml换成中性内容，删掉thumbnail。scripts/check_residue.py会把这些报出来。
如果页数超标，调优顺序见 references/layout.md：先砍内容，再调段间距，最后才动行距和字号。
行距不能调到小于字号（9.5pt 的字，行距乘数低于约 0.87 会重叠）。
Windows 环境注意
- 所有文件操作显式指定
encoding='utf-8'，否则 GBK 会报 UnicodeDecodeError - 用项目自带的 venv 跑 Python（如
<项目>\.venv\Scripts\python.exe），执行前export PYTHONIOENCODING=utf-8 && export PYTHONUTF8=1 - LibreOffice 的
soffice.py脚本在 Windows 上会因AF_UNIX报错，改用 Word/WPS 的 COM 接口（见 scripts/） - Word COM 有残留实例时会报
ComputeStatistics失败，改用DispatchEx("KWps.Application")走 WPS
保密边界
改简历时经常要处理公司内部信息。保留方法论，模糊掉具体数值：
- ✅ "针对同一技术指标存在多种口径，建立冲突清单并列展示、不自行选边"
- ❌ "20Hz–150kHz 是算法上限，4Hz–192kHz 是传感器采样率"（这是公司技术细节）
拿不准时问用户：这个数字可以对外说吗？
参考文件
references/writing-rules.md—— 写作规则详解与正反例对照references/auditing.md—— 真实性审计的完整追问清单references/interview-prep.md—— 追问预演与面试题的生成方法references/layout.md—— 排版参数、页数调优、常见排版故障scripts/page_count.py—— 统计页数并导出 PDFscripts/render_pdf.py—— 把 PDF 渲染为图片scripts/check_residue.py—— 检查新内容是否写入、旧内容是否残留assets/template.docx—— 默认简历模板（空白样式）