Jev playground 实际连到了哪里 — 以及拿到 key 之后会变什么

同一个模型，三扇入口

playground 背后既不是 mock 也不是演示版：匿名访客每天 30 次 playground 调用、登录访客 50 次，都在进行真实的上游推理，且不消耗任何积分。playground 配额按 IP 派生作用域封顶（经过哈希，原始地址不会进日志），而你在浏览器里看到的 JSON 正是带 key 的调用会返回的形状。

生产环境的三个差异

• 端点：/api/playground（浏览器会话）对比 /api/v1/systemone（Bearer key）。
• 鉴权：playground 限制每个访客的次数；API 用工作区 key 为每个请求做认证。
• 配额：每日次数上限 对比 计划速率上限（free 20 req/min、Starter 120/min、Pro 600/min、Team 2,000/min）加积分消耗。

其余全部相同：同样的请求 schema（1–8 个命名问题、状态最多 100,000 字符）、同样带 probability 和 confidence 的答案形状、同样的错误码 — 唯一例外是 playground 永远不会返回 401 或 402，因为那里没有东西消耗积分。

上限为何存在

上限首先是支出天花板，其次才是产品决策：playground 调用是不由任何积分支付的真实推理，上限约束免费流量可能产生的成本。每日重置按访客计而非按工作区计，因此团队无法叠出一个更大的免费额度 — 那 5 个注册积分和 API key 才是为这个准备的。

看到每日上限提示时，出路就是 API key：5 个免费积分恰好覆盖从“我在浏览器里验证过了”到“我在发几百个真实调用”之间的桥。这两个世界之间改变的只有 Authorization 头和 URL。

一个务实的迁移顺序

• 在 playground（免费）里迭代 criteria 措辞，直到十个真实案例返回你本来会做出的决策。
• 注册、创建 key，在 Bearer 头下运行完全相同的请求体 — 由此才能观察你自己负载的真实 usage token 与 latency_ms。
• 把包装层放在功能开关后面，先放量到 5% 的流量；逐请求记录 request_id 和策略动作。
• 等阈值建立在你观察到的分布上而不是猜测上，再扩大规模。

最后一点关于归属：工作区是计费与访问的边界。key 属于工作区，积分也属于工作区。在 Team 计划里，成员创建的 key 共享同一个余额 — 所以请在工作区层面轮换和吊销 key。

第一天会遇到的速率上限数字

第一次批量调 API 通常会在免费档撞上 X-RateLimit：每分钟 20 个请求、1 个并发。响应头会明确告诉你还要等多久（Retry-After 与 X-RateLimit-Reset，epoch 秒），而一个简单的客户端信号量 — 同时在途一个请求、按计划速率补充令牌 — 会把 429 从错误变成调度问题。在 Starter 的量级下，朴素的串行循环依然从容；超过每秒几个请求就该上信号量，而高于 Starter 的计划，并发配额比每分钟数字更重要。

完整响应一览

{
  "request_id": "req_fe17d05411092c4f7f97947a",
  "model": "jev-1.14.0",
  "answers": {
    "refund_requested": { "type": "noul", "noul": 0.28 },
    "policy_supports":  { "type": "noul", "noul": 0.98 }
  },
  "usage": {
    "input_tokens": 401,
    "output_tokens": 39,
    "credits": 0
  },
  "latency_ms": 523
}

注意这里的 credits: 0 — playground 的计费签名。同一请求在 Bearer key 下显示 credits: 1（401 输入 token 向上取整为 1 积分）及 credits_remaining 余额。其余完全一致，这正是 playground 能作为可信排练场的原因。