SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场job-hunt-analyzer

job-hunt-analyzer

办公与效率

查看项目

更新于 10-16 09:12

技能介绍

用途

job-hunt-analyzer 是 job-hunt 套件的分析组件，职责明确：对每条 JD 与用户简历进行多维度匹配评分。它只输出评分和分析，不生成改写建议——改写建议由同套件的 tailor 组件负责。

调用方需要传入 work_dir（工作根目录）、resume_path（标准化简历路径，为 <work_dir>/.work/resume.md）、jd_ids（待分析的 JD ID 列表）、preferences（偏好配置，当前版本传入空 stub，评分不使用偏好权重）以及 run_id（本次 run ID）。

主要能力

第一步：简历 STAR 预处理

该步骤先检查 <work_dir>/.work/resume.star.md 是否存在，并通过 md5 -q <work_dir>/.work/resume.md 计算简历哈希，读取 <work_dir>/.work/resume.md.hash。若哈希文件不存在或哈希不匹配，则重新拆解 STAR 并更新哈希文件；若匹配则直接读取 resume.star.md 并跳过拆解。

STAR 拆解遵循三条过滤规则：

  • 规则一（区块级跳过）：专业技能、教育背景、个人信息、自我评价、证书奖项等区块整体跳过，语义判断、不限死名称。工作/教育合并区块（如「工作及教育经历」）不整体跳过，进入规则二逐行判断。
  • 规则二（行级跳过）：工作/项目经历区块内，同时满足没有行动动词（做了什么）且没有结果描述（达成了什么）的行会跳过。部门名/组织名中的词语（如「运营组」「品牌部」「产品中心」）不算行动动词。典型跳过示例包括「某文化传媒公司　2023.7~2025.11　新媒体-运营组」（公司名+日期+部门，无行动无结果）、「字节跳动 · 产品经理 · 2021.03—2023.06」（职位头部行）、「xx大学　2018.9~2022.6　新闻传播专业-本科」（教育头部行）。
  • 空区块规则：规则二执行完后立即检查，若某区块经规则二处理后全部行均被跳过（即该区块内没有任何行含有行动动词或结果描述），则该区块不生成任何 STAR 条目，不得推测或捏造该区块的 S/T/A/R 内容，直接忽略并继续处理下一个区块。例如「工作及教育经历」区块只有头部行时，规则二全部跳过后该区块完全不出现在 resume.star.md 中。
  • 规则三（剩下的才拆解）：通过前两条规则筛选后剩余的句子/条目才按格式拆解，且必须完整处理所有通过筛选的条目，不得遗漏。若简历有 N 个有效经历/项目条目，resume.star.md 中必须有 N 个对应 STAR 条目。

拆解格式为：标题「## [公司/项目名称] · [职位/角色] · [时间段]」，下含 S（Situation 背景：当时业务背景、团队状况、面临的挑战）、T（Task 任务：被赋予的具体目标/职责）、A（Action 行动：具体做了什么，含技术方法/流程设计/协作方式）、R（Result 结果：可量化成果，含数字/百分比/规模；无数字则标注 ⚠️ 缺数字），以及「技能关键词」行（从该段经历提取、用于硬技能匹配的技能词）。拆解结果写入 <work_dir>/.work/resume.star.md，同时更新 <work_dir>/.work/resume.md.hash。

第二步：逐条 JD 分析

先记录待分析总数 total = len(jd_ids)，计数器 n = 0。对每个 JD ID 先做缓存检查：读取 <work_dir>/.work/jd-pool/<id>.analysis.md（若存在）并校验 frontmatter 中 jd_fetched_at 与 JD 文件的 fetched_at 一致、resume_hash 与当前 resume.md.hash 一致；两项均满足则跳过并复用缓存。

否则重新分析，先读取 JD 全文（<work_dir>/.work/jd-pool/<id>.md），再计算四个 0-100 分维度：

  • 维度 1 硬技能匹配（hard_skills）：从 JD「任职要求」提取所有技能/工具关键词，与 resume.star.md 中所有段落的技能关键词对比。基础分 = JD 要求技能的简历命中率 × 100；JD 中标注「加分项」的技能命中每项 +5（不超过 100）；简历有但 JD 没要求的技能不加分。记录命中、缺失（JD 强调）、已有但未突出（JD 提及）三类。
  • 维度 2 经验深度（experience_depth）：对比 JD 要求年限与简历实际年限。差距 ±1 年内为 90-100 分；简历比要求多 1-3 年为 85-95 分；简历比要求少 1 年为 70-80 分；少 2 年为 50-65 分；差距超过 2 年为 30-50 分。同时考察项目复杂度：相近 +5，明显低于 -10。
  • 维度 3 行业/领域契合（domain_fit）：对比 JD 行业与业务场景和简历工作行业与项目背景。完全匹配（同行业同场景）90-100；行业相近（如同属 B 端 SaaS）75-90；行业不同但技能可迁移 60-75；行业差异大、迁移难度高 40-60；几乎无关联 20-40。
  • 维度 4 软性匹配（soft_fit）：从 JD 提取软性要求（如「优秀的沟通能力」「有 0-1 经验」「能独立推动跨团队项目」），从简历找对应具体事例。从 0 开始累加：JD 强调的软技能在简历中有具体事例支撑每项 +15（上限 100）；JD 提到的加分项（学历/证书/特定背景）命中每项 +5；结果钳制在 0-100 范围内。

总分计算：scores.total = round((hard_skills + experience_depth + domain_fit + soft_fit) / 4)。

结果写入 <work_dir>/.work/jd-pool/<id>.analysis.md，frontmatter 包含 jd_id、analyzed_at、jd_fetched_at、resume_hash 以及 scores 中的 total、hard_skills、experience_depth、domain_fit、soft_fit；正文包含一句话评估（30 字以内，说明核心优势、主要差距、是否值得投递）以及四个维度的详细分析段落。

同时更新 JD 文件 frontmatter 中的 status.analyzed: true，将 <id> 加入 state.json 的 stages.analyzed，更新 checkpoint_at，并输出进度：✅ <company.name>·<title> — 匹配度 <scores.total> 分（<n>/<total> 完成）。

异常处理与完成

若单条 JD 分析出现异常（文件读取失败、字段缺失等），将该 ID 加入 state.stages.analysis_errors，记录失败原因，继续处理其余 JD，不整体中止。所有 JD 处理完成后，将 state.json 的 phase 设为 "analyzed"。

使用方式

该技能是 job-hunt 套件的内部子技能，由调用方（主 skill）传入参数后运行。调用方需要提供 work_dir、resume_path、jd_ids、preferences、run_id 等参数。完成后所有统计数据（新分析数量、缓存复用数量、失败列表）会写入 state.json，由调用方自行从 state.json 读取，无需文字汇报。

适用场景

适用于批量评估用户简历与多个职位描述之间的匹配程度，输出结构化的多维度评分与分析结果，为后续的简历定制改写提供依据。

限制

该技能只输出评分和分析，不生成改写建议（改写建议由 tailor 负责）。preferences 当前版本传入空 stub，评分不使用偏好权重。技能不编造简历内容，空区块不生成任何 STAR 条目，也不得推测或捏造内容。具体收费、价格、平台支持、效果数据等信息暂未提供。