Jev 係 TypeSafe AI 首款 System One 模型：佢面向程式而唔係面向人，目標係喺軟件流程入面迅速做出有結構嘅決策，而非寫一段畀人閱讀嘅文字。TypeSafe AI 喺 2026 年 9 月 15 日開放 Jev 早期存取；呢間三藩市公司由前 OpenAI 研究員 Diogo Almeida 與 Erik Gafni、Sasha Sheng 創辦。216

最大分別：唔係「寫答案」，係「交決定」

大型語言模型（LLM）會逐個 token 生成文字，所以用途很廣：解釋、寫作、規劃、寫程式、回答開放式問題都得。但當軟件要用 LLM 嘅結果去執行下一步時，通常仍要解析自然語言，或者驗證模型生成嘅 JSON。

Jev 做嘅係較窄、但更貼近程式流程嘅工作。程式會送入一段 state（狀態）——可以係文字字串、JSON 物件或文字陣列——再附上有類型嘅問題；Jev 會逐題回傳結構化答案。TypeSafe 嘅 API 文件將呢個流程描述為：以問題對照 state 作評估，每條問題各自得到一個結構化答案。17

現時可用嘅決策形式包括：

• Boolean（布林）：估計一項命題為真嘅機率，例如「呢條指令係咪可以安全執行？」
• Choice（選擇）：喺開發者預先提供嘅選項之中揀一個。
• Score（評分）：按有次序嘅準則或數值尺度打分。

所以 TypeSafe 將 Jev 定位為工作流程嘅「決策元件」，可用於路由、分類、檢索篩選、風險評分同 AI agent 防護欄，而唔係聊天助理。官方文件列出嘅例子包括模型路由、語意檢索、執行軌跡分類，以及檢查其他 AI 嘅輸出。18

「System One」即係咩？

個名取自心理學家 Daniel Kahneman 對兩種思考模式嘅區分：快速、直覺嘅「System 1」，以及較慢、較審慎嘅「System 2」。TypeSafe 用 System One 去形容專注於快速而界線清楚嘅判斷，而唔係開放式推理或寫作嘅模型。16

呢個唔等於 Jev 解決咗通用推理問題。真正意思係佢採用另一種介面：你提供相關狀態同清晰定義嘅決策，佢交返受限制嘅結果同機率分布，而唔係一段長篇說明。

點解受限制輸出對自動化有用？

用 Jev 時，應用程式事先定義輸出形狀；如果係 Choice 問題，亦要列明容許嘅答案。咁樣可減少生成式系統整合時常見嘅問題：模型唔會突然回傳未要求嘅欄位、虛構工具名稱，或者喺程式只期待固定值時輸出一大段自由文字。

不過，呢個係 結構上 嘅保證，唔係「一定正確」嘅保證。受限制嘅決策模型仍然可能喺容許選項之中揀錯、誤解上下文，或者報出喺實際工作流程中校準得唔好嘅信心值。Vercel 亦明確指出：符合 schema 只關乎答案結構；語意上係咪正確，仍然要測試評估。

實際部署時，團隊應該將信心門檻當成需要驗證嘅業務規則，而唔好視為可靠性證明。常見做法係：高信心、低風險嘅個案自動處理；含糊或高影響嘅個案，就交畀 LLM、規則引擎或真人覆核。

訓練同「校準」：TypeSafe 嘅說法

TypeSafe 表示，Jev 只使用合成資料訓練，並採用 Reinforcement Learning for Calibrated Decisions（RLCD）。公司聲稱，目標係令模型報出嘅機率更貼近實際答中率，而唔係優先產生人類偏好嘅書面回覆。

對自動化而言，校準尤其重要：理想情況下，0.9 嘅機率應可幫開發者設定有意義嘅覆核門檻。不過，RLCD 仍未有廣泛公開嘅獨立測試支持；現有材料亦未見 Jev 喺校準度、對抗性穩健度或跨領域準確率方面嘅全面第三方審核。因此，企業仍應按自己要部署嘅資料、任務同決策政策作測試。

價錢、上下文長度同速度

TypeSafe 列出 Jev 1.13 收費為每 100 萬個輸入 token 0.042 美元，即每 10 億個 token 42 美元；輸出 token 免費。按呢個輸入價計，5 美元大約可買到 1.19 億個輸入 token，未計稅項或帳戶個別條款。文件亦列明每次請求上下文長度為 64,000 token，其中 state 最多 32,000 token，另加最長嗰條問題。

公司同早期報道提到，延遲大約介乎 70 至 500 毫秒，視乎工作負載而定。呢啲數字可以作評估起點，但實際延遲會受請求大小、問題設計、地區同服務狀況影響。

Vercel 率先接入

Vercel 已經將 Jev 加入 AI Gateway；開發者可以經實驗性評估 API，以 typesafe-ai/jev 呼叫模型。

Vercel 指出，Jev 推出後 24 小時內，近 13% AI Gateway 付費團隊已經使用，數目超過之前任何模型發布同期付費團隊數量嘅兩倍。 呢個係開發者好奇同早期試驗嘅明顯訊號，但本身唔足以證明長期留存、生產規模可靠性，或者所有工作負載下都優勝。

早期亦有指令安全分類、電郵分類等實驗報告。佢哋有助理解 Jev 針對嘅界線清晰任務，但唔可以代替獨立、受控嘅基準測試。團隊若要同 LLM 比較，應用自身具代表性嘅資料，同時檢驗準確率、校準度、錯誤嚴重性、延遲同整體工作流程成本。

適合邊啲情況？又唔適合邊啲？

如果應用程式一早知道要做咩決定，亦能夠清楚定義答案空間，Jev 可能好合適。例如：

• 決定 agent 應該繼續、重試、要求澄清，定係停止；
• 為指令或工具呼叫分類，交畀安全覆核；
• 評估緊急程度、相關性或風險；
• 由確定性程式先抽取候選值，再喺候選值中揀選；
• 大量文字先做篩選或標籤，再交畀成本較高嘅模型處理。

相反，如果產品要開放式寫作、解釋、腦力激盪、寫程式、廣泛規劃，或者答案無法預先寫入 schema，Jev 就唔係 LLM 嘅替代品。Jev 部署成效亦取決於問題措辭、輸入資料揀選、候選選項、門檻同測試策略。TypeSafe 建議開發者寫清楚條件、盡可能先用程式過濾上下文，並徹底測試整合。

支援模式同未來方向

Jev 目前只接受文字型 state：字串、JSON 物件同文字陣列；未支援圖片、音訊同影片。TypeSafe 將呢幾種模式標為「尚未支援」，但提供嘅文件未有公開多模態模型嘅推出時間表。

重點：佢係「做決定」工具，唔係萬用 AI

Jev 嘅主張唔係所有 AI 都應該停止生成語言，而係好多軟件流程其實根本唔需要生成文字。對於範圍明確嘅分類、路由或政策決定，一個有類型、附帶機率嘅回覆，可能比聊天式答案更易整合、成本更低，亦更快可以採取行動。

但取捨同樣重要：結構化輸出減少嘅係輸出格式失誤，唔係決策錯誤。Jev 真正價值仍要視乎佢嘅準確率同信心估計，能否喺獨立測試、特定領域嘅工作負載中站得住腳。現階段較恰當嘅定位係：一款適合界線清晰軟件決策嘅專門工具，而唔係取代 LLM 嘅通用方案。

Jev 係 TypeSafe AI 首款 System One 模型：佢面向程式而唔係面向人，目標係喺軟件流程入面迅速做出有結構嘅決策，而非寫一段畀人閱讀嘅文字。TypeSafe AI 喺 2026 年 9 月 15 日開放 Jev 早期存取；呢間三藩市公司由前 OpenAI 研究員 Diogo Almeida 與 Erik Gafni、Sasha Sheng 創辦。216

最大分別：唔係「寫答案」，係「交決定」

大型語言模型（LLM）會逐個 token 生成文字，所以用途很廣：解釋、寫作、規劃、寫程式、回答開放式問題都得。但當軟件要用 LLM 嘅結果去執行下一步時，通常仍要解析自然語言，或者驗證模型生成嘅 JSON。

Jev 做嘅係較窄、但更貼近程式流程嘅工作。程式會送入一段 state（狀態）——可以係文字字串、JSON 物件或文字陣列——再附上有類型嘅問題；Jev 會逐題回傳結構化答案。TypeSafe 嘅 API 文件將呢個流程描述為：以問題對照 state 作評估，每條問題各自得到一個結構化答案。17

現時可用嘅決策形式包括：

• Boolean（布林）：估計一項命題為真嘅機率，例如「呢條指令係咪可以安全執行？」
• Choice（選擇）：喺開發者預先提供嘅選項之中揀一個。
• Score（評分）：按有次序嘅準則或數值尺度打分。

所以 TypeSafe 將 Jev 定位為工作流程嘅「決策元件」，可用於路由、分類、檢索篩選、風險評分同 AI agent 防護欄，而唔係聊天助理。官方文件列出嘅例子包括模型路由、語意檢索、執行軌跡分類，以及檢查其他 AI 嘅輸出。18

「System One」即係咩？

個名取自心理學家 Daniel Kahneman 對兩種思考模式嘅區分：快速、直覺嘅「System 1」，以及較慢、較審慎嘅「System 2」。TypeSafe 用 System One 去形容專注於快速而界線清楚嘅判斷，而唔係開放式推理或寫作嘅模型。16

呢個唔等於 Jev 解決咗通用推理問題。真正意思係佢採用另一種介面：你提供相關狀態同清晰定義嘅決策，佢交返受限制嘅結果同機率分布，而唔係一段長篇說明。

點解受限制輸出對自動化有用？

用 Jev 時，應用程式事先定義輸出形狀；如果係 Choice 問題，亦要列明容許嘅答案。咁樣可減少生成式系統整合時常見嘅問題：模型唔會突然回傳未要求嘅欄位、虛構工具名稱，或者喺程式只期待固定值時輸出一大段自由文字。

不過，呢個係 結構上 嘅保證，唔係「一定正確」嘅保證。受限制嘅決策模型仍然可能喺容許選項之中揀錯、誤解上下文，或者報出喺實際工作流程中校準得唔好嘅信心值。Vercel 亦明確指出：符合 schema 只關乎答案結構；語意上係咪正確，仍然要測試評估。

實際部署時，團隊應該將信心門檻當成需要驗證嘅業務規則，而唔好視為可靠性證明。常見做法係：高信心、低風險嘅個案自動處理；含糊或高影響嘅個案，就交畀 LLM、規則引擎或真人覆核。

訓練同「校準」：TypeSafe 嘅說法

TypeSafe 表示，Jev 只使用合成資料訓練，並採用 Reinforcement Learning for Calibrated Decisions（RLCD）。公司聲稱，目標係令模型報出嘅機率更貼近實際答中率，而唔係優先產生人類偏好嘅書面回覆。

對自動化而言，校準尤其重要：理想情況下，0.9 嘅機率應可幫開發者設定有意義嘅覆核門檻。不過，RLCD 仍未有廣泛公開嘅獨立測試支持；現有材料亦未見 Jev 喺校準度、對抗性穩健度或跨領域準確率方面嘅全面第三方審核。因此，企業仍應按自己要部署嘅資料、任務同決策政策作測試。

價錢、上下文長度同速度

TypeSafe 列出 Jev 1.13 收費為每 100 萬個輸入 token 0.042 美元，即每 10 億個 token 42 美元；輸出 token 免費。按呢個輸入價計，5 美元大約可買到 1.19 億個輸入 token，未計稅項或帳戶個別條款。文件亦列明每次請求上下文長度為 64,000 token，其中 state 最多 32,000 token，另加最長嗰條問題。

公司同早期報道提到，延遲大約介乎 70 至 500 毫秒，視乎工作負載而定。呢啲數字可以作評估起點，但實際延遲會受請求大小、問題設計、地區同服務狀況影響。

Vercel 率先接入

Vercel 已經將 Jev 加入 AI Gateway；開發者可以經實驗性評估 API，以 typesafe-ai/jev 呼叫模型。

Vercel 指出，Jev 推出後 24 小時內，近 13% AI Gateway 付費團隊已經使用，數目超過之前任何模型發布同期付費團隊數量嘅兩倍。 呢個係開發者好奇同早期試驗嘅明顯訊號，但本身唔足以證明長期留存、生產規模可靠性，或者所有工作負載下都優勝。

早期亦有指令安全分類、電郵分類等實驗報告。佢哋有助理解 Jev 針對嘅界線清晰任務，但唔可以代替獨立、受控嘅基準測試。團隊若要同 LLM 比較，應用自身具代表性嘅資料，同時檢驗準確率、校準度、錯誤嚴重性、延遲同整體工作流程成本。

適合邊啲情況？又唔適合邊啲？

如果應用程式一早知道要做咩決定，亦能夠清楚定義答案空間，Jev 可能好合適。例如：

• 決定 agent 應該繼續、重試、要求澄清，定係停止；
• 為指令或工具呼叫分類，交畀安全覆核；
• 評估緊急程度、相關性或風險；
• 由確定性程式先抽取候選值，再喺候選值中揀選；
• 大量文字先做篩選或標籤，再交畀成本較高嘅模型處理。

相反，如果產品要開放式寫作、解釋、腦力激盪、寫程式、廣泛規劃，或者答案無法預先寫入 schema，Jev 就唔係 LLM 嘅替代品。Jev 部署成效亦取決於問題措辭、輸入資料揀選、候選選項、門檻同測試策略。TypeSafe 建議開發者寫清楚條件、盡可能先用程式過濾上下文，並徹底測試整合。

支援模式同未來方向

Jev 目前只接受文字型 state：字串、JSON 物件同文字陣列；未支援圖片、音訊同影片。TypeSafe 將呢幾種模式標為「尚未支援」，但提供嘅文件未有公開多模態模型嘅推出時間表。

重點：佢係「做決定」工具，唔係萬用 AI

Jev 嘅主張唔係所有 AI 都應該停止生成語言，而係好多軟件流程其實根本唔需要生成文字。對於範圍明確嘅分類、路由或政策決定，一個有類型、附帶機率嘅回覆，可能比聊天式答案更易整合、成本更低，亦更快可以採取行動。

但取捨同樣重要：結構化輸出減少嘅係輸出格式失誤，唔係決策錯誤。Jev 真正價值仍要視乎佢嘅準確率同信心估計，能否喺獨立測試、特定領域嘅工作負載中站得住腳。現階段較恰當嘅定位係：一款適合界線清晰軟件決策嘅專門工具，而唔係取代 LLM 嘅通用方案。