一步步设计
先把用户原话与已核实事实分开
虚构工单：“耳机左侧没声音，买了十天，想换货。”state 同时放用户原话、已验证购买时间和检测状态。购买时间来自订单系统；故障描述只是用户报告。不要让一句“买了十天”直接成为已核实的换货资格。
列出三个原子问题
用 Choice 判断主诉是设备故障、配送、账单还是其他；用 Noul 判断用户是否明确提出换货；用 Score 按清晰档位判断排查信息是否充分。主诉、意愿和信息充分度是三个不同问题，不要把“故障并且符合换货并且很急”塞进一个 Noul。
只合并共享现有 state 的问题
官方支持在一次请求里放多个问题。上面三个都能读取同一份工单，所以可以同时问。是否通过声道测试，只有测试系统返回之后才有事实依据；这个判断应在新 state 到来后进行。并行不是把流程里的因果依赖消掉。
把使用条件写进代码
主诉为设备故障且 Choice 达到经过验证的阈值，才进入排查队列；明确换货意愿只标注给处理人员，不触发换货。主诉为配送时忽略故障排查分数。每个问题名固定，代码读取对应字段，缺字段或调用失败进入复核。
记录整条链路再比较方案
用相同工单和问题版本，比较一批请求与逐个请求的 p50/p95 延迟、总费用、错误和回退率。加问题通常能减少往返，但实际收益取决于输入、限额和服务状态。保留模型版本、原始结果与动作日志，不把官方演示数字写成自己的收益。
完整走查 · 本站虚构样本
| 观察到什么 | 如何判断 | 代码怎么处理 |
|---|---|---|
| 故障主诉；换货意愿明确；尚未测试 | 换货意愿不等于可换货 | 进入诊断，保留换货标注 |
| 实际是配送延误；仍有故障分数 | 故障分数在该分支无关 | 只进入配送队列 |
| 主诉不确定；订单状态缺失 | 不能靠多问几个问题补齐事实 | 查询订单或交给人工 |
可复制的设计草案
以下为本站原创示例。JSON 展示请求或输入形状；Python 仅计算虚构分数，不调用 API。真实接入仍需核对官方接口及任务策略。
{
"model": "jev-latest",
"state": {
"user_report": "Left earbud is silent; I want a replacement.",
"order_verified": true,
"diagnostic_status": "not_tested"
},
"questions": {
"issue": {
"type": "choice",
"instructions": "What is the main issue in the user report?",
"criteria": {
"device": "Device behavior or malfunction",
"shipping": "Delivery, tracking, or missing parcel",
"billing": "Payment or charges",
"other": "None of the above"
}
},
"replacement_requested": {
"type": "noul",
"instructions": "Does the user explicitly request a replacement?"
}
}
}容易踩的坑
- 把问题的答案串成依赖：先预测类别再让另一个问题把预测当事实。应共享原始 state，后由代码组合。
- 收到每个字段就使用每个字段。应先判定分支，再读取该分支需要的答案。
- 把一次请求理解成一次业务动作。请求得到判断；动作还要经过权限、条件和失败处理。
TRY / THINK / COMPARE
先想一想，再看解析
用户说“可能是没电，也可能坏了”。能否在同一次请求中判断“充电后是否恢复正常”？
展开解析
不能。可以同时判断主诉和信息是否充分，但充电后的结果尚不存在。先执行或询问充电测试，再用更新后的 state 继续；不能用语义预测替代观察。
交付前检查
- 每个问题只判断一个概念，输入事实能追溯。
- 每个答案都有使用条件和忽略条件。
- 调用失败、缺字段、低 confidence 有明确去处。
- 费用与延迟比较使用同一数据和版本。
常见问题
并行提问一定更快吗？
不一定。它可以减少串行往返；本例没有实测，仍需在你的任务和限额下测量。
多个问题会自动互相校验吗？
不会。答案之间的约束与冲突处理应由你明确设计。
资料与延伸阅读
参考官方架构模式与 Datawhale 实战主题，本站独立编写讲解、案例与练习。示例为教学设计，未调用 API，不代表性能测试。