---
title: "我們如何以 Jev（TypeSafe）解決 BudgetWorks OS 的模糊判斷問題"
description: "以有類型的 AI 判斷取代脆弱的關鍵字匹配：BudgetWorks OS 如何將 Jev 應用於收件箱分流、收據類別和通話處理，並附真實的影子模式結果。"
url: https://www.budgetapp.works/blog/how-we-use-jev-select-dont-generate
canonical_url: https://www.budgetapp.works/blog/how-we-use-jev-select-dont-generate
last_updated: 2026-10-12
---

[ 返回博客](/blog)

 October 1, 2026 55 瀏覽

# 選擇，而非生成：我們如何以 Jev 解決模糊判斷問題

![選擇，而非生成：我們如何以 Jev 解決模糊判斷問題](/cdn-cgi/image/width=1536,quality=80,format=auto/https://public-api.budgetapp.works/api/public/media/1b6623cb-6fc5-41fe-8ccb-e6df054e6f82)

## 選擇，而非生成：我們如何以 Jev 解決 BudgetWorks OS 中的模糊判斷問題

每個企業系統都有一些地方，單靠程式碼是不夠的。這張掃描的發票屬於哪個項目？這張收據是餐飲還是辦公用品？來電者說的是「quite interested」還是「quit」？

多年來，我們以關鍵字清單和 `ILIKE '%word%'` 處理這些問題。它們在大部分時候有效，一旦失效，卻是悄無聲息地出錯。本文介紹我們如何以 TypeSafe 的 System One 模型 **Jev** 改善這個情況，以及確保安全的一條原則。

## Jev 是什麼（以及不是什麼）

Jev 不撰寫文字。它回答**有類型的問題**，並為每個答案附上機率：

| 原語     | 返回                   | 適用於                 |
| ------ | -------------------- | ------------------- |
| choice | 從清單中選出一項，並附每個選項的機率   | 分類、路由、「是哪一個？」       |
| noul   | 是／否的機率               | 條件檢查：「來電者是否要求結束通話？」 |
| score  | 在 2 至 10 個有序等級上的加權位置 | 緊急度、風險、相關度          |

整個概念就是：**選擇，而非生成**。對聊天模型問「這屬於哪個項目？」，它會以自由文字編出一個答案，我們還要再解析和驗證。Jev 只能從我們提供的選項中挑選，並說明它有多大把握。

## 原則：程式碼決定「有哪些可能」，Jev 判斷「指的是哪一個」

```mermaid
flowchart LR
    A[文件或訊息到達] --> B[程式碼從資料庫載入真實的候選項]
    B --> C[Jev choice：是哪一個，或都不是？]
    C --> D{有把握嗎？}
    D -->|有| E[自動套用]
    D -->|沒有| F[向人員顯示前三個候選項]
    E --> G[稽核記錄]
    F --> G

```

規則、計算和精確查找留在程式碼中，只有需要「理解」的一步才交給 Jev。選項一律來自我們自己的資料庫（該租戶的進行中項目、會計科目、供應商），因此 Jev 不可能回答一個不存在的東西。信心不足時交給人處理，這與我們現有 AI 代理「先預覽、再確認」的設計一致。

## 舊做法的問題

我們檢視後端中脆弱的邏輯時，發現的問題並不特別：

* **通話被誤掛斷。** AI 通話引擎只要訊息中_包含_「quit」或「stop」這類子字串就會掛斷。「I'm **quite** interested」會結束通話，「Thanks, that's all」卻不會。這段邏輯在每一通電話的每一輪都會執行。
* **收件箱自動分流靠猜。** 文件以 `project_name ILIKE '%關鍵字%'` 配對項目，取第一個結果。像「ltd」或「hk」這樣的關鍵字幾乎可以匹配任何項目，結果是自動建立任務並移動檔案，既沒有信心度，也沒有確認。
* **收據類別靠子字串。** 「bar」匹配了 barber，「tea」匹配了 team，「gas」匹配了 Vegas。類別清單寫死，中文收據大多落入 `other`。

## 我們的做法（按順序）

1. **先修正明顯的錯誤，不使用 Jev。** 通話引擎現在按完整單詞匹配；收件箱分流不再接受過短或過於通用的關鍵字，也不會在未確認時移動檔案。正則表達式能解決的錯誤，不需要用模型。
2. **撰寫一個小型客戶端。** 由單一服務封裝 TypeSafe API，而且永不拋出例外：金鑰缺失、請求逾時或服務繁忙時，它只會返回空值，現有邏輯繼續運作。API 金鑰只保存在伺服器端。
3. **以影子模式運行 Jev。** Jev 在背景作答，我們把它的答案與現有邏輯的決定一併記錄。使用者不會看到任何改變。在信任它之前，先以真實數據比較。

## 影子模式的初步結果

我們回填了 30 張真實收據，把 Jev 的類別與視覺模型給出的類別作比較：

| 指標                   | 結果               |
| -------------------- | ---------------- |
| 整體一致率                | 30 張中有 24 張（80%） |
| Jev 信心度 ≥ 0.90 時的一致率 | 23 張中有 20 張      |
| 延遲中位數                | 約 412 毫秒         |

有分歧的個案最值得留意。一張便利店購買香煙的收據，舊邏輯判為 `meals`，Jev 判為 `other`，而 Jev 是對的。一張升降車租賃收據，舊邏輯判為 `other`，Jev 判為 `supplies`，這確實是見仁見智。另有三張視覺模型完全沒有返回結果的收據，Jev 仍然給出合理的答案。

這只是一個小樣本，我們明確說明這一點。它足以顯示這個方向值得繼續，但還不足以正式啟用。

## 接下來的應用

| 問題         | Jev 的提問                                        |
| ---------- | ---------------------------------------------- |
| 收件箱文件 → 項目 | 在該租戶進行中的項目加上「無」之間 choice                       |
| 收據類別       | 在該租戶的費用科目之間 choice                             |
| 結束或轉接通話    | 針對最近幾輪對話，在同一個請求中提出兩個 noul 問題                   |
| 試算表匯入欄位對應  | 每個欄位在真實的目標欄位加上「略過」之間 choice                    |
| 發票付款對帳     | 程式碼按金額和日期篩選候選發票，choice 選出配對，noul 判斷「這是否為部分付款？」 |

## 不交給 Jev 的部分

同樣重要的是我們_沒有_交出去的部分：用戶自行定義的 SKU 規則、收據上日期和總額的擷取、評估量表的計分公式、資料類型推斷。這些都是確定性的，所以保持確定性。任何生成文字的功能（報告、建議書、聊天）仍由語言模型負責，任何需要看圖的步驟仍由視覺模型負責。Jev 只讀取文字。

## 重點整理

* 使用附有機率的有類型答案，而不是需要自行解析的自由文字。
* 為模型提供來自自家資料的選項，並加上「都不是」。
* 先修正程式碼能解決的問題，只在需要理解語意的一步才加入模型。
* 先以影子模式運行，以真實數據比較後，才讓它改變任何行為。
* 把機率當作門檻：有把握就自動處理，不確定就由人決定。

_想了解這如何應用於你自己的文件和工作流程？[歡迎聯絡我們](/contact)。_

 #jev #typesafe #ai #classification #shadow-mode #automation

### 想了解其運作方式？

了解 BudgetWorks OS 如何改變您的業務營運。

[免費試用](/try)

---
Site map for agents: [llms.txt](https://www.budgetapp.works/llms.txt) · [sitemap.md](https://www.budgetapp.works/sitemap.md)