使用 TypeSafe 建置
TypeSafe 讓 AI 的智慧單元可像程式設計基本元素般使用：可以組合成更大功能的小型判斷。其 System One 模型 能快速回傳專注的判斷，讓軟體可直接使用。Jev 是 TypeSafe 的旗艦產品，也是第一個 System One 模型。它能理解自然語言，並回傳類型化的答案與機率，而非產生文字或推理說明。程式碼掌握工作流程；模型則在一般程式碼需要語義理解時，提供可程式化的常識。
閱讀即時文件
TypeSafe 的即時文件是最終權威。請將其作為任務的一部分來閱讀。 這個技能提供方向；文件則包含當前概念、提示指導、API 合約、SDK 使用方式、模型、限制以及實作範例。
- 從文件索引開始，探索相關頁面與操作指南。進行有目標的閱讀，而非載入整個網站。
- Mintlify 透過在頁面路徑後附加
.md來提供 Markdown，例如如何使用 TypeSafe 建置。從索引中的連結開始；必要時將無副檔名的文件頁面連結轉換為.md。相對路徑請以https://docs.typesafe.ai為基礎進行解析。 - 在撰寫整合程式碼之前，請先閱讀當前的 API 或所選 SDK 頁面，以及與設計相關的問題指導。對於新的工作流程，也請檢查最接近的操作指南：它通常會展示比通用分類器更好的分解方式。
- 如果索引無法使用，請使用下方的直接連結或網站的導航。如果 Markdown 擷取失敗，請嘗試一般頁面。如果無法即時存取，請使用可用的本地文件或已安裝的 SDK 類型，說明此限制，並避免編造與版本相關的細節。
| 任務 | 從此處開始；並遵循相關細節 |
|---|---|
| 了解程式設計模型 | System One、建置指南 |
| 探索可建置的內容 | 應用案例地圖，然後從索引中尋找相關操作指南 |
| 準備輸入與問題 | 狀態、基本元素，然後是所選基本元素的頁面 |
| 決定如何處理不確定性 | 信心度 |
| 撰寫 API 程式碼 | HTTP API、Python SDK 或 JavaScript SDK |
| 更新舊版整合 | 遷移指南 與已安裝 SDK 的當前參考資料 |
找出有用的形狀
從使用者想要的行為開始：應用程式會顯示、選擇、更改或移交什麼？反推回它所需的判斷。將已知規則、計算、精確查詢和執行保留在程式碼中。保留使用者選擇的技術堆疊與範圍；在需要語義理解的地方加入 TypeSafe。
在腦力激盪或選擇架構時，考慮的不只是分類。以下模式是起點：圍繞使用者的目標組合基本元素，包含那些不符合既定食譜的想法。
- 路由與填寫已知引數。 一個請求可以選擇一個處理器及其類型化的參數。事先提出有用的分支特定問題，並僅使用相關答案。探索函式呼叫與推測性扇出。
- 選擇而非生成。 在程式碼中尋找候選值或原始碼區段，使用判斷來選擇預期的值，然後複製或正規化它。程式碼也可以將原始文字組合成格式化文件或閱讀指南。探索數值萃取與結構復原。
- 尋找並判斷證據。 檢索候選項，比較它們與查詢的相關性，並選擇有用的上下文。探索重新排序與層級分類。
- 將判斷轉化為可重複使用的資料。 一次為多個維度評分，然後讓程式碼或使用者控制項改變權重、閾值、排名與檢視。有了標記的結果，這些訊號可以成為傳統機器學習的特徵。探索複合評分與特徵發現。
- 驗證與升級。 根據其證據檢查特定的主張或欄位；將不確定或失敗的情況交給人員或推理模型。探索引用檢查與萃取串聯。
- 回應變化的狀態。 程式碼可以保留目標與觀察結果，同時新的判斷引導下一步的有限行動。保持推斷的狀態與觀察到的事實有所區別，並在將結果應用於已變化的情境之前檢查新鮮度。
對於開放式的請求，提供最能服務使用者目標的少數方向，並推薦一個起點。對於具體的請求，選擇相關的模式並建置；腦力激盪並非必要的繞道。
設計判斷
根據答案的意義來選擇，然後閱讀相關的基本元素頁面：
| 需求 | 基本元素 | 重要區別 |
|---|---|---|
| 從定義的集合中選一個 | 選擇 | 選取一個選項；其分佈用於比較競爭選項 |
| 條件是否成立 | 布林 | 肯定的機率；沒有單獨的信心度；當可能有多個成立時，每個標籤使用一個 |
| 沿著描述維度的程度 | 分數 | 在有序層級上的機率加權位置；用於需要分級排名時，每個項目的分數可互相比較 |
為每個問題提供足夠相關的狀態來回答：原始文字、身份標識、關係、政策與當前事實。當上下文包含多個部分時，偏好使用具名的 JSON 欄位。將判斷放在指示中，並在標準中定義其可能的答案。問題 ID 是給程式碼使用的，不會發送給模型；請在問題中包含完整的意義。使用反引號路徑來引用巢狀狀態，例如 ticket.messages[0].text。
每個問題提出一個狹隘而連貫的判斷。拆分有獨立用途的維度，但不要破壞被判斷的關係。有限的行動選擇或上下文詮釋是有效的；「原子」並不意味著字面的事實擷取或一句話的限制。簡單問題使用字串。當定義、對比、排除或範例有助於釐清指示或標準時，使用結構化物件或陣列。分數層級必須描述具體情況，並且能獨立存在。
保持所需的答案可用。當可能沒有任何項目符合時，包含一個「無匹配」的結果；當獨立有用時，使用一個單獨的存在判斷。對於原始值的選擇，檢查候選項的涵蓋範圍：模型無法選擇被省略的值。
組合與驗證
一起詢問關於相同狀態的獨立問題，包含有用的推測性問題。它們會並行執行，並且看不到彼此的答案。明確陳述每個推測性前提；程式碼會使用適用的答案。當需要先前的答案來取得證據、建構新狀態或決定下一步選項時，才需要第二個請求。額外的問題仍會消耗 token；請在實際環境中衡量請求預算、成本與端到端延遲。
使用機率與信心度來引導行為，並在使用者的資料與後果上評估閾值。選擇/分數的信心度總結了分佈的集中程度，而非整體工作流程的正確性或行動權限。接近 0.5 的布林值表示「是」與「否」的機率相近，而非中等強度。幾個可接受的替代方案也可能分散機率；信心度低並不使無害的偏好選擇無效。忽略未使用分支上的不確定性。
保持政策明確，並使原始判斷可重複使用。加權分數適用於補償性偏好；「任何嚴重違規」規則需要獨立的條件。當證據與問題意義不變時，更改權重或顯示濾鏡不需要重新執行推論。類型化的輸出保證的是介面，而非真實性。System One 模型經過校準決策的訓練；請在目標領域驗證其效能。
測試代表性案例與產生的應用程式行為。對於失敗，檢查確切的狀態、問題、候選項、答案、組合與觀察到的結果。區分遺失證據、模型錯誤、程式碼錯誤與服務失敗。將操作指南中的閾值與示範結果視為需要評估的範例，而非通用規則或永久模型限制。在網頁應用程式中，保持 API 憑證在伺服器端。