从 Jev 到 Simplex CD：迁移决策 API 的检查清单

已经用 Jev 做工单分类或候选动作选择，想评估 Simplex CD 时，最有用的第一步是保留原来的任务。不要一边换模型，一边重写问题、选项和业务规则，否则结果变化很难归因。

下面的清单用于准备一轮可回退的迁移评估。它不假设两个服务的全部字段、限制或概率行为相同。

先保留 state、问题和候选的语义

TypeSafe 的公开快速开始使用 state、model 和 questions 组织请求，questions 中有按名称定义的判断。Simplex CD 也采用这样的基本组织方式，但地址、鉴权凭据和具体字段仍需按目标平台文档核对。TypeSafe 快速开始 · Simplex CD API 文档

保持问题名称、候选键和候选描述稳定。例如，把 billing 改名为 payments 可能影响下游代码；删掉一句候选解释则可能改变模型理解。先验证原任务，再单独优化提示。

用一个明确的选择题检查响应契约

下面是按 Simplex CD 文档组织的请求体示例。它用于客服分流，包含“其他”作为不匹配任何已定义部门的出口。

{
  "model": "spx-cd-flash",
  "state": {
    "message": "我被重复扣款了，请帮我核对账单。"
  },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "根据主要诉求选择负责部门。",
      "criteria": {
        "billing": "账单、扣款和退款问题",
        "technical": "产品故障和集成问题",
        "other": "不属于上述类别，或信息不足以确定"
      }
    }
  }
}

把请求放进 Playground，先检查结构是否符合预期，再用 Pro 重复同一请求。预期标签可人工标注为 billing，但实际模型输出应以真实响应记录为准，不能把预期答案当成测试已通过。

业务代码要检查 department 是否存在、choice 是否属于自己的候选集合，以及需要的概率字段是否有效。如果调用失败或字段缺失，进入既定回退流程；不要自动解释为 other 或零风险。

同名 confidence 字段不代表阈值可直接迁移

迁移后选中的类别相同，并不意味着概率分布相同。保留完整分布，在业务验证集上重新画出阈值与自动处理覆盖率、错误率的关系。

一个可操作的流程是：先让两个模型都只记录答案，由现有规则继续决定动作；检查分歧样本，再在验证集上选阈值，最后在未用于调参的测试集上评估。具体方法见 决策模型 API 评估指南。

多选、图片和有序评分单独验证

Simplex CD 提供 choice、multi_choice、noul、score。迁移现有文本选择题后，再把新增任务作为独立变更测试。Simplex CD 功能与案例

例如，多选任务要明确允许选几个、一个也不选是否有效；评分任务要检查 criteria 的排列顺序和返回分数含义；图片请求要按当前文档处理文件格式、大小与路由。不要用只覆盖文本 Choice 的测试推断其他类型也已经验证。

当前公开调用不要添加自行猜测的 effort 字段。评测文章中的 effort 是测试配置记录，实际接口支持和服务默认值以当前文档为准。

控制并发，并记录迁移后的实际成本

先从受控的小流量开始。记录请求的问题数量、输入规模、客户端耗时、有效响应和计费用量。批量请求需要同时看整批耗时与有效题数，避免把摊销耗时当成用户等待时间。

遇到 429 应尊重服务提示并有界退避；超时可能意味着服务已经执行，但响应没有被客户端收到。不要无上限重试，也不要让后续业务动作因为重试重复执行。迁移初期保留原服务回退路径，但明确重试和回退的次数上限。

上线前保存一张迁移验收表

常见问题

只改 base URL 就可以了吗？

不能据此认定完成迁移。还要换令牌、选择有效模型 ID，并核对字段、限制和响应语义。

必须重写所有题目吗？

初次评估时反而应尽量保留。把模型替换和题目优化拆开，才能知道提升来自哪里。

可以先在生产系统旁边观察吗？

可以做影子评测，但应先确认数据使用权限、额外调用成本和容量。影子结果只用于比较，不直接触发业务动作。

想先了解已有测试表现，可以查看 Jev 与 Simplex CD 对比，再从一条真实、可合法用于测试的任务开始。