用途
TypeSafe 让 AI 智能单元像编程原语一样被使用：它们是可组合成更大能力的小型判断。其 System One 模型返回快速、聚焦的判断，软件可以直接消费。Jev 是 TypeSafe 的旗舰模型，也是首个 System One 模型。它理解自然语言，返回带类型的答案和概率，而不是生成文本或推理说明。代码拥有工作流，模型在普通代码需要语义理解的地方提供可编程的常识。
主要能力
- 编程模型：System One 与构建指南，把 AI 判断当作可组合原语。
- 三类判断原语：
- Choice：从已定义集合中选一个选项，其分布用于比较竞争选项。
- Noul：判断某条件是否成立，返回“是”的概率；没有单独的置信度；当多个标签可能同时适用时，每个标签使用一个 Noul。
- Score：沿所描述维度给出程度，返回有序层级上的概率加权位置；对可比较的逐项 Score 可用于分级排序。
- 输入与问题设计：为每个问题提供足够的、相关的状态（源文本、身份、关系、策略、当前事实）。上下文包含多个部分时优先使用具名 JSON 字段。把判断写在指令中，把可能答案定义在 criteria 中。问题 ID 供代码使用，不发送给模型；问题本身要包含完整含义。嵌套状态用反引号路径引用，如 ticket.messages[0].text。
- 组合与验证：对同一状态可同时提出相互独立的问题（包括有用的推测性问题），它们并行运行且彼此看不到对方的答案。推测性前提要显式陈述，代码消费适用的答案。当需要先前答案来获取证据、构造新状态或确定下一步选项时，才发起第二次请求。
- 不确定性与置信度：用概率和置信度指导行为，阈值应在用户数据与后果上评估。Choice/Score 的置信度概括的是分布集中度，不代表整个工作流的正确性或行动许可。Noul 接近 0.5 表示“是”与“否”概率相近，而非中等强度。多个可接受备选也会分散概率；低置信度不一定使无害的偏好选择失效。未使用分支上的不确定性可忽略。
- 策略与复用：保持策略显式、原始判断可复用。加权分数适合可补偿的偏好；“任何严重违规”规则需要单独条件。当证据与问题含义不变时，改变权重或显示过滤无需重新推理。带类型输出保证的是接口，不是真实性。System One 模型为校准决策而训练，仍需在目标领域验证其表现。
使用方式
实时 TypeSafe 文档是权威来源，应作为任务的一部分阅读。该技能给出方向；文档承载当前概念、提示指南、API 契约、SDK 用法、模型、限制与示例。
- 从文档索引开始，发现相关页面与 cookbook。使用定向阅读，而非加载整个站点。
- Mintlify 通过在页面路径后追加 .md 提供 Markdown，例如如何用 TypeSafe 构建。跟随索引中的链接；需要时把无扩展名的文档页链接转换为 .md。相对链接以 https://docs.typesafe.ai 为基准解析。
- 编写集成前，阅读当前 API 或所选 SDK 页面，以及与设计相关的问题指南。对于新工作流，还要查看最接近的 cookbook：它常能给出比通用分类器更好的分解方式。
- 若索引不可用，使用下方直接链接或站点导航。若 Markdown 获取失败，尝试普通页面。若无法实时访问，使用可用的本地文档或已安装 SDK 类型，说明该限制，并避免编造依赖版本的细节。
按任务选择起点：
- 理解编程模型：System One、构建指南。
- 探索可构建内容：用例地图，然后从索引中找相关 cookbook。
- 准备输入与问题：State、primitives，然后所选原语的页面。
- 决定如何处理不确定性：Confidence。
- 编写 API 代码：HTTP API、Python SDK 或 JavaScript SDK。
- 更新旧集成：迁移指南与已安装 SDK 的当前参考。
寻找有用形态：从用户想要的行为出发——应用将展示、选择、更改或交接什么？再倒推它需要的判断。把已知规则、计算、精确查找与执行留在代码中。保留用户选定的技术栈与范围；在语义理解有帮助处加入 TypeSafe。
头脑风暴或选择架构时，考虑分类之外的模式：
- 路由并填充已知参数：一个请求可选择处理器及其带类型参数。预先提出有用的分支特定问题，只消费相关答案。可探索函数调用与推测性扇出。
- 选择而非生成：在代码中找到候选值或源片段，用判断选出意图中的那个，再复制或规范化。代码也可把源文本组装成格式化文档或阅读指南。可探索值提取与结构恢复。
- 查找并判断证据：检索候选，比较其与查询的相关性，选出有用上下文。可探索重排序与分层分类。
- 把判断变成可复用数据：对维度评分一次，再让代码或用户控件改变权重、阈值、排名与视图。有标注结果时，这些信号可成为经典 ML 特征。可探索复合评分与特征发现。
- 验证并升级：对照证据检查具体主张或字段；把不确定或失败的案例交给人工或推理模型。可探索引用检查与提取级联。
- 响应变化的状态：代码可保留目标与观察，同时新鲜判断指导下一个有界步骤。把推断状态与观察到的事实区分开，在把结果应用到已变化的情境前检查新鲜度。
对于开放式请求，给出最符合用户目标的少数方向并推荐起点。对于具体请求，选择相关模式并构建；头脑风暴不是必须的绕路。
设计判断时按答案含义选择原语，然后阅读相关原语页面。给每个问题足够的相关状态以作答。每个问题只问一个狭窄、连贯的判断。拆分独立有用的维度，但不破坏被判断的关系。有界动作选择或情境解释是有效的；原子不等于字面事实提取或一句话限制。简单问题可用字符串。当定义、对比、排除或示例能澄清指令或 criteria 时，使用结构化对象或数组。Score 层级必须描述具体情境并能独立成立。
保持所需答案可用。当可能都不匹配时，加入无匹配结果；当“存在性”独立有用时，使用单独的 presence 判断。对于源值选择，检查候选覆盖：模型无法选择被省略的值。
适用场景
- 需要语义理解但希望由代码掌控工作流的软件集成。
- 路由请求并填充带类型参数。
- 从候选中选择意图值，而非生成文本。
- 检索候选并判断相关性、重排序、分层分类。
- 对维度评分一次，再通过权重、阈值、排名与视图复用。
- 对照证据验证主张或字段，并把不确定案例升级给人工或推理模型。
- 在状态变化时，用新鲜判断指导下一个有界步骤。
限制
- 带类型输出保证的是接口，不是真实性。
- System One 模型为校准决策而训练，仍需在目标领域验证其表现。
- Choice/Score 的置信度只概括分布集中度，不代表整个工作流的正确性或行动许可。
- Noul 接近 0.5 表示“是”与“否”概率相近，而非中等强度。
- 额外问题仍消耗 token；应测量实际请求预算、成本与端到端延迟。
- cookbook 阈值与演示结果只是待评估的示例，不是通用规则或永久模型限制。
- Web 应用中 API 凭据应保留在服务端。
- 若无法实时访问文档，应使用可用的本地文档或已安装 SDK 类型，说明该限制，并避免编造依赖版本的细节。
- 关于具体收费、价格、平台支持范围，资料暂未提供。