不用寫程式
無需提供自己的 API key,就可以先在本站獨立免費體驗中測試資料和問題。你可以設定是/否判斷標準,也可以定義 2–6 個選項。若要把 Jev 接入自己的應用程式,請使用下文另行說明的 TypeSafe 官方帳號與 API 存取途徑。
本站體驗允許資料、問題、判斷標準和選項合計最多 10,000 個字元,按 Unicode 碼點計數。這是本站額度,不是 Jev 的上下文視窗。即時檢查可能需要真人驗證,達到用量或預算限制時會暫停。載入範本不會自動執行,也不會預填模型結果。
1. 從正確的使用管道開始
截至 2026 年 9 月 17 日,TypeSafe 公開網站提供候補名單。官方快速入門則提供 Playground 與 API 的使用說明。能夠閱讀文件,不代表每個帳號都已取得模型使用權限。
- **尚未取得使用權限:**請加入 TypeSafe 官方網站上的候補名單。本站無法核准帳號,也不能發放 API 金鑰。
- **帳號已有使用權限:**請開啟 TypeSafe 主控台,依照 Playground 或 API 金鑰流程操作。
帳號開放情況與啟用流程可能變動。請到官方主控台確認自己的帳號狀態。
2. 先試一個範圍明確的問題
在 Playground 中,輸入一則簡短的虛構訊息,並提出一個 Noul 問題。例如,使用一則要求回電的訊息,詢問寄件者是否明確要求回電。接著把輸入改成一則籠統的求助訊息,觀察結果是否改變。
這是探索練習,不是準確度測試。先使用兩個有差異的範例,有助於確認問題是否表達出你想區分的情況。
Jev 將提供的資訊稱為 state,也就是供判斷使用的資料與脈絡。它可以是字串、JSON 物件或陣列。較複雜的任務可以使用具名欄位,讓訊息、佐證紀錄與相關規則保持清楚區分。輸入格式
開發者串接
3. 送出第一個 API 請求
文件記載的端點為 POST https://api.typesafe.ai/v1/systemone,接收模型名稱、state 與具名問題,並使用 Bearer Token 進行驗證。API 參考文件
請在本機環境中安全地設定 TYPESAFE_API_KEY,再於終端機執行以下由本站編寫的範例:
查看技術細節
curl --fail-with-body --silent --show-error \
https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
--data-binary @- <<'JSON'
{
"model": "jev-latest",
"state": "Please call me tomorrow morning to discuss the setup.",
"questions": {
"callback_requested": {
"type": "noul",
"instructions": "Does the sender explicitly ask for a phone call?"
}
}
}
JSON請從成功回應中讀取 answers.callback_requested.noul 與 usage.input_tokens。回應欄位
Noul 表示答案為「是」的估計機率。Noul 結果解讀
請將金鑰保存在終端機或伺服器環境中,不要嵌入瀏覽器 JavaScript、公開儲存庫、螢幕截圖或共用範例。本指南不會要求你將金鑰貼到網站上。
4. 依照任務需求增加結構
當下一步取決於類別時,使用 Choice;當你有具意義且依序排列的等級時,使用 Score;需要是非題的機率時,則使用 Noul。針對相同 state 的獨立問題可以放在一起,再由應用程式處理各項結果。
接下來可以閱讀具體的客服工單範例,了解如何將文件中的輸出轉成分流建議。
5. 分開排查存取權限與請求問題
如果主控台登入流程未完成,請從正常入口重新開啟官方主控台,並確認使用的是已取得權限的帳號。不要為了解決瀏覽器登入問題,而反覆修改 API 請求。成功登入也不代表已核發 API 金鑰。若需要帳號協助,請使用 TypeSafe 官方支援管道;公開回報時,絕對不要附上金鑰或登入連結。
對於 HTTP 請求,應先檢查狀態碼與錯誤回應本文,再調整問題內容:
| 狀況 | 接下來檢查什麼 |
|---|---|
401 回應 |
確認金鑰與 Bearer 驗證標頭 |
422 回應 |
閱讀回傳的驗證細節,並檢查請求欄位 |
429 回應 |
降低請求壓力,並採用退避策略重試 |
529 回應 |
視為暫時過載,並採用退避策略重試 |
這些狀態碼記載於 API 參考文件。遇到 429 或 529 時,請使用指數退避。SDK 預設已會重試;新增外層重試迴圈前,請先將 SDK 的嘗試次數納入考量。
逾時與否定答案不同。請設定整體截止時間與有限的嘗試次數,並將仍未解決的工作交付審查。也要確保重試模型請求時,不會重複執行建立任務指派等後續動作。
6. 排查出乎預期的答案
| 觀察到的情況 | 建議的檢查方式 |
|---|---|
| 答案有效,卻回答了錯的問題 | 將實際指令與預期條件逐一比對,並明確寫出例外情況 |
| 編輯後結果改變 | 一併保存模型版本、state、選項標籤、順序與評分規準 |
| 評分落在兩個等級之間 | 將它理解為加權位置,而非整數標籤或精確數量 |
| 結果看似明確,證據卻不足 | 檢查 state 實際包含的資料;信心值無法補足缺少的紀錄 |
| 兩個答案互相矛盾 | 分別檢查各個問題,並在程式碼中定義衝突處理規則 |
這些是本站提供的除錯建議。Score 指南說明了小數值的意義;限制頁面則連結至目前的廠商注意事項,並另外標示社群觀察。
jev-latest 別名可能改為指向更新的模型。測試時請記錄回傳的模型識別名稱;需要可重現性時,請使用帳號支援的版本化識別名稱。模型別名
7. 判斷第一個流程是否已準備就緒
啟用自動動作前,請保留一小組附有預期決策的案例、檢視錯誤,並為自己的流程選定門檻。使用定價計算機估算輸入 Token 支出,再參考比較指南,判斷哪些部分應繼續由其他工具處理。
來源與延伸閱讀
本指南以官方文件及附有連結的社群回報為依據。社群觀察均註明原作者。
我們如何查核來源