应用场景
线索评分
一次请求内，从定价页表单读出匹配度与购买阶段。
问题
SDR 把每一封演示请求一视同仁，漏掉高意向的工程师。
代码拿到答案后怎么做
当匹配度强且意向为评估或就绪时，给销售发出跟进提醒。
一份表单载荷，三个信号
定价页载荷就是 state：company_size、role、线索自己写下的备注，以及来源。三个问题在一次调用里返回 — fit（从 poor 到 strong 的 score）、intent（在 researching、evaluating、ready 之间 choice）与 contact_sales（yes/no）。示例里，那句“每月 40k 工单、LLM 成本在爆炸”读起来清清楚楚是一个强匹配、评估阶段的线索 — 这正是值得当天就得到人工回复的那种人。
销售拿答案做什么
当 fit 强且 intent 为 evaluating 或 ready 时，24 小时内跟进 — 一条基于三个数字的朴素代码规则。线以下的其他线索也照常分流：强匹配的调查者进培育，疑似匹配的评估者进 SDR 队列，弱匹配进 drip。模型会读那句留言 — “成本在爆炸”，而不只是字段 — 所以一家小公司写下的认真来信也会被评得值得一看，而不是被人数规模过滤掉。
线索评分专属的坑
不要让分数顶替人的判断：分数为“谁该接到电话”提供参考，这个决定归人 — 拒绝尤其如此。一个描述实际上是“任何技术人员”的“强匹配”是个大杂烩，而大杂烩会把错误的队列灌满。message 字段永远要带上：它是信号最强的输入，一旦悄悄丢掉，所有东西都会退化到按字段数据的规则运行。
请求结构
这是 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": {
"form": {
"company_size": "200-500",
"role": "Head of Engineering",
"message": "We route ~40k support tickets a month with an LLM and costs are exploding. Looking for something faster."
},
"source": "pricing page"
},
"questions": {
"fit": {
"type": "score",
"instructions": "How well does this lead fit a developer API product?",
"criteria": [
"Poor fit",
"Possible fit",
"Strong fit"
]
},
"intent": {
"type": "choice",
"instructions": "What is their buying stage?",
"criteria": {
"researching": "Early research",
"evaluating": "Comparing options now",
"ready": "Ready to buy"
}
},
"contact_sales": {
"type": "noul",
"instructions": "Should sales reach out within 24 hours?"
}
}
}'关于此用例的常见问题
- 线索决策是公平性敏感的决策吗？
- 是 — 把它约束在明确的赛道里：分数提供路由参考，谁被联系、谁被拒绝由人决定。为低置信线索设一个阈值，让他们等人处理，而不是收到一个自动化的“不”。
- 模型能抓到规则漏掉的什么？
- 它读 message 字段，而规则完全无视它。胜出的组合通常是类型化决策出信号、静态规则管合规：国家限制、存量客户去重、供应商名单检查。
- source 字段重要吗？
- 重要 — 把它作为 state 传入（“定价页”对比某个转介绍）。contact_sales 的概率会读这个意向上下文，而你的规则仍然可以对不同来源区别加权。