用户意图分类：理解客户希望采取的下一步
识别客户消息中的购买、求助、取消或了解更多意图。结合对话上下文复核取消相关表述。
匿名体验受免费额度限制。登录后使用账户积分并保留决策历史。
你的下一次决策，从这里开始。
在上方添加背景信息，或使用示例开始体验。
提到某个动作，不代表正在请求执行
询问取消条款的人可能仍在考虑购买，比较价格的人可能只需要信息而不是销售跟进。意图识别的价值在于保留这些区别。以最新消息为中心，补充足够的会话上下文，理解客户此刻的请求。结果只是下一次回复的参考，不代表用户同意取消订阅、接收优惠或由系统代为购买。
从具体案例理解边界
以下为场景示例和人工判断要点，并非模型实跑结果。输入你的实际上下文，查看本次决策。
购买前了解取消规则
订阅之前，能告诉我取消是怎么操作的吗？
客户在购买前询问政策。提及取消并不构成当前终止订阅的请求。按明确意图的口径，应考虑了解更多这一类，并保留购买前的语境，不应仅根据“取消”这个词分流。
在比较，还没有做决定
我找到了更便宜的服务。能解释一下换过去会少哪些功能吗？
这是比较请求，可能反映犹豫，却不一定是取消指令。先回答具体问题。下游挽留流程应有自己的资格与同意规则，不能依据一个标签自动发放折扣。
历史改变了最后一句话的意思
之前：“请在续费时终止我的订阅。”最新消息：“对，我就是这个意思。”
只看最后一句并不能知道具体动作，相关历史才能解释“这个意思”。保留说话人和最近的修正；如果客户已经改变主意，长记录中的旧取消请求反而可能误导判断。
先约定分类口径
以下是这些选项的建议复核口径。运行时，请在问题或上下文中写明适用于你团队的规则。
| 选项 | 适用情形 | 需要区分的边界 |
|---|---|---|
| 购买 | 客户表达购买、订阅或扩容的愿望。 | 一般性的价格比较仍可能属于信息收集。 |
| 寻求帮助 | 希望解决现有产品或账户问题。 | 抱怨故障不自动等于准备离开。 |
| 取消 | 表达当前终止服务的意图。 | 政策咨询、引用他人的话和假设情景应分别判断。 |
| 了解更多 | 请求信息，但未明确要求交易或处理现有问题。 | 检查相关会话中是否已表达具体承诺。 |
这些情况值得多看一步
否定与改变主意
“我不想取消了”和“我觉得不想继续了”需要不同回复。把这类案例纳入人工评估集，保留最新陈述，不将所有带取消关键词的消息视为同一种意图。
旧意图覆盖当前请求
摘要要保留时间顺序和说话人。客服建议的选项不是客户作出的选择。新信息出现后重新判断，不要用一个标签描述整段客户关系。
将回复分流与不可逆操作分开
分别检查误判取消和漏掉取消请求的情况。代价取决于后续动作：准备回复、发送未请求的优惠和改变账单状态不是一回事。应评估你实际准备自动化的那一步。
用人工审阅的会话选择适合流程的阈值。无论置信度多高，账户变更仍需明确确认和既有取消流程。意图不明时，应提出针对性问题，而不是直接假定客户想购买或取消。
从一个 Jev API 示例开始接入
通过 cURL 调用 iajev REST API，以 JSON 获取选项、概率与置信度。
curl https://iajev.com/api/v1/decisions/run \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Idempotency-Key: YOUR_UNIQUE_REQUEST_ID' \
-H 'Content-Type: application/json' \
--data '{
"state": {
"message": "怎样才能在 3 号自动续费之前取消套餐？",
"plan": "starter"
},
"decision": {
"type": "choice",
"question": "这个人想做什么？",
"choices": [
"购买",
"寻求帮助",
"取消",
"了解更多"
]
}
}'关于这个工具
传最后一条消息，还是整段会话？
传入足以解释指代和意图变化的最小相关上下文，包括最新消息、正在讨论的动作及最近的修正。无关历史会增加干扰，也可能暴露不必要的信息。
意图分类能替代关键词规则吗？
可以互相补充。明确的取消按钮和账户动作仍应走确定性的控制流程。自然语言中的模糊请求可交给分类器，但修改线上分流前应对照现有规则评估错误。
使用 iajev
提供上下文
保留本次判断所需的事实。
确认选项
按业务流程调整问题与候选项。
运行并复核
查看结果分布，再决定下一步。
置信度就是判断正确的概率吗？
不是。置信度是模型单独给出的估计，选项概率则描述各候选项的分布。两者都不等于经过测量的准确率保证。
可以比较两种输入吗？
修改上下文后，用同一个问题再次运行即可比较概率变化。修改问题或选项会开始新的比较。