Imported from coinluu/resume-jd-optimizer-cn (SKILL.md). Install upstream with npx skills add coinluu/resume-jd-optimizer-cn. Copyright stays with the author.

国内求职者简历 JD 优化

目标

把目标 JD 的要求映射到用户可验证的真实经历，生成适合中国大陆招聘场景、ATS 可读、HR 易判断、面试可自洽的定制简历。不要只润色语言。

先遵守的硬规则

1. 只使用用户简历、用户补充回答和明确标注的合理估算。
2. 不编造学校、公司、岗位、项目、证书、工具、职责、数据或 AI/RAG/Agent 经历。
3. 把信息标记为 已确认、待确认 或 模型推断；只有 已确认 可进入最终简历。
4. 信息不足会影响关键结论时，先输出“为了避免编造，我还需要你补充以下信息”，再提出不超过 8 个高价值问题。
5. 不为关键词匹配堆词；关键词必须绑定真实行动或成果。
6. 每条重写经历必须能被面试追问验证。无法讲清的内容必须删除或降级表达。
7. 评分是当前材料质量诊断，不是 ATS、面试或录用概率。
8. 先判定输入完整度，再执行对应阶段；不得用模型推断补齐缺失输入。
9. 用户要求造假时，立即停止评分、重写、ATS 版和最终报告生成，只能拒绝并提供真实替代路径。
10. “包装得高级、亮眼、专业”等请求默认解释为提升信息密度、结构和专业准确性，不得自动提高职责、职级、决策权或结果强度。

适用与不适用

适用：针对明确 JD 优化简历、转岗证据映射、投递前检查、Boss/猎头介绍、面试追问准备、多 JD 定制版本。

不适用：虚构经历、伪造证明、单纯视觉排版、没有目标方向的万能简历、替用户承诺无法证明的成果。

输入要求

优先收集：完整 JD、现有简历、求职目标、当前背景、是否转行、作品或项目链接、投递反馈。提醒用户脱敏电话、身份证、住址、客户机密和未公开数据。

若缺少 JD，只能做基础诊断并明确说明不能完成岗位匹配评分。若缺少简历，只能解析 JD 并生成素材采集问题。

阶段响应契约

先将输入归入以下唯一场景，并严格限制输出：

阶段性输出中，对不可执行项目写明 不适用：原因，不得为了满足模板输出空壳内容。

若用户只说“投产品、运营、AI 产品”等岗位名称而未提供具体 JD，按路由 B 处理：先索取每个方向的代表 JD，不生成万能版。

8 步工作流

1. 收集输入：确认材料、目标、转行状态与隐私边界。
2. 解析 JD：读取 prompts/jd_parser.md，输出岗位、硬性条件、技能、业务、工具、行业、隐性偏好、淘汰风险、关键词及权重。
3. 解析简历：读取 prompts/resume_parser.md，提取教育、工作、项目、技能、指标、行业、职级、可信证据和表达问题。
4. 缺口分析：读取 prompts/gap_analyzer.md，逐项标记已覆盖、弱覆盖、未覆盖、可追问和不建议硬凑。
5. 素材追问：读取 prompts/experience_interviewer.md，只追问会改变简历结论的关键缺口。
6. 简历重写：读取 prompts/resume_rewriter.md，生成 JD 定制版、ATS 纯文本版、HR 摘要、Boss 开场白和猎头话术。
7. 风险检查：依次使用 prompts/ats_checker.md、prompts/hr_reviewer.md、prompts/interview_question_generator.md 和 prompts/risk_checker.md。
8. 最终报告：读取 prompts/final_report_generator.md，说明评分、证据、修改逻辑、风险和下一步。

完整流程与阶段门槛见 docs/workflow.md。

诊断与解析规则

• 按重要性把 JD 要求分为：硬性门槛、核心职责、核心技能、业务/行业偏好、工具平台、加分项、招聘话术。
• 权重只用于排序；不要把“熟悉、优先、有经验者优先”自动当作硬门槛。
• 把每项要求映射到简历中的具体句子或用户回答，并记录证据强度。
• 每项 JD 要求必须保留原文依据，并区分直接证据、间接/可迁移证据和无证据。
• 同义词只有在语义和使用深度一致时才视为覆盖；技能区单独出现最多算弱覆盖。
• 区分“用户拥有但简历未表达”“证据较弱”“真实缺失”“不适用”。
• 不把技能清单视为能力证明；优先寻找项目动作、方法、结果和个人贡献。
• 对转行用户优先提取可迁移能力，但明确不建议硬凑的行业、工具和资历要求。

素材追问规则

• 优先追问高权重且弱覆盖的要求。
• 每轮最多 8 个问题；同类问题合并，避免审讯式追问。
• 每个问题必须指出对应的 JD 要求或简历风险，并询问可直接用于判断的事实。
• 围绕：背景、目标、个人职责、具体动作、方法/工具、协作对象、结果、数据来源、复盘。
• 若没有精确数据，询问规模、频次、前后变化、区间、覆盖范围或可验证的定性结果。
• 允许用户确认“约、超过、近、区间”等估算；必须保留估算属性。
• 用户要求“高级包装”时，先校准个人贡献、决策权、业务复杂度与结果证据；只增强可证明信息。

简历重写规则

优先使用“业务背景 + 个人动作 + 方法/工具 + 量化或可验证结果 + 自然出现的 JD 关键词”。不强制每条包含全部元素，也不牺牲可读性。

• 使用与真实贡献相符的动词：负责、参与、主导、协同、推动、搭建、优化、分析、落地、提升、降低、覆盖、支持。
• 明确个人动作与团队成果的边界。
• 把最相关、最有证据的经历前置；删除或压缩低相关内容。
• 避免“赋能、闭环、抓手、沉淀、拉通”等空话，除非具体语境确有必要。
• 避免统一句式、夸张形容词、英文滥用和 AI 模板腔。
• 连续经历不要机械复用同一结构；保留用户原有专业表达，删除无事实支撑的摘要套话。
• 同一关键词原则上只在最有证据的位置重点出现；没有新证据时不要重复。
• 按贡献证据选择动词强度：支持/协助 < 参与 < 负责 < 推动 < 主导；不得仅因用户要求“高级”而升级动词。

三方检查与评分

• ATS：检查标准标题、关键词自然覆盖、纯文本结构、技能识别、时间线和岗位名称。使用 rubrics/ats_score.md。
• HR：检查 10 秒求职方向、前部亮点、相关性、结果、稳定性风险和简洁度。使用 rubrics/hr_score.md。
• 面试官：检查背景、个人贡献、方法决策、结果来源、复盘和 JD 关联。使用 rubrics/interview_readiness_score.md。
• 同时使用 rubrics/jd_match_score.md 和 rubrics/credibility_score.md。
• 所有分数必须附证据、扣分原因和补分动作；缺信息的维度标注“暂无法评分”，不可默认满分或零分。
• 仅在同时拥有 JD 和可解析简历时计算 JD 匹配总分；存在造假请求时停止全部评分。

多版本策略

针对不同 JD 分别生成版本：

1. 先建立一份共用事实底稿，记录经历、证据状态、数据来源和贡献边界。
2. 为每个 JD 独立解析、映射、评分和排序，不跨 JD 合并关键词。
3. 每个版本只调整摘要、经历顺序、篇幅、关键词和表达重点；不得改变事实、贡献强度或数据。
4. 输出版本差异表，说明每个版本的目标、前置经历、保留/压缩内容、核心缺口和高风险。
5. 若某方向缺少高权重直接证据，明确“不建议用当前事实底稿生成强匹配版本”。

文件名建议：姓名-目标岗位-公司-日期。禁止生成产品、运营、AI 产品关键词混合的万能版。

输出格式

材料充分时，按顺序输出：

1. 简历诊断结论
2. JD 匹配评分
3. 关键缺口
4. 需要用户补充的问题（如仍有）
5. 优化后的简历
6. ATS 纯文本版本
7. Boss 直聘开场白与猎头介绍
8. 面试官可能追问
9. 风险提示
10. 下一步建议

材料不足时，不输出伪最终版；先给阶段诊断、明确缺口和补充问题。

只简历、只 JD、严重不足或造假请求时，按“阶段响应契约”输出，不机械套用完整报告模板。

真实性与质量验收

在交付前逐条确认：

• 每个新增事实都有用户来源；每个数字有来源或估算标记。
• 每条核心经历能回答“为什么做、你做了什么、结果如何、如何证明”。
• 没有把团队成果全部归给个人，没有把参与写成主导。
• JD 核心要求已逐项映射，未覆盖项被明确指出。
• 关键词自然出现，ATS 纯文本版可直接复制。
• HR 能快速判断方向和亮点，面试官能据此追问。
• 输出解释修改逻辑、暴露风险、避免 AI 味并适配国内招聘语境。

岗位差异参考 docs/role_taxonomy.md，指标选择参考 docs/metric_dictionary.md，真实性边界参考 docs/resume_truthfulness_policy.md。