Jev

模式与 fan-out

已发布的组合模式与TypeSafe决策示例。

TypeSafe 发布了四种组合模式：speculative fan-out、置信度门控路由、组合评分和意图路由。它们都将控制流保留在代码中。文档要求掌握的核心能力，是把问题拆成可组合的原子决策来思考。请先阅读 Primitives 和置信度页面。本页索引这四种模式，并列出 Jev 可参与的软件决策用例，从工单路由、理赔，到防护规则、搜索和游戏。建议从 fan-out 开始。

四种已发布模式

推测式 fan-out：在一次调用中发送多个问题，其中包括推测性问题，再由代码判断哪些结果相关。TypeSafe 列出的优势是成本和速度。智能家居演示提供了完整示例。对于“关闭房屋中的所有灯”，仍然要同时询问类别、领域、设备和操作；即使尚不知道这句话与灯有关，也要提前加入操作问题。顺序调用需要逐步等待，而并行评估后再用代码筛选正是此模式的要点。

Confidence门控路由：将 Confidence 作为是否执行操作的第二个判断轴。优点是可靠性和安全性。没有 Confidence 门槛时，标签即使面对平坦分布也会触发。请为Choice或Score配置随风险提高而收紧的阈值，并让Noul保持为独立维度。

复合评分：把一项判断拆成多个原子 Score，再在代码中按权重组合。优点是成本、可靠性和速度。不要让 Jev 直接给出一个笼统的 1-100 质量分。分别用Score评估证据、政策匹配度和严重程度，再相加。意图路由：对意图分类，并将其路由至业务逻辑、LLM 或人工处理。优点是成本和速度。Jev 只决定运行哪个处理程序；它本身不会变成撰写回复的处理程序。

Four published TypeSafe patterns: fan-out, confidence routing, composite scoring, intent routing
扇出、Confidence 路由、复合评分与意图路由。

推测式 fan-out

做什么
在一次调用中发送多个问题，包括推测性问题。
收益
成本、速度

Confidence 门控路由

做什么
将置信度作为是否执行操作的第二条判断轴。
收益
可靠性、安全性

综合评分

做什么
将判断拆成原子级评分，再在代码中按权重组合。
收益
成本、可靠性、速度

意图路由

做什么
分类意图，并路由至逻辑程序、LLM 或人工。
收益
成本、速度
决策类别Jev 判断什么
客户支持automation分类工单、检测紧急程度和退款诉求，并路由到相应队列。
保险理赔automation分类首次损失通知记录，并升级高风险理赔。
金融犯罪automationScore 警报叙述，并路由含糊的 KYC 案例。
电商平台automation规范商品信息，并标记违禁品或假货信号。
内容审核与信任安全automation按严重程度应用公司专属的审核标准。
广告automation检查品牌安全及广告与落地页的一致性。
游戏automation审核聊天内容、评估挫败程度，并路由玩家支持请求。
招聘automation依据明确且与岗位相关的标准 Score 简历。
潜在客户开发automation将资料与理想客户画像匹配，并路由购买意图。
模型路由automation选择由哪个 LLM 接收各条提示词。
LLM 护栏automation检测越狱、注入和政策违规行为。
搜索与检索automationScore 查询与候选结果的相关性，并重新排序。
特征提取automation将语言转换为供传统机器学习使用的概率特征。
风险评估automation将事件记录转换为概率型风险指标。
图与知识图谱automation分类关系并检测矛盾。
语义代码检查automation在 CI 中运行团队专属的语义检查。
需求预测automation提取意图和紧急程度特征以用于预测。

用例图中的决策示例

TypeSafe的用例图列出的是行业示例，而非第二套 Primitives。客户支持可分类工单、检测紧急程度和退款情况，并路由队列。保险理赔可分类首次损失通知记录，并升级高风险档案。金融犯罪防控可为警报叙述评分，并路由模糊的 KYC 案例。法律与合规可检测缺失条款和禁止性声明。电商平台可规范商品信息并标记假货信号。

内容审核可按公司专属标准及严重程度处理。广告场景可检查品牌安全和广告与落地页的一致性。游戏场景可审核聊天、评估挫败感并路由玩家支持。招聘场景可按明确的职位相关标准评估简历。潜客开发可将客户资料与 ICP 匹配。模型路由可选择由哪个 LLM 接收提示词。LLM 护栏可检测越狱、注入和政策违规。

搜索与检索可评估查询和候选项的相关性。特征提取可把语言转换为供传统 ML 使用的概率特征。风险评估可把事件记录转换为指标。图谱可分类关系并检测矛盾。语义代码检查可在 CI 中执行团队专属检查。需求预测可提取意图和紧急程度特征。每一行代表一种决策形态，而非托管工作流。执行操作的代码仍由你负责。

在代码中组合，不要塞进一个提示词

扇出配合置信度路由是生产环境中的常见组合：提出超出实际所需的问题，丢弃无关的 Noul，然后仅在 Choice 置信度达到高门槛时自动执行操作。当单个 Score 会掩盖三项不同判断时，可在下层采用综合评分。意图路由则作为入口，决定请求的其余部分交给 Jev、LLM 还是人工处理。

evals.typesafe.ai 发布的评测系列包括安全事件、代理轨迹可观测性、发票处理和客户服务。TypeSafe 首页上的 193.6x / 444.6x 数据，来自这些工作流评测与 Astra 和 Fable 平均值的对比。请将其视为 TypeSafe 发布的对比结果，而非本 wiki 复测所得的数据。

如果所需模式不在这四种之中，仍可组合使用基础单元。新的控制流应保留在你的仓库中。如果希望将其加入文档索引，请向 TypeSafe 提交说明。在 TypeSafe 发布另一个具名模式前，额外组合都应留在应用代码中。

为工作流选择模式

当多个问题共用一个 state，且其中一些可能不适用时，优先采用 speculative fan-out。这是助手、工单机器人及所有类似总机系统的默认模式。一旦某个答案可能触发副作用，就应加入置信度门控路由，例如退款、封禁、转账或部署。

当单个 Score 会混合不同维度时，使用综合评分。证据质量、政策符合度和客户问题严重程度应分别作为三个 Score，再由你在代码中进行加权求和。对于还包含 LLM 或人工队列的混合系统，应在边界处使用意图路由，让 Jev 决定目的地，而不是代替目的地完成工作。

本页的 18 个示例决策是 TypeSafe 提供的应用图谱，并非额外端点。客户支持、理赔、护栏、搜索和游戏场景仍然调用 POST /v1/systemone，并传入 Choice、Score 和 Noul。可复用决策结构，但判断标准应来自你的政策文本，而不是通用提示词库。

默认使用扇出。当标签可能导致花钱或封禁用户时，加入置信度门控。如果单个说明会混合不同轴线，就拆分为多个 Score。与 LLM 相接的边界应使用意图路由。这四句话涵盖了全部已发布模式。

用例图谱包含十八种决策结构，而非十八个 API。每一行最终仍会转换为 POST /v1/systemone 上的一个或多个问题。将结构复用到你的业务领域，再依据自身政策编写标准。不属于你政策的通用审核提示词无法匹配此图谱。

推测式 fan-out 的名称也是本页的 H1，因为 TypeSafe 首先介绍的就是这种模式。其余三种模式列在下方，用于处理单次调用返回后的答案。

18 个决策示例共用同一个系列名称 automation，因为它们都是软件判断，并非另一条产品线。

来源