如何使用 Next.js、Supabase 和 TypeSafe Jev 构建 AI 简历筛选工具
内容提要
本文介绍用 TypeSafe Jev 模型构建简历筛选系统。Jev 不生成文本，只返回带校准概率的数值答案，避免大模型打分不可比、无法排序的问题。系统由 HR 按岗位编写评分标准，代码计算加权总分，低置信度结果转人工复核。实测 71 份简历，单次成本约 0.0002 美元，中位延迟 400 毫秒，60% 被标记复核。
延伸解读
为什么生成式打分不可靠
文章指出，大语言模型逐词生成文本，其输出的数字只是“看起来像数字的文本”，并非经过校准的概率。同一份简历两次运行可能得到不同分数，且不同简历之间的分数没有共享尺度，无法直接比较排序。这解释了为何用LLM直接打分会导致排序结果不可信，也是该工具选择判别式模型而非生成式模型的核心原因。
校准置信度如何支撑人工复核
Jev返回的置信度基于概率分布计算，而非模型的主观判断。当分布集中时置信度高，分布均匀时置信度低。文章强调，即使模型准确率高达95%，若无法指出哪些判断不可靠，仍需人工检查所有结果。校准置信度让系统能自动标记低置信度条目转人工，使人工复核成为有选择的设计，而非全量兜底。
评分标准由HR编写而非模型决定
该工具将评分标准作为数据库中的Jev问题存储，每个岗位可独立编辑。HR用自然语言定义各等级的行为描述，代码负责加权计算总分。文章对比了关键词过滤和ATS匹配分：前者易被关键词堆砌欺骗，后者标准不透明且无法调整。此设计让招聘经理能解释每个分数的来源，并在标准变化时快速重新评分。
实测成本与延迟表现
文章报告了71份简历的实测数据：单次筛选成本约0.0002美元，中位延迟400毫秒，60%的结果因置信度低于0.5被标记为需人工复核。成本低到可随时重新评分，延迟短到无需后台任务队列。但60%的复核率也说明，当前标准下多数简历仍需人工介入，自动化主要承担排序和初筛，而非替代阅读。
Q&A
为什么用大语言模型给简历打分不可靠？
大语言模型是生成式模型，逐 token 生成文本，其输出的数字只是看起来像数字的文本，并非经过校准的概率。同一份简历两次运行可能得到不同分数，且不同简历的分数之间没有共享尺度，无法比较和排序。
TypeSafe Jev 和 GPT、Claude 这类模型有什么本质区别？
Jev 不生成任何文本，只接收文本和一组带类型的问题，返回带校准概率的数值答案。它的输出空间被限制在预先定义的选项集合内，因此不会产生幻觉式的文本，也不需要解析 JSON 或阅读段落。
Jev 支持哪几种问题类型，分别返回什么？
Jev 支持三种类型：Score 按有序等级返回概率分布和期望值分数；Noul 是是否题，返回答案为是的概率；Choice 从固定选项集中选一个，返回所选键、各选项概率和置信度。
这个简历筛选系统的置信度阈值是怎么用的？
Score 和 Choice 的答案附带 0 到 1 的置信度，反映概率分布的集中程度。系统将阈值设为 0.5，低于该值的答案会被标记为需要人工复核，高置信度则自动通过，低置信度转人工。
Jev 处理一份简历的速度和成本大概是多少？
Jev 响应时间约 70 到 500 毫秒，单次请求约 4500 输入 token，成本约两百分之一美分。处理 350 份简历每周约花费七美分，输出 token 免费。
为什么综合评分要在代码里算，而不是让 Jev 直接给？
Jev 的分数输出不适合精确计算，等级只用于阈值判断。代码中的加权求和便于审计，能展示公式和输入，且修改权重后可在毫秒内重新计算所有候选人，无需重新调用模型。
Jev 有哪些做不到的事情？
Jev 不生成文本，没有摘要或理由；不能做算术，如计算年限或比较日期；只能读文本，扫描件无法处理；回答非常字面，严格按问题字面意思执行；虽然不会输出定义外的值，但判断仍可能出错。
这个系统的数据模型包含哪些表？
共六张表：jobs 存职位和描述，job_criteria 存每个职位的 Jev 问题，applications 存每份简历并缓存提取文本，screenings 存每次筛选运行，screening_answers 存每个问题的答案，profiles 镜像 auth.users 并加显示名。
