这次维修保内还是自费
实用保修还剩 49 天 —— 但故障原因决定了它算不算保内
客服工单进来的第一跳。答错的代价是要么白送一次维修，要么惹一次投诉。
为什么要快 客服在跟用户通话中等这个答案。三秒钟的静默，用户就会开始重复问题。
接线长什么样
判断层和计算层之间没有依赖，所以它们并行发 —— 串起来等于白花一个来回。
状态一直在你这边，模型不持有任何东西
合法动作由你的代码生成，模型只在里面挑
3 个问题一次前向答完，不是问 3 次
回来的是选项 + 把握程度，不用再解析文字
需要的那个数随判断一起回来
精确值，带单位，可以逐位核对
执行动作，世界更新
然后进入下一个 tick
当时的情况
一段话，和你真的会拿到的一样
用户 2024 年 11 月 18 日购机，整机保修 730 天，到今天已使用 681 天。本次故障是屏幕不显示，用户说没有摔过，外观检查无磕碰、无进液痕迹。若判为自费，需要更换屏幕总成：工时 2.5 小时、工时费率 180 元/小时、配件 680 元、上门费 80 元。同型号整机现价 2999 元。
要判断的事
一次问完，回来的是选项和把握程度，不是一段还要再解析的文字
保修还剩几天
- 整机保修期730 day
- 已使用681 day
展开这一步
#0 = 730 day （整机保修期） #1 = 681 day （已使用） left = SUB(#0, #1) result = @left
「快到期了」不能作为定性依据 —— 差一天就是免费和收费两种结果，而这个差值要能拿去跟工单系统里的日期字段对得上。
如果自费，一共多少钱
- 工时2.5 h
- 工时费率180 CNY/h
- 屏幕总成680 CNY
- 上门费80 CNY
展开这一步
#0 = 2.5 h （工时） #1 = 180 CNY/h （工时费率） #2 = 680 CNY （屏幕总成） #3 = 80 CNY （上门费） labor = MUL(#0, #1) s1 = ADD(@labor, #2) tot = ADD(@s1, #3) result = @tot
这个数要报给用户，报错了就是纠纷。而且它得跟整机现价比一比 —— 修比换还贵的时候，话术是完全不同的。
状态一直在你这边，模型不持有任何东西
合法动作由你的代码生成，模型只在里面挑
3 个问题一次前向答完，不是问 3 次
回来的是选项 + 把握程度，不用再解析文字
需要的那个数随判断一起回来
精确值，带单位，可以逐位核对
执行动作，世界更新
然后进入下一个 tick
接进你的系统
下面就是这一页真正发出去的东西。把 state 换成你的场景、criteria 换成你的动作集， 它就是你的了。
POST /v1/systemone
{
"model": "memorylake-c1",
"state": "用户 2024 年 11 月 18 日购机，整机保修 730 天，到今天已使用 681 天。本次故障是屏幕不显示，用户说没有摔过，外观检查无磕碰、无进液痕迹。若判为自费，需要更换屏幕总成：工时 …",
"questions": {
"verdict": {
"type": "choice",
"instructions": "这次维修怎么定性？",
"criteria": {
"in_warranty": "保内免费维修",
"out_warranty": "保外自费维修",
"need_inspect": "需要送检后再定",
"goodwill": "已过保但给予善意维修",
"other": "以上都不合适"
}
},
"auto_close": {
"type": "noul",
"instructions": "这一单可以自动处理、不转人工吗？"
},
"escalate": {
"type": "score",
"instructions": "这一单升级成投诉的可能性有多大？",
"criteria": [
"低",
"需要留意",
"高"
]
}
}
}回来的是 {answers: {key: {value, probs}}} ——不用再写一个解析器去猜模型想说什么， 也不用为「它这次多说了一句」写兜底。
"保修还剩几天": {
"type": "number",
"unit": "day"
}
→ { "value": ..., "unit": ..., "exact": true }数值问题和其它问题写在同一个 questions 里， 一次请求一起答完。返回的 exact: true 表示 这个值可以直接拿去跟阈值比大小。