先说个我一直没想通的坑
上个月我给一个内容工具加过滤逻辑，需求特别简单：判断一条用户投稿是不是广告，只要一个是或否。我当时的写法是让模型返回 `{"is_ad": true, "reason": "..."}`，然后我再去解析这段文字。
跑了两天，问题全冒出来了。有时候模型多加个换行，有时候 reason 里带了引号把 JSON 撑坏，有时候干脆返回一句「好的，我来帮你判断」。
我写了一堆容错代码去修它的格式，越修越像打地鼠。
后来我停下来想了想：我要的其实就是一个真假值，为什么要让模型先写一段作文，我再从作文里抠答案出来？这一步到底是必要的，还是我自己给自己找的麻烦？
一条量化资料，点醒了我
最近翻到一篇拆解 Jev 的文章，讲的是量化场景，但里面一个观点我觉得对做应用的人更有用。它说 Jev 只有三种问法：选择题、打分题、判断题。
- 选择题：从预定义选项里选一个，返回选项和概率
- 打分题：按评分标准打分，返回分数和概率
- 判断题：判断一句话是真是假，返回一个 0 到 1 的概率
关键那句话是：没有格式需要修复，没有文字需要解析，没有 token 需要逐个生成。答案空间本身就是模型输出的一部分。
资料里还有个细节我印象很深。你让模型判断一条新闻是利好还是利空，传统做法是它逐字生成 `{"sentiment": "positive"}`，再解析取出 positive。
三选一的判断，它写了十几个字，每个字都要走一遍完整的生成过程。
看到这我一下子就对上号了。我那个广告过滤，本质上就是个判断题，我却让它按「写作文」的模式在跑。
这个思路对独立开发者到底意味着什么
说真的，Jev 这类东西大部分人接触不到，量化回测那段（资料里 BTC 回测 AUC 0.471–0.503、订单簿 339 次命中率 67.8% 扣费后净亏 -62.69）也跟做应用的我们没啥关系。但它背后那个判断方式，是可以直接搬进日常开发的常识：
先分清楚，你这个需求到底是不是判断题。
我后来把手里的功能过了一遍，发现能归成「判断/分类/打分」的，比想象中多得多：
- 内容审核：是不是垃圾、是不是广告、要不要人工复核
- 意图识别：这条留言是咨询、投诉还是闲聊
- 优先级打分：这个工单急不急，给个 1 到 5
- 分流路由：这个问题该丢给哪个处理分支
这些场景的共同点是，最终我只需要一个标签或一个分数，模型给我的那一大段解释文字，我根本不看，还得花代码去清洗它。
反过来，哪些任务千万别这么做
这里得说清楚边界，不然容易走偏。不是所有任务都适合压成判断题。
凡是用户要读模型输出的场景，就必须让它正常表达。比如给用户写回复、生成摘要、解释一个报错、陪聊——这些内容本身就是产品价值，你把它压成一个标签就没意义了。
还有一类是我自己踩过的：需要模型给出推理过程你才能信任结果的场景。判断题给你一个是或否，但它凭什么这么判断你是不看不到的。
资料里那篇文章也提醒过一个更狠的点——模型说的置信度本质是个语言现象，它可能在完全不确定时照样输出「置信度 0.95」，只是在预测「下一段文字看起来像不像一个高置信度的回答」。这个具体的校准方法资料里也标了没有公开、不可验证（待核实）。
所以我的判断是：低风险、高频、结果我自己消费的分类打分，往判断题方向做，省钱又稳；高风险、要给用户看、要能审计的决策，老老实实让模型正常表达，别图省事。
用平台能力怎么落地，我是这么搭的
落到 VicroCode 上，这套东西不需要什么复杂架构。核心就两步：调模型出判断，把结果存下来做核对。
第一步，调模型这块我直接用Python在线运行写一段脚本，通过模型中心 API 去调平台已接入的模型。提示词我写得很死，明确告诉它「只返回一个词」或者「只返回 0 到 1 之间的数字」，不给它发挥空间。
返回内容我做一次严格校验，不符合格式的直接当异常处理，而不是想办法去修。
这里有个我踩过的小教训：与其在提示词里求它「请务必只返回 JSON」，不如把选项收窄到极致。选项越少、越明确，模型跑偏的概率越低。
第二步是核对，这一步很多人省了，但恰恰是它让整套东西能用起来。我把每一条判断的输入、模型给的标签、当时的时间，都写进 SQLite，用SQLite编辑器直接看表结构，抽几十条人工过一遍，看模型判错的都是哪一类。
这样我才知道我的过滤器到底靠不靠谱，而不是拍脑袋觉得它准。
跑通之后，这套判断逻辑可以包成 API 端点托管起来，或者做成站内工具给别的应用调，也能直接发布分享出去。
一个我没料到的反转
本以为把判断做轻，最大的收益是省 token、省钱。真跑起来发现，更值钱的是那张核对表。
因为判断类任务有明确的对错，我能把模型的输出和我人工标的答案摆在一张表里直接比。这让我第一次能量化地说「这个功能准确率大概多少」，而不是凭感觉。
资料里那些量化项目亏钱，很大原因就是把一个概率当成了策略，从来没在数据层验证过它到底有没有预测力。做应用同理，你不核对，就永远不知道那个是或否是真的能用，还是在给你添乱。
今天就能动手的一件小事
打开你手上的产品，找一个正在让模型生成 JSON 再解析的地方，问自己一句：我最后真正用到的，是不是就一个标签或一个分数？
如果是，就把提示词改成只让它返回那个值，跑一百条存进表里，人工抽查一遍准确率。就这一步，你大概率会发现原来那堆格式清洗代码，可以删掉一大半。