模型學會照著食譜卡回答，而你家廚房早就這樣做了

2026年9月23日，一篇關於 llm-typesafe 0.1a0 的完整指南在網路上流傳。這個還在 alpha 階段的外掛，把 TypeSafe AI 的 Jev 模型接進 LLM CLI，讓語言模型的回覆從一段自由文字，變成有固定欄位、有型別、可以直接交給程式讀取的答案。聽起來是工程師的事，但我在讀完那份指南的晚上，正好看見冰箱門上那張婆婆手寫的滷肉食譜卡，忽然覺得這兩件事是同一件事。

自由發揮的菜，和照卡辦事的菜

你一定遇過這種食譜：「醬油適量，燉至入味，起鍋前嚐味道調整。」這種寫法給了廚師自由，也給了廚師麻煩。適量是多少？入味是多久？每次照著做，端出來的顏色深淺不一，鹹甜飄移，你沒辦法跟家人保證，這週五的滷肉跟上週五是同一鍋。

自由文字的模型回覆也是這樣。指南裡講得很清楚，一般聊天模型即使被要求回傳 JSON，開發者仍要自己定義格式、驗證欄位、處理失敗的狀況，就像你拿到一句「差不多就好了」，還是得自己判斷那個「差不多」落在哪裡。

llm-typesafe 做的事，是把問題先定型。它把輸入稱為 state，把問題分成幾種固定型態：noul 是非判斷、choice 選項分類、score 有序評分。這就像把「燉至入味」改寫成「小火加蓋，四十分鐘，筷子能穿過五花肉即成立」。問題定義清楚了，答案才有辦法被檢查。

換到廚房裡，這其實跟市場裡挑菜去雜訊、換一張安靜餐桌是同一門手藝：先把雜訊排除，留下可以動手的東西。

信心值那個數字，像鍋裡冒的泡

官方文件把 noul 定義為判斷敘述是否成立，回傳 0 到 1 的數值。指南裡有一個很誠實的提醒：0.99 並不代表現實正確率是百分之九十九，那個數字能不能當門檻，要用標註資料檢查。

這句話讓我想到熬糖。食譜上寫加熱到攝氏118度，糖漿開始冒出細密的小泡，顏色轉成淺琥珀。溫度計給你一個數字，泡的狀態給你另一個訊號，但最後決定離火的，是你知道這鍋糖今天用的火、今天的濕度、上一次的經驗。數字是線索，裁決在你。

Simon Willison 的公開 CLI 範例裡，noul 被拿來問客服訊息是不是要求退款，程式讀到回傳值再決定下一步。這就像你問學徒：這鍋湯鹹了嗎？他說「有一點」，你還得再嚐一口才敢下判斷。程式可以分支，但分支之前的判斷，仍要有人負責。這也是我們先前聊廚房裡請外部試喫、把關味道時的同感：一直自己嚐味道的廚師，最後往往嚐不出問題。

分流處理：高信心快炒，中間地帶送人工

指南裡建議的三段式處理，我讀起來就像一個營業中的廚房。高信心且通過規則檢查的，自動執行，像熱鍋快炒，三十秒起鍋；中間區間的送人工，像那鍋需要有人盯著的燉湯；低信心、欄位不完整、服務失敗的，進重試或人工佇列，而且重試不能只是把同一個請求再送一次，要增加資訊或改變路徑。

這最後一句最像做菜。湯太鹹了，你不會只是再加一次水，你會先嚐、再判斷是鹽下重了還是煮太久濃縮了，然後決定補水、加馬鈴薯，還是留到明天配麵。同樣的動作重複一次卻期待不同結果，在廚房裡我們叫它浪費食材。

choice 選項分類也一樣講究。指南提醒，選項描述必須互相區分，而且要保留「無適用選項」的退路。這就像菜單上的分類：牛肉、豬肉、海鮮、蔬食，最後一定要有一欄「其他」，否則點了雞肉的客人會被硬塞進豬肉那鍋裡。分類的誠實，在於承認有些東西不在你的清單上。

Alpha 版的味道，還在試菜階段

指南寫得節制：llm-typesafe 目前是早期外掛與整合入口，公開資料能說明介面，尚不足以證明準確率、穩定性、延遲、成本或長期維護效益。這種誠實我特別欣賞，因為它像一個試菜階段的廚師會說的話：今天的菜是這個方向，味道還沒定，你先嚐，別急著寫進菜單。

0.1a0 這個版本號本身就是一張告示。你家用新醬油第一次滷那鍋肉的時候，也是這樣，配方可行，風味未定，得再滷個三五次，讓香料的比例沉澱下來，才能說這是我的味道。型別驗證能確認答案的長相，不能確認模型的理解正確；就像食譜卡能保證你沒漏放八角，不能保證這鍋滷肉好喫。

收在餐桌上

所以下次你在冰箱門上貼一張新的食譜卡，寫清楚鹽幾克、火多大、時間多久，旁邊留一行「失敗時怎麼補救」，你其實就在做 llm-typesafe 那套工程：把自由發揮變成可檢查的步驟，把判斷拆成可以分開測試的問題，然後承認有些狀況要留給人。

指南裡那句官方文件的話我記到現在：「Jev evaluates typed questions against a state and returns structured results directly。」直接翻出來是，Jev 對一個狀態回答定義好的問題，直接回傳結構化的結果。把它放到餐桌上就是：問對問題，答案才站得住。這週末燉湯的時候，試著把「燉到差不多」改寫成「兩小時，筷子一插就穿過」，你會發現連味道都穩了起來。