HackerRank 开源 ATS 评分系统：同一份简历，分数从 66 到 99 随机波动

背景：开源 ATS 工具引起关注

HackerRank 近日将旗下自动简历筛选系统（ATS）开源，托管于 GitHub。工具迅速在 LinkedIn 和 Reddit 引发热议，获得数千点赞。作者同事偶然提及后，决定亲自测试其稳定性和公平性。

测试结果：同一份简历得分剧烈震荡

首次运行获得 90/100，作者感觉不错。随后清理调试打印语句后再次运行，分数骤降至 74/100。为排除随机因素，作者关闭开发模式，将程序放入循环中运行 100 次，结果分数在 66 到 99 之间大幅波动。假设某公司以 85 分为筛选阈值，那么同一份简历有 65% 概率被淘汰——纯粹凭运气。

工具工作机制解析

PDF 简历经解析转换为文本。
大模型被调用六次，提取结构化信息：基本信息、工作经历、教育背景、技能、项目、奖项。
同时拉取 GitHub 个人主页，扫描顶级仓库作为额外上下文。
最后将所有信息一次性喂给 LLM 评分。

评分总分 100 分，另加 20 分奖励：开放贡献 35 分、个人项目 30 分、工作经验 25 分、技术技能 10 分。奖励分覆盖创业经历、个人网站、技术博客等。默认模型是 gemma3:4b，运行温度设定为 0.1——该低温值理论上能促使模型输出相对确定的结果。

各维度评分稳定性对比

技术技能：近乎完美的一致性

技术技能得分为 8/10 的比例高达 98/100 次。原因很简单：技术技能本质上是清单检查——会不会 React，一目了然，无需 LLM 做主观判断。五岁小孩也能完成此类匹配工作。

项目评分：巨大的随机波动

LLM 在判断项目质量时表现出极大不确定性。同一次简历，有时被 LLM 认定为“缺乏架构复杂度”，有时又被称赞为“展示真实世界部署经验”。最终结果是掷骰子般随机。即便将温度降至 0，问题仍未解决。早在 2025 年 10 月，就有 GitHub issue 报告过温度 0 下连续六次运行分数为 27、34、32、34、34、30 的剧烈跳动。这种非确定性不是可以通过微调修复的 Bug，而是深层设计缺陷。

工作经验评分：稳定但无意义

工作经验项在每次运行中都稳定为 25/25。作者特意翻出只有一段实习经历的旧简历进行测试，结果同样满分。原因出在提示词：

分析工作和志愿者经历中的真实世界、实习或生产经验。
特殊考虑：对创始人、联合创始人或早期阶段工程师（前 10-20 员工）给予额外加分。

整个评分维度仅两行文字：没有评分标准，没有示例，没有区分 15 分和 25 分的锚点。一个仅有一次实习的初级工程师与拥有十年分布式系统经验的首席工程师获得同样满分，说明该维度虽然一致，但毫无区分力。

开放贡献评分：已改善但项目仍不稳定

开放贡献维度经过改进后变得稳定，这是一个合理的提升。但项目评分依然混乱。

核心问题：LLM 适合做什么

LLM 在做结构化数据提取（如解析简历）和清单式检查（如判断是否掌握 Python）时表现出色。但在主观评价上，例如判断候选人的工作经验值 18 分还是 24 分，本质上只是“感觉评估”。这正是 HR 团队、面试把关人以及众多反偏见倡议多年来努力避免的现象。

打分权重设置也加重了偏见：开放贡献加个人项目合计占 65%。这意味着一个曾构建 S3 的三十年经验工程师，得分可能还不如两个实习加一个开源项目的候选人。许多优秀工程师的工作从未上传至 GitHub，但工具会先扣掉他们大半分数，然后才轮到人类招聘者过目。

对招聘实践的建议

如果工程师在公司内有任何影响简历筛选流程的话语权，请谨慎对待 AI 筛选工具。一个无法有效区分的工具，不是在筛选质量，只是在盲目过滤。结果与随机丢弃一半简历几乎没有区别，将招聘变成了“运气过滤器”。

后续修正：职位无关的评分维度

有读者指出 resume_evaluation_criteria.jinja 模板第1行写着“Software Intern”——该词在仓库其他地方均未出现。同一模板后又对创始人等角色给予加分。作者用明确的“Senior SWE”提示词重新运行后，结果完全一致，说明评分维度与职位无关，设计上存在潜在偏见。

社区反应

尽管开源时间实际上可追溯到 2025 年 10 月（当时已有非确定性问题的 GitHub issue），但近期因 LinkedIn 和 Reddit 上诸多帖子的病毒式传播才引发大规模关注。

原标题：HackerRank open sourced its ATS. My resume scored 90/100. Oh wait 74. No – 88。 HN 原始发布时间：2026年6月29日星期一。当前记录为 962 分、405 条评论。

阅读原文 · 查看 HN 讨论