你的应用不需要再多一段回复（OpenAI Decisions API 和「只要一个判断」的工程）
OpenAI Decisions API 公测：应用要的常常只是「是/否、走哪条路、打几分」，专用的判定端点官方称比同模型走 Responses API 快约 10 倍，只按输入计费。
打开你产品里的 AI 调用日志，数一数。
有多少次，你真正想要的只是一个字：是，或者否。
有多少次，你想要的只是一个方向：这张工单该去哪个部门。
有多少次，你想要的只是一个数：这个故障有多严重。
然后再看看你实际拿到了什么。
一段客客气气的回复。
一段你还得再写代码去解析的文字。
这就是今天大多数 AI 应用的真实样子：用一台写作机器，去回答一道选择题。
2026 年 10 月 6 日，OpenAI 把一个专门回答选择题的端点放进了公测。
它叫 Decisions API。
接口是 POST /v1/decisions。
目前只支持一个模型：gpt-6-luna。
OpenAI 官方文档称，用它做判断，比用同一个模型走 Responses API 快约 10 倍。
这个数字值得注意。
但更值得注意的，是它背后的那个承认：判断和生成，本来就是两种活。
默认陷阱：把每个问题都当成写作题
先说一个大多数团队都踩过的坑。
你需要判断一封客诉该给退款组还是物流组。
最顺手的做法是：写一段 prompt，让模型「请判断这封邮件属于哪个部门，只回答部门名」。
它大多数时候很听话。
偶尔会多说一句「根据邮件内容，我认为……」。
偶尔会把「物流组」写成「物流部门」。
于是你开始写兜底：正则、字符串匹配、重试。
你的代码里慢慢长出一层专门用来「驯服回复」的胶水。
这层胶水不创造任何价值。
它只是在弥补一个错配：你要的是一个判断，你调用的却是一个生成器。
更隐蔽的成本在延迟上。
生成式接口的节奏，是一个 token 一个 token 往外吐。
当你的问题只需要一个答案时，这种节奏就是浪费。
（这一句是我的推断：生成式接口的延迟和输出长度相关，判断类请求输出极短，专用端点自然有压缩空间。官方并没有解释「约 10 倍」具体来自哪里。）
如果你的业务每天要做成千上万次这样的判断，这些浪费不会消失。
它们会叠加成用户等待的那几百毫秒，叠加成账单上的那一行。
拆到底：一个判断由什么组成
我们把「判断」拆到最底层。
几乎所有应用里的判断，都能归进三种形状：
- 是不是：这张图里有没有裂纹
- 选哪个：这封信该去哪个部门
- 有多少：这个故障严重到什么程度
Decisions API 恰好就是按这三种形状设计的。
OpenAI 官方文档列出了三种题型：
- predicate：回答「是不是」，返回一个概率
- choice：回答「选哪个」，返回选中的选项和置信度
- score：回答「有多少」，返回一个加权分数
注意它们返回的东西。
不是一句话。
是一个可以直接写进 if 语句的值。
一个好的接口，会让错误的用法变得不自然。
这就是这个端点真正的价值：它不让你有机会得到一段多余的话。
概率、选项加置信度、分数。
这三样东西，你的代码天然就会处理。
还有一个细节值得单独说：predicate 返回的是概率，不是硬邦邦的「是」或「否」。
这意味着阈值在你手里。
验货场景里，你可以把阈值压低，宁可多拦几个，也别放过一个裂纹。
内容推荐场景里，你可以把阈值抬高，宁可少推，也别推错。
（阈值怎么定是我的建议，官方只说了返回概率。）
工具给你概率。
你给概率赋予后果。
这条边界，就是你的 point of view。
反转：AI 最值钱的产出，常常是最短的那个
大多数人对 AI 的想象，还停留在「它能写」。
写文章、写代码、写回复。
所以大家默认：输出越长，价值越大。
Decisions API 的定价把这个默认翻了过来。
OpenAI 官方文档称：
- 输入 $0.10 / 百万 token
- 没有输出费
- 没有缓存读写费
- 单次请求输入超过 272K 时，整单输入价格翻倍
最后一条要读仔细：不是超出的部分翻倍，是这一整单的输入价翻倍。
按字面算，就是这一单变成 $0.20 / 百万 token。（这是我按「翻倍」自算的，官方文档原话是翻倍。）
你只为「你给它看了多少」付钱，不为「它说了多少」付钱。
这个定价结构本身就在告诉你它的定位：它不打算替你说话。
它只打算替你看，然后下一个判断。
这里有一个很多人会忽略的推论。
当输出不再收费，你设计请求时唯一需要克制的，是输入。
那条 272K 的线，就是官方替你画的克制线。
（以下是我的推断，不是官方说法。）如果你习惯往 prompt 里塞整段历史、整份文档、几十张参考图，再让模型「顺便判断一下」，这条线迟早会咬你一口。
判断需要的是相关信息，不是全部信息。
信息越聚焦，判断越干净，账单也越干净。
这不只是省钱。
这是 taste 在工程里的样子：知道什么该给模型看，什么不该。
速度这件事，要分清谁说的
关于速度，有两个说法在流传，必须分开看。
第一个是官方的：比同一模型走 Responses API 做判断快约 10 倍。
这是 OpenAI 官方文档给出的相对说法。
第二个来自社区：OpenAI 开发者论坛上有人演示了用它验蛋壳裂纹，响应达到了近实时、亚秒级。
这是社区个人的演示。
它说明了这个端点「可以很快」，但不代表你的业务一定这么快。
你的图片大小、网络位置、并发量，都会改变结果。
所以合理的态度是：
- 「约 10 倍」可以当成官方给的方向
- 社区演示可以当成可能性的证据
- 你自己的延迟，只能用你自己的流量去测
把演示当承诺，是技术选型里最常见的自我欺骗。
执行模块：怎么把它放进你的系统
下面是我会怎么用它。
先说清楚：以下是思路，不是接口教程，具体字段和写法以官方文档为准。
1) 先把你的 AI 调用分成两堆
回到开头那份调用日志。
把每一次调用归类：
- 用户最终要读的，是一段文字：留在生成式接口
- 用户最终不读，只被代码消费的，是一个值：考虑迁到 Decisions
第二堆往往比你想象的大。
审核、分流、打标签、排优先级、质检。
它们都不需要文采。
它们只需要稳定、快、便宜。
2) 把题目改写成三种形状之一
很多判断一开始说不清是哪一种。
「这条反馈重要吗」可以是 predicate，也可以是 score。
我的经验法则（这是我的建议）：
- 后面只有两条分支：用 predicate
- 后面有几条固定分支：用 choice
- 后面要排序、要和别的值比较：用 score
OpenAI 官方文档举的三个例子，正好对应这三种：
- 验货找裂纹：是不是，predicate
- 把客诉路由到对应部门：选哪个，choice
- 给故障严重度打分：有多少，score
把题目改写清楚，本身就是一半的工作。
模糊的问题，换哪个接口都得到模糊的答案。
3) 图片请求，提前处理成 inline base64
这一条很具体，但很容易在上线那天卡住。
Decisions API 的输入可以是文本、图片，或者两者都有。
但 OpenAI 官方文档写明：图片必须以 inline base64 的方式传入。
不支持托管 URL。
不支持 file_id。
如果你现有的流水线习惯把图片先传到存储，再把链接丢给模型，这里要改。
（以下是我的推断。）质检这类场景，图片通常就在本地产线的机器上，直接编码进请求反而少了一跳。
但图片体积会直接算进输入，也就是算进那条 272K 的线。
送进去之前，想清楚判断需要多大的图。
4) 和 Structured Outputs、function calling 分好工
这是最容易混淆的地方。
三样东西都能让模型「输出结构化的东西」，但它们解决的是不同的问题。
以下分工是我的理解和建议，不是官方原话：
- Decisions：答案的形状是固定的，概率、选项、分数三选一。适合分类、路由、排优先级。
- Structured Outputs：答案的形状由你用 schema 自己定义，可以有很多字段。适合从一段内容里抽取信息、填一张结构复杂的表。
- function calling：模型决定要不要调用你的工具、用什么参数调用。适合让模型去「做事」，而不是「下判断」。
一句话区分：
要一个判断，用 Decisions。
要一份自定义结构的数据，用 Structured Outputs。
要模型去调用你的系统，用 function calling。
OpenAI 官方文档的定位也很清楚：Decisions 不适合生成自由格式的 JSON，也不适合写长文。
别用它去做它不打算做的事。
那只会让你重新长出一层胶水。
它们也可以串起来。（这是我的推断。）比如先用 Decisions 的 choice 判断一封客诉该去哪个部门，再在对应部门的流程里，用生成式接口起草回复。
判断归判断，表达归表达。
5) 合规先问清楚，再谈上线
很多判断类场景，恰好落在敏感数据上。
医疗分诊、金融风控、客户隐私。
OpenAI 官方文档称：合格客户可以使用 ZDR（零数据保留）和 HIPAA 支持，并且有美国和欧盟的数据驻留选项。
注意「合格客户」这四个字。
这些能力不是默认对所有人开放的。
如果你的场景涉及这些要求，先确认你的账户是否符合条件，再设计架构。
把合规当成上线后再补的事，是最贵的顺序。
6) 记住它还在公测，而且只有一个模型
最后一条，也最容易被兴奋淹没。
Decisions API 现在是公测。
它只支持 gpt-6-luna。
这意味着两件事。（这是我的推断。）
第一，接口细节和行为可能还会调整，关键路径上最好保留回退方案。
第二，你没有在模型之间挑选的余地，判断质量好不好，只能用你自己的数据去验。
合理的做法是：
- 先拿一类判断试，比如客诉路由
- 和现有方案并行跑一段时间，对比准确率、延迟和成本
- 确认阈值和失败模式之后，再扩到下一类
冷静收尾
Decisions API 不是一个更聪明的模型。
它是一个更诚实的接口。
它承认了一件很多人不愿承认的事：应用里的 AI，大部分时候不需要表达自己。
它只需要看一眼，然后告诉你：是，或者否。去这里，或者去那里。三分，或者八分。
你可以继续让模型写一段话，再写代码去拆那段话。
你也可以把问题改写成它本来的形状。
前者是在和工具较劲。
后者是在设计系统。
当 AI 能说出任何一句话的时候，真正稀缺的能力，是知道哪些地方，你根本不需要它说话。
来源：OpenAI 官方文档：Decisions；OpenAI 开发者社区：Decisions API is now available in public beta（2026-10-06 公测）。「约 10 倍」为官方称；单次输入超 272K 后 $0.20/百万 token 为作者按「翻倍」自算；社区验蛋裂纹的近实时/亚秒级演示为个人演示，非官方数据；与 Structured Outputs、function calling 的分工及标注为推断或建议之处为作者观点。