用 Jev 筛选简历：匹配度、资历和下一步

这个工具检查什么

上面的示例是为一个高级后端工程师岗位筛选一位候选人，岗位要求 Go、Postgres 和 Kubernetes。候选人有六年后端经验，主要用 Python 和 Django；在一家金融科技创业公司主导过向 Kubernetes 的迁移；最近 18 个月一直用 Go 开发内部工具；熟悉 Postgres 调优。Jev 在一次调用里回答三个问题：

这是一份有意设计得"不上不下"的履历。候选人的主力语言不是岗位写明的那一个，但最近有 Go 经验，也做过岗位需要的 Kubernetes 和 Postgres 工作。关键词过滤器恰恰会在这种情况下拒掉合适的人。值得看的是 match 在 Partial 和 Strong 之间怎么分布，以及 next_step 是否偏向 phone_screen 而不是 reject。

state 很短，问题只有三个，所以这是一次标准评估：在 JevStation 上扣 1 点。

怎么写好筛选问题

把门槛写出来，而不是让它去猜。 预设问的是"候选人是否达到资历门槛？"，却没说门槛是什么。Jev 按字面理解指令，所以它只能猜。在问题的 criteria 里用职责范围来描述门槛——例如"独立主导过一个系统或一次迁移"。

年限和日期在代码里算。 "六年""最近 18 个月"看起来很简单，但 TypeSafe 把计数和日期比较列为弱项。如果岗位要求最低工作年限，就从招聘系统的结构化数据里算出来，以 years_backend: 6 这样的字段传入，或者干脆不放进自动化环节。

只发送决策应当使用的内容。 Jev 有上下文腐化（context rot）的问题：state 里无关的内容会降低准确率。把简历裁剪到经历和技能，任何招聘决策不该依赖的信息都不要放进去（见下文）。

别让 reject 成为默认项。 像预设那样给每个下一步写清定义，并且把 reject 当作需要人确认的建议，而不是一个会自动执行的动作。

更多关于问法的内容，见设计 Jev 能回答的问题。

从一位候选人到筛选流程里的一步

1. 先用历史决策回测。 跑 50 到 200 位团队已经评估过的候选人。批量页面可以对 CSV 里的每一行跑同一组问题，让你在接入真实流程之前，先把 Jev 的回答和招聘人员的决定做对比。
2. 用 Jev 给队列排序。 按 match 给申请人排序，把有把握的 onsite 或 phone_screen 建议快速交给招聘人员。其余的仍然要有人看。
3. 每一个建议拒绝都交给人。 拒绝对候选人代价最大，而你对它的可见度最低。不要让它自动触发。
4. 记录答案。 保存各项概率、所用的问题集，以及每次响应都会返回的 model 字段，以便事后还原某位候选人是如何被打分的。模型或问题变化时重新校验阈值。
5. 从流水线里调用。 同样的评估可以用 API Key 通过 System One API 调用，扣点规则和试验台一样。

负责任地使用

对人做自动筛选是高风险的事，而一个又快又便宜的分类器，很容易把同一个错误复制到成千上万名申请人身上。在 Jev 给真实候选人打分之前：

• 每一个拒绝都要有人复核。 Jev 的输出应该改变人工复核的先后顺序，而不是取代复核。
• 用自己的数据检验不同群体的结果差异。 在你有权持有的数据范围内，比较不同群体的候选人分别得到各个 next_step 的比例，并且让这项审计和 Jev 看到的 state 完全分开。出现意料之外的差距，说明问题或输入在上线前还需要调整。
• 不要发送受保护属性或明显的替代信息。 姓名、照片、年龄、毕业年份、住址、国籍、婚姻或家庭状况等细节，都不应该出现在 state 里。
• 记住校准是群体层面的性质。 TypeSafe 说明，校准是在一组预测上衡量的，并不保证任何单个答案是正确的。
• 核实当地法律和你自己的制度。 关于招聘中自动化决策的规定因地而异，也可能变化。在自动化环节影响谁能进入下一轮之前，先确认哪些规定适用于你。

哪些时候 Jev 不是合适的工具

• 你必须向候选人解释每个决定。 Jev 返回的是概率，不是理由。一篇公开的 Jev 分析文章正是针对受监管行业提出了这个质疑。
• 岗位由硬性数字决定。 年限、日期、有有效期的证书、薪资区间，都应该放在代码里。
• 你想让它做最终决定。 不应该这样。用它把复核时间花在最需要的地方。
• 大部分简历不是英文。 先单独衡量这部分。

想更全面地比较通用 LLM 和训练好的分类器，见 Jev 与 LLM 分类对比。漏斗另一端的评分，见线索评估。