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

使用 TypeSafe 构建

TypeSafe 让 AI 智能单元像编程原语一样可用：你可以将小型判断组合成更大的能力。它的 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 凭证保留在服务器端。