不一定要 AI 寫答案：從 Jev 到 Laya，試想快速選擇器

如果只要選下一步，還需要一大段回答嗎？

我最近在想，AI 工作流裡有不少時刻，其實不需要模型寫一篇答案。它只要判斷這個問題交給誰、下一步做哪件事，或現在是不是應該停下來問使用者。

看到 TypeSafe AI 的 Jev，我想試的就是這種用法：先把能做的選項列清楚，再讓它幫忙選。LLM 當然也能分類、輸出結構化結果；我想比較的是，在品質可以接受的前提下，換一種決策工具，整個流程會不會更快、更省。

先弄清楚 Jev 幫忙做哪一段

TypeSafe 將 Jev 定位為 System One 模型。官方文件提供 Choice、Score、Noul 三種決策形式；這篇先聚焦 Choice：提供狀態與有限選項，取得選擇結果，以及選項的機率分布和信心值。

固定選項讓程式比較容易接住結果，但不代表它一定選對。這裡的 confidence 是從輸出分布推導的指標，不能直接讀成「這次有幾成機率是正確答案」。要拿它當作轉交或停止的門檻，仍得用自己的資料檢查。

Jev 官方文件介紹的是雲端 API，呼叫它會有資料外傳與網路往返。想把選擇器本身放在地端，朋友分享的 Laya 專案提供了另一條可研究的路。

朋友的 Laya 專案，讓這個想法有了地端入口

朋友 yihsinhung 的 laya-snake-dgx，把原本的 laya-mlx 貪食蛇示範改接 PyTorch，在 DGX Spark GB10 上使用 Laya 權重。README 有作者的驗證紀錄；我這裡先讀文件與程式，還沒有重跑。

Laya 上游提供與 Jev 相容的決策 API，但採用自己的開源權重。比較準確的說法是「Jev 相容的地端決策方案」，不把它寫成 TypeSafe 官方 Jev 權重的移植版。

這個示範的政策模組從本機目錄或既有快取讀取權重，再呼叫本機模型。模型与依賴仍須事先準備；我想驗證的是準備完成後，在自己的目標設備上能否穩定離線運作。

我最想先試的：地端與雲端模型之間的分流

假設地端助理收到一個任務，簡單整理可以留在本機，較複雜的推理可能交給雲端，也可能因為資訊不足，先問使用者一句。我想把地端 Laya 與雲端 Jev 放進同一個評估框架，比較誰適合做這一段選擇。

流程前面要先有本機規則：資料能不能外傳、哪些模型有需要的能力、這次允許多少預算。不能把私人資料先送到雲端，再問雲端「這份資料可不可以送出去」。只有通過規則、且適合提供的最少量狀態，才交給選擇器。

我會把流程拆成：本機規則檢查 → 在允許的選項中做判斷 → 驗證選擇結果 → 執行任務 → 記錄結果。若資料不允許外傳，就留在本機規則或本機模型處理；若選擇器逾時、資訊不足或信心太低，就依事先定義的方式詢問或停止。

這還是架構假設。選擇器本身也有成本，如果原本一句規則就能分流，多加一次 AI 呼叫反而可能更慢。Laya 地端推論也要算設備、記憶體、耗電和維護；能自行託管，不代表總成本為零。

貪食蛇很適合當小型試驗，但先別把題目做大

我會先從貪食蛇開始：把蛇身位置、食物位置和合法方向整理成狀態，讓選擇器只決定下一步往哪裡走。明顯會撞牆或撞到自己的動作，先由遊戲規則排除。

朋友的程式提供了具體參考：規劃器先算安全路徑與食物可達性，甚至先標出較好的方向，再讓 Laya 對選項評分；啟用防護時，還會修正不安全的動作。因此遊戲成果要分開看規劃器、模型與防護各自的貢獻，不能全部算成模型的能力。

比較對象不能只有大型 LLM，也要包含簡單規則、BFS 或 A* 這類搜尋方法。用相同地圖與隨機種子，比吃到的食物、存活步數、無效動作和每步實際等待時間，才知道 AI 有沒有幫上忙。

TypeSafe 的介紹文章展示過 Doom 情境，並說明輸入是結構化狀態，而不是畫面。這和「看懂任何遊戲畫面就能破關」是兩件事。我想先把小遊戲測清楚，再考慮更複雜的關卡。

選股與交易決策，我會先當成離線研究題目

另一個想法是把當時已知的市場資料整理成狀態，讓模型從「加入觀察名單、繼續觀察、略過」等選項中做分類。之後也可以研究買入、持有、賣出這類動作，但現在還沒有回測，更沒有獲利結論。

這個題目最容易把「輸出格式正確」誤認為「判斷有價值」。測試資料必須按時間切開，只能用決策當時已知的資訊，也要把交易成本與滑價算進去，和簡單規則比較。先做離線評估，再考慮模擬交易，不把草稿裡的構想直接接到真實下單。

第一輪，我想先回答四個問題

先選模型路由做最小試驗，準備一組固定任務，標記哪些能留在地端、哪些需要雲端、哪些應該先澄清。標記不只靠直覺，也要看候選模型能否完成任務。保留未參與調整的測試資料，避免把門檻調到只適合這一批例子。

第一，選得對不對？看每一類的錯誤，尤其是把不該外傳的資料送出去，或把做不到的任務留給地端。第二，使用者真的少等了嗎？記錄包含網路、選擇器和任務執行的端到端時間，觀察中位數與較慢的 p95。

第三，真的省錢嗎？把選擇器、執行模型、重試和結果檢查一起算，不能只看單次選擇便宜。第四，選錯或服務中斷時，流程能不能按預期回到澄清、停止或允許的替代方案？

我會在同一組任務上比較規則、本機 Laya、LLM 結構化輸出和 Jev。先約定可接受的品質與錯誤，再看速度和成本；目前不填預想的成績。朋友的遊戲測試可以幫忙設計實驗，但不能直接當作模型路由或選股的證據。

這篇接下來一起補什麼？

下一步先把第一個任務說清楚：路由時到底看得到哪些資料？什麼情況必須留在地端？慢到多久算不能接受？回答這幾個問題，才有辦法選資料、寫測試，也才知道 Jev 適不適合。

我現在最想驗證的是，流程裡這一小段選擇工作，有沒有更合適的做法。等有了實測，再把條件、失敗案例和結果補回這篇；在那之前，它會留在「待驗證」。