用 Jev 做了一个电商客服质检 Demo：意图识别、情绪监控与危险话术拦截
摘要： 用一个开源 Demo，看看 Jev（TypeSafe 的 System One 结构化判断模型）如何做客服意图识别、情绪监控、转人工判断和危险话术拦截。包含完整的配置思路与代码。
最近 Jev（TypeSafe 推出的 System One 模型）讨论度很高。它不是用来"写一段文字"的，而是专门做结构化判断：你给它问题和分析对象，它直接返回程序能用的结果。
我很快把它和以前接触过的电商客服 AI 质检对上了号。一通对话里要判的事太多了：用户想解决什么、现在多生气、该不该转人工、客服这句话有没有越权承诺……这些判断发生得频繁，还得跟得上对话节奏。用户已经聊到下一句，上一句的情绪分析还没回来，系统就很难及时调整。
这正是 Jev 擅长的。我顺手用它搭了一个客服质检 Demo，跑下来效果不错，于是把思路、配置和代码整理了出来。
[图 1] 系统全貌：左侧剧本库、中间对话区、右侧实时看板
一、先说清楚，Jev 到底干什么
我们平常用大模型，多半是让它写东西：回答问题、生成代码、总结文档。
Jev 是 TypeSafe 推出的 System One 模型，专门面向软件里的结构化判断。你把需要分析的内容和问题交给它，它返回程序可以直接使用的结果。
可以把它理解成一个专门"答题"的模型。它目前有三种基本题型：[2]
| 题型 | 客服场景里的例子 | 返回结果 |
|---|---|---|
choice，选择题 |
用户主要想查物流、退款，还是处理支付问题？ | 选中的类别及各选项概率 |
score，评分题 |
用户的负面情绪有多强？ | 按预设档位计算的分值及档位概率 |
noul，判断题 |
现在是否应该转人工？ | 答案为"是"的概率 |
比如用户说："付款卡了一下，结果扣了我两次钱。"
我们可以同时问它：主要意图是什么？情绪有多强？这件事有多急？要不要转人工？有没有风险信号？这些问题共享同一段对话上下文。
这里最让我感兴趣的是速度。
常见的自回归 LLM 会逐个生成 token，即便要求它输出 JSON，也仍要经过文本生成过程。按照 TypeSafe 的介绍，Jev 并行输出结构化判定及概率，专门为这类短促、频繁的判断做了优化。官方发布文章给出的端到端响应时间是 70–500 毫秒。这是官方环境的数据，评测主要在美国西海岸进行；我们通过不同网络和渠道调用，实际耗时会变化，切勿把这个数字当作本项目的实测结果。[1]
放到客服场景里，速度的价值很具体：每来一句用户消息，更新一次情绪和路由；每准备发送一句客服回复，检查一次话术风险。
LLM 当然也能做分类和评分。Jev 值得试的地方在于：把这类判断做得足够快，快到能塞进业务流程里随时调用。
二、我把哪些场景放进了 Demo
这个项目里有三组判定，分别看用户消息、客服回复和整段会话。
意图识别配置了 14 类：物流查询、物流异常、退款退货、换货补发、商品咨询、价格优惠、订单修改、支付问题、发票开票、售后维修、账号问题、投诉举报、活动规则、闲聊其他。
客服危险话术配置了 9 类风险，加一个"无风险"选项：绝对化承诺、越权赔付、时效硬承诺、泄露隐私、情绪失控、推诿甩锅、私下交易、违规宣称、诋毁他人。
用户侧还会识别监管投诉、媒体曝光、法律诉讼、人身攻击、疑似异常索赔等信号。
这些判定结果交给规则表，决定进入哪个队列、是否转人工、优先级是多少，以及危险话术需要提示还是阻断。
Jev 负责判断，程序按业务规则执行动作。
为了让这条链路看得见，我做了 12 个剧本。点一下就能逐条回放，也可以切换用户和客服身份，自己输入一句话试试。
三、第一组：用户到底想解决什么问题
这一组有三个剧本：①普通查件、⑪重复扣款、⑫售前咨询。
普通查件是基线场景。用户客客气气地问物流，自助流程能处理，就没必要直接升级。
重复扣款属于支付问题，需要识别到支付与账号队列。至于是否需要人工，要结合转人工判定和规则一起看。
售前咨询的例子是："这个显示器支持 144Hz 吗？我想接 PS5 用。"它应该进入商品咨询对应的售前队列。
这三个剧本验证的是：系统能不能听懂诉求，把问题交到合适的位置。
代码里怎么配置
判定问题写在 shared/policies.json。下面从意图配置中节选三个选项：
{
"id": "intent",
"type": "choice",
"instructions": "这位用户这条消息最主要想解决什么问题？只看这条消息想干什么，别猜他的情绪。",
"criteria": {
"物流查询": "问包裹到哪了、什么时候到、为什么不动了、物流信息不更新",
"支付问题": "付款失败、重复扣款、支付方式、分期、优惠没抵扣",
"商品咨询": "问商品参数、材质、尺码、是否适配、怎么用、有没有货"
}
}
instructions 写要问的问题，criteria 写可选答案及其含义。项目里完整配置有 14 类，包含兜底选项。
然后在 shared/routing.json 的 intentQueue 里，把分类映射到队列：
{
"物流查询": "bot",
"支付问题": "payment",
"商品咨询": "presale"
}
想增加业务类别，就同时补充"这个类别怎么判断"和"判断出来后送到哪里"。
[图 2] 普通查件、重复扣款、售前咨询的意图与队列结果
四、第二组：用户越来越生气，处理方式也得跟着变
这一组是 ②退款没到账、③丢件且急用、④投诉与媒体曝光。
退款剧本里，用户先问："退款申请三天了还没到账，什么时候处理？"
客服回复"请耐心等待"后，用户开始质疑："每次问都是这句话，你们是不是在拖？"最后要求当天解决，否则投诉。
这时光识别"退款退货"已经不够了。业务问题没变，用户的情绪和处理诉求却在变化。看板上的情绪曲线就是用来观察这个过程的。
丢件剧本又多了一层时间压力。用户说东西明天就要用，今天必须拿到。系统需要同时判断情绪和紧急度，符合条件时进入高优先专线。
到了剧本 ④，用户明确提到 12315 和媒体曝光，就要按外部投诉升级规则处理，进入客诉专席。
代码里怎么配置
情绪和紧急度都用 score，但分别定义评分口径：
| 判定项 | 从低到高的档位 |
|---|---|
| 情绪强度 | 平静、略有不满、明显不满、愤怒、暴怒 |
| 紧急度 | 不急、一般、较急、非常急 |
情绪看措辞和表达，紧急度看有没有明确期限、是否即将造成损失。一个用户很客气，也可能确实急需处理。
是否转人工则是一个判断题：
{
"id": "escalate",
"type": "noul",
"instructions": "这通对话现在就应该转给人工客服吗？判断依据：机器人已经解决不了、用户明确要求人工、涉及赔付或纠纷、情绪已经失控。"
}
程序拿到结果后，再匹配规则。比如 R4 的关键配置是：
{
"when": [
{ "q": "emotion", "gte": 2 },
{ "q": "urgency", "gte": 2 }
],
"then": {
"queue": "vip",
"human": true,
"priority": "P1",
"reason": "用户明显不满且有时间压力，交给资深客服，60 秒内接起"
}
}
这里的数字按从 0 开始的评分档位解释，when 里的两个条件要同时满足。60 秒是沙盘配置的响应目标。
另一个规则 R5 会在"该转人工"的概率达到 0.6 时，按意图转入对应队列。
规则从上往下匹配，第一条命中就生效。所以监管投诉、媒体曝光等信号对应的 R1 放在前面，命中后进入客诉专席 P0，标记必须人工处理。
[图 3] 退款剧本的情绪曲线与逐条路由变化
[图 4] 紧急丢件、外部投诉命中的规则及优先级
五、第三组：客服这句话，说出去会不会惹麻烦
这一组有四个剧本：⑤保证三天到、⑥私自承诺赔偿、⑦泄露隐私、⑧顶撞用户。
"我保证三天内一定送到，百分百没问题。"听着很积极，但物流时效并不完全由客服控制。这个场景检查绝对化承诺和时效口径，提示客服修改表达。
"我直接给您全额退款，再赔两百块。"涉及未经审批的赔付承诺，项目把它配置为阻断级别。
隐私剧本中，客服把其他人的姓名、完整手机号和地址告诉了用户。这类信息一旦发出就难以收回，因此同样按阻断处理，看板也做了脱敏展示。
顶撞用户的例子是："是您自己不看规则，这也要怪我们？"系统既检查情绪失控风险，也会独立评价这句回复的服务质量。
代码里怎么配置
agent_risk 是一个 choice 问题，在九类危险话术和"无风险"之间选择。识别结果交给 routing.json 中的拦截配置。下面是节选：
{
"minProb": 0.5,
"blockLevels": {
"绝对化承诺": "warn",
"越权赔付": "block",
"泄露隐私": "block",
"情绪失控": "block"
}
}
选中风险类别且相应概率达到阈值后，程序执行对应处置：warn 提示改写，block 标记阻断。
改写建议也有配置。例如越权赔付对应的建议是：
不要直接报赔付金额。改成"您的情况我已记录，会按售后政策为您申请，审核结果 X 小时内回复您"。
其中的时间要按实际业务填写。当前项目的改写建议来自预设模板，Jev 负责识别风险类别。
这里还有个实际边界：一条话术可能同时涉及几种风险，当前 choice 配置只返回一个选中的类别。以后如果需要同时标出"绝对化承诺"和"时效硬承诺"，可以拆成多个独立判断题。
[图 5] 绝对化承诺的风险提示与改写建议
[图 6] 越权赔付或隐私泄露的阻断展示
六、第四组：异常索赔要核查，好服务也要看得见
⑨疑似异常索赔的台词是："这个月第四单了，还是老规矩仅退款不用退货吧。"
这个场景要识别可能需要核查的信号，进入风控队列，避免客服当场继续承诺赔付。文本线索只能触发核查，是否真的存在异常，还需要结合订单、历史售后等数据。
代码中用 user_risk 识别"疑似薅羊毛"，再由 R3 路由到风控核查。这条规则排在"高情绪加高紧急度"前面，防止催得越急反而越容易跳过核查。
⑩优秀服务范本则反过来，看看好的回复能不能得到相应评价。
用户收到破损的杯子，客服先表达歉意，再给补发方案，说明后续通知方式，并留下没有收到通知时的跟进办法。
代码里怎么配置
我把服务评价拆成三个问题：
| 配置项 | 题型 | 具体看什么 |
|---|---|---|
agent_quality |
score |
回复整体质量，从很差到优秀 |
empathy |
noul |
有没有理解或安抚用户，纯流程话术不算 |
actionable |
noul |
有没有给出具体动作或明确处理方案 |
这样就能分清：有的回复很客气，却没说下一步做什么；有的回复方案明确，但态度生硬。
"优秀服务"剧本用来观察这几项如何评分，不预设真实模型每次都给满分。方案是否符合补发权限和售后政策，正式使用时也需要提供相应依据。
[图 7] 异常索赔进入风控核查队列
[图 8] 优秀服务的质量、共情和可执行方案判定
七、聊完以后，再看整通对话
单句回复不错，不一定代表问题已经解决。所以我还加了一组会话分析，当前通过按钮手动触发。
它看四件事：用户可能有多满意、核心诉求是否一次解决、有没有流失倾向，以及这通对话该归档到哪个标签。
这些配置在 policies.json 的 session 组里。比如判断问题是否解决：
{
"id": "resolved",
"type": "noul",
"instructions": "用户的核心诉求在这通对话里被真正解决了吗？给了方案但没落地不算解决。"
}
最后这句很关键。客服说"已经帮您申请"，和用户的钱已经到账，中间还有一段距离。模型只能依据提供的记录判断；满意度预测也不能当成用户实际提交的评价。
[图 9] 整段会话分析结果
八、换成自己的业务，主要改三个文件
前面的场景看起来不少，主要配置集中在三个地方：
| 文件 | 用途 |
|---|---|
shared/policies.json |
定义问题、选项、评分标准 |
shared/routing.json |
定义路由条件、队列、优先级和拦截策略 |
shared/scripts.json |
定义演示对话 |
从接口角度看，一次 Jev 请求的核心就是 state 和 questions。下面是一个简化的请求体：
{
"model": "jev-latest",
"state": "用户：退款三天了还没到账，我已经问了好几次，现在请转人工处理。",
"questions": {
"escalate": {
"type": "noul",
"instructions": "用户是否明确要求转人工？"
}
}
}
state 放需要判断的内容，questions 放题目。实际项目会拼入最近的对话消息，明确指出当前要判断哪一句，再按用户、客服或会话选择问题组。模型名称按使用渠道配置。
这类场景里，提示词最需要花心思的地方，是把业务口径写清楚。"用户情绪怎么样"太笼统，哪些表现算明显不满，哪些算愤怒，需要先有一致的标准。
九、没有 Jev 账号，也能先跑起来
下载项目后，进入目录执行：
npm install
npm run dev
浏览器打开 http://127.0.0.1:5173 即可体验。
不配置 API Key，程序会使用内置 Mock 规则引擎。 12 个剧本都可以回放，适合先看界面和流程。Mock 主要依赖关键词规则，它的表现不能当成 Jev 的真实效果。
要接入 Jev，可以在 OpenRouter 注册账号、充值并创建 API Key。支付宝和微信支付可通过一次性支付入口使用；如果充值页只显示银行卡，可以查看 Use one time payment methods，具体以结账页面为准。[3]
在项目根目录创建 .env，填入自己的配置：
OPENROUTER_API_KEY=你的OpenRouter密钥
JEV_ENDPOINT=https://openrouter.ai/api/alpha/decisions
JEV_MODEL=~typesafe/jev-latest
这里使用的是 Jev 的 Decisions API。配置后重启服务，查看右上角引擎标识，确认已经从 Mock 切换到 Jev。[4]
目前这个项目是演示沙盘，展示判断、路由和拦截流程。真正接到客服工作台时，要把风险检查接在消息发送之前，再用标注过的业务对话验证误拦、漏拦和响应耗时。
十、这次尝试留下了什么
客服质检真正难的地方，是它由一堆小判断组成：意图、情绪、风险、可执行性……每一项都要先有清晰口径，才谈得上稳定自动化。
把每个小判断用明确的标准定义好，用 Jev 这种结构化判断模型做快，再接上明确的路由规则，就能搭出一个"处理过程看得见、策略随时能调"的系统。真正落地时，风险检查必须接在发送之前，并用标注过的真实对话去验证误拦、漏拦和耗时。
十一、关于 Laya：开源的另一个选择，现在该怎么看
写完这个 Demo，被问得最多的问题是：Laya 怎么样？ 它开源、能本地部署，社区里流传着"比 Jev 快 20 倍"的说法——这个数字多来自批处理或端到端往返对比，单问题延迟实际约 7~8 倍。[5]
这个模型一出来我就关注了，也让公司的算法工程师在内部环境部署起来，用我们自己的业务数据集跑了一轮实测。之后又对照官方模型卡、公开 benchmark 和社区里的专项微调项目做了交叉验证，两边得出的结论是一致的：
Laya 适合当"可私有化、可专项训练的轻量决策底座"，但现在还不能直接当 Jev 的中文开源平替。
官方自己就把边界写清楚了。 目前重点推的 laya-typed-decisions，是围绕四个工作流专门微调的：发票处理、安全事件、客服、Agent 轨迹分析。模型卡里有两句很关键的话：
Laya is a fast base to specialise, not a zero-shot decision engine.
（Laya 是一个适合做专项特化的快速底座，不是一个开箱即用的零样本决策引擎。）...it is specialised to four synthetic workflows and should not be a silent default.
（它专门面向四个合成工作流，不应被当作静默默认选项。）
同一份 benchmark（400 个测试 case、2000 次判断）上，微调后的 checkpoint 是 0.766，而未微调的基础模型只有 0.362，低于"永远选多数类"的 0.461 基线。换句话说，权重拿下来直接用，还不如一条 if-else。[5]
中文是目前最明显的短板。 multilingual checkpoint 支持 100 多种语言，但"能输入中文"不等于"中文业务判断靠谱"。模型卡显示非英语场景表现明显偏低，更麻烦的是存在"低准确率 + 高置信度"的情况——某些语言上准确率接近 0，模型照样给出 0.9 以上的置信度。所以不能直接拿置信度做自动放行。
社区里几组小规模中文测试（飞书消息分类、中文 Agent Skill 路由、企业文档分类）方向也一致：Laya 与 Jev 在中文业务判断上还有明显差距，部分错误答案同样带着高置信度。样本量都不大，不足以当权威结论，但足以说明：
多语言 tokenizer ≠ 中文业务决策能力。
还有个架构上的注意点：choice 不是选项越多越好。 官方 Banking77（77 类意图）上 Laya 是 0.425，Jev 是 0.870；官方建议一个 choice 控制在 20 个选项以内。[5] 所以它更适合"是否投诉""情绪几级""风险几级"这类判断，不适合从几十上百个工具或 Skill 里挑一个。
但训练之后，它确实有价值。 最有说服力的是一个 Browser Agent 案例：零样本下真实任务成功率是 0%，做了约 3.1 万条专项训练数据之后，升到了 50~62%。这条路子大致是这样：
基础模型
↓ 定义明确的 Decision Schema
↓ 构造业务专项数据（万级 Decision Samples）
↓ Fine-tune
↓ 温度校准
↓ 独立测试集 + 置信度阈值
↓ 生产
真正的门槛不在推理部署，而在数据。 开源权重拿下来、本地跑起来，这步很容易。重的是后面那堆：高质量中文训练数据、场景覆盖、标注体系、置信度校准、大规模专项训练、能验证的中文业务 benchmark。
这些恰恰是国内大厂最有优势的地方。我们不是做基础模型的公司，没必要替社区补这段基础设施，也没必要现在就为 Laya 专门堆几万条中文训练集。
更现实的策略是：现在研究范式，不重投入模型本身。
把 noul / choice / score 这套 Decision Model 的思路、接口抽象和评测体系先做好。以后无论出来的是阿里、字节、腾讯、智谱、MiniMax 还是别的国产开源决策模型，直接换 Provider 就行。我们已经把接口预留成这样：
DecisionProvider
├── Jev
├── Laya
├── Qwen Classifier
├── Local Fine-tuned Model
└── Future Chinese Decision Model
现阶段的用法：用 Jev 验证产品形态，Laya 做技术储备和本地化演练。 我比较看好后面国内会出现真正中文优化好的 500M~2B 级 System-1 / Decision Model——它很适合 Agent 路由、客服质检、风控分类、内容审核、意图识别、工具选择、RAG 判断，都是国内企业 AI 落地里最实际的需求。
在那之前，等模型生态成熟，比自己替它补中文能力划算得多。
代码在这里：
https://github.com/kiler398/jev-demo
下载跑一跑，换几句自己的业务话术试试。如果觉得有用，欢迎给项目点个 Star。
参考资料：
浙公网安备 33010602011771号