
名称	jev-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 凭据保存在服务器端。