本頁內容

難度
中階
所需時間
約 30–60 分鐘(含練習與自行驗證)
你需要準備
TypeSafe 官方文件
開始之前
- 能閱讀 JSON 與基本流程規則
- 先用教學或去識別資料,保留人手回退
Choice 用來從已定義的類別選一項;Score 用來在有序描述之間評級;Noul 用來回答一個是非命題的機率。選錯 primitive,後面的程式即使能解析回應,也可能拿到語意不合用的資料。本篇重點是問題設計,而不是重複 API 安裝步驟。
資料核對:2026 年 9 月 21 日。本文依官方文件研究;原創情境、門檻及計算例子均有標明。本站未以 Jev API 執行性能或廣東話準確率測試。模型、價格與 early access 狀態可能更新。

Choice:選項應覆蓋需求,描述要能獨立閱讀
客服類別可以是付款、技術、物流與其他。每個 criteria 描述都應明確界定收甚麼例子;不要只寫「A、B、C」,也不要要求模型參照「上一項」。若多種意圖經常同時出現,先定義如何取主要意圖,或分成多個是非題,不要任由分類政策飄移。
{
"type": "choice",
"instructions": "Choose the primary support issue; use other when unclear.",
"criteria": {
"billing": "Charges, invoices, payments or refund enquiries.",
"technical": "Login errors or software defects.",
"delivery": "Shipping, delivery timing or missing goods.",
"other": "Unclear issue or none of the listed domains."
}
}
Choice 只保證在給定答案空間中選擇。若你把「批准」與「拒絕」列為唯一選項,資料不足時也沒有自然的「待補資料」出口。把暫緩、其他或覆核設成明確結果,會令下游更容易保留不確定性。這是工作流設計建議,不代表新增選項必然提高模型準確率。
核對來源:Choice primitive。
Score:有序 rubric,不是任意 0–100 分
評估故障影響時,先寫可辨識的情境:「外觀問題而功能正常」「部分功能失效但有替代方法」「關鍵功能無法使用且沒有替代方法」。這比「低、中、高」更容易讓標註者和模型使用同一套定義。每一級都要完整描述,不要寫「比上一級嚴重」。
| 陣列位置 | 本篇故障影響 rubric | 要注意的條件 |
|---|---|---|
| 0 | 外觀或文字問題,主要功能可正常完成 | 不把客人語氣平靜誤認為影響很低。 |
| 1 | 部分功能失效,但有可行替代方法 | 替代方法須在資料裏有依據。 |
| 2 | 主要工作無法完成,而且沒有已知替代方法 | 不知道有沒有替代方法,不應自動等同確定沒有。 |
Score 回傳的是以機率加權的等級位置,陣列由 0 起算。例如一個純計算示例的分佈是 0 級 0.1、1 級 0.6、2 級 0.3,score 就是 0×0.1+1×0.6+2×0.3=1.2。這不是 Jev 實測,也不是「120% 嚴重」。
平均位置亦可能隱藏不同形狀:全部機率在 1 級,與 0、2 級各一半,都得到 score=1;但前者集中、後者分裂。若高影響的少數可能性很重要,程式應同時檢查各級機率,而不是只看平均分數。
核對來源:Score primitive、Composite scoring。
Noul:明確界定「是」的意思
「需要優先處理嗎?」混合了客人語氣、實際時限、商戶政策及後果。可以改問「客人是否明確提到今天內需要完成?」再由程式決定優先級。越能把觀察和政策分開,越容易寫出一致的測試標籤。
{
"type": "noul",
"instructions": "Does the message explicitly request a refund now? Negated or merely quoted refund requests are not current requests.",
"criteria": {
"true": "The customer currently asks for money to be refunded.",
"false": "No current explicit request; includes denial, quotation or an enquiry about charges."
}
}
Noul 的 noul 值介乎 0 與 1,沒有另一個 confidence 欄位。兩個分開提問的「是 A 嗎?」與「不是 A 嗎?」亦不應被假設必然加起來等於 1;它們是不同問題。若政策需要互斥分類,優先考慮同一道 Choice 的分佈,而不是事後強行拼湊一致性。
核對來源:Noul primitive、Jev 1.13 jaggedness — 已知能力弱點。

一次多題有甚麼優點,又有甚麼限制?
如果工單類別、退款意圖和時限訊號都只依賴同一段 state,可以同一個請求處理。這讓你不用為每題重送整個上下文。但每題獨立判斷,不能寫「根據上一題答案決定處理方式」。有依賴的兩步應由程式串接;不依賴的工作才並行。
亦不要為追求一次完成,把未必會用到的數百條問題全部加入。先計算哪些分支常見、額外問題 token 與延遲是否值得,再比較先分流後提問與一次 fan-out。答案數量增多,也會增加你需要維護的規則與測試面積。
核對來源:Speculative fan-out、TypeSafe HTTP API reference。
提交問題前的六項自查
- 這題是否只有一個可解釋的維度?
- 每個選項或等級能否獨立閱讀,不依賴相鄰文字?
- 資料缺漏、否定、引用、混合意圖有沒有明確處理?
- 這件事是否其實可用日期、regex、數學或資料庫規則精確完成?
- 人手標註者是否能用同一份 rubric 得出相近判斷?
- 改寫問題後,有沒有在相同的留出資料上量度,而非只挑幾個成功例子?
下一步閱讀
資料來源與引用
我們附上第一手及官方來源,方便你逐一核實。
常見問題
Score 是整數嗎?
不一定。它是等級位置按機率加權的值,可以落在兩級之間。
Choice 可以多選嗎?
一道 Choice 選一個選項;多個可同時成立的訊號可改用多個 Noul 問題,再以程式組合。
本文遵循我們的 編輯準則.

關於作者
HK Learn AI 編輯部
HK Learn AI 編輯部負責研究、查證同編寫每一篇內容,並引用官方及第一手來源。
此主題相關文章

Jev API 教學:用 JavaScript 發出第一個 TypeSafe 請求、讀取答案與處理錯誤
用 Node.js 與 fetch 呼叫 Jev:完整 model/state/questions 示例,讀取 Choice、Noul 和 usage,處理 401、422、429、529,並固定模型版本。

Claude Code GitHub Actions 教學:@claude 修 issue、PR 自動審查,訂閱 token 定 API key 點揀
按 Anthropic 現行官方文件(2026 年 9 月 15 日核對)設定 Claude Code GitHub Actions:用 /install-github-app 快速設定,或手動安裝 Claude GitHub App、加 Secret、放 workflow,再留言 @claude 改 code 及開 PR 自動審查。另有訂閱 token 與 API key 之選、成本、安全設定同排錯。文首附支援地區狀態。

Claude Code MCP 教學:連接 GitHub、資料庫同 Notion,scope、權限同安全設定
按 Anthropic 現行官方文件(2026 年 9 月 15 日核對)一步步設定 Claude Code MCP:加第一個免登入 server、分清 HTTP/stdio 同 -- 分隔符、揀 local/project/user scope,再連接 GitHub(唯讀網址)、DBHub 資料庫(唯讀帳戶)同 Notion,最後講 mcp__ 權限規則、安全清單、context 用量同常見錯誤。文首附支援地區狀態。