用概率分类模型为编码助手分配算力

给编程 AI 前面再放一个 AI，不是让它多写一轮方案，而是让它先判断：这条需求该用哪个模型、该选哪个技能。作者在 Claude Code 中接入了 TypeSafe 的 Jev，用带概率的结构化判断辅助分流。

这套实验值得看的地方，是它怎样限制判断器的权力：低于 60% 就不建议，超过 2.5 秒就放弃，高风险任务仍由主模型处理。它展示了一种可参考的工作流，但没有证明模型选得更准，也没有给出省钱的对照数据。

为什么有些 AI 决策只需要一个选项

Jev 被 TypeSafe 称为 System One 模型。按原文描述，它不生成长篇回答，而是返回带类型的判断与概率：是非题返回 0 到 1 之间的数值，选择题返回选项及各选项的概率，评分题返回分数。

这种输出适合直接写进程序分支。程序不用从一段解释里提取「应该选哪个」，而是检查返回值，再决定下一步。

作者把它接入了两个 Claude Code hooks。Hook 可以理解为消息提交时触发的脚本，每次提交消息都会执行判断。

第一个是模型路由器，把请求分成四档：

• tiny：查询信息、重命名等小任务。
• everyday：常规的单项修改。
• large：多步骤实现，或涉及多个文件的功能。
• hardest：策略判断，或做错代价很高的任务。

四档从最小模型映射到最强模型。原文没有列出具体模型名，也没有交代映射配置，不能据此推导哪种模型最适合哪档任务。

第二个是技能选择器。它把用户消息和已安装的技能列表交给 Jev，让它选择匹配的技能，同时返回各选项的概率。

作者看重的并不是路由器比自己更会选，而是每条消息都能低成本地完成一次明确选择，减少反复手动判断的负担。

真正让路由器可用的是退出机制

判断器能否可靠退出，比它能否每次给出答案更重要。

作者设置了 60% 的置信度门槛：最高概率低于这个值，hook 就不输出建议。但这只是他们采用的阈值，原文没有解释为什么是 60%，也没有给出阈值测试结果。

另一层保护是失败放行（fail open）。报错、超时或答案格式不合规时，hook 输出为空，消息照常到达编程代理。每次判断只有 2.5 秒预算，耗尽就放弃。

所有返回结果还要验证类型、选项是否属于已知集合，以及概率是否合法。结构化输出方便程序使用，却不能省略校验。

更关键的是权限边界。路由器只建议，不覆盖工作流里的强制规则。涉及资金、账本、迁移和认证的任务，无论它如何分类，都留给主模型处理。

隐私和费用也被纳入设计。两个 hook 默认关闭，只有输入 router on 或 skill picker on 才启用。启用期间，每条消息都会发送到第三方 API；作者认为公开开发停车应用可以接受，私密内容则不适合。

Hook 不记录输入文本，只记录决策和数值，但这不等于消息没有离开本地。费用方面，作者使用少量预付额度，账户不绑定银行卡。余额耗尽后，hook 继续按失败放行处理。

我的判断

我认同把简单决策从长篇生成中抽出来，尤其是选模型、选技能这类候选集合明确的任务。结果容易检查，也方便观察它为什么选择或退出。

但返回概率，不等于概率已经校准。 校准的大意是：长期来看，那些被标为 80% 把握的判断，是否真的约有 80% 正确。原文没有提供这类验证，也没有报告路由准确率、延迟分布或整体成本变化，因此「便宜、快速」目前只能视为作者的经验判断。

与关键词规则相比，模型可能更能处理表达变化，但也增加了第三方调用、等待时间和误判来源。与手动选模型相比，它减少操作，却未必提高选择质量。候选项少、规则稳定的团队，先写确定性规则同样合理。

还要分清实验落点：作者曾获准在 ParkEase 的 API 和 job worker 中使用 Jev，例如给支持工单分类，但这些功能没有上线。这个面向印度的点对点停车市场由作者独自使用 Claude Code 开发，产品目前没有 Jev 调用，实际使用发生在开发工作流里。

文末提到的 55 次会话技能统计，是下一篇的预告，不能拿来证明当前路由器的效果。

能拿来做什么

• 如果你经常在重命名、常规修改和跨文件功能之间切换，可以参考四档分类，先把团队的模型选择标准写清楚，再判断是否需要自动路由。
• 如果准备在 Node 脚本或 Claude Code hook 中接入判断模型，应同时实现类型校验、合法选项检查、超时退出和失败放行，让服务故障时消息仍能正常提交。
• 将资金、账本、迁移和认证任务写成明确的强制规则，并先确认源码和需求能否发送到第三方，再决定是否启用判断器。