Cloudflare Clef 怎麼用？Jev 決策流程的模型切換與驗收

先判斷你需要的是決策，還是生成內容#

Clef 讀取 state 與一組具型別的問題，回傳選項機率。它適合回答「這筆訊息應交給哪個部門」，後續客服回覆仍交給其他流程。

三種問題分別是 choice 固定選項分類、noul 是非條件機率，以及 score 有順序的程度評分。這個分類模型不會替你完成退款、寫出客服信，或驗證資料庫裡的訂單資格。

如果你尚未建立 Jev 流程，可先看 Jev API 的 Choice、Score 與 Noul 範例。這篇新增的是切換供應商與驗收方法，不重做同一份 SDK 入門。

Workers AI 呼叫要對齊兩個模型欄位#

Workers AI 的模型 ID 是 @cf/cloudflare/clef 與 @cf/cloudflare/clef-flash。request 內還有 model selector，分別填 clef 或 clef-flash，兩者要一起切換。

既有 Worker 先加入 AI binding；以下是需合併到 Wrangler 設定的 JSON 片段：

1
{
2
  "ai": {
3
    "binding": "AI"
4
  }
5
}

下面只示範一則固定訊息的 API 呼叫。部署前仍需完成 Cloudflare 帳號與 Worker 的基本設定；這段不包含公開客服 endpoint、驗證登入或儲存工單：

1
export default {
2
  async fetch(request, env) {
3
    const result = await env.AI.run('@cf/cloudflare/clef', {
4
      model: 'clef',
5
      state: '付款頁顯示系統錯誤，今天所有訂單都無法結帳。',
6
      questions: {
7
        team: {
8
          type: 'choice',
9
          instructions: '哪個部門應處理這則訊息？',
10
          criteria: {
11
            billing: '帳單、扣款與退款',
12
            technical: '系統錯誤、服務中斷與串接',
13
            other: '資訊不足或不符合上述分類',
14
          },
15
        },
16
      },
17
    });
18

19
    return Response.json(result);
20
  },
21
};

binding 回傳結果與 REST API 的外層包裝要分開處理。替換現有 Jev client 時，先保存一份真實回應 fixture，確認程式取得的確實是 answers.team，再接回原本的分流政策；不要只修改 URL 就假設所有欄位仍位於同一層。

API 相容，仍有平台邊界#

Clef 的 Workers AI 模型文件限定每次 1–64 個問題，答案依問題 ID 回傳。先把現有 schema 的問題數與 ID 檢查一遍，再考慮批次合併；如果超出限制，要拆分 state 與問題，而不是等待 API 自動省略。

多模態也要區分介面：model card 有本地 image／video 用法，但 Workers AI 文件中的 images 接受嵌入的 PNG、JPEG 或 WebP，最多四張，不接受遠端 URL。不能把本地模型能力直接套到託管 API 的 request。

開放權重則是另一條部署路徑。官方 model card 提供 Apache 2.0 權重與專用的 schema head／systemone 範例；下載權重不等於已完成一般聊天模型伺服器的部署，也不能從模型大小推定自己的筆電一定跑得動。這篇只處理 Workers AI 與既有決策流程的串接選擇。

先保留人工路徑，再校正門檻#

下面的函式只處理三個已知部門，信心低、答案格式不完整或選項不在 schema 中時，回到人工。0.8 是示意政策，不是 Clef 官方建議值：

1
function decideRoute(answer, threshold = 0.8) {
2
  const allowed = new Set(['billing', 'technical', 'other']);
3
  if (!Number.isFinite(threshold) || threshold < 0 || threshold > 1) {
4
    throw new RangeError('threshold must be between 0 and 1');
5
  }
6
  if (!answer || !allowed.has(answer.choice) ||
7
      !Number.isFinite(answer.confidence) ||
8
      answer.confidence < 0 || answer.confidence > 1 ||
9
      answer.confidence < threshold || answer.choice === 'other') {
10
    return 'manual';
11
  }
12
  return answer.choice;
13
}

這裡的 confidence 是模型回應欄位，不能直接稱為實際正確率。真正門檻要由你已標註的資料決定：錯送部門的成本、人工負載與可以接受的漏判，各自影響不同。

可把函式放入 route-check.mjs，附上以下測試並以 node route-check.mjs 執行。本次維護流程已在 Node.js v24.13.0 驗證這些分支，未驗證模型輸出品質：

1
import assert from 'node:assert/strict';
2

3
assert.equal(decideRoute({ choice: 'technical', confidence: 0.9 }), 'technical');
4
assert.equal(decideRoute({ choice: 'billing', confidence: 0.4 }), 'manual');
5
assert.equal(decideRoute({ choice: 'other', confidence: 0.99 }), 'manual');
6
assert.equal(decideRoute({ choice: 'unknown', confidence: 0.99 }), 'manual');
7
assert.equal(decideRoute({ choice: 'billing', confidence: NaN }), 'manual');
8
assert.equal(decideRoute(null), 'manual');
9
assert.throws(() => decideRoute(null, 2), RangeError);
10
console.log('route checks passed');

API timeout 或服務錯誤也要回到相同的人工路徑，不能以預設最高信心答案補上缺失。真正執行工單移轉時，再加入工單 ID 與冪等檢查，避免重試產生兩張工單。

用同一份資料比較 Jev、Clef 與 Clef-flash#

先凍結一份具有正確部門標籤的樣本，包含中文、英文、資訊不足與容易混淆的付款系統故障。三個模型使用完全相同的 state、schema 與標籤，再各自量測：

• 自動分流的比例，以及其中錯送部門的比例。
• 被送人工的案例，有多少其實可以正確自動分流。
• 從應用程式送出到收到答案的 p50／p95 延遲。
• 同一份資料實際產生的 usage 與平台帳務成本。

先以 shadow mode 記錄答案，不改原本工單路由；比較完成後，才調整門檻與切換模型。正式切換應讓供應商和門檻可獨立回復，遇到延遲或分布變化時，能退回舊模型而不重寫業務邏輯。

Cloudflare 的公告有內部 benchmark 與延遲比較，但沒有替你的中文工單測試。建議以現有模型作基準，先測 Clef，再測 flash 是否能在可接受的錯送率下減少等待；如果兩者都讓人工負載超過產品可接受的範圍，就保留原流程。

資料必須留在自有環境時，則應另外評估權重部署與硬體成本，或比較 Laya 本機決策模型，不能只因為 API 接起來方便就改變資料處理範圍。

參考資料：

Cloudflare：Clef 官方發布公告

Workers AI：Clef changelog

Workers AI：AI binding 設定

Workers AI：Clef 模型與 API

Workers AI：Clef-flash

Cloudflare Clef model card