请求从业务决策开始，不从 prompt 开始
先写清软件下一步需要什么：分队列、打等级，还是判断是否进入复核。然后再整理 state、question type 和 criteria。这样做能避免把业务规则埋在一大段自然语言里。
API key、模型 ID 和重试留在服务端
不同 provider 的 endpoint、鉴权、模型名和 usage 字段可能不同。把它们封装在自己的 API route，前端只依赖统一结果，后续切 provider 或增加限流时不会牵动整个页面。
把网络失败和低置信度分开处理
超时、401、返回结构错误属于调用失败；confidence 太低或答案不符合业务条件属于决策失败。两者日志、重试和告警策略不同，不能都简化成一个空值。
从第一天记录可复现信息
至少保存任务版本、provider、model、latency、confidence、最终答案和是否触发 fallback。后面调 criteria 或升级模型时，这些记录就是最有价值的回归样本。
服务端 / TypeScript
const decision = await jev.evaluate({
state: ticket,
questions: {
routing: {
type: "choice",
instructions: "把工单分到正确队列",
criteria: { shipping: "物流问题", other: "其他问题" }
}
}
})