--- layout: post.njk source: https://yage.ai/share/decision-model-boundary-20261025.html web_feed: articleId: cmvoemp5e000dyee7r036fa02 feedSourceId: webfeed_yage_ai guid: https://yage.ai/share/decision-model-boundary-20261025.html sourceUrl: https://yage.ai/share/decision-model-boundary-20261025.html speaker: yage.ai title: 靠“我不是什么”走红的决策模型，正在亲手擦掉自己的边界 date: '2026-10-25' summary: 文章探讨了决策模型从最初的“我不是什么”（否定式边界）的营销成功，到随着接口功能不断扩张（如增加box、text抽取、数值估计等）而逐渐失去其独立品类定义权的演变过程。核心观点是，品类边界的模糊并非市场消失，而是产品在迎合真实业务需求时，亲手擦掉了最初的营销护栏，最终退化成通用结构化输出层。真正的壁垒在于概率校准质量、垂类业务数据和自动化工作流的嵌入深度，而非最初的“只做判断”这一营销口号。 area: tech-engineering category: ai-application tags: - decision-model - structured-output - model-boundary - ai-tooling - system-one people: [] companies_orgs: - TypeSafe - Jev - Cloudflare products_models: - Jev - TypeSafe - Cloudflare Clef - OpenAI Decisions media_books: [] draft: true status: evergreen --- 写业务代码或搭 Agent 循环时，经常会碰到一类高频的分支判断：意图路由、状态分类、风险打分、工具选择。要是每次做这种轻量判断都去调逐 token 生成的自回归大模型，延迟高，按输出 token 计费也贵，还得时刻防着模型吐出越界的格式。 决策模型就切在这个工程痛点上。调用方显式声明一组带类型的问题或候选空间，模型不生成自由文本，只做单次前向计算，直接返回选项概率、分数或类型化值。靠着一套“我不是什么”的否定式宣言，像 TypeSafe 的 Jev 这样的决策模型很快在通用大模型的夹缝里跑了出来。 但品类刚立住脚，变化就开始了。最早把这套接口做成商业 API 的 Jev，连同后面跟进的同类产品，纷纷往原本极简的接口里塞进各种新类型：在图片里框出目标位置的 box、从文档里抽字段的 text 和 date、估计连续数值概率分布的 estimate、预测未来多步时间序列的 forecast，甚至把最初特意剔除的拒绝通道 refusal 也加了回来。 不少开发者觉得这只是产品功能的自然丰富，可放在品类定义的尺度上看，走向恰恰相反。一个靠否定式边界建立起来的物种，每往接口里添一种新类型，就擦掉了一条当初用来画圈的“我不是什么”。等圈子擦干净，这个刚攒出辨识度的独立品类，也就退化成了通用的结构化输出层。 ## 它靠“我不是什么”走红 只有看清一个技术品类最初凭什么在营销上爆火，才能明白它后来在扩张里丢掉了什么。对每天在业务代码里调 API 的工程师来说，一个新模型如果只讲正面功能，很难从现有的大模型工具链里独立出来，更谈不上在短时间内撑起一个新类别。 试想一下，要是这类模型发布时主打的正面口号是“我能输出 decision（判断）”，市场上不会起任何波澜。今天几乎所有通用 LLM，配合结构化输出、JSON 模式或函数调用，都能按调用方给定的格式输出分类标签或布尔判断。只靠正面宣称自己“能做判断”，在工程上拉不开任何差距。 真正帮这类模型撕开市场缺口的，是一套干脆的否定式宣言。以最早的样本 Jev 为例，它在发布博客和原语文档里反复向开发者强调四个“不是”：我不是自回归模型；我不是负责慢思考的 System 2 模型；我不需要做耗时费力的深度推理；我不生成自由文本、不附带解释、不提供拒绝回答的通道，只从你给定的候选选项里做选择。 这套否定式定位之所以奏效，是因为它借了当时的行业背景做反衬。彼时市面上几乎所有主流大模型都在走自回归生成路线，都在比拼 System 2 式的长链条慢思考，默认输出一段段自然语言文本。所有玩家都在往同一个方向堆能力时，正面讲“我能做什么”很容易淹没在噪音里；反过来连续声明“我不是什么”，一下就在同质化的市场里画出了一个高辨识度的圈。这个品类最初能跑出来，本质上是一次否定式定位的营销成功。 这类模型在宣传时常借用心理学家卡尼曼的双系统理论，把快、自动、直觉的认知称为 System 1，把慢、费力、逻辑推理的认知称为 System 2。厂商常把 System 1 叫作 System One，并自称 System One 模型。但单拿“我是 System 1”出来讲，说服力其实有限，因为 System 1 只是一个心理学隐喻，落不到代码接口和系统架构上。真正让工程师买单的是“我不是 auto-regression”这句声明，它对应的是可以在首字延迟、吞吐量和解码路径上直接验证的工程差异。 这套否定式宣言能够自圆其说，前提是它守住了一个极窄的产品边界：只做离散判断、只从调用方给定的选项里选、只返回概率或分数。在 Jev 初版的接口设计中，核心问题原语只有三类：choice（在有限候选项里多选一）、noul（对命题做真假或正负判断）和 score（在给定标尺上打分）。所有输出都严格落在调用方事先声明的封闭候选空间内，没有自由文本字段，没有解释字段，接口里也没有定义 refusal（拒绝）类型。模型不聊天、不寒暄、不弃权，只充当代码里的智能条件分支。正是这种收敛，撑起了它作为独立产品存在的前提。 关于这类模型的单步前向机制、为什么底层技术没有壁垒以及判断 API 的四轮历史演进，可以参考此前的机制与时机分析；封闭输出空间如何实现零幻觉三层边界与概率校准实测，此前的边界测试文章已有详细数据；至于这类高频轻量判断在 RPA 语义重放与业务 skill 分层里的位置，以及为什么运行层的高频调用像UiPath 把收费站搬到运行层一样具有商业吸引力，也可以回看早前的自动化分层讨论。回到品类边界本身，这个类别最初的力量，不在它能说什么，而在它不能说什么。 ## box 擦掉了“只做判断” 一个靠“只做代码里的离散分支判断”立身的接口，一旦开始往外输出图像里的矩形坐标，最初画下的第一道品类边界就开始松动了。只要跨出离散选项、进入连续的图像感知空间，“决策模型”这四个字对应的工程契约就会变形。 标志性的转折点出现在 Jev 1.14 版本。官方在原本只有 choice、noul、score 的原语列表里新增了 box 类型。按官方文档的定义，box 用于在输入图像中定位单个目标，返回一个边界框，由四个边占图像尺寸的比例坐标和一个置信度组成。 翻开 box 的官方文档，有一句很醒目的规则说明：一个 Box 回答永远是一个框，不存在“未找到”这个回答（“A Box answer is always a box. There is no ‘not found’ answer.”）。这句话把最初的判断契约与新任务之间的冲突暴露了出来。在离散分支判断里，调用方要求模型在给定的几个选项里必选其一，不设“未找到”还讲得通；可到了图像目标定位场景，待查找的物体很可能根本不在画面里。文档没有给“不存在”这个状态；按文档的字面规则，目标不在图里，返回的仍是一个框，拿不准的程度压进 confidence 数值里，交由下游代码自己设阈值。 从接口形态看，box 做的是计算机视觉里的视觉定位，也就是单目标检测：根据文本提示，在图像的连续坐标空间里框出目标位置。这属于感知任务，并非离散判断。在视觉定位这条技术谱系上，成熟方案出现得比决策模型早得多：早在 2020 年，DETR 就把目标检测建模成了集合预测，本身就是直接输出坐标框的非自回归架构；2023 年的 Grounding DINO 进一步打通了开放集合目标检测；后来的 Florence-2 与 Qwen2.5-VL 等多模态模型，也早已把视觉定位作为标准能力内置其中。往决策 API 里塞一个单目标 box，并没有在视觉感知上提供什么新原语。 有人可能会反驳：box 依然没有逐个生成自由文本 token，底层依然保持单步或非自回归的快速解码，为什么不能算作 System One 决策模型的自然延伸？这种看法把底层的实现属性和上层的品类定义混在了一起。“不生成 token”只是一个工程实现特征，代表不了一种认知模式。DETR 从诞生的第一天起就不逐 token 生成文本，但计算机视觉社区从来没人把 DETR 叫做“System One 模型”或“决策模型”。接口从有限候选集跨到连续像素空间，任务的数学本质就变了。 对于这次越界，官方自己心里也很清楚。在 Jev 1.14 的发布博客中，团队自述 box 是他们第一个不纯粹服务于智能条件分支的类型，并把这次改动称作在简单决策之外的探索。box 文档开头也标了“Dreamer-ready”，说明图像与 Box 问题尚未达到他们自己认定的生产级标准。 那些否定式的技术声明（不是自回归、不吐自由文本）在 box 身上依然成立，但“我只做 smart-if 式的离散判断”这道核心产品边界，已经由画圈者自己动手擦掉了。box 表面上是多了一个原语类型，实际上是少了一个“只做判断”。 左栏是 System One 的名字，右栏是结构化预测的路径；Jev 借了前者，走的是后者。 ## Clairic 擦掉了“只做离散选择” box 留下的那个“永远返回一个框、没有 not found”的生硬约束，放到真实业务工程里很难走通。只要把接口接进文档处理或数据流水线，调用方马上就会碰到字段缺失的情况。可如果后来者在修补这个缺失值漏洞的同时，顺手把文本抽取、连续分布回归和时间序列预测全装进同一套接口，这个品类的第二道边界也就跟着消失了。 Cloudflare 的另一条产品线，展示了另一种类型边界。他们在 Workers AI 上同时放了两个模型：Clef 负责传统的分支决策，Clairic 则直接切入结构化抽取与预测。打开 Clairic 的官方文档可以看到，它的请求结构以 fields 组织，支持的字段类型一口气扩展到了九种：text、number、date、time、datetime、duration、list、estimate 和 forecast。 为了处理真实数据里常见的字段缺失问题，Clairic 在类型设计上引入了 p_null、confidence 和 guess 的组合。每个标量回答都同时携带缺失概率 p_null 与置信度 confidence，接口允许 value 直接为 null，同时用 guess 字段给出模型如果不弃权原本会选的值。官方文档给出的一个返回示例是 value: null, p_null: 1, guess: "INV-2291", confidence: 0.9995。这套设计把“目标在原文里根本不存在”和“目标存在但模型拿不准”拆成了两个可独立读取的信号。 单看类型机制，p_null 的引入确实补上了此前 box 那种“没有 not found、找不到也必须返回一个框”的类型缺口。但这里需要分清任务边界：p_null 是长在结构化信息抽取任务上的一套通用类型设计，并非给视觉定位 box 打的补丁。当接口开始用 text、number、date、duration 和 list 从非结构化输入里往外抠字段并判断字段是否为空时，它干的已经是传统文档理解和字段抽取的活了。 真正把“只做离散选择”抹平的，是排在类型列表最后面的 estimate 和 forecast。根据 Clairic 发布博客的说明，estimate 用于对未知连续数值做分布估计，模型会在调用方指定的 [min, max] 网格上返回完整的概率分布，并给出中位数以及 p10、p90 分位数；forecast 则面向时间序列场景，为未来的每一个时间步分别返回一个预测区间。 把这几件事放回机器学习的基本任务分类里看：在几个固定枚举项里挑一个，是分类或离散决策；从一段话里抠出字符串和日期，是信息抽取；在 [min, max] 连续区间上估计分布与分位数，是连续变量回归或密度估计；给出未来多步的数值区间，是时间序列预测。它们本来就不属于同一种任务。 走到 Clairic 这一步，底层“不是自回归、不生成自由解释文本”的工程特性固然还在，但最初用来圈定品类的“只做离散选择、只从给定选项里选”已经不复存在。Clairic 把空值这个合法状态加回了类型系统，同时顺手装进来的也不再局限于判断，还多了抽取、回归与预测。 ## 为什么大家都在扩张：一个可能的解释 看到从 Jev 到后来者都在往接口里塞新类型，很容易把这件事理解成跟风堆功能，或者责怪厂商背叛了最初的极简主义。我的判断是，更重要的原因在于原来那道“只做离散判断”的边界在真实流水线里不够用。 一个完整的 Agent 循环或自动化流水线，不只需要二选一、多选一的分支路由。同一条链路经常还要从非结构化文档里抽字段、在截图或照片里框出目标、对未知的连续数值给出估计、对未来几个时间步做区间预测。如果一个接口只能回答“走哪个分支”，调用方为了跑完业务链路，往往还要在旁边接视觉检测、字段抽取和统计预测组件。窄边界在营销上更锋利，在产品交付上却更不完整。 我的判断是，这类产品身上有一个反市场的成分：为了在同质化的自回归大模型市场里撕开缺口，它必须画一道“我不做这个、不做那个”的硬线，靠否定式宣言在营销上爆火、吸引注意力，并顺势把声明式请求接口规范下来。但客户不会为了守住厂商的营销边界，把自己的真实需求砍掉。画圈者如果长期死守“只做判断”，就等于把紧挨着分支判断的抽取、定位、估计需求让给更完整的产品；继任者和竞争者把这些类型加进来，产品变完整了，靠“我什么都不多做”成立的锋利感也就消解了。 这条解释与过去几个月的产品动作是相容的，但公开材料不足以证明每一家厂商的动机。能确认的是：同一个接口形状也出现在 OpenAI、Microsoft、Cloudflare、Perplexity、Liquid 和 ScaleDown 的产品里；其中一些在共享声明式外壳的同时扩展了类型，另一些只做了接口兼容。Microsoft-Decision-1 沿用 state 加 noul/choice/score，文档只写请求模式类似 system-one API；Cloudflare Clef 主打完全兼容 Jev API，Clairic 则用 fields 扩展抽取与预测；OpenAI Decisions 采用 predicate/choice/score，并加入了一个 refusal 类型；Perplexity、Liquid、ScaleDown 也各自有不同的类型面。把这些动作放在一起，能看到“接口形状被共享、类型边界各自扩张”的现象，但不能从现象直接推出每一家的因果。 refusal 是一个有用的例子。Jev 初版没有这个类型；OpenAI Decisions 有。公开材料没有解释 OpenAI 为什么加它，也没有把它和 Clairic 的 p_null 绑定。能说的是：拒绝也被做成了一个 schema 里的类型化分支。行业由此出现了接口层和语义层的分化：Cloudflare Clef 明确宣称完全兼容 Jev API；但共享声明式外壳，不等于只改 base URL 就能迁移。接口兼容与概率、空值和拒绝语义等价是两回事：各家的 p_null、confidence、estimate 与 refusal 在缺失定义、概率分布和校准语义上并不相同。 ## 失去的不是市场，是定义权 为什么要较真一个技术品类叫什么、边界在哪里？因为在软件工程里，品类的边界决定了开发者在系统架构图里如何安放一个组件。当一个品类再也说不出自己和通用模型的结构化输出有什么任务边界上的不同时，它在架构里就会从一个独立的一级组件，退化成通用模型网关底下的一个普通解码参数。 把几种接口设计并列比较，就能看清最初那个靠“我不是什么”画出来的圈，是如何被一层层擦掉的： 阶段 仍然成立的“不是” 已经擦掉的“只” 品类实质 最初（Jev 初版） 不是自回归生成；不是 System 2 慢思考；不生成自由文本、不解释、不拒绝 （边界完整：只做离散判断、只从给定选项里选、只返回概率或分数） 纯粹的 Smart-If 离散判断器 box 之后 / Jev 1.14 不是自回归生成；不生成自由文本；没有 not found 或拒绝通道 擦掉了“只做判断”（进入连续坐标空间的视觉定位，且找不到目标也必须返回框） 混入单目标视觉感知的混合接口 Clairic 不是自回归自由文本生成（仍按声明字段直接输出结构化结果） 擦掉了“只做离散选择”与“永不报空”（引入 p_null ，扩充文本抽取、连续回归 estimate 与时序预测 forecast ） 带弃权机制的通用抽取与统计预测接口 其他厂商接口 不生成自由解释文本（保留强类型请求与响应外壳） 擦掉了“不拒绝”与统一语义（OpenAI 将 refusal 类型化，各家自定义原语与概率语义全面分化） 共享 JSON 形状的非自回归通用结构化输出层 顺着这张表往下看，演进脉络一目了然。这个类别最初的正面定义是“判断”，外面围着一圈“不是自回归、不是慢思考、不生成自由文本”的护栏。把这些扩展放在一起看：视觉定位 box、字段抽取与回归预测 Clairic、以及其他厂商的不同接口，“判断”这个正面内核已经不见了，只剩下“不生成自由文本”这一条否定式属性还留在原地。但在我看来，对这里讨论的决策模型而言，单靠这些否定式属性，已经不足以说明它与其他结构化预测接口的任务边界。 随着接口支持的类型越加越多，它在调用方眼里反而越来越像自己最初反对的东西。今天的通用自回归 LLM 配合 JSON schema 和结构化输出，同样可以接收一段上下文和一份字段声明，然后输出分类选项、抽取文本、日期、数值区间乃至拒绝状态。外层接口能装的任务趋于一致，这类模型与“通用 LLM + JSON schema”之间的差别，就只剩下底层是采用非自回归单步解码还是自回归逐 token 解码。曾经的品类之别，退化成了底层的实现属性之别。 所以说，这个类别在功能扩张中丢掉的是定义权，市场并没有丢。在我看来，品类边界的模糊，并不意味着低延迟、低成本、强类型调用的工程需求也随之消失；但作为独立品类的“决策模型”，已经再也说不出“我不是什么”了。它把视觉检测、字段抽取、数值回归、时间序列预测和拒绝通道全都揽进怀里，也就亲手拆掉了当初让自己脱颖而出的那道围栏。 如果要按它今天实际承担的工程任务，给它换一个诚实的正面技术名字，它应该叫“带弃权的类型化预测”，英文是 typed prediction with abstention；或者叫“非自回归结构化预测”，英文是 non-autoregressive structured prediction。所谓带弃权的类型化预测，指的是模型在调用方声明的类型空间里直接输出结构化值、分布或 null/弃权概率，不生成自由文本。叫什么名字本身并不重要，关键是剥离掉“System One”这类营销隐喻之后，真正支撑这套接口工程价值的只剩三条正面契约：第一，输出空间由调用方显式声明；第二，模型直接解码输出，不生成自由文本；第三，类型系统必须原生表达缺失、不确定性与概率分布。 退回到这个技术实质，它在产业链里的经济位置也就清楚了：外层的 JSON 接口形状没有任何排他壁垒，谁都可以做到接口兼容；真正决定哪个模型能留在生产环境里的，依然是概率校准质量、垂类业务数据、人工复核闭环以及嵌入自动化工作流的深度，这一点在此前的时机与壁垒分析中已有完整分析。 从商业角度看，对 TypeSafe 这样的开创者来说，失去品类定义权未必是坏事，但这只是情景推演，不是已经发生的营收事实。死掉的可能是“System One 决策模型”这个早期用来破局的营销壳，而不是产品本身。如果厂商能把同一套声明式接口扩展到抽取、定位、估计与预测，并让客户愿意为这些任务付费，它面对的业务场景可能比“只做判断”更大。真正要守的是校准、数据、复核闭环和工作流嵌入；人为画出的“只做判断”并不是客户持续付费的理由。 这个品类更像是在一次次迎合场景的扩张中，把自己最初画下的边界擦没了。对技术分类而言，还能不能守住自己画的那个圈，可能比 API 明天还能多输出多少种类型更重要；但对身处其中的公司来说，品类名死掉不等于生意死掉。这个判断只针对这类决策模型，不是对所有技术品类的普遍历史规律。