---
title: LiteTMS 中的 Jev AI：我们将其应用在何处
description: 了解 TypeSafe 的 Jev AI 模型如何助力 LiteTMS 评估司机消息、地点匹配与数据导入，配有 JSON 和 Java 示例解析底层工作原理。
slug: where-jev-helps-in-litetms
locale: zh
date: 2026-09-24
updated: 2026-09-25
category: technology
tags: jev, ai, transport, driver-chat, data-import
author: LiteTMS Team
draft: false
---

我们将来自 [TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=litetms.eu) 的 AI 模型 Jev 集成到了 LiteTMS 的多项业务流程中。它能协助识别需要优先处理的司机留言、判断两个地名是否指同一座城市、为导入文件的字段匹配提供建议，还能避免对受众原本就能看懂的语言进行不必要的翻译。这些都是嵌入在运输管理系统（TMS）内部的微型决策评估，而不是在办公室里又多加一个聊天机器人助手。

如果您对这个名称还感到陌生，[我们的首篇 Jev 文章](/en/blog/jev-ai-decisions-transport)已详细阐释了其设计理念。生成式 AI 通常负责根据提示词撰写回复，而 Jev 的定位是回答更具针对性的具体问题，例如“这条消息需要回复吗？”。随后，LiteTMS 会将该评估结果无缝应用于相关的业务工作流中。

## 值得重点关注的司机消息

司机会发送常规状态更新、进行咨询或上报突发问题。调度室显然不需要以同等紧急程度对待每一条信息。在司机聊天功能中，我们引入了 Jev 评估机制，能根据主题对收到的消息分类，并判断调度员是否需要立即采取行动。该机制不仅适用于文本消息，语音留言在转录为文本后也同样支持。

举例来说，“车辆爆胎了”与“我已到达”的重要性完全不同。被判定为需要处理的消息会直接进入待办视图；车辆故障类问题还可以触发紧急通知。调度员仍然可以阅读完整对话、进行回复并将事件标记为已处理。Jev 不会直接替您向司机发消息，也不会代为决定故障的具体维修方案。

针对车辆爆胎的信息，AI 评估结果的 JSON 数据示例如下：

```json
{
  "input": { "driver_message": "I have a flat tyre and cannot continue." },
  "jev_assessment": {
    "category": "vehicle_problem",
    "needs_action_probability": 0.94
  }
}
```

LiteTMS 会读取事件类别与行动紧迫度分值。对于置信度如此之高的车辆故障，系统会直接将其标为紧急事件，以便调度员第一时间响应处理。

## 订单与运输单证中的地名核验

单证上可能写着“Köln”，而订单中注明的却是“Cologne”。字面上的文本比对会判定为两个不同的词，尽管它们指的是同一座城市。在 AI 辅助录单流程以及 CMR 运单的地名核验环节中，我们已专门引入了 Jev 来处理这类特定比对。

在录入订单时，它可以帮助系统在候选地点中做出准确选择，或者将存疑的匹配项留给人工作业复核。在核验 CMR 运单时，如果系统高度确认为同一城市，即可自动消除本会被标记的*地名不一致*预警。单证的识别由专门的 AI 步骤完成，而 Jev 则负责精准判定两处地名是否完全一致。

针对上述两个城市名称，其判定结果示例如下：

```json
{
  "input": { "document_place": "Köln", "order_city": "Cologne" },
  "jev_assessment": { "same_city_probability": 0.92 }
}
```

极高的同城置信度分值可直接消除地名不匹配的预警。CMR 单证核验的其他检查项则各自独立运行。

## 表头不规则的数据文件导入

向新系统迁移数据通常始于电子表格。一份文件里写着“registration number”（注册登记号），另一份写着“plate”（车牌号），还有一份文件的表头甚至很难一眼辨认。LiteTMS 首先会应用常规匹配规则。若常规规则无法完全匹配，Jev 能够推断文件中包含的数据记录类型，并建议各列分别对应哪个系统字段。

这些字段映射建议均带有“AI 辅助”标记，负责导入文件的人员可以在最终生成数据前逐一核对。我们已将该功能接入通用导入向导，以及 CRM 交易与货物信息的批量导入环节。与之类似的核验逻辑还能识别出即使拼写略有差异但也已存在于承运商/往来单位名录中的企业，只要置信度足够高，就能有效避免生成重复档案。

假设在导入的车队表格中，用“Unit ref.”表示车牌号，而“Internal ID”表示企业自有的车辆内部编号。具体的样本数值有助于 Jev 准确区分二者。在常规表头规则无法识别车牌字段时，判定结果示例如下：

```json
{
  "input": {
    "columns": {
      "col_0": { "header": "Unit ref.", "examples": ["WX 4821A", "PO 7619K"] },
      "col_1": { "header": "Internal ID", "examples": ["FLEET-17", "FLEET-42"] }
    },
    "field_to_match": "registration_number"
  },
  "jev_assessment": { "column": "col_0", "probability": 0.93 }
}
```

随后，LiteTMS 会建议将第一列映射为车牌号字段。调度室人员可在正式导入数据前确认该映射关系。如果没有相符合的列，Jev 会选择“none”（无），将字段留给人工自行选择，绝不强行盲目匹配。

## 聊天翻译前的微型判断机制

有时，司机发来的消息所使用的语言正是阅读者的语言。在运行完整的聊天翻译之前，LiteTMS 可以让 Jev 先对此进行核验。如果匹配结果可信度高，系统会直接显示原文；如果无法确定，则走常规翻译流程。这样能确保决策严谨：只要系统无法十分确信地跳过翻译，读者就依然能看到翻译内容。

比如司机写了“Jestem na miejscu, czekam na załadunek”（意为“我已到达，等待装货”）。对于使用波兰语的操作员，系统核验后可能会得出如下评估：

```json
{
  "input": {
    "message": "Jestem na miejscu, czekam na załadunek.",
    "reader_language": "pl"
  },
  "jev_assessment": { "language": "pl", "probability": 0.96 }
}
```

检测到的语言与阅读者的界面语言一致，因此 LiteTMS 可以直接显示原文。对于使用英语的操作员，这条波兰语消息仍需要翻译。而像“OK”这样简短的回复信息量较少：当无法确定其语言时，系统依然会走常规翻译流程。

## Jev 评估如何在 LiteTMS 中发挥作用

Jev 为 LiteTMS 提供了实用的判断信号，而办公室调度人员始终掌握工作的主导权。这些集成均为系统内置，当平台决策层启用且符合企业设置时便会运行。如果 Jev 不可用，常规的聊天、单证和导入流程仍可照常运转。

## 技术视角：TypeSafe Jev、JSON 与 Java

对于想了解底层运作机制的读者，最合适的切入点是我们发送的查询请求。正如 [TypeSafe 快速入门指南](https://docs.typesafe.ai/introduction/quickstart?utm_source=litetms.eu) 所示，一个请求包含待评估的信息 `state` 以及需要做出的评估项 `questions`。`noul` 类型的提问会返回一个介于 0 到 1 之间的数值，代表某项陈述成立的概率。`choice` 类型的提问则用于在指定选项中进行选择，我们正是用它来判断消息的类别。

以下是单项操作提问的示例，其中使用了我们在 OpenRouter 集成中配置的模型标识符：

```json
{
  "model": "typesafe/jev-1.13",
  "state": {
    "driver_message": "I have a flat tyre and cannot continue."
  },
  "questions": {
    "needs_action": {
      "type": "noul",
      "instructions": "The dispatcher must act on driver_message today: reply, give instructions, inform the customer or arrange help. Routine updates and thanks need no action."
    }
  }
}
```

返回结果的相关部分如下所示：

```json
{
  "answers": {
    "needs_action": {
      "type": "noul",
      "noul": 0.94
    }
  }
}
```

应用程序读取 `answers.needs_action.noul` 并应用规则。LiteTMS 对司机消息关注度设定的触发阈值为 `0.55`。在解析 JSON 之后，该核验逻辑在 Java 中可以这样实现：

```java
Double probability = 0.94; // Value from answers.needs_action.noul
boolean needsAttention = probability != null
    && Double.isFinite(probability)
    && probability >= 0.55
    && probability <= 1.0;

if (needsAttention) {
    System.out.println("Flag the message for dispatcher review");
}
```

代码在与阈值比对前，会先验证该数值是否有效。在 LiteTMS 中，类别评估构成了规则的另一部分：需要关注的车辆故障问题同时会触发紧急警报。模型负责评估消息，应用程序负责定义响应动作。如果未返回结果，则继续执行常规聊天流程。

阈值的高低取决于后续操作的性质。对于导入字段列建议，当概率达到至少 `0.60` 时 LiteTMS 便会采纳推荐列；而跳过翻译则要求识别为读者语言的概率至少达到 `0.90`。因此，`0.85` 的评分足以支撑由人工复核的字段列建议，但还不足以直接跳过聊天翻译。每项规则的设定都与其决策带来的实际影响相权衡。

## 常见问题解答

### Jev AI 是由谁开发的？

TypeSafe AI 将 Jev 开发为用于结构化决策的 System One（快思考）模型。LiteTMS 将其集成到司机消息评估和地名匹配等特定工作流程中。

### Jev AI 在 LiteTMS 中有哪些用途？

Jev 应用于司机消息分流、订单录入与 CMR 运单地点核对时的同城判定、数据导入建议，以及聊天翻译前的同语言检测。具体功能是否在工作区中启用，取决于平台和企业的配置设置。

### Jev 会自动回复司机或审批 CMR 运单单证吗？

不会。它只能标记需要关注的司机消息，或评估两个地名是否属于同一个城市。消息始终由人工处理，同城判定结果也不会自动使整份 CMR 运单单证生效。

### 如果 Jev 无法确定结果或服务不可用，会发生什么？

LiteTMS 会保留现有工作流程。例如，语言判定不确定时会走常规聊天翻译通道，导入建议不确定时则将字段映射留由人工复核。