同一份简历从 66 到 99 分：LLM 简历打分不能直接当淘汰线

同一份简历，第一次跑出 90/100。清掉调试输出后再跑，变成 74/100。关掉开发模式、循环 100 次后，分数落在约 66 到 99 之间。

这是 HackerRank 旗下 InterviewStreet 账号开源的 hiring-agent 最近被讨论起来后，一名开发者做的本地测试。它不能证明所有 AI 招聘系统都不可靠，也不能说明 HackerRank 官方 ATS 已在企业招聘中大规模使用这套机制。

但它戳中了一个很现实的问题：如果 LLM 给简历打总分，企业又把这个总分接到筛选阈值上，招聘流程就可能从评估变成抽签。

发生了什么：简历被解析、补 GitHub，再交给 LLM 打总分

hiring-agent 的流程并不神秘。

PDF 简历先被解析成文本。LLM 再抽取基本信息、工作经历、教育、技能、项目和奖项。系统还会拉取候选人的 GitHub 信息，扫描热门仓库，把这些内容一起送进最后的评分环节。

真正敏感的是最后一步：由 LLM 给候选人打总分。

默认权重也有明显取向。开源贡献 35 分，个人项目 30 分，工作经验 25 分，技术技能 10 分，另有最高 20 分 bonus，用来奖励创业经历、个人网站、技术博客等。

在 gemma3:4b、temperature 0.1 下，同一份简历 100 次总分约为 66 到 99。若企业把 85 分设为线，同一候选人约 65% 概率会失败。

换成 Gemini 3.1 Flash Lite 后，分布更窄。50 次约在 48 到 64。但如果分数线设为 60，同一份简历仍有约 28% 概率被挡下。

这才是反常点。

不是分数高低有争议，而是同一材料、同一候选人、多次运行后会进入不同命运。

为什么会波动：清单稳定，判断不稳定

简历筛选里，最适合自动化的是硬条件匹配。

有没有 Python、React、Kubernetes。有没有某段工作经历。学历、年份、公司名能不能抽出来。这些接近 checklist，LLM 做得稳定并不奇怪。

麻烦在“质量判断”。

一个项目到底是玩具项目，还是证明了真实部署能力？一个开源仓库是偶然提交，还是长期维护？一段经历是核心贡献，还是只是在团队里待过？这些问题需要岗位上下文，也需要面试追问。

LLM 可以给出像样理由。但像样，不等于可复现。

材料里还有两个限制值得放在台面上。

一个是温度参数。GitHub issue 中已有反馈，temperature 设为 0 时仍会出现连续评分差异。所以不能把问题简单归结为“温度没调好”。

另一个是岗位提示词。作者发现模板首行曾出现 Software Intern，但用明确的 Senior SWE prompt 重跑后，结果仍类似。这说明波动不只是岗位名写错，而是评分锚点本身不够硬。

这里要分清两件事。

LLM 做摘要、抽字段、标记缺失信息，价值很明确。它能省面试官时间，也能让简历阅读更顺。

LLM 做最终分数，尤其是让一个总分决定是否淘汰，风险完全不同。前者是辅助阅读，后者是在替流程关门。

谁最受影响：选型团队要先查阈值，筛选团队要保留复核

最该在意这件事的，不是普通围观者，而是两类人。

一类是参与招聘系统选型的工程师。看到带 AI scoring 的 ATS 或插件时，不该只看 demo 里总结得多漂亮。更该要求供应商或内部团队提供一致性测试：同一份简历重复运行多少次，分数方差多大，模型版本变更后是否重新校准，是否保留审计日志。

如果这些回答不上来，采购和上线就应该延后。至少不能让分数直接触发拒信。

另一类是负责简历筛选流程的技术管理者。LLM 可以放在前处理环节，帮团队提炼技能、项目、风险点和面试问题。但如果要打分，分数只能做排序参考，不能做硬淘汰。

更稳妥的做法是把自动化边界写清楚：硬性条件用规则判断，主观质量用 rubric 约束，低于线的候选人保留人工抽查。尤其是 85 分、60 分这类阈值，不能只因为系统给了数字就当成尺。

接下来最该观察的也不是这个项目还会涨多少 star，而是三个变量。

目前能下的结论要克制。

这组实验不是对整个 AI 招聘行业的量化判决。它只是说明，在这个开源项目和相关测试条件下，LLM 总分还不适合直接变成自动淘汰线。

但这已经够用了。

招聘里，尺子可以粗一点，流程可以快一点。但尺子如果每次量出来都不一样，就不能拿来卡门。