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