一个下午从 Playground 到生产

第 0 步 — 选对决策

好的第一批候选，是你现在已经做得很糟或纯靠人工的决策：一段手工维护的路由正则、一条要人一遍遍重读的同一政策、一个没人盯着却一直挂着的“请人工复核”标记。糟糕的候选是那些出错代价昂贵且不可测量的决策 — 先让它们保持“脚本转人工”，把类型化决策当作第一道过滤器。

把 state 写成你已有的数据：工单原文、表单载荷、即将执行的工具调用。不要预先摘要 — 让模型自己读。

第 1 小时 — 在 Playground 跑十个真实例子

Playground 跑的是真实模型，在浏览器里免费。从你的积压里贴真实例子 — 真工单，不是假想例 — 直到十个例子都得出一位细心同事会做出的判断。

• 答案不稳定？用具体 true/false 表述收紧 criteria。
• 模糊的案例却给出高置信答案？你的 criteria 太粗 — 给量表再加一级。
• 缺少上下文？把缺失的事实补进 state，别指望模型自己知道。

第 2 小时 — 把 JSON 复制进带 key 的调用

你在 playground 看到的 JSON 就是服务器应该发送的 JSON。生产环境只差三件事：Authorization 头、端点路径（/api/v1/systemone 而不是 playground 的浏览器端点），以及配额（免费计划 20 请求/分钟，Starter 从 120/min 起步）。升级计划同时提高并发和每分钟请求数 — Starter 3 并发，Pro 10 并发。

async function decide(state, questions) {
  const resp = await fetch("https://jevai.website/api/v1/systemone", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.JEV_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ state, questions }),
  });
  if (resp.status === 429 || resp.status === 502 || resp.status === 529) {
    // exponential backoff here — never retry 401/402/422
  }
  return resp.json();
}

第 3 小时 — 设阈值、打标记、上线

在把数字接进系统之前先定义它的含义：confidence 低于 0.8 时送人工，而不是自动决策。先放在功能开关后面，比如第一天把 5% 的生产流量发给类型化决策，并记录 request_id 连同你的旧决策，方便日后 diff。

• 记录 request_id、score 或 noul 值，以及你的策略采取的动作。
• 设置能容忍偶发冷启动的超时（闲置后的第一次调用可能要约 3 s；其余集中在 400–600 ms）。
• 对 402（积分不足）设置告警 — 这是重试循环唯一救不回来的失败。

第一天常见的失败与修法

• 相似案例的答案不一致 — criteria 描述含糊或互相矛盾。把它们改写成政策条文。
• 突发流量时出现 429 — 免费档只允许 20 req/min。转到 Starter（120/min、3 并发），或在客户端排队削峰。
• 所有请求都路由到第一个选项 — 各 criteria 文本偏向同一边。让它们保持平衡。
• 以为按问题计费，却只被扣 1 积分 — 计费按输入 token、每请求最低 1 积分，所以在一个请求里横向合并问题比分拆便宜。算术细节见积分那篇。

阈值来自数据，而不是直觉

开关以 5% 跑满一天后，分布就在你手里了。把低置信区间（0.8 以下、0.8–0.9 之间、0.9 以上）写进一张草稿表，你通常会发现决策呈双峰 — 一大堆清晰的自信答案，外加一条 0.5–0.7 的尾巴。人工复核就发生在那条尾巴上。然后把阈值挪到你的队列能消化复核量的位置；在共享收件箱场景下，15% 的复核率可能超出预算，正确的动作是收紧 criteria — 而不是默默接受 15%。

没把握时的升级路径

• 置信度低于阈值 — 连同 state 和完整分布一起送人工。
• 请求失败（重试后仍 429/502/529）— 默认走旧路径，而不是跳过决策。缺一个决策是 bug，不是可接受的风险。
• answers 映射里缺少答案键 — 视为失败并记录。（本不该发生；schema 保证每个问题名都有一个答案。）

能提升准确率的措辞模式

• criteria 当政策条文写，而不是同义词列表：“true: 明确对时间敏感或业务关键；false: 未表达紧迫性”胜过“true: 紧急；false: 不紧急”。模型读的是 criteria，所以请为一位从未见过你们产品的细心临时员工来写。
• 指名你引用的字段：“Does `proposed_tool_call` match what `user_request` asked for?” 让模型有据可依；“这个可疑吗？”则让它瞎猜。
• 一个问题只问一个决策：不要问“这紧急吗 而且要呼叫人吗 而且不是重复件吗？” — 复合问题的答案无法解读。
• 量表带红线：当动作在某一级发生变化时，在相关问题的 criteria 里写明那一级，而不是指望 score 单独表达。