1. 为什么“不写一个字、只出判断”的 AI 反而更值钱1.1 大多数软件需要的不是“回答”而是“裁决”这几年做软件架构咨询我越来越常被问到一个问题AI 到底放在系统哪个位置才能真正把成本降下来。大多数团队的第一反应是聊天窗口、Copilot、RAG 知识库结果聊完一圈发现算力账单上去了人的负担反而变重了——模型每次输出几百上千字读完、判断、再决定下一步还是得人工来。其实很多业务场景里软件调用 AI 的真实目的不是一个“回答”而是一个“裁决”。这笔交易算不算异常、这条日志要不要告警、这个工单该归给哪个组、这个数据库 schema 变更能不能自动执行背后都是同一个动作在有限几个选项中选一个然后触发后续流程。用户不想要 500 字分析报告只想要一个“过 / 不过”“正常 / 异常”“A 类 / B 类”。我最早意识到这个问题是在一个内部工单系统里。原来的方案是让通用大模型生成一段处置建议结果运营同学每天要翻几百条建议真正有用的只是最后那句“建议转给财务组”。剩下那些铺垫、解释、补充说明全部变成需要阅读的噪音。后来我们换了一种思路让模型只输出一个结构化判断把那段话砍掉。效果立竿见影处理速度上去了Token 费用也降了一大截。1.2 “系统一”不是比喻而是一种架构取舍《思考快与慢》里把人脑的认知分成了两套系统系统一负责快速、直觉、自动化的判断几乎不消耗注意力系统二负责慢速、理性、需要推理的分析费力但更可靠。这个框架放到 AI 场景里同样成立。我之前一直以为 AI 都应该是“系统二”的样子你给它一个问题它思考许久给你一段逻辑严密的回答。后来接触 Jev 这类判断型模型才意识到“系统一”在软件里可以单独成一种产品形态输入一堆特征和上下文输出一个标签附带置信度结束。它不追求解释长篇大论也不尝试把复杂问题讲清楚只是把“判断”这个动作做到极致。关键在于这类模型省掉的是表达成本不是思考能力。大多数业务决策要的只是“分诊”而不是“论文”。系统一模型正好把认知负荷压到最低机器能直接消费结果人能一眼看懂结论误判时也能快速定位到具体标签和置信度而不是从头读一遍正文再猜模型到底想表达什么。1.3 成本账的第一行改动Token 消耗量级下降成本账上最先被改写的是 Token 消耗。用一个我实际测过的场景举例工单分类通用大模型的做法是塞进两千字上下文让它写一段分析。一个请求下来输入加上输出轻轻松松两三千 Token。而 Jev 这类判断模型输入可能只需要几百 Token 的结构化特征输出就是一个 JSON 标签和置信度整体消耗直接差出一个数量级。有人可能会说这不就是少写几个字吗哪有那么夸张。但软件成本是乘法不是加法。每天十万次调用每次差两千 Token乘以 30 天再乘以模型单价就是一笔明显能感受到的账单。更关键的是Token 量下来之后延迟、超时、重试、熔断这些连锁反应都会跟着缓解整个系统的稳定性也会好很多。后面我会专门用一张表把这几项拆开算。2. Jev 的系统一本质不是模型大小问题而是接口形态问题2.1 判断型模型的典型返回结构化判定聊 Jev 这类判断模型之前得先建立一个认知它和通用大模型根本不是同一种接口形态。通用大模型返回的是自然语言 token 流而判断模型返回的是可以直接被代码消费的结构化数据。一次完整的典型响应大概长这样{ judgment: { label: needs_human_review, confidence: 0.87, reason_short: detected_schema_breaking_change, suggested_rule_id: RULE_1042 }, meta: { request_id: req_8f3a19c07b4e, model_version: jev-judgment-v3, latency_ms: 124 } }看到没有没有“根据分析我们认为……”这种套话只有字段、标签、置信度、原因代码。这种返回可以完全不经过人直接交给下游规则引擎去执行。对于软件工程师来说这比解析大模型的自然语言输出可靠得多——不会出现模型今天说“是”、明天说“是的”后天给你回一句“不确定怎么回答”的尴尬情况。2.2 它在软件架构里更适合的位置路由层和门禁层在我实际落地过的项目里Jev 这类模型最合适的位置不是用户对话框而是业务链路的入口位置。讲四个比较典型的用法。第一个是代码评审门禁。提交 PR 时判断模型在几毫秒内给出一个结论这个变更是否涉及数据库表结构、是否触碰了支付相关代码、是否属于需要双人复核的高危变更。能自动判断的放行高危的自动标记。以前靠规则引擎写几百条正则和关键词现在让模型去识别语义层面的风险规则库维护成本低了不少。第二个是数据库同步软件。很多同步任务卡在 schema 冲突上源端把字段重命名了、删掉了默认值、改了类型目标端要不要跟着改规则引擎只能识别“字段名不同”这种表层问题但判断模型可以结合上下游影响面给出“可自动解决 / 需要人工介入”的裁决。这个场景我后面会拿来做成本测算案例。第三个是双机热备的故障转移判断。传统方案是一堆阈值规则CPU 达到多少、心跳丢失几次就切换但误切率很高。判断模型可以把多个指标拼在一起输出一个“建议切换 / 建议继续观察 / 建议立刻人工介入”的多级判断。规则负责处理已确认的故障模型负责处理“不确定要不要切”的灰度地带。第四个是工单路由和告警收敛。监控系统一天能产生几万条原始告警大多数是重复或者不重要的。判断模型先把告警分类、去重、定级只有真正需要人处理的才往上送。告警泛滥导致“狼来了”效应减弱的问题用这种方案解决非常有效。2.3 系统一与系统二之间的级联预算分配讲到这里必须强调一点Jev 这类系统一模型不是用来取代通用大模型的它是用来给通用大模型“挡流量”的。一个健康的架构应该是级联结构。我用机场安检来类比。自动闸机是系统一它处理绝大多数普通旅客刷脸核验、放行整个过程不打扰任何人。只有当闸机报警、行李特征可疑时才会转去人工安检通道。人工安检就是系统二能力更强、判断更全面但它贵、慢不可能让每个人都走这个通道。AI 架构也一样让系统一模型消化掉 90% 的常规流量把低置信度、高风险、需要复杂推理的样本甩给通用大模型或者真人专家去处理。这种设计带来的成本优势非常直接高价的通用模型调用量骤减低价的判断模型扛起主要流量。而且两个层级的日志都清晰可查出了问题知道该追查哪个环节。3. 软件成本账哪些行项目正在被改写3.1 先看一张成本对照表总有人说 AI 太贵我理解的是贵不在模型本身贵在架构设计不当导致的浪费。判断模型改写成本账写的是下面这六个行项目成本维度通用生成式方案判断型模型方案变化方向单次调用的 Token 成本高长输入 长输出低结构化特征 短标签显著下降端到端延迟数百毫秒到数秒通常几十到两百毫秒明显下降模型输出解析成本需要写解析器处理自由文本天然 JSON直接消费下降提示词工程成本高改动频繁且脆弱低但需要调阈值和特征转移人工复核成本每一条 AI 输出都得读一遍只复核低置信度样本下降审计与合规成本难需保留完整对话记录易自带 label 和置信度字段下降要注意的是判断模型把成本从一个口袋挪到了另一个口袋——它省掉了生成和解析的开销但引入了阈值校准和漂移监控的工作。这不是“零成本”而是“把成本换到更可控的地方”。3.2 用数字算一遍每天 100 万次判断调用我拿一个真实的测算模型来说。假设有一个数据库同步服务每天要处理 100 万次 schema 冲突判断。用通用大模型方案一个请求平均 1500 Token 输入加 300 Token 输出用 Jev 这类判断模型输入压缩到核心结构信息约 400 Token输出不到 50 Token。假设两者 Token 单价差异不算太大仅以 Token 量来看就是 1800 比 450差 4 倍。再加上两个隐性放大因素一是通用模型的 P95 延迟高调用端超时后会有重试重试本身又产生新 Token 费用二是通用模型的输出是自由文本为了安全起见代码里往往还要加一层校验逻辑无效输出只能重试。这些因素叠加起来实际降本幅度经常能到 6 到 10 倍而不是理论上的 4 倍。可能有读者会质疑那判断模型的准确率够用吗这里要分清一个概念判断模型的目标不是取代所有人类判断而是把确定性高的部分自动处理掉。一个 95% 准确率的自动裁决配合 5% 的随机人工抽检已经能压过手工处理全量数据的效率了。关键是让那一小撮“高价值错误”被兜住而不是追求 100%。3.3 隐性成本从提示词工程迁移到阈值校准刚才提到成本转移细说一下这一块。通用大模型的隐性成本是提示词工程同样的任务今天加一句“请用中文回答”明天换一个 prompt 模板输出格式可能完全漂移评估集和回归测试跟着遭殃。判断模型的隐性成本则在于阈值和置信度校准。输出空间小了格式稳定了但“置信度 0.6 算不算可信”这个问题落到每个具体业务里答案不一样。我踩过的坑是拿到一个判断模型默认用 0.5 作为判定阈值上线没几天人工复核率飙到 30%。后来拉出历史日志分析发现这个业务场景下置信度低于 0.75 的样本基本都判不准于是把阈值调到 0.75复核率又跌回 8%。阈值就是这样一个需要跟着业务去调的东西。它比提示词工程可控但也还是一门手艺活。4. 接入 Jev 这类判断模型的实战过程4.1 从“聊天对话”到“函数调用”的思维转换我在接入 Jev 这类模型时遇到的第一个损耗不是技术问题而是思维惯性。团队习惯了把模型当成一个“会聊天的服务”一切交互都要走到聊天接口上输出还得用流式、用 SSE 推到前端。接入判断模型之后我发现完全不需要这套东西。它本质上是一个函数调用给它一个固定结构它返回一个固定结构仅此而已。用 Python 写一个最简调用大概长这样import httpx def ask_jev(payload: dict) - dict: resp httpx.post( https://api.example.com/v1/judgments, json{task: payload[task], input: payload[input]}, headers{Authorization: Bearer your-token}, timeout5.0, ) resp.raise_for_status() return resp.json() payload { task: db_sync_conflict_arbitration, input: { source_schema_version: v3.2.1, target_schema_version: v3.3.0, conflict_type: column_renamed_with_drop_default, rows_affected: 12580 } } result ask_jev(payload) decision result[judgment][label] score result[judgment][confidence] print(decision, score)这段代码的背后是产品层面的思路转变把 AI 当作业务函数而不是会话对象。老是把 AI 当人聊软件逻辑就很难往工程化方向走当它是一个普通的系统组件之后重试、熔断、监控、回归测试全部可以套用现有的工程体系。4.2 三个工程细节幂等、版本、兜底接入过程中有三个细节直接影响系统稳定性。第一个是幂等。判断接口必须带上 request_id下游拿到结果后即使重复执行也不会产生重复动作。比如数据库同步同一个 request_id 对应同一个 schema 冲突无论调用多少次都应该返回一样的结果。这个字段放在 meta 里配合日志追踪出问题能一路查到源头。第二个是版本。判断模型和它依赖的特征版本都要记录在响应里。模型升级后旧数据需要重算新老版本能对照。否则模型偷偷迭代了行为和以前不一样你以为是数据变了查半天查不出原因最后发现是模型版本的问题。这个我在实际项目里被坑过一次之后所有调用都必须带 model_version。第三个是兜底。任何模型都有超时或者不可用的时候要提前定义好超时了默认放行还是默认拦截我的经验是看业务风险。代码评审门禁这种场景默认拦截宁可多人工审一下也不放过工单分类这种场景默认走规则引擎兜底宁可不自动分也不要卡住整个队列。这个决定必须在开发前定不能等到线上才拍脑袋。4.3 上线顺序影子模式、小流量、全量最后分享一下上线的节奏。我强烈建议不要一上来就切生产流量至少跑两周影子模式。所谓影子模式就是把真实请求复制一份发给判断模型但结果只落库、不参与业务决策。这一阶段要做的就是把模型输出和最终真实结果放在一起算出准确率、召回率。等影子模式的数据显示效果符合预期再切 10% 流量灰度。灰度期间重点关注人工复核率有没有异常升高毕竟模型可能把几万个样本判得很机械但人工复核率突然暴涨就是信号。两周之后稳妥了再全量切换。我用这个节奏上线过几个系统最深的体会是前两步省下的钱会变成上线后省下的夜班电话。架构上的从容是拿流程换来的。5. 判断模型踩坑实录它错得和生成模型不一样5.1 高置信度不等于准确校准问题通用大模型出错的方式是答非所问或者编造事实判断模型不一样它出错的方式是自信地错。我遇到过最典型的情况模型对某个样本给出 96% 的置信度结果该归 A 类的案例它判决成了 B 类。单看一次没什么但如果系统把这个高置信度当成免检通行证错误就会悄悄进入下游不被任何人发现。解决这个问题靠两件事。第一件事是攒样本画校准曲线把模型置信度分桶比如 0.9 到 1.0、0.8 到 0.9 这样一档档切开看每一档桶里的实际准确率。如果 0.9 以上的桶实际准确率只有 82%说明模型过度自信阈值再怎么调也没用。第二件事是必要时做置信度校准把模型原始分数调整到更贴近真实概率。别迷信模型打印出来的置信度它只是一个信号不是真相。5.2 数据漂移业务变化后灵敏度的“温水煮青蛙”数据漂移是判断模型最隐蔽的坑。通用大模型的漂移现象比较明显——如果输入数据变了你很快会从输出内容的风格变化里感觉到。但判断模型输出只给一个标签数据变了它可能依然是那个标签只是判断的内在依据变了准确率慢慢掉没有任何人注意到。我处理过的一个告警收敛项目就是这样。一开始指标很正常上线两个月后人工复核率开始缓慢爬升从 6% 涨到 12%再涨到 18%。如果不是因为复核率有数字可看这个退化过程几乎不可见。后来发现是业务系统改版日志字段的格式变了判断模型基于的特征分布整体偏移。从那之后我养成了给判断模型加监控的习惯标签分布变化、置信度分布变化、人工复核率变化三个指标至少要盯住一个。具体做法很粗暴设一个基线偏差超过一定程度就触发告警让工程师重新检查特征和阈值是否还适用。5.3 阈值需要为业务“量体裁衣”最后一类坑是把阈值当成模型自带属性。实际上阈值完全是业务决策不取决于模型本身。我列一个常见的权衡表业务场景漏判后果误报后果阈值倾向生产故障转移服务不可用损失大切换成本高但可恢复中高宁可有误切也怕漏代码高危变更识别高危改动上线出事故影响开发效率多一次复核高宁睡勿漏工单自动分类转错组处理时间变长也无非是多转一次单中两边都可接受广告违规初筛违规素材流入投放误杀正常素材用户投诉低宁放过不误伤先算清楚漏判和误报各自的经济成本再去定阈值而不是随手拿一个 0.5 或者 0.7。我自己的经验是阈值定完之后要留一个评估集每次调整都要看准确率和召回率两个方向的变动否则很容易为了追求一个数字牺牲另一个数字。6. 哪些场景不应该用判断模型边界画清楚6.1 适合与不适合的判断条件聊了这么多判断模型的优势也该把边界画清楚。它适合的是有限标签、需要低延迟、可兜底的任务它不适合的是需要长文本产出、复杂推理链、开放语义表达的任务。适合不适合分类与路由工单、告警、邮件开放式写作、创意内容生成门禁判断代码、配置、变更是否高危长文档摘要与翻译开关决策是否重试、是否切换、是否告警复杂推理、多步骤逻辑推导异常初筛交易疑似风险、日志异常需要向用户展示完整解释链的场景规则引擎的语义补充高情感浓度的对话陪伴场景这段表格背后有个判断原则如果业务最终动作可以被压缩成有限个选项而且允许出错后再补那么判断模型大概率适合如果业务本质就是“帮用户把一件事做完整”那还是老实去用通用大模型。6.2 我的选型问题清单5 个问题团队要决定是否接入判断模型时通常拿着这 5 个问题过一遍就能得到结论业务最终动作是否可以压缩为有限的几个固定选项如果答案是“得看情况”说明输出空间不够窄判断模型帮不上忙。判断错误是否有人工或规则兜底没有兜底的任何模型都不该直接上生产。用户是否把“解释过程”当成产品体验的一部分如果必须展示分析长文判断模型没办法独立扛事。调用量是否大到值得单独接入低并发的内部小工具用通用大模型手动判断成本可能还更低。团队能否维护阈值和监控指标判断模型的优化节奏完全围绕这两个东西没有人盯就会慢慢腐烂。这 5 个问题里第 4 个最容易被忽略。判断模型的价值是规模化之后才凸显的一天几百次调用的场景没必要专门引入一套工具链。6.3 落地建议与最后一点体会如果看完这篇文章你也想把 Jev 这类判断模型引入自己的软件系统我的建议是别搞“AI 大改造”。找一个最痛的单一场景最好是一个每天要重复上千次、当前靠规则和人工硬扛的决策点比如告警收敛、工单路由、数据库同步冲突仲裁先用两周影子模式验证效果。跑完再决定要不要扩大范围。我个人的实际体会是以往做 AI 集成总觉得要设计一个够酷的对话入口用户才能“感觉”到 AI 存在。但 Jev 教会我最重要的一件事好的 AI 很可能是不说话安静地在每个业务流程的入口处帮你把该放行的放行、该拦截的拦截。它不写一个字软件的成本账却真的被改写了。