Jev 官方入口清单：别只看 193.6x，把官方示例数字复算一遍

先说结论

1. Jev 官方入口已经能凑成一套“快速上手链路”：官网 → 文档 → llms.txt → 控制台。其中 docs.typesafe.ai 和 console.typesafe.ai 是最值得收藏的两个。
2. 官方首页标题写着 193.6x Faster、444.6x Cheaper，但用同页示例框数字做除法，速度比约 75.1x、成本比约 171.4x（自己推算）。两者并非同一口径，脚注已经提示基于 System One tasks (proof) 工作流。
3. 工单里“llms.txt 只有 5 个页面”的说法与官方文件实际内容不符；我打开后看到的是完整文档索引，条目数量远超 5，因此不采用“文档很薄”这个结论。
4. 第三方基准 jev-benchmark 在 60 例工具调用风险分类上显示校准总体可信，但样本量小且没有前沿 LLM 基线，只能当早期信号。
5. 对新模型，先找“可跑的 artifact”（代码仓库、脚本、真实账单），再看分数；没有 artifact 的基准宣传，打折听。

入口清单：官方资源逐条过

这里只列我实际打开并确认可达的官方入口，不补猜测链接。

其中 Manifesto 的独立链接我未在官方首页抓取中直接拿到，但社区整理 list 中给出了 https://typesafe.ai/manifesto，属于二手整理转引，请以官网为准。团队页也只能从首页导航进入，未能核实独立 URL。

llms.txt：工程友好的入口，但不是“只有 5 页”

https://docs.typesafe.ai/llms.txt 是官方文档的机器可读索引，格式为 Markdown 列表。我打开后看到的是从 Introduction、Quick start、System One、State、Primitives，一直到 Python/JavaScript SDK 的 API 类和方法，条目数量远超 5（粗略计数 30+，自己推算；官方数据未给总数）。

这里必须纠正工单中的一个说法：工单提示“llms.txt 只有 5 个页面，说明官方文档很薄”。这与实际内容不符。我核对后认为这个说法不成立，因此正文不采用“只有 5 页”这一结论。官方文档确实不算厚，但也不是 5 页能概括的。

给 AI 编码工具用的正确姿势：把这个文件内容贴给工具，或者直接告诉工具去抓 https://docs.typesafe.ai/llms.txt，然后用官方 quick start 开始跑。

复算：193.6x 和 444.6x 与示例框数字不是一个口径

官方首页（https://typesafe.ai/）同时给出了两个东西：

• 标题倍数：193.6x Faster, 444.6x Cheaper（官方数据）
• 示例框数字：TypeSafe AI Cost $0.000081，Completed in 0.114s；LLMs Cost $0.013880，Completed in 8.566s（官方数据）
• 脚注：*based on workflows for System One tasks (proof)（官方数据）

很多人看到这两个数字会误以为 193.6 和 444.6 是从示例框两个数字相除得来的。用示例框数字做除法，结果如下：

# 官方首页示例框数字（官方数据）
ts_time   = 0.114     # 秒
llm_time  = 8.566     # 秒
ts_cost   = 0.000081  # 美元
llm_cost  = 0.013880  # 美元

speedup   = llm_time / ts_time    # 速度倍率（自己推算）
costup    = llm_cost / ts_cost    # 成本倍率（自己推算）

print(f"速度倍率 ≈ {speedup:.1f}x")
print(f"成本倍率 ≈ {costup:.1f}x")

输出：

速度倍率 ≈ 75.1x
成本倍率 ≈ 171.4x

这两个结果（自己推算）与标题的 193.6x、444.6x 明显不一致。所以标题倍数不是示例框两个数字的商，而是来自另一些“System One tasks (proof)”工作流。官方没有在首页披露这些工作流的具体任务集和计算方法，仅用脚注提示口径差异。这是本次复算最重要的观察：别拿示例框当标题倍数的证明。

社区资产：可复现的基准与资源整理

第三方基准仓库 themsquared/jev-benchmark（https://raw.githubusercontent.com/themsquared/jev-benchmark/main/README.md）给出了一套可复现实验：60 个手工标注的 agent 工具调用风险分类案例，分为 readonly、destructive、privileged、exfiltration 四类，其中 34 clear、14 ambiguous、12 adversarial。该仓库明确说明不是为了复现厂商倍数，而是验证一个更操作性的问题：如果要把 Jev 放在 agent call path 上，置信度是否值得做路由？

其报告的关键结果（社区二手，非官方，复现时请自己跑）：

• 准确率：两种模型均 91.7%（55/60）
• clear 切片：100%
• ambiguous 切片：71.4%
• adversarial 切片：91.7%
• 延迟 p50：约 421.6 ms / 378.5 ms
• 单次成本约 $0.0000173
• 校准结果：所有错误答案都带有 hedge 过的置信度，未出现置信度 1.000 却答错的情况

这个校准结果是该仓库最看重的发现，但作者自己也在 README 里提醒：样本量 n=60 太小，且 0.9–1.0 置信区间占 50/60，大部分 ECE 由单一 bin 决定；此外没有 frontier-LLM 基线，所以不能支持或反驳厂商的速度/成本倍数。我同意这个判断：这是一份有用的早期信号，但别当成定论。

社区整理 AbdelStark/awesome-typesafe（https://raw.githubusercontent.com/AbdelStark/awesome-typesafe/main/README.md）是另一个导航入口，但它明确标注“非官方、未被 TypeSafe 审核”。里面列出了不少官方资源链接，也包含第三方 SDK、browser agent、金融交易、游戏机器人等项目。它适合用来快速看社区已有哪些尝试，但引用前必须区分哪些是官方、哪些是三手。

自己的判断：先找 artifact，再看分数

我的判断很简单：一个新模型值不值得试，按这个顺序来。

1. 是否有官方 quick start 能跑通：https://docs.typesafe.ai/introduction/quickstart（官方）。
2. 是否有可复现的第三方 artifact，例如 jev-benchmark 这种带 tasks.jsonl、bench.py、原始结果 CSV 的仓库（社区二手）。
3. 是否有人贴真实账单或物理测试。本批来源中未找到“物理 AI 实测仓库（真实账单）”的直接链接，因此暂不纳入判断。
4. 是否能看到对比基线和同一任务定义。没有同口径对比的倍数宣传，先不要写进采购评估表。

按这个标准，目前 Jev 值得花一个下午做 quick start + 跑一遍 benchmark，但不建议直接上生产。校准看起来有潜力，但需要更大样本、更多任务类型、以及至少一个 frontier LLM 基线。

这次没核实的

• Our Team 的独立 URL 未能核实，只能通过官网首页导航进入。
• 工单中“llms.txt 只有 5 个页面”的说法与官方实际内容不符，弃用。
• 标题倍数 193.6x 和 444.6x 对应的具体工作流、任务集、模型版本，官方首页未披露，未能核实。
• 物理 AI 实测仓库（真实账单）未在本批来源中提供，未能核实。
• pricing 页面是否 404，本批链接中未包含 /pricing，未能核实。

参考来源

• 官方首页（含倍数与示例框） — 一手
• 官方文档索引页 — 一手
• 官方 llms.txt（页面清单） — 一手
• 第三方基准仓库 jev-benchmark — 社区二手
• Awesome TypeSafe（社区整理，非官方） — 二手整理