一份简历在同一个ATS系统里不同得分：90分、74分、88分。
HackerRank开源ATS对同一份简历重复评分，结果从66到99分随机分布。技术能力评分几乎完全一致，项目经验评分却像摇骰子。
65%的权重压在开源和个人项目上，意味着一个写过S3的资深工程师可能被两个实习生的GitHub仓库打败。resume_evaluation_criteria.jinja模板里白纸黑字写着创始人额外加分，但跑出来的分数根本不认这个规则——写了等于没写。
ATS的GitHub地址是：
https://github.com/interviewstreet/hiring-agent
项目名叫 hiring-agent，由 HackerRank 母公司 interviewstreet 发布，采用 MIT 许可证，最近在 GitHub 上热度很高，已经获得了超过一千个 star
我跑了100次评分，得到了一堆不重样的数字
HackerRank最近开源了他们家那个叫hiring-agent的ATS系统，GitHub上星星暴涨，LinkedIn和Reddit上到处都是讨论贴。同事几天前随口跟我提了一嘴，我就顺手拉下来试试看。
第一次跑，90分。感觉不错，对吧？然后我清理了一下调试打印语句，又跑了一次。74分。同一份简历，同一个命令，唯一的变化就是删了几行print。
我关了DEVELOPMENT_MODE，写了个循环跑了100次。最低66，最高99。如果你的公司把分数线设在85分，那我有65%的概率被刷掉。不是简历内容变了，是运气变了。
评分原理拆开看，像极了HR在走流程
这个工具的工作流程大概是这样的：先把你的PDF简历解析成纯文本，然后调用LLM六次，分别提取个人信息、工作经历、教育背景、技能列表、项目经验和获奖情况。它还会去扒你的GitHub主页，扫描你置顶的几个仓库，把这些额外信息塞进去。最后把所有东西一股脑扔给LLM，打一个总分。
评分体系是这样的：满分100，外加最多20分Bonus。开源贡献占35分，个人项目占30分，工作经历25分，技术技能10分。Bonus给创业经历、个人作品集网站、技术博客之类的东西。
默认模型是gemma3:4b，温度参数设成temperature=0.1。按理说温度越低，输出越确定。但实际情况完全不是那么回事。
技术技能评分稳得像计算器，项目评分疯得像算命
我把100次评分按类别拆开看，发现了一个特别有意思的对比。技术技能那一项，10分满分，我98次都拿了8分。几乎纹丝不动。
为什么？因为技术技能本质上就是个勾选框。你简历上写了React，系统就勾一下，写了Python再勾一下，写了Docker再勾一下。这不是判断，这是匹配。一个五岁小孩拿着清单也能干这事。
但项目评分就完全失控了。有时候模型说我的项目"缺乏架构复杂度"，有时候又说"展示了实际部署能力"。同一个项目，两套说辞，全看模型当时的心情。
温度调到0.1已经很低了，但有人去年十月就提过GitHub issue，说temperature=0跑六次，分数分别是27、34、32、34、34、30。这个随机性不是调参能修好的bug，是设计层面的根本问题。
换了个模型，问题从摇骰子变成了转轮盘
我担心问题出在gemma3:4b这个本地小模型上，于是换成了gemini-3.1-flash-lite再跑50次。分布确实收窄了，分数集中在48到64之间。但如果你的公司把及格线设在60分，那你还是有28%的概率因为不可控因素被淘汰。
再看细分项，gemini的开源贡献评分稳了很多，算是个进步。但项目评分依然忽高忽低，稳定不下来。
最让我心里发毛的是工作经历评分。25分满分，每一次都是25分。一次不落。
我翻出一份老简历，上面只有一个实习经历。也是25分。这就离谱了。
提示词写了一堆规则，模型一条都没执行
我去翻了一下源码里的prompt模板，resume_evaluation_criteria.jinja里关于工作经历的部分长这样：
Production (0-25 points)
- Analyze the 'work' and 'volunteer' sections for real-world, internship, or production experience
- SPECIAL CONSIDERATION: Give extra points for founder roles, co-founder positions, or early-stage engineer roles (first 10-20 employees) at startups
看清楚了吗？白纸黑字写着"创始人、联合创始人、早期初创员工额外加分"。但你猜怎么着？我拿同一份简历，改了一个版本说自己是创始人，另一个版本说是普通工程师，跑出来的分数一模一样。
这不是模型没看懂，是这条规则在代码执行层面根本没有被激活。模板第一行还写着"Software Intern"，这个标注在整个仓库里没有被任何地方引用过，没有任何文档解释它是干嘛的。一条写了但没执行的规则，比没写更糟糕。它制造了一个"系统会考虑创始人背景"的假象，实际上它连你是不是实习生都分不出来。
一个只有一次实习的初级工程师拿25分，一个做了十年分布式系统、写过S3的资深工程师也拿25分，我也拿25分。这个分数稳定得毫无意义，因为它压根没在区分任何东西。
反过来，项目评分有详细的rubric和示例，结果却是噪音最大的类别。有细则的反而更不准，没细则的倒是很稳定——稳定在无效。这就好比一把尺子，要么刻度模糊量不准，要么刻度清晰但每次量出来的长度都不一样。
有些事LLM就是做不好，不管你怎么写prompt。
网友观点
根据你贴的Hacker News评论区，网友的主要看法可以总结为这几点：
1. 对LLM随机性的技术讨论
很多人在争论temperature=0到底该不该产生确定性输出。有人认为理论上应该稳定，但GPU矩阵乘法的非确定性、浮点精度、批处理等因素导致了实际运行中的波动。也有人指出，就算temperature=0，如果多个logit相同，采样本身还是随机的。
2. 对AI筛简历的态度两极分化
一边是HR背景的人说"35%通过率已经很好了，简历量太大根本看不过来"，认为AI至少能帮他们从1000份里筛出300份。另一边是求职者视角的愤怒："这不就是随机扔简历吗？65%的合格候选人被无缘无故刷掉。"
3. 有人在吐槽这个工具本身的设计
网友指出用gemma3:4b这么小的模型来做评判很荒谬，"就像在系统里插了个RNG"。有人调侃"这项目就是vibe coding出来的，跑通了测试就发了"。还有人发现评分权重65%压在开源和个人项目上太离谱，等于歧视那些在公司代码库里干活但没空搞副业的工程师。
4. 提到"随机扔掉一半简历"的老梗
评论区反复出现一个段子：某CTO把收到的简历随机扔掉一半，理由是"不想招运气不好的人"。大家说这个ATS系统把这个段子做成了产品。
5. 质疑这套系统谁在用
有人追问"到底有没有公司真的在用这个工具？"回应的人说，即便不是这个具体工具，各个ATS都在加AI自动评分功能，你的简历早晚会撞上某个类似的"魔法八号球"。
6. 法律层面的担忧
有人提到GDPR规定，被自动化决策拒绝的求职者有权要求人工复核。但大家普遍觉得，在实际操作中这条很难落实。