JEV / LESSON 02 · 9 分钟
Jev 的 state 怎么写？从原始消息到可判断的事实
学会限定事实、补足上下文、删除敏感信息，并用四类反例检查输入。
先确定决定，再决定给模型看什么
假设任务是把客服消息分给物流、账单、技术或人工。state 应包含本次消息和已经核实的订单状态，而不是整个客服历史。先写清业务代码最终会使用哪个结果，再倒推所需事实。
把事实、用户说法和缺失信息分开
“客户称包裹未收到”是用户说法；“承运商显示已签收”是系统事实；“签收人未知”是缺失信息。把来源写明，避免模型把投诉当作已证实的物流事件。时间、地区和产品版本只有影响判断时才加入。
一个对照样本
差的 state：‘用户很着急，帮我处理。’它没有可路由的事实。较好的 state：‘message: 包裹显示送达但未收到；carrier_status: delivered；delivered_at: 2026-09-22；signature: unknown；payment_issue: none。’这些字段仍需由应用核实和脱敏。
进入 API 之前做确定性检查
代码先验证必填字段、权限、枚举和输入长度；能靠订单状态或规则直接判定的情况就用代码。移除姓名、地址、银行卡号等无关敏感信息。模型只处理剩下的语义判断。
四组必须保留的测试输入
①只有‘救命’却没有订单信息；②一句话同时提到退款和物流；③‘我并不着急’这类否定；④中文、英文或日文混写。每组至少标出预期队列与可接受的人工回退，再用实际模型结果核验。
练习：改写自己的 state
找一条脱敏样本，列出决策需要的最少字段、每个字段的来源、缺失时的处理方式。然后删除一个字段：如果路由结果不该变，它可能不必传给模型；如果会变，则把它列为必需信息。
动手练习
动手练习
承运商记录缺失时，state 应怎么写？
缺失就是缺失。来源不同的陈述必须分开；必要事实查不到时走补充信息或人工路径。
这是知识练习，不调用 Jev；示例答案只是教学说明。先看原始任务：客服真正需要什么？
从客户原话、核实订单、设计三道问题，到阅读示意结果、处理边界案例和上线评估，完整走一遍 Jev 工作流。
完整实战：一条“显示送达却没收到”的工单，如何设计 Jev 决策流程学习进度仅保存在当前浏览器