返回 Skill 列表
extension
分类: 其它无需 API Key

研发简历筛选

面向开发岗位的简历深度筛选器。从 PDF 简历中提取技术信息,对照岗位要求做深度评估,输出匹配度评分、技术深度分析、风险预警和排名。当用户提到筛选简历、评估候选人、看简历、招人、简历分析、候选人排名时触发。也适用于用户提到具体技术岗位招聘(后端开发、前端开发、全栈、架构师等)需要评估简历的场景。

person作者: user_84d07600hubcommunity

开发岗位简历深度筛选器

聚焦一件事:从简历中挖掘候选人的真实技术能力,判断是否值得面试。


核心流程

需求确认 → 简历解析 → 深度评估 → 排名输出

第一步:需求确认

不要一上来就开始筛。先搞清楚要什么样的人。

必须确认的信息:

  1. 岗位 - 从文件名提取(格式:【{岗位}_{地点} {薪资范围}】),用户可修正
  2. 硬性门槛 - 最低工作年限、必须掌握的技术栈、学历要求等
  3. 加分项 - 哪些经验或能力是锦上添花
  4. 红线 - 什么样的简历直接淘汰

如果用户只说"帮我筛简历",主动追问以上信息。


第二步:简历解析

文件发现

  • 批量模式:扫描指定日期目录下所有 PDF 文件
  • 单文件模式:处理用户指定的单个文件
  • 文件名格式:【{岗位}_{地点} {薪资范围}】{姓名} {工作年限}年.pdf

信息提取

从每份简历中提取以下维度的信息:

基础信息

  • 姓名、工作年限、学历、期望薪资(从文件名或简历内容获取)

技术栈

  • 编程语言及熟练度
  • 框架/中间件/工具
  • 数据库、缓存、消息队列等基础设施
  • 区分"用过"和"深入使用"——看项目描述中的角色和职责

项目经历(最核心)

  • 每段项目的业务领域和规模
  • 候选人的具体角色(主导/参与/协助)
  • 技术决策的深度——是做执行还是做设计
  • 可量化的成果(性能提升、用户增长、成本降低等)

职业轨迹

  • 公司规模变化(小→大 vs 大→小 vs 横向跳)
  • 职责范围变化(纯开发→带团队 vs 一直做执行)
  • 技术栈演进(是否在更新 vs 停留在老技术)
  • 在每家公司的停留时间(频繁跳槽 vs 稳定)

第三步:深度评估

这是本 Skill 的核心。不是简单匹配关键词,而是判断候选人的真实技术深度。

3.1 硬性条件初筛

先过门槛,不满足的直接标记淘汰:

| 检查项 | 判定 | |--------|------| | 工作年限 | 低于最低要求 → 淘汰 | | 必须技术栈 | 简历中无相关经验 → 淘汰 | | 学历 | 不满足要求 → 淘汰 |

3.2 技术深度评估

对通过初筛的候选人,逐项评估:

技术广度(0-10分)

  • 掌握的技术栈覆盖面
  • 是否只会在单一框架下工作

技术深度(0-10分)—— 这是区分度的关键

  • 项目描述中是否有技术选型的理由(说明参与过决策)
  • 是否处理过性能、并发、可用性等非功能性需求
  • 是否有从 0 到 1 的系统设计经验
  • 还是只做 CRUD 和业务逻辑实现

项目含金量(0-10分)

  • 项目规模(用户量、数据量、QPS 等指标)
  • 候选人的实际贡献(看描述中的"我"做了什么 vs "我们"做了什么)
  • 有无量化成果

成长性(0-10分)

  • 技术栈是否在更新
  • 职责是否在扩展
  • 是否有持续学习的迹象(开源、技术文章等)

3.3 风险识别

| 风险信号 | 说明 | |----------|------| | 频繁跳槽 | 3年内换3家以上 | | 技术栈停滞 | 多年使用同一套老技术,无更新 | | 描述模糊 | 项目经历只有"参与开发",无具体职责 | | 角色不匹配 | 申请高级岗但简历体现的都是执行角色 | | 薪资错位 | 期望薪资与能力水平明显不匹配 | | 过度包装 | 描述夸大,如"独立负责"但项目规模很大 |

3.4 综合匹配度

匹配度 = 硬性条件(通过/不通过) × 0.3
       + 技术深度 × 0.3
       + 项目含金量 × 0.2
       + 技术广度 × 0.1
       + 成长性 × 0.1

最终换算为 10 分制。


第四步:输出报告

4.1 候选人排名表

【简历筛选报告 - {岗位名称}】

筛选条件:{硬性门槛摘要}
筛选范围:{日期目录},共 {N} 份简历
通过初筛:{M} 份,淘汰:{K} 份

| 排名 | 姓名 | 匹配度 | 技术深度 | 项目含金量 | 核心优势 | 主要风险 | 建议 |
|------|------|--------|---------|-----------|---------|---------|------|
| 1    | 张三 | 8.5    | 8       | 9         | 高并发经验 | 薪资偏高 | 推荐 |
| 2    | 李四 | 7.2    | 7       | 7         | 全栈能力   | 项目偏小 | 可面 |
| ...  | ...  | ...    | ...     | ...       | ...      | ...     | ...  |

建议列取值:推荐(≥8.0)、可面(6.5-7.9)、备选(5.0-6.4)、淘汰(<5.0 或未通过初筛)

4.2 淘汰原因汇总

【淘汰候选人】

| 姓名 | 淘汰原因 |
|------|---------|
| 王五 | 工作年限不足(2年 < 最低3年) |
| 赵六 | 无 Java 后端经验 |

4.3 重点候选人详情(排名前3)

对推荐和可面的候选人,输出详细分析:

【{姓名} - 详细评估】

基础信息:{工作年限}年 | {学历} | 期望 {薪资}

技术栈:
- 核心技能:{列出并标注熟练度}
- 基础设施:{数据库/缓存/MQ等}

项目亮点:
1. {项目名} - {一句话总结候选人贡献和技术深度}
2. ...

风险点:
- {具体风险及判断依据}

面试建议:
- 重点追问:{基于简历中模糊或值得深挖的点}
- 考察方向:{建议面试重点考察的技术方向}

注意事项

  1. 隐私保护 - 简历包含个人隐私,评估结果不要输出到公开渠道
  2. 避免过度解读 - 简历信息有限,对不确定的判断标注"待面试确认"
  3. 文件名是重要信息源 - 岗位、地点、薪资、年限都在文件名中,不要忽略
  4. 不要只看关键词 - "使用过 Spring Boot" 和 "设计过 Spring Boot 微服务架构" 是完全不同的深度
  5. 区分事实和推断 - 评估中明确标注哪些是简历中明确写的,哪些是基于描述的推断