Resume Optimizer

概述

三阶段简历优化引擎：先全局评估（含JD匹配度雷达图）→ 再针对性改写 → 最后效果对比+导出。每次优化基于用户提供的真实简历和可选JD，绝不编造数据。以中文求职市场为主要场景，兼容英文简历。优化完成后可一键导出 ATS 兼容的 .docx 和跨平台 .pdf 文档，并生成量化效果对比报告让用户直观看到优化价值。

功能范围

• 阶段1·全局评估：先做简历绝对评估（量化密度/动词力度/结构/ATS风险），再做JD相对评估（关键词覆盖度+匹配度雷达图），让用户先看到全局短板
• 阶段2·简历改写：基于评估结果针对性改写——工作经验走STAR结构，项目经验走软性叙述（保留STAR要素但用自然语言组织），缺失数据时启动批量追问对话
• 阶段3·成果交付：六维评分前后对比报告 + Top3关键提升点 + 雷达图可视化 + .docx/.pdf 文档导出

伦理边界（必须严格遵守）

1. 所有优化基于用户提供的真实经历。严禁编造数据、经历、技能、学历、公司名称
2. 量化结果仅从用户已提供的数据中提取。缺失关键量化数据时，启动追问对话向用户询问真实数据，拿到后填充；不编造、不在终版简历中留 [建议补充] 等占位符。详见"数据补全追问协议"
3. 关键词优化以自然融入为目标，拒绝堆砌（单条bullet ≤3个关键词）
4. 如JD含年龄、性别、籍贯、婚姻状况、民族、宗教信仰、外貌要求任一敏感条件，标注提醒但不用于优化
5. 如JD含"985/211"等硬性学历门槛且用户不满足，明确告知但不建议编造

路由决策树

收到用户请求后，按以下顺序判断：

用户是否提供了简历文件/文本？
├── 否 → 请用户提供简历（文件或粘贴文本均可）
└── 是 → 进行入参校验（≥200字且含工作/项目经历相关关键词）
    ├── 不通过 → 提示用户：内容过短或不像简历，请确认
    └── 通过
        ├── 用户提供了JD？→ 是 → 自动进入三阶段完整流程
        │   阶段1：全局评估（绝对评估 + JD相对评估 + 雷达图）
        │   阶段2：简历改写（工作经验STAR + 项目经验软性叙述 + JD定向 + ATS）
        │   阶段3：成果交付（前后对比报告 + 文档导出）
        └── 否 → 进入两阶段流程
            阶段1：简历绝对评估
            阶段2：简历改写（工作经验STAR + 项目经验软性叙述 + ATS）
            阶段3：成果交付（前后对比报告 + 文档导出）

v1.5.0关键设计：用户提供了JD时，先执行阶段1的JD相对评估（含雷达图），让用户看到全局短板，再开始阶段2的针对性改写——这避免了"边改边补 JD关键词"的盲目性，让每次改写都精准锚定短板。

输入与文件处理

支持的输入形式

• 纯文本粘贴
• .docx / .pdf / .txt / .md 文件
• 图片（截图/拍照）—— 先 OCR 提取文字，OCR 失败则请用户提供文本版

文件读取方式

• .txt / .md：直接读取全文
• .docx：优先用 python-docx 提取段落和表格文本；如不可用，用 unzip 解压后读 word/document.xml 并剥离标签
• .pdf：优先用 pdfplumber 或 pymupdf 提取文本；扫描版 PDF（无文本层）走 OCR 流程
• 图片：用 pytesseract（中文需 chi_sim 语言包）或调用平台多模态能力提取文字

提取后展示给用户确认："已从文件提取简历内容如下，确认无误后开始评估。"

使用

完整端到端工作流示例

场景：用户提供了简历 + 猎聘CHO岗位JD

[用户] 这是我的简历，目标岗位是猎聘上看到的CHO，JD也附上了。

[Agent 阶段1·全局评估]
1. 简历绝对评估（模块1A：量化密度0%/动词力度35/结构60分/ATS 72%）
2. JD相对评估（模块1B：解析JD → 10个核心关键词 → 关键词-证据映射表）
3. 生成JD匹配度雷达图（六个维度展示简历相对JD的覆盖度）
4. 评估报告：综合匹配度约68%，最大gap是缺"大制造100亿上市CHO"经验
   → 让用户看到全局短板
   → 询问用户是否基于评估结果开始改写

[用户] 继续

[Agent 阶段2·简历改写]
2a. 工作经验STAR改写（基于评估短板——动词力度弱、量化缺失）
    → 标记所有缺失的量化数据点
2b. 项目经验软性叙述改写（避免"五维追问+bullet结构"的工程化感）
    → 标记缺失的角色/成果信息
2c. 汇总全部缺失数据 → 一次性发起批量追问（数据补全追问协议）

[Agent 追问示例]
"我已完成初步改写。为让简历更有说服力，需要补充以下真实数据：
  1. 电商业务-会员体系搭建：覆盖了多少付费用户？付费转化率从X提升到Y？
  2. 推荐系统AB实验：你在实验中是产品/算法/工程哪个角色？样本量多大？核心指标提升多少？
  3. 跨境出海项目：首月GMV/新用户增长数据？
能提供的提供，记不清的告诉我，我用定性表述处理。"

[用户] 1.覆盖30万付费会员，付费率从8%提到14% 2.产品负责人，样本量50万，CTR+12% 3.记不清了

[Agent]
2d. 用真实数据填充 → 记不清的改用定性表述
    → 针对阶段1雷达图短板做JD定向优化
    → 18项ATS检查清单核对
    → 输出无占位符的最终优化简历 → 询问用户是否满意

[用户] 满意

[Agent 阶段3·成果交付]
3a. 优化效果对比报告（六维评分前后对比表 + 综合分提升 + Top3提升点 + 雷达图）
3b. 文档导出（.docx + .pdf）→ 告知文件路径

关键参数的设计原因

中间格式约定

简历在模块间传递时统一使用以下 Markdown 格式。中文简历用中文标准标题（与ATS检查项#7一致），英文简历用英文标题：

中文版：

# [姓名] - [目标岗位]

## 个人简介
[2-3句职业概述]

## 工作经验
### [公司名] | [职位] | [起止时间]
- [STAR优化后的bullet 1]
- [STAR优化后的bullet 2]

## 项目经验
### [项目名] | [角色] | [时间]
[2-4句软性叙述段落，保留STAR要素]

## 技能
[技能1, 技能2, 技能3]（按类别分组：编程语言 / 框架工具 / 领域知识）

## 教育背景
[学校] | [学位] | [专业] | [时间]

英文版：使用 Summary / Experience / Projects / Skills / Education。

Before/After 展示模板

每条改写使用固定模板：

**原文**：[原始描述]
**优化后**：[改写结果]
**改动说明**：[一句话说明改了什么：补STAR要素 / 注入量化 / 动词升级 / 关键词对齐]

阶段1：全局评估

v1.5.0核心改进：把"评估"前移，作为整个优化流程的起点。用户先看到简历的绝对状态和相对于目标JD的匹配度雷达图，再决定改写方向。

模块1A：简历绝对评估

对简历做四项评估，输出诊断报告。同时必须缓存原始数据（总bullet数、含数字bullet数、强动词数、缺失模块数、ATS风险数等）供阶段3对比报告使用。

缓存原始数据（供阶段3对比）：

• original_total_bullets、original_quantified_bullets、original_strong_verb_bullets、original_weak_verb_count
• original_modules_count、original_ats_risks、original_jd_keywords_covered（提供JD时）

模块1B：JD相对评估与匹配度雷达图

v1.5.0新增：把原来"模块2的JD定向"中的解析部分前置，让用户先看到简历相对于JD的覆盖度雷达图。

1B-1. JD解析

从目标JD中提取关键词并分类，详见 references/jd-tailoring.md。

输出关键词脊柱（8-12个核心词）和关键词-证据映射表：

| 关键词 | 类型 | 简历中已有证据 | 需补充/调整 |
|--------|------|-------------|------------|
| 用户增长 | Functional | "粉丝增长至3.2万" | 补充增长策略细节 |
| SQL | Hard | 无 | 如在技能区有则抽取，否则标红 |
| 跨部门协作 | Functional | "协调市场、产品、运营" | 已有，可前置强调 |

1B-2. 六维度匹配度雷达图

关键产出：用雷达图直观展示简历相对JD的覆盖度。修改后用阶段2的优化行动填满短板区域。

六个评估维度（与阶段3的效果对比报告共用维度，但评估角度不同——这里评估"原始简历"，阶段3评估"优化后简历"）：

雷达图渲染规范：

• 修改前用浅色填充（橙色 #F39C12，30%透明度）
• 修改后用深色填充（绿色 #27AE60，30%透明度）
• 六个维度按等角分布
• 数值轴范围 0-100，便于对比
• 标签清晰可读

示例输出：

## 简历相对JD的匹配度评估

### 关键词覆盖
- 关键词脊柱：10个核心词
- 已覆盖：6个（60%）
- 弱覆盖：3个
- 未覆盖：1个

### 经验对齐
- JD核心职责：5项
- 直接匹配：2项（用户增长、SQL分析）
- 可迁移：2项
- 需补充：1项

### 综合匹配度
约58%（基于六维加权平均）
最大短板：技能匹配（仅2/6硬技能满足）

雷达图的具体设计规范和可视化代码模板见 references/jd-tailoring.md 的"雷达图渲染规范"章节

1B-3. 评估报告输出与决策点

阶段1完成后，输出：

1. 绝对评估四维表（模块1A）
2. JD匹配度雷达图（模块1B，可视化）
3. 关键词-证据映射表（模块1B）
4. 综合匹配度百分比 + Top 3 短板
5. 询问用户是否开始阶段2改写——明确告知"基于以上短板，我们将在阶段2针对性改写"

阶段2：简历改写

改写顺序：工作经验STAR改写 → 项目经验软性叙述 → 数据补全追问 → JD定向优化 → ATS检查。前两步初步改写 + 标记缺失数据 → 第三步批量追问 → 第四步用真实数据填充 + 针对性JD补强 → 第五步ATS合规。

模块2A：工作经验STAR改写

逐条处理工作经验中的每条bullet（项目经验单独走模块2B软性叙述）：

改写四步法：

1. 提取：从原始描述中识别已有的S/T/A/R要素
2. 补全：对缺失要素启动追问对话（详见"数据补全追问协议"），批量收集真实量化数据后填充，不留占位符
3. 重构：按"强动词 + 具体行动 + 量化结果 + 关键词"顺序重组
4. 校准：确保单条bullet ≤50中文字（英文≤25词），至少含1个量化指标

中文强动词库（按场景）：

完整中英文动词库、弱动词替换对照和 Before/After 示例见 references/star-methodology.md

改写示例：

**原文**：负责公司公众号运营，发布文章并维护粉丝
**优化后**：主导公司公众号从0到1搭建，6个月内输出原创内容120+篇，粉丝增长至3.2万（月均净增5000+），平均阅读量提升至行业Top 20%
**改动说明**：补STAR全要素，动词从"负责"升级为"主导"，注入量化结果，补充规模和排名

模块2B：项目经验软性叙述改写

v1.5.0关键改进：从v1.4.1的"五维追问+bullet结构"改为"软性叙述段落"——保留STAR要素但用自然语言组织，避免"在填表"的工程化感。

核心设计思想

为什么改：v1.4.1的"五维追问法+S/T/A/R四要素+五种项目bullet模板"虽然完整，但呈现给用户和HR时显得生硬——读者一眼能看出"在按模板套用"，反而降低简历的可信度和可读性。

软性化原则：

1. 从bullet改为段落：项目经验用2-4句叙述段落，每个项目一段，不用bullet列表
2. 隐性结构替代显性标签：S/T/A/R要素保留但用自然语言组织，不出现"S背景""R角色"等标签
3. 故事化展开：背景→角色→行动→成果按叙事流自然过渡
4. 数据嵌入但不让数据喧宾夺主：量化数据埋在叙述中，不堆砌
5. 保留STAR的"硬"内核：所有要素不能丢，只是表达方式更软

软性叙述的段落结构

每段项目用2-4句话展开，建议四句结构：

第一句：项目背景（什么项目、多大规模、为什么启动）
第二句：个人角色（你在这个项目中的位置、带多少人、决策权）
第三句：关键行动（用了什么方法、克服了什么难点）
第四句：项目成果（量化结果+对业务/团队的长期影响）

Before/After 对比

v1.4.1生硬版（用五维追问+bullet结构）：

**原文**：E-HR系统导入项目（金蝶：项目经理）

**优化后（v1.4.1）**：
- 项目背景：500人公司人力数字化转型
- 角色：项目经理，统筹产研+业务+金蝶三方共15人
- 目标：6个月完成全量上线，线上化率达95%
- 行动：需求调研→定制开发→分模块上线→全员培训
- 成果：覆盖中东区5国1200+员工，线上化率从30%提升至95%

v1.5.0软性版（用叙述段落）：

**原文**：E-HR系统导入项目（金蝶：项目经理）

**优化后（v1.5.0）**：
作为项目经理主导了金蝶E-HR系统在中东区的导入项目，跨国产研、业务方与金蝶实施顾问三方共计15人协同，6个月内完成从需求调研、定制开发到分模块上线的全流程，最终覆盖5国1200+员工，区域人力流程线上化率从30%提升至95%。

软性版的提升：

• 5个bullet → 1段流畅叙述，视觉上不"工程化"
• S/T/A/R要素全部保留（背景:500人公司+5国1200人 / 角色:项目经理+15人 / 行动:全流程+三方协同 / 成果:30%→95%）
• 读起来像"项目故事"而不是"项目报告"
• 数据嵌入自然（1200+员工、30%→95%）不堆砌

软性叙述的五种项目类型模板

详细的项目类型模板、完整示例库、软性化改写技巧见 references/star-methodology.md 的"项目经验软性叙述专章"

软性化改写的执行要点

1. 保留所有数据：软性化≠弱化数据，相反要让数据"自然融入"叙述流
2. 保留"角色"显式表达：用"作为项目经理""主导""负责"等显式词标识角色（虽然"主导"已偏硬，但比"角色：项目经理"标签更自然）
3. 避免机械连接词："首先/其次/最后""背景：""成果："等连接词让叙述生硬
4. 让数据服务于故事：数字不能是裸数据，要有语境（如"覆盖中东区5国1200+员工"比"覆盖1200人"更有故事感）
5. 长度控制：单个项目段落2-4句、80-150字为佳，过长则失去精炼感
6. 项目bullet优先于项目段落：如果用户简历原来是bullet形式且特别简短，可以保留bullet但用软化语言（而不是段段落）

改写示例

**原文**：负责公司公众号运营，发布文章并维护粉丝
**优化后**：主导公司公众号从0到1搭建，6个月内输出原创内容120+篇，粉丝增长至3.2万（月均净增5000+），平均阅读量提升至行业Top 20%
**改动说明**：补STAR全要素，动词从"负责"升级为"主导"，注入量化结果，补充规模和排名

模块2C：数据补全追问协议

STAR改写和项目叙述过程中，缺失关键量化数据时必须启动追问对话，不留占位符直接输出。

触发条件

改写任一bullet/段落时，以下数据缺失则触发追问：

• 规模类：团队人数、覆盖员工数、涉及部门数、管理预算、项目周期
• 效果类：提升幅度（%）、降低幅度（%）、达成率、转化率、线上化率
• 对比类：优化前基线、行业排名、同业对比
• 产出类：交付数量、专利数、论文数、培养人数

追问方式：批量收集，不逐条打断

错误做法：每改一条bullet就停下来问一次，打断用户节奏 正确做法：先完成所有工作经验和项目经验的初步改写 → 汇总所有缺失数据点 → 一次性向用户发起批量追问

追问对话模板

我已完成简历的初步改写（工作经验STAR + 项目经验软性叙述）。为了让简历更有说服力，需要您补充以下真实数据（能提供的提供，记不清的标注"记不清"，我会用定性表述替代）：

【工作经验】
1. SaaS产品经理 - 增长模块：DAU/MAU从X增长到Y？付费转化率是多少？
2. 跨境电商 - 用户增长：拉新成本CAC多少？D7/D30留存率？
3. 内容平台 - 社区运营：UGC日均产出量？社区月活规模？

【项目经验】
4. AB实验框架搭建：累计跑了多少次实验？核心业务指标提升多少？
5. 会员体系重构项目：会员付费率从X提升到Y？ARPU变化幅度？

请逐条回复，或直接告诉我"都记不清了"我用定性表述处理。

用户回应处理

禁止行为

• ❌ 在终版简历中保留 [建议补充]、[补充：XX]、[XX人] 等占位符
• ❌ 未追问就自行编造数字（如"覆盖500人"）
• ❌ 逐条追问打断用户节奏（应批量收集）
• ❌ 用户说"记不清"后仍反复追问同一数据点

追问与模块2B项目经验软性化的联动

项目经验软性叙述（模块2B）与数据补全追问（本协议）合并执行——在项目经验改写阶段同步收集缺失数据，不重复发起两轮追问。执行顺序：

1. 先做工作经验STAR改写（模块2A）→ 标记缺失数据
2. 再做项目经验软性叙述（模块2B）→ 标记缺失数据
3. 汇总全部缺失数据 → 一次性发起批量追问
4. 拿到用户回应后填充 → 输出无占位符的终版简历

模块2D：JD定向优化

v1.5.0位置调整：JD定向从原来的模块2（独立模块）调整为模块2D（阶段2的最后一个子模块），基于阶段1的雷达图短板做针对性优化。

高杠杆区域定向改写

只改5个区域（15-20分钟工作量），不是全量重写。每个区域的改写都锚定阶段1雷达图的对应短板：

1. 标题/个人简介：注入目标岗位名称和top3关键词
2. 技能区：按JD关键词优先级重排，补充缺失但真实掌握的技能
3. 最近岗位前3条bullet：重排顺序让最匹配的经历前置，关键词自然融入
4. 一条匹配的项目经验：选最贴合JD的项目前置
5. 教育/证书：如JD有硬性要求，确保格式标准且关键词可解析

改完后输出完整的JD对齐版简历 + 匹配度评估：

**整体匹配度**：约78%（估算，基于关键词覆盖率）
**硬性要求满足**：5/6（缺失：Spark）
**经验对齐度**：核心经验2/3项直接匹配，1项可迁移
**需注意**：JD要求"3年以上团队管理"，你当前经历侧重个人贡献，建议补充管理相关描述

匹配度公式权重（L1×50% + L2×35% + L3×15%）基于行业经验设定，非实证数据，仅作参考。

与阶段1雷达图的关联

阶段1输出的雷达图显示了"哪个维度最弱"（如关键词覆盖60%、经验对齐40%、技能匹配33%），模块2D的改写就针对这些短板做加强：

• 关键词覆盖弱 → 改写个人简介和最近岗位bullet，把缺失关键词自然融入
• 经验对齐弱 → 把可迁移经验从工作经历末尾前置，调整bullet侧重JD核心能力
• 技能匹配弱 → 在技能区补充JD硬技能（仅限用户真实具备的）

模块2E：ATS兼容性检查

18项检查清单

完整检查项和修复方案见 references/ats-optimization.md

关键词覆盖度热力图

对模块1B提取的关键词脊柱做逐一检查，输出三类标记：

• ✅ 已覆盖（关键词在简历中出现且位置合理）
• ⚠️ 弱覆盖（出现但位置不突出，建议前置）
• ❌ 未覆盖（缺失，如用户真实具备则补充）

阶段3：成果交付

模块3A：优化效果对比报告

v1.5.0增强：阶段3的对比报告与阶段1的JD雷达图共享同一组六维度（量化密度/动词力度/STAR完整度/结构完整性/ATS兼容性/JD匹配度），形成"前后对比"的完整闭环。

六维评分模型

无JD场景：JD匹配度维度不计入，其15%权重均分到其余5个维度（各+3%）。 权重说明：基于行业经验设定，非实证数据。量化密度和STAR完整度权重最高（各20%），因为这两项是简历说服力的核心驱动因素。

综合分 = Σ(维度分 × 权重)，满分为100。

评分采集

修改前分数来自模块1A诊断阶段记录的原始简历指标；修改后分数来自优化完成后的终版简历重新评估。关键：模块1A诊断时必须记录原始数据（总bullet数、含数字bullet数、强动词bullet数等），供阶段3对比使用。

报告格式

## 简历优化效果对比报告

### 综合评分
修改前：XX分 → 修改后：XX分（+XX分，提升XX%）

### 六维评分对比

| 维度 | 权重 | 修改前 | 修改后 | 提升 |
|------|------|--------|--------|------|
| 量化密度 | 20% | 0 | 85 | +85 |
| 动词力度 | 15% | 55 | 90 | +35 |
| STAR完整度 | 20% | 20 | 80 | +60 |
| 结构完整性 | 15% | 60 | 100 | +40 |
| ATS兼容性 | 15% | 65 | 100 | +35 |
| JD匹配度 | 15% | 50 | 80 | +30 |
| **综合分** | 100% | **42** | **88** | **+46** |

### 关键提升点（Top 3）
1. [维度名]从XX提升至XX——[一句话说明优化动作带来的变化]
2. ...
3. ...

### 仍可继续优化建议
1. [具体建议 + 预期提升方向]
2. ...

关键提升点撰写要点

• 每条必须关联到具体的优化动作（数据补全追问 / STAR改写 / 项目软性叙述 / JD定向 / ATS修复），让用户知道提升来自哪里
• 优先展示提升幅度最大的维度
• 如某维度提升不明显（<10分），不强行包装，如实说明原因

可选可视化

如执行环境支持可视化输出，建议生成雷达图直观展示六维前后对比——修改前用浅色填充，修改后用深色填充，叠加在同一张图上。雷达图比纯表格更能让用户一眼看到优化效果的全貌。

v1.5.0增强：阶段3的对比雷达图与阶段1的JD匹配度雷达图共享视觉语言（相同的维度标签、相似的配色方案），让用户感受到"从评估到对比"的完整闭环。

执行时机

• 最早可生成时机：模块2E（ATS检查）完成后——此时所有优化已完成，六维数据齐全
• 推荐时机：模块3B（文档导出）完成后，作为整个优化流程的收尾报告
• 模块1A诊断时必须缓存原始简历的评分数据，否则无法做前后对比

模块3B：文档导出

优化完成后，询问用户是否需要导出为 .docx 和/或 .pdf 文件。

导出流程

1. 将最终优化版简历整理为中间格式 Markdown（见"中间格式约定"章节）
2. 写入临时文件（如 resume_optimized.md）
3. 调用 scripts/export_resume.py 生成 .docx 和 .pdf
4. 将生成的文件路径告知用户

脚本调用方式

# 安装依赖（首次使用）
pip install python-docx reportlab

# 同时生成 .docx 和 .pdf（默认）
python scripts/export_resume.py resume_optimized.md -o <output_dir> -n <文件名>

# 仅生成 .docx
python scripts/export_resume.py resume_optimized.md -o <output_dir> -n <文件名> -f docx

# 仅生成 .pdf
python scripts/export_resume.py resume_optimized.md -o <output_dir> -n <文件名> -f pdf

脚本源码和详细说明见 scripts/export_resume.py

字体与跨平台兼容策略

.docx 文件：

• 正文字体指定为宋体（SimSun），标题字体为黑体（SimHei）——这是 ATS 平台标准字体
• Windows：原生渲染，ATS 完美解析
• macOS：Word/LibreOffice 自动替换为 STSong/STHeiti，显示正常
• 页面尺寸：A4（210mm × 297mm）

.pdf 文件（双路线保障）：

两条路线均将字体子集嵌入 PDF（FontFile2 标记），确保：

• Windows / macOS / Linux / iOS / Android 上中文均正确显示，不依赖目标系统字体
• 嵌入的是字体子集（仅含简历中使用的字符），文件体积可控（通常 80-130KB）
• 符合 PDF/A 字体嵌入规范，主流 PDF 阅读器（Adobe Reader、Foxit、浏览器内置、WPS）均兼容

导出后的检查清单

生成文件后，向用户确认以下事项：

• 文件名格式：姓名_目标岗位_简历.docx（符合 ATS 检查项 #15）
• .docx 可在 Word/WPS 中正常打开，中文显示正确
• .pdf 可在 Adobe Reader / 浏览器 / 手机上正常打开，中文无乱码
• 页数符合预期（5年以下经验≤1页，5-10年≤2页）
• 如需投递要求 PDF 的岗位，使用 .pdf；否则优先 .docx（ATS 解析更准确）

产出物存放

• 阶段1评估报告直接在对话中呈现（含雷达图可视化）
• 阶段2改写结果用 Before/After 模板格式
• 阶段3对比报告含六维评分表和雷达图
• 如用户要求导出文件：
  • Markdown 版写入 resume_optimized.md（当前工作目录或用户指定路径）
  • .docx / .pdf 版通过 scripts/export_resume.py 生成，输出到同一目录
  • 文件名优先使用 姓名_目标岗位_简历 格式，如用户指定其他名称则用用户指定的
• 诊断报告、关键词映射表、ATS 检查结果、优化效果对比报告等中间产物不强制落盘，除非用户要求

边界场景处理

详细容错场景和边界处理（入参异常、JD解析异常、用户交互异常、结果异常、跨行业/特殊场景、多语言混合等 21 个场景）见 references/edge-cases.md

核心原则速查：

• 入参过短/非简历：先确认再处理，不强行优化
• JD 过短/关键词不足：降级为仅模块1，告知用户
• 用户拒绝/无法提供量化数据：启动追问对话批量收集（数据补全追问协议）；用户说"记不清"或拒绝时，改用定性表述（如"覆盖全员""驱动显著提升"），不在终版简历留占位符
• 简历过长：5年以下→1页，5-10年→1-2页，10年以上→2页；合并早期经历
• 跨行业转行：抽取可迁移技能，用目标行业术语重新表达，保留量化成果
• 中英文混合/双语：识别主体语言（>60%占比为准），英文简历用英文STAR规则（≤25词/bullet）
• 应届生：教育前置，不过度追求量化，不编造实习经历
• 高管/20年+经验：重点放在"成就表述是否够高维"，早期经历允许合并