
名称	TypeSafe 系统一模型构建
开源协议	MIT
描述	> 使用 TypeSafe 构建 AI 驱动的软件：小单元的人工智能能力，可以像编程原语一样使用。它的 System One 模型，包括 Jev，将自然语言和应用状态转化为代码可以组合的类型化判断和概率。当某个功能需要可编程的常识、当你在头脑风暴 AI 能为应用带来什么，或者当 LLM 提示并解析步骤可以变成结构化决策时，使用它。应用包括路由、排序、抽取、验证和交互体验；这些只是起点，不是限制。阅读实时文档和 cookbook，寻找有用的模式并发现新的组合。

使用 TypeSafe 构建

TypeSafe 让人工智能能力像编程原语一样可用：你可以把小判断组合成更大的能力。它的 System One 模型 返回快速、聚焦的判断，软件可以直接消费。 Jev 是 TypeSafe 的旗舰产品和第一个 System One 模型。它理解自然语言，并返回类型化答案和概率，而不是生成文本或推理说明。代码掌控工作流；模型在普通代码需要语义理解的地方提供可编程常识。

阅读实时文档

TypeSafe 实时文档是事实来源。请把阅读文档作为任务的一部分。 本技能提供方向；文档承载当前概念、提示指导、API 契约、SDK 用法、模型、限制和示例。

从文档索引开始，发现相关页面和 cookbook。使用有针对性的阅读，而不是加载整个站点。
Mintlify 通过给页面路径追加 .md 来提供 Markdown，例如如何使用 TypeSafe 构建。从索引跟随链接；如有帮助，把无扩展名的文档页面链接转换为 .md。相对链接请基于 https://docs.typesafe.ai 解析。
在编写集成之前，阅读当前 API 或所选 SDK 页面，以及与设计相关的问题指导。对于新工作流，还要检查最接近的 cookbook：它通常展示出比通用分类器更好的分解方式。
如果索引不可用，使用下面的直接链接或站点导航。如果 Markdown 获取失败，尝试普通页面。如果实时访问不可用，使用可用的本地文档或已安装的 SDK 类型，说明该限制，并避免编造依赖版本的细节。

任务	从这里开始；跟随相关细节
理解编程模型	System One、构建指南
探索要构建什么	用例地图，然后阅读索引中相关 cookbook
准备输入和问题	状态、原语，然后阅读所选原语的页面
决定如何处理不确定性	置信度
编写 API 代码	HTTP API、Python SDK 或 JavaScript SDK
更新旧集成	迁移指南和已安装 SDK 的当前参考

找到有用的形态

从用户想要的行为开始：应用将展示、选择、改变或交接什么？反向推导它需要的判断。把已知规则、计算、精确查找和执行保留在代码中。保留用户选择的技术栈和范围；在语义理解有帮助的地方加入 TypeSafe。

在头脑风暴或选择架构时，不要只考虑分类。下面的模式只是起点：围绕用户目标组合原语，包括不符合既有配方的想法。

路由并填充已知参数。 一个请求可以选择处理器及其类型化参数。提前询问有用的分支特定问题，并且只消费相关答案。探索函数调用和推测性扇出。
选择而不是生成。 在代码中找到候选值或源跨度，使用判断选择预期的一个，然后复制或规范化它。代码也可以把源文本组装成格式化文档或阅读指南。探索值抽取和结构恢复。
寻找并判断证据。 检索候选，比较它们与查询的相关性，并选择有用上下文。探索重排序和分层分类。
把判断转化为可复用数据。 对维度评分一次，然后让代码或用户控制改变权重、阈值、排名和视图。有了带标签的结果，这些信号可以成为经典 ML 特征。探索复合评分和特征发现。
验证并升级。 根据证据检查具体声明或字段；把不确定或失败的案例发送给人或推理模型。探索引用检查和抽取级联。
响应变化的状态。 代码可以保留目标和观察，同时新鲜判断指导下一个有界步骤。把推断状态与观察事实区分开，并在把结果应用到已变化情况之前检查新鲜度。

对于开放式请求，提供最符合用户目标的少数方向，并推荐一个起点。对于具体请求，选择相关模式并构建；头脑风暴不是必须的绕路。

设计判断

根据答案的含义选择，然后阅读相关原语页面：

需求	原语	重要区别
已定义集合中的一个	Choice	选择一个选项；其分布比较竞争选项
条件是否成立	Noul	为“是”的概率；没有单独的置信度；当多个标签可能适用时，每个标签使用一个
沿描述维度的程度	Score	在有序层级上的概率加权位置；对每个项目使用可比较的 Score 进行分级排名

给每个问题足够的、相关的状态来回答：源文本、身份、关系、策略和当前事实。当上下文有多个部分时，优先使用命名 JSON 字段。把判断放在 instructions 中，并在 criteria 中定义其可能答案。问题 ID 供代码使用，不会发送给模型；在问题中包含完整含义。用反引号路径引用嵌套状态，例如 ticket.messages[0].text。

每个问题只问一个狭窄、连贯的判断。拆分独立有用的维度，但不要破坏被判断的关系。有界动作选择或上下文解释是有效的；原子并不意味着字面事实抽取或一句话限制。简单问题可以用字符串。当定义、对比、排除或示例能澄清 instructions 或 criteria 时，使用结构化对象或数组。Score 层级必须描述具体情境，并且能够独立成立。

保持所需答案可用。当可能什么都不适合时，包括一个无匹配结果；当存在性判断独立有用时，使用单独的存在性判断。对于源值选择，检查候选覆盖：模型无法选择被省略的值。

组合并验证

对同一状态一起询问独立问题，包括有用的推测性问题。它们并行运行，并且看不到彼此的答案。明确陈述每个推测前提；代码消费适用的答案。当需要较早答案来获取证据、构造新状态或确定下一组选项时，第二次请求是合理的。额外问题仍然消耗 token；测量实际请求预算、成本和端到端延迟。

使用概率和置信度来指导行为，阈值要在用户数据和后果上评估。Choice/Score 置信度总结的是分布集中度，而不是整个工作流的正确性或行动许可。Noul 接近 0.5 意味着“是”和“否”的概率相近，而不是中等强度。多个可接受备选项也可能分散概率；低置信度不一定使无害的偏好选择无效。忽略未使用分支上的不确定性。

保持策略明确，并让原始判断可复用。加权分数适合补偿性偏好；一个“任何严重违规”规则需要单独条件。当证据和问题含义不变时，改变权重或显示过滤器不必重新运行推理。类型化输出保证接口，而不是真相。System One 模型为校准决策而训练；在目标领域验证它们的表现。

测试代表性案例和由此产生的应用行为。对于失败，检查确切状态、问题、候选、答案、组合和观察到的结果。区分缺失证据、模型错误、代码错误和服务故障。把 cookbook 阈值和演示结果视为需要评估的示例，而不是通用规则或永久模型限制。在 Web 应用中，把 API 凭据保留在服务端。