version: "1.0.0" name: resume-tailor-analyze description: 内部匹配分析 skill。基于当前 run 的候选人证据模型执行五维评分和 Top N 深度分析，输出带 evidence ID 的匹配依据、缺口、策略与岗位质量信号，支持缓存复用。

Resume Tailor Analyze

Inputs

• data/resume.md
• data/resume.star.md（STAR 拆解版）
• data/profile.md
• output/<run_id>/candidate-profile.json
• data/experience-bank.md
• output/<run_id>/jobs/<job_id>/job.json

Outputs

output/<run_id>/jobs/<job_id>/analysis.md
output/<run_id>/jobs/<job_id>/analysis.json

Layer 1：5 维快速打分（所有岗位）

维度 1 — 核心能力匹配（语义能力对齐 · 0-100）

• 先识别 JD 中明确、可验证的能力要求，再用候选人证据逐项判断。能力目录同时覆盖技术与非技术岗位：例如 Agent 编排、后端 API、研究调研、内容策划与写作、运营活动、项目协调、课程与培训、传播沟通等。
• 不因候选人专业或岗位名称而预设能力类型；文科、商科、教育和综合职能岗位应按其 JD 中的研究、内容、运营、协作或培训要求匹配。
• 同义表达可归入同一能力主题；不得把公司名、岗位名、泛化动作词或整句 JD 片段当作技能。
• 每项命中必须附候选人 evidence ID；没有证据只能标为缺口，不能据此生成简历事实。
• 缺口只保留影响胜任度的明确要求，按重要性最多展示 5 项。无法判断、仅出现在福利/公司介绍、或只是职位标签的内容不列为缺口。
• 输出：✅已匹配（含证据）/ ⚠️待补充（含 JD 原文依据）。

维度 2 — 经验深度（纯规则 · 0-100）

• 先从候选人工作/实习经历中解析可识别的时间段；项目经历如与同一实习重叠，绝不重复累计为工作年限。
• 对比 JD 明确最低年限与相关经历时长，并以项目数量和可核实结果作为有限补正；不能因为 bullet 多、动作词多或项目重复出现而给满分。
• JD 未写年限时，明确标注“未给出年限”，只基于相关经历时长、项目复杂度和结果证据估算。
• 分析结果必须写明：JD 年限要求、可识别的相关时长（或无法识别）及其对分数的影响。

维度 3 — 行业/领域契合（纯规则 · 0-100）

• 仅在 JD 明确给出业务场景时评估同场景证据；不得用技术关键词重合代替行业契合。
• 同场景且有证据 → 高分；无同场景但技术可迁移 → 中低分；JD 没有明确场景 → 中性分，并说明无法判断。

维度 4 — 软性匹配（证据核验 · 0-100）

• 只评估 JD 明确提出的沟通、协作、业务理解等要求，并查找对应的具体经历文本。
• JD 未提出可核验软性要求时给中性分，并明确其不构成投递推荐的加分依据；不能把“参与”“团队”等泛词当作已匹配。

🆕 维度 5 — 岗位质量（纯规则 · 0-100 · 来自 参考项目乙 Block G）

检查以下信号，纯规则打分，不调 LLM：

综合分

候选人匹配总分 = (硬技能 + 经验深度 + 行业契合 + 软性匹配) / 4

四舍五入到整数。

岗位质量是 JD 信息完整度与机会风险，必须单独展示，不得纳入候选人匹配总分或用于抬高匹配推荐。

排序

所有已分析岗位按总分降序排列。

Layer 2：深度分析（仅前 N 岗位 · 建议 N=5~10）

只对排序后前 N 个岗位，在 analysis.md 中附加以下内容：

🆕 定制策略（← 参考项目乙 Block E）

## 定制策略
 
| # | 改动点 | 当前状态 | 改成什么 | JD 触发原因 |
|---|--------|---------|---------|------------|
| 1 | ... | ... | ... | ... |
 
建议补充的经验/项目：
- ...

🆕 级别与薪酬参考（← 参考项目乙 Block C+D）

## 级别与薪酬参考
 
- JD 级别判断：<级别>
- 用户当前级别：<级别>
- 建议薪资区间：<基于 JD 报价 + 市场数据>
- 如果被压级：<应对策略>

未执行联网调研时，必须写“市场薪酬：未联网调研”，不得用 JD 报价冒充市场数据。

🆕 岗位可信度评估（← 参考项目乙 Block G）

## 岗位可信度评估
 
- 发布新鲜度：<判断>
- JD 质量：<具体 vs 泛泛>
- 风险标记：<如有，逐条列出>

缓存策略

• analysis.json 记录 resume_hash 和 jd_hash
• JD、简历 hash 和评分版本都不变时，复用已有 Layer 1 五维分数
• Layer 2 深度分析内容不缓存，每次重新生成（薪酬数据有时效性）

Required Sections

# 匹配分析：<company> · <title>
 
## 匹配评分
| 维度 | 分数 |
|------|------|
| 核心能力匹配 | xx/100 |
| 经验深度 | xx/100 |
| 行业契合 | xx/100 |
| 软性匹配 | xx/100 |
| 岗位质量 | xx/100 |
| **总分** | **xx/100** |
 
## 投递建议
 
## 匹配依据
 
## 主要风险
 
## 简历调整策略
 
## 需要确认
 
（Layer 2 内容仅前 N 岗位附加在此之后）

Evidence Rules

• Bind every positive candidate claim to evidence IDs from candidate-profile.json.
• Quote or paraphrase only from resume.md, resume.star.md, experience-bank.md, or the JD.
• If evidence is weak, say so.
• Do not turn absence into a positive claim.
• 不得用字符串分词或词表交集直接输出“已匹配能力”或“缺失能力”；应先完成能力主题归类，再检查候选人证据是否支持。
• 每个展示出的分数必须有可读的评分依据；“无信息”必须说明为无法判断或中性分，不能伪装成高匹配。
• “主要风险”和“需要确认”只能输出当前岗位的实际年限差、能力缺口、场景差或证据不足，禁止重复通用免责声明。