应用场景
简历预筛
核查硬性要求、给总体匹配度打分，且不编造经历。
问题
关键词搜索奖励注水简历，惩罚转行者。
代码拿到答案后怎么做
只有硬性条件明显缺失时才拒绝。其余全部进入面试。
先查硬性条件，再评匹配
state 带结构化的岗位信息（must_have 与 nice_to_have 清单）加简历文本。两个问题：meet_must_have（简历是否覆盖每一条硬性要求）与 fit（跨 weak、possible、strong 的 score）。拆开它们很重要，因为两者的行为不同：硬性条件覆盖是清单核对 — TypeScript、Postgres 与 API 设计，对照五年 Node.js 和两套计费系统 — 而 fit 是一个由你的阈值说了算的分级判断。
面试的是人，不是关键词
只有硬性条件明显缺失（低 meet_must_have 概率且高置信）时才拒绝。其他人继续推进 — 被关键词筛选惩罚的转行者，正是语义阅读的价值所在。把 nice_to_have 清单留在 state 里：fit 分数会吸收它，并且当管道渐满时，你为“possible”设的门槛可以浮动。
简历筛选专属的坑
公平在这里是法律层面的问题：分数负责分流、人负责决定，而且硬性条件拒绝必须可落地 — 是缺失的能力，而不是对文化契合的印象。不要把身份数据（姓名、住址、出生日期）送进决策调用；核查硬性条件用不到它们。还有，按季度复审 criteria — 资历会过时，一条实为 nice-to-have 的 must-have 就是靠关键词潜入的偏见。
请求结构
这是 playground 为该预设发送的完整请求 — 与你的服务器带 Bearer key 发往 /v1/systemone 的 JSON 相同。
curl
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": {
"role": {
"title": "Backend engineer",
"must_have": [
"TypeScript",
"Postgres",
"API design"
],
"nice_to_have": [
"Workers",
"payments"
]
},
"resume": "5 years Node.js, shipped two billing systems, strong TypeScript and Postgres. No public-cloud certs."
},
"questions": {
"meet_must_have": {
"type": "noul",
"instructions": "Does the resume cover every item in `role.must_have`?"
},
"fit": {
"type": "score",
"instructions": "How strong is this candidate for the role?",
"criteria": [
"Weak",
"Possible",
"Strong"
]
}
}
}'关于此用例的常见问题
- 这能取代招聘人员吗？
- 不能 — 它先行处理的是规模化最差的那一步：第一遍的硬性条件核查。淘汰终选人的决定保持人工，fit 分数送去准备面试，而不是丢进拒信堆。
- 如何避免关键词作弊？
- 模型读语义，这是双刃剑：“上线过计费系统”读起来比一张技能清单更有分量。把 must_have 项描述成能力，而不只是工具名，这次调用就会奖励真材实料而非注水。
- 简历属于敏感数据吗？
- 属于。网关把请求转发给模型计算答案且不保留内容 — 尽管如此，仍要在流程中取得申请者的同意，并且只发送决策所需的字段。