HackerRank 的这个开源 ATS 最近引起了很多关注：https://github.com/interviewstreet/hiring-agent 它在 LinkedIn 和 Reddit 上出现，获得了数百，有时甚至数千个赞。几天前，一位同事随口提到这个工具。我决定试试看。第一次运行得分：90/100。感觉非常不错！在排查设置问题时，我的代码中散落着一些调试打印，因此我把它们清理掉并再次运行。得分：74/100。同一份简历。同一个命令。唯一的区别是删除了打印语句。我关闭了 DEVELOPMENT_MODE，并将它放入一个循环中运行了一百次。得分范围从 66 到 99。如果你公司的分数标准是 85，我失败的概率是 65%。完全相同的简历，不同的运气。这里是这个工具如何工作的快速概述：你的 PDF 被解析为文本。一个 LLM 被调用六次以提取结构化信息——你的基本信息、工作经历、教育背景、技能、项目、奖项。它会提取你的 GitHub 个人资料，扫描你的顶级仓库，将它们作为额外的上下文信息。然后，所有数据一次性输入 LLM 进行评分。评分最高为 100 分，还有最多 20 分的加分：35 分用于开源贡献，30 分用于个人项目，25 分用于工作经验，10 分用于技术技能，最多 20 分的加分用于创业经验、个人网站、技术博客等。默认模型是 gemma3:4b，以 0.1 的温度运行——这个设置较低，理论上促使模型朝向确定性输出。查看这些单独类别时，我发现了一些情况。在技术技能方面：我在 100 次运行中有 98 次得分为 8/10。几乎完美的一致性。为什么？因为技术技能是一份检查表。你要么知道 React，要么不知道。这对于 LLM 来说没有任何可评判的内容——五岁的小孩也能完成这个检查表。现在看看项目——这里的差异巨大。LLM 很难持续地作出这样的判断。有时候我的项目“缺乏架构复杂性”，有时候它们“展示了真实世界中的部署”。LLM 吐出的结果就像掷骰子。温度 0.1 已经很低，但即使降到温度 0 也无法解决这个问题。有人在十月的时候在 GitHub 上提出了一个问题，显示在温度 0 时连续六次运行得分为 27、34、32、34、34、30。2 这种非确定性并不是你可以简单调整解决的错误，而是一种基本的设计缺陷。我担心部分原因可能在于模型。毕竟，gemma3:4b 是在我的机器上运行的本地模型。Gemini 产生了更紧密的分布——得分集中在 48 到 64 之间。但是如果你的分数临界值是 60，你仍然会以 28% 的几率失败，这不应该归咎于你自己。开源得分已经变得一致——这确实是一个令人满意的进步。但项目得分仍然五花八门。经历让我最为担忧。每次运行都得到 25/25。当我找到一份旧简历时——上面只有一个实习经历。也得 25/25。线索就在提示中……整个内容只有两行。没有评分标准。没有示例。没有什么能够区分 15 分和 25 分的标杆。一个有一个实习的初级工程师得 25/25。一个有十年分布式系统经验的首席工程师得到 25/25。我也得 25/25。经历只有两行，没有标杆——一致，但没有用。项目有详细的评分标准和示例，但它的噪音最大——不一致，也没有用。有些东西 LLM 无论如何都无法做得很好。用 LLM 将简历解析为结构化数据——很好，这是它们擅长的。用它来判断某人是否知道 Python——太棒了。用它来判断候选人的经历是否值 18 分还是 24 分？你得到的是直觉判断。这是人力资源团队、评估者，以及其他几个倡议花了几十年努力避免的事情。开源 + 项目的 65% 权重也无济于事。我会选择那位有 30 年经验、建立了 S3 的工程师，而不是那位只有两个实习经历和一个开源项目的候选人——但这个工具不会。有些我认识的最优秀的工程师建立的东西，从来没有出现在 GitHub 上。这是在任何人看向他们之前，超过一半的得分就消失了。如果你是一名对你的公司如何处理简历筛选有任何发言权的工程师：请非常小心 AI 筛选工具。一个无法区分的工具并不是在过滤质量——它只是在过滤。你干脆可以扔掉一半的简历，并告诉申请者你不希望碰到霉运。更正（6 月 28 日）：有读者指出，resume_evaluation_criteria.jinja 模板在第 1 行写着 "软件实习生"——在其他地方没有文档记录，也没有其他地方引用。相同的模板后来为“创始人角色、联合创始人职位或早期工程师角色”提供了加分。我用明确的高级软件工程师提示重新运行了一次，结果相同——评分维度与职位无关。1 在 LinkedIn 上广为传播（自担风险）和 Reddit 帖子。它们都声称该仓库最近已开源。