choice 适合从固定选项里选出唯一结果，公开资料显示它的选项规模可以支撑很大的闭集，但线上生产配置千万别盲目往满了堆255个选项。这篇主要讲选项命名、描述、分组和置信度兜底的实用方法。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
封面是 Jev 在 Vercel AI Gateway 模型页的真实截图，这篇属于接口配置实操教程，配图只用来标识模型入口，具体优化方法都通过参数对比表和可运行的JSON示例说明。
选项越多，越需要工程化管理
Choice 最容易被滥用在意图分类、部门路由、商品类目、工具选择这类场景里。选项少的时候配置起来一目了然，数量一多很容易出现含义重叠、命名随意改动、概率分散、日志难读的问题。
所谓最多支持255个选项，从来不是让你一上来就塞得满满当当，真正的核心要求是每个option的边界互斥、含义清晰可解释。
Choice 返回值为什么适合路由
Choice 的输入是规则映射，键是后端代码可以直接读取的稳定标识，值是该选项的适用说明。Jev 会返回最终选中的结果、每个选项的对应概率和整体置信度。
业务代码拿到结果可以直接根据选中的选项跳转到对应处理队列，也可以在置信度太低、或者前两名概率差太小的时候转人工。这种方案比让普通大模型输出自由文本标签，写测试和链路回放要简单很多。
高选项数量下的配置步骤
- 先分层：超过30个选项时，优先考虑先粗分再细分，别硬往一个Choice里塞。
- 稳定 key：选项键用英文 snake_case 格式，别用随时可能改动的中文标题当标识。
- 写清排他边界：每个选项的说明里，既要写适用条件，也要明确写出不适用条件。
- 保留兜底项：必须加入 other、unknown 或 manual_review 这类兜底选项。
- 监控概率分散：前两名概率差小于设定阈值的时候，别直接走自动执行逻辑。
大 Choice 与两段式 Choice 对比
| 方案 | 优点 | 风险 |
|---|---|---|
| 单次大 Choice | 一次请求完成全部分类 | 选项重叠时概率会严重分散 |
| 两段式 Choice | 先粗分再细分，边界更清晰 | 多一次请求或多一层处理逻辑 |
| 规则预筛 + Choice | 明显匹配规则的样本先走判断，降低调用成本 | 后续规则维护成本会上升 |
选项描述应该怎么写
别只写 billing、support、sales 这种干巴巴的短标签，更稳妥的写法是用一句话把用户表达、业务对象和触发条件都覆盖到。
比如 billing 可以写成“payment failure, duplicate charge, refund, invoice or subscription billing”。
如果碰到两个选项都能覆盖同一句用户输入的情况，要么把这俩合并，要么补充更明确的互斥排除条件。
255 个选项不是上线目标
大家常看到的“最多255个选项”，是能力上限的定义，不是默认的配置目标。如果你的后台有200个商品类目，建议先让Choice判断一级类目，再在命中的一级类目下做二级类目的判断。
这么做既能降低概率分散的问题，出问题的时候也方便人工快速定位是哪一层类目设计不合理。
| 选项规模 | 推荐策略 | 原因 |
|---|---|---|
| 10 个以内 | 单次 Choice | 边界很容易写清楚 |
| 10 到 50 个 | 增加 other 和人工兜底 | 避免模型硬分配结果 |
| 50 个以上 | 分层 Choice | 后续可维护性更高 |
大选项集合的复盘方法
上线之后重点盯四个指标：other占比、前两名概率差、人工改派率和新增类别需求。
如果other占比持续升高，说明现有选项覆盖不全；如果前两名概率长期拉不开差距，说明选项边界重叠；如果人工频繁推翻模型分类结果，说明选项描述和实际业务的判断标准不匹配。
要扩展类目的时候先把新选项加到测试版本验证，别直接修改线上的criteria规则，不然历史概率分布会直接失去对比参考性。
带兜底和置信度判断的 Choice 示例
const questions = {
department: {
type: 'choice',
instructions: 'Route this customer ticket to exactly one team.',
criteria: {
billing: 'Payment failure, duplicate charge, refund, invoice, or billing plan',
logistics: 'Shipping status, delivery delay, courier issue, or tracking update',
account: 'Login, password, permission, membership, or profile settings',
product_bug: 'Feature does not work, error message, outage, or integration bug',
other: 'None of the above teams clearly match the ticket',
},
},
};
function chooseAction(answer) {
if (answer.choice === 'other' || answer.confidence
<h2>Choice 高阶使用坑点</h2>
- 选项键随便改名，之前积累的历史统计会直接断档没用。
- 多个选项语义重叠，前两名概率会长期拉不开差距。
- 没加other兜底，碰到不匹配的输入模型也会硬选一个结果。
- 拿中文长句当key，后端写分支逻辑的时候很难维护。
- 只看排名第一的winner，不看全量probabilities，很容易漏掉边界模糊的灰区样本。
什么时候可以用很多选项
只有当所有选项完全互斥、描述足够清晰、日志体系能稳定消费全量返回结果时，Choice才适合扩展到很大的集合。只要业务场景允许先做粗分再做细分，两段式的设计通常调优起来更省事，排查错误分类的问题也更方便。
