每日一个开源项目（第141篇）：hiring-agent - HackerRank 开源了他们的简历评分系统，你的简历能得几分？

引言

"HackerRank 把他们的内部招聘系统开源了------这意味着你现在可以用招聘方的视角来审查自己的简历。"

这是"每日一个开源项目"系列的第141篇文章 。今天的主角是 hiring-agent------HackerRank/InterviewStreet 开源的简历评分流水线。

先说最重要的一点。

这个工具本来是给招聘方用的：批量处理候选人简历，给每份简历输出可解释的评分结果。但对程序员来说，它的价值可以反过来用：用招聘方的标准给自己的简历打一遍分，看看评分系统怎么看你。

看到自己得了多少分是次要的，更重要的是理解：系统扣分在哪里，加分在哪里，什么被认为是强项，什么在评分体系里根本不算数。这些信息直接告诉你，你的简历在招聘系统眼里是什么样的。

你将学到什么

• 评分系统的四个维度权重------为什么 GitHub 贡献比你想象的更重要
• 五阶段流水线：PDF 怎么变成一个分数
• GitHub Enrichment 的细节：哪些仓库会被选中，哪些会被忽略
• 从应聘者视角：如何用这个工具 review 自己的简历
• 评分范围 -20 到 120 的设计含义
• 本地运行（Ollama）vs 云端（Gemini）两种方案

前置知识

• 有 Python 基础（能跑起来一个项目）
• 简历是 PDF 格式
• 有 GitHub 账号（没有也可以评分，但会少一大块分数）

---

项目背景

项目简介

hiring-agent 是一个简历评分流水线：输入 PDF 简历，输出结构化的评分报告。底层用 LLM（Ollama 本地或 Google Gemini）做文本理解和评分，额外拉取 GitHub 数据作为信号补充。

HackerRank 的公司宗旨是"根据技能评判候选人，而非学历背景"。这套评分系统体现了这个理念------权重最高的是你实际做过什么（开源贡献、个人项目、生产经验），而非你毕业于哪所学校。

作者/团队介绍

• 组织: HackerRank / InterviewStreet
• License: MIT
• 语言: Python（100%）

项目数据

• ⭐ GitHub Stars: 2,200+
• 🍴 Forks: 599+
• 📄 License: MIT

---

评分维度：先把规则看清楚

这是最关键的部分。系统按四个维度打分，加上奖励分和扣除分：

基础分（满分 100）
  ├── open_source（开源贡献）
  ├── self_projects（个人项目）
  ├── production（生产经验）
  └── technical_skills（技术技能）

奖励分：最多 +20 分（超出预期的亮点）
扣除分：最多 -20 分（不一致、虚假信号等）

最终分数范围：-20 到 120

关键数据点 ：根据 Reddit 社区的讨论，open_source 和 self_projects 两个维度合计占基础分约 65 分。也就是说，GitHub 贡献和个人项目在这套评分里占了三分之二的权重。

这个设计对程序员的启发很直接：如果你的 GitHub 档案空洞或者私有，这套系统会给你打很低的分------不管你简历上写了多少技术栈。

维度解读

open_source（开源贡献）

系统查看的是你对外部开源项目的贡献，不只是自己建的仓库。有实质性 commit 记录的贡献加分，只是 star 或者 fork 不算。贡献到知名项目（Linux 内核、主流框架等）加分更多。

self_projects（个人项目）

你自己主导建设的有意义的项目。系统会过滤：只有达到一定 commit 数量阈值的仓库才被算入，Hello World 级别的仓库不计入。多年持续维护的项目比短期冲刺的项目更有分量。

production（生产经验）

工作经历里是否有真实上线、被实际用户使用的产品经验。简历里提到的技术需要有对应的实际影响描述（"服务了多少用户"、"处理了多少请求"之类的数据），而不只是"负责开发了某某模块"。

technical_skills（技术技能）

技术广度和深度的综合评估。简单罗列技术栈（React、Python、Docker......）不如能展示这些技术在实际场景中的深度应用。

---

流水线：五个阶段

你的简历 PDF
    ↓
Stage 1: PDF → Markdown（PyMuPDF）
    ├── 解析页面内容
    ├── 保留标题层级、表格、链接
    └── 输出可供 LLM 处理的文本

Stage 2: 章节结构化（Jinja 模板 + LLM）
    ├── Basics（基本信息）
    ├── Work（工作经历）
    ├── Education（教育背景）
    ├── Skills（技能）
    ├── Projects（项目）
    └── Awards（奖项）
    按 JSON Resume 标准输出结构化数据

Stage 3: GitHub 信号增强
    ├── 拉取 GitHub 个人资料
    ├── 抓取所有公开仓库
    ├── 筛选：commit 数量 > 阈值的仓库
    ├── 分类项目类型
    └── 选取最有代表性的前 7 个仓库

Stage 4: 评分（LLM + 规则）
    ├── 按四个维度打分
    ├── 生成每项分数的证据说明
    ├── 计算奖励/扣除分
    └── 公平性约束检查

Stage 5: 输出
    ├── 终端可读报告（分项分数 + 证据）
    └── CSV 追加记录（可选）

从应聘者视角看 Stage 3：系统从你的简历里提取 GitHub 用户名，然后直接去 GitHub 拉数据。这意味着：

• 简历上要明确写 GitHub 链接（否则系统可能找不到）
• Private 仓库不可见，不计分
• Forked 但没有实质修改的仓库价值低
• 空仓库（只有 README）基本不算

---

如何用它给自己的简历打分

安装和运行

# 克隆仓库
git clone https://github.com/interviewstreet/hiring-agent
cd hiring-agent

# 创建虚拟环境
python -m venv .venv && source .venv/bin/activate

# 安装依赖
pip install -r requirements.txt

# 配置
cp .env.example .env

方案一：本地运行（Ollama，不需要 API Key）

# 先安装 Ollama: https://ollama.ai
ollama pull gemma3:12b  # 质量较好的选择，需要约 8GB 内存

# .env 配置
LLM_PROVIDER=ollama
DEFAULT_MODEL=gemma3:12b

方案二：Google Gemini（质量更高，需要 API Key）

# .env 配置
LLM_PROVIDER=gemini
DEFAULT_MODEL=gemini-2.5-pro
GEMINI_API_KEY=your_key_here

运行评分：

python score.py /path/to/your_resume.pdf

可选：设置 GitHub Token 避免 API 限流：

GITHUB_TOKEN=your_github_pat  # 在 .env 里加这一行

如何解读输出结果

输出报告不只给你一个总分，每个维度都有证据说明：

=== 评分报告 ===

open_source: 18/30
  证据: 在 tensorflow/models 仓库有 3 个 merged PR，
        参与了 kubernetes/kubernetes 的文档贡献。
        扣分：未找到主要开源项目的核心贡献记录。

self_projects: 22/35
  证据: GitHub 上检测到 4 个有效项目（commit > 阈值）：
        - my-web-scraper: 230 commits，持续 2 年
        - cli-tools: 180 commits
        - ...
        奖励: 其中 1 个项目有 150+ stars

production: 12/20
  证据: 工作经历中提及了用户规模数据（"日活 5 万用户"），
        但缺乏关于系统规模、可靠性指标的具体描述。

technical_skills: 15/15
  证据: 技能覆盖前端、后端、基础设施，
        且在项目和工作经历中有具体应用记录。

奖励分: +5
  证据: 在顶级会议发表过技术文章。

扣除分: 0

总分: 72/100（含奖励：77）

这个细粒度的证据说明才是最有价值的地方。它告诉你：

1. 系统找到了什么：你的 GitHub 项目是否被正确识别
2. 系统没找到什么：哪些信息在简历里没有体现
3. 扣分在哪里：具体哪个维度拖了后腿
4. 哪里可以加分：奖励分的触发条件

从评分结果反向优化简历

几个典型的改进方向：

情况一：open_source 分低

• 简历没有 GitHub 链接 → 加上
• GitHub 主要是 private 仓库 → 考虑把部分仓库开放
• 只有自己建的仓库 → 找几个活跃的开源项目贡献 PR

情况二：self_projects 分低

• GitHub 上仓库少且 commit 少 → 说明"有项目"但代码不在公开 GitHub 上，或者缺乏持续维护
• 项目描述不清晰 → README 里加上项目背景、技术选型、实际效果

情况三：production 分低

• 工作经历写的是"负责...开发..."而非"实现了...使得..." → 改成结果导向的描述
• 缺少数据：用户量、请求量、性能指标 → 在合规范围内加入具体数字

情况四：technical_skills 分低

• 技能列表太长太泛 → 精简到真正有深度使用经验的技术
• 技能没有在项目/工作经历里对应体现 → 确保简历各部分相互印证

---

系统的局限性：用它参考，别迷信它

有几点需要注意：

GitHub 公开度偏差：系统只能看公开仓库。如果你在公司做了大量内部代码工作，或者出于保密原因主要用私有仓库，你的评分会系统性偏低。

语言和格式敏感：PDF 解析质量会影响结构化准确率。排版复杂的简历（多栏、图形元素多）可能导致信息提取失败。建议用干净的单栏格式。

模型质量影响结果：用 Ollama + 小模型（gemma3:4b）和用 Gemini Pro 跑出来的结果会有差异。如果评分看起来有明显错误，换更大的模型重跑。

评分体系的价值判断：这套系统的权重（开源 + 个人项目 > 生产经验）反映了 HackerRank 自己的招聘偏好，不一定代表所有公司。大厂可能更重视生产经验，创业公司可能更看重个人项目的创造力。把它当参考，而不是唯一标准。

---

快速开始：用 Gemini Flash 跑最省钱

如果只是想快速试用，Gemini Flash 成本极低：

# .env 配置
LLM_PROVIDER=gemini
DEFAULT_MODEL=gemini-2.0-flash  # 速度快，成本低
GEMINI_API_KEY=your_key         # Google AI Studio 可以免费获取

DEVELOPMENT_MODE=True  # 开启缓存，避免重复调用 LLM

然后：

python score.py ~/Desktop/my_resume.pdf

---

项目地址与资源

• 🌟 GitHub : interviewstreet/hiring-agent
• 🏢 HackerRank : hackerrank.com
• 📄 JSON Resume 标准 : jsonresume.org

---

总结

hiring-agent 的最大价值，对程序员来说，不是帮你理解"招聘方用什么工具"，而是帮你回答一个具体问题：按照这套标准，你的简历现在能得多少分，差在哪里。

四个维度的权重分布揭示了一件事：在这套体系里，GitHub 上可见的项目活动占了基础分的约 65%。这意味着简历写得再好，如果 GitHub 档案空洞，分数就会很低。这个洞察直接影响你的时间分配------是继续打磨简历措辞，还是花时间把一个值得展示的项目推上 GitHub。

评分之后仔细读每一条证据说明，那里有具体的信息：系统认为你的哪些项目有价值，哪些被忽略了，工作经历里缺少什么类型的描述。这些才是可以直接转化为行动的反馈。

---

探索 PrimeSkills ------ 精选 AI Agent 与技能的市场，每一个都经过真实企业工作流验证，去掉浮夸，留下真正有用的。

欢迎访问我的个人主页，发现更多有价值的见解和有趣的产品。