Resume Tailor（简历定制）
Overview
把用户的原简历（或口述经历）改写为面向特定岗位的内容。两个核心能力：
能力一：原版式保真改写（默认）
保留用户原有简历的全部排版——字体、字号、颜色、表格、分栏、页边距、项目符号、装饰线条，
只替换文字内容。用户的模板是他们自己选的，不改。
能力二：双版本产出（按需）
| 版本 | 用途 | 篇幅 |
|---|---|---|
| A 详细版 | 网申、招聘网站、邮件投递、面试准备 | 沿用原版式，2–4 页 |
| B 一页纸版 | 纸质投递、宣讲会、现场面试递交 | 严格 1 页 A4 |
两个版本共享同一套内容素材，区别只在详略取舍。
能力三：英文版同步产出（按需）
用户确认需要时，在中文版定稿后产出一份内容完全同步的英文简历（同一套事实与数字，只换语言与句式）。规范见 Step 6 与 resume-writing-guide.md 第十一章。
最高优先级原则：不改版式
这是本 skill 与普通"重做简历"工具的根本区别。默认必须原地改写用户文件的内容，不重新排版。
铁律
- 读原文件 → 保留结构 → 只替换文字。 不重建文档、不套用新模板、不重新设计配色与版式。
- 替换时保持原段落结构。 原来 3 个项目就还是 3 个项目；原来每个项目 2 行要点就还是 2 行。需要增删条目时，先问用户。
- 保留所有原有格式属性。 替换文字时只改
run.text，不碰font、size、color、bold、paragraph_format。 - 下列元素绝不改动：表格结构、合并单元格、分栏、页眉页脚、页边距、编号/项目符号样式、装饰线、图片与头像、色块。
- 不写视角旁白。 简历里禁止出现分析性、对照性、自我剖析性的句子——那是给 HR 的解说，不是经历本身。红线示例：
- ❌「这正是临床监查最看重的底子」（能力对照/岗位映射，只能出现在给用户的诊断报告里）
- ❌「我清楚自己缺少 XX 经验，已通过 XX 补足」（自我披露短板；短板在面试口头讲，或最多一句"目标进入 XX 领域长期发展"）
- ❌「可迁移能力对照」「岗位视角」这类小节标题（用户 2026-10-19 明确要求删除）
- ✅ 正确做法：把能力融进经历描述本身（"严格执行 SOP、记录可追溯"），标题也不带"视角"字样 - 不确定就留白。 拿不准某处该不该改（比如用户没提过的"自我评价"），保留原文不动，在报告里提一句建议。
例外：什么时候才可以新建版式
只有用户明确要求时才新建排版：
- "帮我重新排一版"、"换个好看的模板"
- "生成一页纸版"（一页纸版本身是衍生版，可新建）
- "这个模板太丑了，重新做"
即便如此，一页纸版也应尽量沿用原文件的字体与配色，只是压缩版面。
保真改写的实现路径（先预检，再执行）
第 0 步永远是环境预检：python scripts/env_check.py --file <简历.docx>。
它 30 秒内告诉你：XML 手术依赖是否齐全、editor_sdk 是否在位、Windows 坑位，并给出本次执行路径结论。
解读与降级方案见 references/execution-playbook.md 第一节。
主路径：XML 手术（零外部依赖，实测零漂移）——全部由 scripts/xml_surgery.py 完成：
python scripts/xml_surgery.py 简历.docx --list列出全部段落与 run 结构，据此编写替换映射- 写
replacements.json（规范见 playbook 第二节；match必须唯一命中，字数守恒按梯度表：≤15字±2 / ≤40字±4 / ≤80字±10 / 更长±15%） python scripts/xml_surgery.py 简历.docx 输出.docx --map replacements.json
—— 工具自动完成：唯一性检查 → 字数检查 → 按"行首空白 run / 标签 run（到「：」为止）/ 正文 run"切分回填 →ET.fromstring校验 → 段落/表格/run 数结构比对，任何一步不过就报错退出且不写盘- 渲染预览（有 editor_sdk 时）：
doc_to_image，必须用英文路径副本；服务繁忙（50000/437009）等 60–120 秒重试 - 无渲染条件时用
scripts/check_one_page.py --file 输出.docx估行数，与原件对比，并在报告里注明"未做渲染级确认"
为什么不用编辑器 SDK 改字（实测于 2026-10-18/19，先前"完全保格式"的结论是错的）：
- doc_replace_text 替换范围内的 run 格式会被重置（颜色丢失、字体回退、加粗边界消失），且把 doc_find 片段坐标当整段用会产生新旧拼接乱码
- doc_update_text_property 的 bold 写入无效、color 设默认值被忽略；doc_find_and_set 返回 ok 但同样不生效
- 结论：SDK 只用于读结构（doc_resolve_document_structure、doc_find）与渲染预览，改字一律走 XML 手术
SDK 相关的坑（速查表见 playbook 第四节）：编辑池脏实例（version>0 先 close_file(force) 重开）；中文路径传 SDK 会变 // 分隔报 not found（复制到英文路径副本）；/tmp 在 Windows Git Bash 不存在（用 $TEMP）。
不要用 python-docx 手搓新文档，也不要用 html-to-docx 重新生成——那都会丢版式。
若原文件是 .pdf，先告知用户"PDF 无法保真改写，需要提供 docx 原件"，或产出一个新 docx（并明确说明版式已重置）。
核心内容原则
- 不编造。 任何数字、公司名、项目名、技术栈都必须来自用户提供的材料或用户确认过的回答。缺失关键数据时先问，不要用"提升了 XX%"这类占位符糊过去。若用户明确允许，可用
【待确认：xxx】标记出来，最后统一提醒用户替换。 - 动词开头，结果收尾。 每条经历的主句用强动词（负责→主导/独立完成/推动；做了→设计并落地），句尾尽量落到结果或影响。
- 量化优先。 能量化的必须量化：规模、幅度、时间、成本、质量、影响面。给不出精确数字时用区间或量级并标注估算。
- 关键词对齐 JD。 用户给了 JD 就必须做关键词映射。JD 里有但简历里没体现的，要么真实补上，要么在报告中明确标为缺口。
- 一页纸不是删字数，是换结构。 砍背景铺垫、合并同类项、把版面留给最匹配的 2–3 个项目。
工作流
Step 0 — 确认输入、目标岗位与改写模式
必问四项（一轮问完，用 AskUserQuestion，maxItems 上限正好 4，四项一次问完；用户界面放不下时 ④ 可并入 ③ 的选项描述里）：
① 改写模式
| 选项 | 说明 |
|---|---|
| 保留原版式，只改内容（默认推荐） | 原地替换文字，排版完全不动，输出到新文件 |
| 保留版式 + 另出一页纸版 | 原版式改详细版，再额外生成一页 A4 |
| 重新排版 | 不保留原样式，重新设计版式 |
② 目标岗位
先在 references/job-profiles.md 的岗位索引里找匹配项。库里覆盖 40 个方向，分 8 组：
| 组 | 门类 | 含方向（编号） |
|---|---|---|
| A | 信息技术与算法 | 技术研发01、嵌入式硬件20、半导体21、AI算法26、数据分析04、数学统计精算40 |
| B | 电子电气·通信·自动化 | 电子电气22、通信射频23、自动化24、机器人25、能源电力新能源32 |
| C | 机械与运载 | 机械设计27、汽车28、航空航天29 |
| D | 材料·化工·环境·食品·制造 | 材料30、化工31、环境33、食品34、生产制造质量16 |
| E | 土木·建筑·资源·安全 | 土木结构BIM35、建筑规划36、测绘地质37、安全EHS38 |
| F | 生物医药 | 医药研发12、临床研究13 |
| G | 商科与职能 | 产品02、运营03、市场05、销售06、财务07、金融08、HR09、法务10、设计11、供应链15、行政17 |
| H | 公共·教育·科研·通用 | 教育14、公务员18、科研高校39、应届通用19 |
选择策略：
- 用户说了具体岗位 → 直接匹配方向，跳过门类
- 用户说"理工科"/"技术岗"/不确定 → 先给 8 个门类让他挑（不要列 40 个）
- 用户给了专业背景（如生物技术、机械、材料）→ 按专业列出 3–4 个最可能的方向 + "其他（我输入岗位名）"
- 不要一次列超过 5 个选项，选项多了用户反而选不出
用户给了 JD 就不问了，直接从 JD 提取，并在报告里说明"已按 JD 关键词匹配"。
②-b 40 个方向都对不上时（必须停下来问，不许硬套）
判定：用户说的岗位名在索引里找不到对应方向，或用户明确说"都不是"。
禁止：
- 把"最接近"的方向当答案（如"储能系统工程师"直接按 32 新能源写而不问、"医疗器械注册"按 13 临床研究写）
- 自己凭想象编一套岗位模板
- 跳过询问直接动手改
必问 4 项（一轮问完，尽量让用户口述而不是选择题）：
| # | 问什么 | 为什么问 |
|---|---|---|
| 1 | 岗位全名（公司里实际叫什么，带职级更好） | 同一个词在不同公司差别很大（如"工艺工程师"在芯片厂和在化工厂是两回事） |
| 2 | 行业 / 目标公司（举 2 家最好） | 决定用词、合规口径、指标单位 |
| 3 | 每天具体做什么（3–5 条日常任务） | 比岗位名有用得多，直接决定能力权重 |
| 4 | 有没有 JD（贴原文最好） | 有 JD 就跳过 2、3，直接从 JD 提词 |
问完先出一张「临时方向卡」给用户确认，六项齐全（模板见 job-profiles.md 第三节）：
- 关键词组：从用户的描述和 JD 里原样摘词，不要替换成行业黑话
- 能力权重：按"每天做什么"的时间占比排，不要按想象排
- 项目叙事角度：一句话说清"从哪个维度切入 → 讲什么 → 落到什么结果"
- 必备 / 常见缺口 / 避坑：不确定的写"待确认"，不要编
确认方式：把卡压成 3–5 行摘要回给用户，问一句"这样理解对吗"，不要把整张表甩过去。用户点头再动手。
借力规则：可以借用相邻方向的写作规范（证书怎么写、量化口径、篇幅分配），但叙事角度必须按用户描述定，不能沿用相邻方向的默认角度。
多个目标岗位：一岗一张卡，分别改写；不要用一张卡糊两个岗位。
用户自己也说不清岗位名：让他贴 3 条真实招聘 JD（截图或文字都行），从 JD 反推方向，比逼他想岗位名有效。
③ 工作年限 / 投递场景
应届 or 几年经验？只投一个岗位还是要多版本？
④ 是否需要英文简历（必问，哪怕用户没提）
| 选项 | 说明 |
|---|---|
| 不需要（默认推荐） | 只出中文版 |
| 需要：中文定稿后出英文版 | 中文版（含一页纸版）确认无误后，同步产出英文版 |
| 中英同步推进 | 中英两版一起改、一起交付（用户赶时间或有英文 JD 时） |
- 只要用户投外企、合资企业、英文 JD、海外岗位、留学申请、外企管培生，无论用户选什么，都在报告里提一句"该场景通常需要英文版，需要的话告诉我"
- 用户选"需要"时，追问一句：英文版是逐句对应中文版，还是按英文简历惯例重组（默认：按惯例重组，但事实与数字与中文版完全一致）
- 用户已有英文简历文件 → 问是否作为英文版的版式基准
Step 1 — 读取与拆解原简历
读取用户简历（.docx/.pdf/.md/.txt）。Office 文件走 workbuddy-office-routing 路由。
建立素材清单（内部使用）：
【有据可查】原文已有信息 —— 可直接用
【需补充】缺数字/缺职责/缺结果 —— 必须问用户
【存疑】时间线冲突、职级与职责不匹配、技术栈与年限矛盾 —— 向用户核对
【可删】与目标岗位无关、过于久远、重复度高
必查项：时间线连续性与重叠 / 职级 vs 职责匹配度 / 技术栈与项目年份 / 数字自洽。
同时对每一段做版式登记（这是保真改写的前提）：
段落ID | 原文 | 是否需改 | 改后文字 | 字数变化
字数变化控制在 ±15% 以内——超出容易挤破原版式。
Step 2 — 若材料不足，进入采访模式
按 STAR 骨架逐个项目提问（模板见 references/resume-writing-guide.md）：
- S 项目是什么、为谁解决什么问题、团队规模、你的角色
- T 你具体负责哪一块（边界清晰，避免把团队成果写成个人成果）
- A 用了什么方法/技术/工具、最大难点、怎么决策
- R 结果如何——量化指标、上线情况、被谁使用、是否复用
一次只问 1–2 个项目。用户答不上数字时给选项引导（"是变快了还是变省事了？大概几成？"）。
Step 3 — 按岗位方向重写内容
读取 references/job-profiles.md 中对应方向的配置，按该方向的能力权重、叙事角度、关键词组改写。
若该方向是 Step 0 现场生成的临时方向卡（库中对不上），就读那张卡，按卡里的六项改写；不要回头去套相邻方向的默认叙事角度。报告里要注明"本版按你的描述设定方向，非标准库模板"。
3.1 岗位配置怎么用
每个方向都给出了 6 项配置，逐项落到简历上：
| 配置项 | 怎么用 |
|---|---|
| 关键词组 | 优先在职责/成果条目里自然融入（必须真实） |
| 能力权重 | 决定哪个项目放前面、写多细（权重高的多写） |
| 项目叙事角度 | 决定"项目介绍"往哪个方向引（技术？业务？规范？） |
| 必备证书/工具 | 有就必须显眼位置；没有则在报告里建议补 |
| 常见缺口 | 自查清单，避免踩同样的坑 |
| 避坑提示 | 该行业的红线，写之前先看一眼 |
3.2 跨岗位通用规则
- 内容权重排序：相关经历 > 通用能力经历 > 无关经历（压成一行或删）
- 年限决定篇幅：应届 1–2 页 / 1–3 年 2 页 / 3–5 年 2–3 页 / 5 年以上 3 页
- 教育位置：应届放第 2 位；3 年以上压到末尾一行
- 岗位不在库中：提取 JD 关键词 → 按通用逻辑处理 → 报告里说明"无专属模板，建议提供 JD"
3.3 项目经历写法
- 项目介绍：2–3 句，背景/目标 + 规模 + 你的角色定位
- 项目职责：3–5 条，动作 + 方法/技术 + 范围
- 项目成果：2–4 条，必须带数字或明确影响
> 字数预算：改写后的文字要与原段落字数接近。原来一行只有 20 字，就不要改成 45 字——
> 会把原版式挤变形。宁可少写一条，也不要破坏版面。
Step 4 — 生成输出
4.1 保留版式模式（默认）
- 先跑
python scripts/env_check.py --file 简历.docx预检（playbook 第一节） python scripts/xml_surgery.py 简历.docx --list读出全部段落与 run 结构- 按 Step 3 定稿的内容写
replacements.json（唯一 match + 完整新段文字 + 字数守恒梯度表） python scripts/xml_surgery.py 简历.docx 输出.docx --map replacements.json—— 工具自带唯一性/字数/XML/结构四重校验，退出码非 0 时按 playbook 第四节处置- 有 editor_sdk →
doc_to_image（英文路径副本）逐页目检；无 →check_one_page.py --file 输出.docx估行数对比 - 输出到新路径：
简历-姓名-岗位名-详细版.docx，不要覆盖原文件
4.2 一页纸版（按需）
- 硬性一页 A4，生成后用
scripts/check_one_page.py估算版面 - 超了就按顺序砍：无关经历 → 合并同类项 → 砍背景铺垫 → 职责 5 条压 3 条 → 删自我评价 → 教育压一行
- 项目用紧凑格式：
项目名 | 角色 | 时间+背景/职责/成果各一行 - 优先沿用原文件的字体与主色
- 字号 10–10.5pt，行距 1.15–1.25，页边距 1.5–2cm
- 删内容后仍溢出时的收紧顺序（从影响最小开始）：标题段前间距 → 段后间距 → 页边距 top/bottom → 正文行距倍数；每步渲染确认页数
- 产出后必须渲染成图确认实际页数（
doc_to_image，服务偶发繁忙需重试；中文路径会失败，用英文路径副本）
> 一页纸版可以新建版式（它是衍生版），但也应让人一眼看出与原版同源。
Step 5 — 输出诊断报告
除简历外，给用户一份简短诊断（直接写在回复里）：
- 改了什么、为什么（3–6 条）
- 版式是否动了（明确说明"版式完全未改动"或"如需调整请告知"）
- 仍缺的关键信息（
【待确认】清单） - JD / 岗位关键词覆盖：命中 X/Y，缺口是哪几个
- 风险提示：时间线疑点、可信度问题
Step 6 — 英文版产出（仅当 Step 0 ④ 确认需要时执行）
前置：中文版必须先定稿（含一页纸版，如果做了）。英文版永远基于定稿后的中文版产出，不允许两条线各写各的——事实与数字必须一一对应。
6.1 内容规则（详见 resume-writing-guide.md 第十一章）
- 不是逐句翻译，是按英文简历惯例重组：
- 每条以强动词过去式开头（Led / Developed / Optimized / Coordinated / Independently performed），不用第一人称 I/my，不写完整句号长句，用短语式 bullet
- 在读/现任用现在时，已结束的经历用过去时，全文时态一致 - 事实零改动：数字、时间、公司、项目名、成果与中文版逐项一致。中文版的
【待确认：xxx】在英文版写成【TBC: xxx】，同样最后提醒替换 - 岗位关键词用英文 JD 原词；有中文 JD 没英文 JD 时，用该行业国际通用术语（如 GCP / ICH-GCP / TMF / CRF / SAE / CRO；SOP / DOE / SPC；APQP / PPAP / DV / PV）
- 专名处理：
- 姓名：姓全大写 + 名首字母（张三 → ZHANG San）；电话 +86；邮箱原样
- 机构：查官方英文名；查不到用拼音 + 括注（如 XX University (China)），不要自造译名
- 课程/奖项/实验室名：用通用英译，拿不准就拼音 + 括注 - 篇幅：英文通常比中文紧凑 15–25%；详细版仍按原版式结构，一页纸英文版同样必须一页。长度对齐用"视觉宽度"衡量（原中文段宽度 W，英文控制在 1.0–1.3×W）——
check_one_page.py本身按视觉宽度折算（ASCII 计 0.5），英文直接可用
6.2 版式规则
- 保真模式：与中文版走同一条 XML 手术流水线——复制原 docx → 按 run 切分回填英文 → rPr 不碰 → XML 校验 → 结构比对
- 英文回填后字体若显示不佳（原模板用中文字体渲染英文），不要擅自改字体；在报告里建议"英文部分建议切换 Calibri/Arial，需要的话我来改"
- 一页纸英文版：可沿用中文一页纸版的版式，只换文字；改完后同样渲染确认页数
- 校验：除姓名拼音、括注外，全文不应有 CJK 字符残留（用正则
[\u4e00-\u9fff]扫一遍）；数字与日期格式全文统一
6.3 交付
- 文件名：
Resume-<NamePinyin>-<RoleEN>-Detailed.docx/Resume-<NamePinyin>-<RoleEN>-OnePage.docx（与中文版放在同一输出目录） - 报告里加一条：中英对照差异说明——哪些表述为符合英文惯例做了重组（对应关系列 2–3 例即可，不用全列）
输出交付
用 present_files 呈现。文件名格式：简历-姓名-岗位名-详细版.docx / 简历-姓名-岗位名-一页纸.docx；
英文版：Resume-<NamePinyin>-<RoleEN>-Detailed.docx / Resume-<NamePinyin>-<RoleEN>-OnePage.docx。
默认不覆盖原文件，保留用户原件。
Resources
references/
job-profiles.md— 40 个岗位方向（8 大门类）的配置：关键词组、能力权重、叙事角度、必备证书、常见缺口、避坑提示。Step 0 选岗位时读。另含「岗位不在库中」的自定义方向流程（必问 4 项 → 现场出临时方向卡 → 用户确认 → 再改 → 可选入库）。resume-writing-guide.md— 写作细则：强动词表、量化话术库、STAR 采访模板、三段式示例、一页纸压缩技巧、常见错误清单、英文简历写法（第十一章）。每次执行前读一遍。execution-playbook.md— 执行手册：环境预检解读、replacements.json 规范、真实案例完整示例、10 类执行冲突的恢复速查、交付前自查清单。每次改 docx 前读。
scripts/
xml_surgery.py— docx 保真改写主工具（纯标准库，零外部依赖）：--list列段落，--map replacements.json整段回填文字并自动做唯一性/字数/XML/结构四重校验，rPr 零接触。改字只准用它。check_one_page.py— 估算一页纸版面占用（视觉宽度折行 + 标题间距补偿），超页给删减建议；无渲染条件时兼作页数核验。env_check.py— 执行前环境预检：Python 版本、XML 手术依赖、脚本在位性、editor_sdk 可用性、Windows 坑位、目标 docx 可读性，输出本次执行路径结论。
assets/
one-page-template.md— 一页纸结构骨架，含各模块字数预算。
