Jev 系統架構師

Jev 系統架構師 是做什麼的？

目的

使用此技能來判斷：

1. Jev 是否應該存在於系統中
2. Jev 的邊界應該確切落在何處
3. 哪些判斷應轉化為 Choice、Score 或 Noul 問題
4. 每個判斷應看到什麼狀態
5. 哪些問題應該一起執行
6. 一般程式碼應如何組合結果
7. 不確定性應如何改變系統行為
8. 在正式使用前應如何評估整合效果

這主要是一項架構和分解技能。

有關確切的 SDK 語法、請求/回應欄位、模型、限制或特定版本的 API 行為，請閱讀當前的 TypeSafe 文件，並在可用時使用 TypeSafe 的官方代理技能。

請勿憑空發明 API 欄位。

---

核心思維模型

Jev 不是應用程式。

Jev 不是工作流程引擎。

Jev 不是自主代理。

首選架構是：

應用程式狀態
      ↓
有界限的語義問題
      ↓
     JEV
      ↓
類型化判斷 + 機率
      ↓
確定性應用程式碼
      ↓
路由 / 排序 / 驗證 / 詢問 / 升級 / 執行

模型提供可程式化的判斷。

程式碼擁有：

• 控制流程
• 權限
• 計算
• 確定性規則
• 持久化
• 交易
• 副作用
• 工具執行
• 授權
• 政策執行

僅在一般軟體需要對非結構化或模糊資訊進行語義理解時，才使用 Jev。

---

觸發條件

當系統包含形狀如下的邊界時，考慮使用 Jev：

非結構化或上下文資訊
                ↓
     需要進行有界限的判斷
                ↓
 軟體需要一個類型化值才能繼續

強烈候選項目包括：

• 意圖分類
• 語義路由
• 審核決策
• 文件分類
• 證據驗證
• 引用檢查
• 語義護欄
• 風險訊號
• 訊息解讀
• 候選者選擇
• 排序維度
• 相關性判斷
• 情緒或緊急程度
• 使用者請求解讀
• 工具/函數選擇
• 從已知候選集中提取
• RAG 段落過濾
• 工作流程分流
• 品質判斷
• 政策與案例比較
• 模糊比對
• 實體對齊
• 升級決策

同時檢查程式碼中是否存在此類症狀：

LLM → 散文 → 解析器 → JSON → 驗證 → 重試

或：

大型正規表示式樹
大型 if/else 語義分類器
傳回任意 JSON 的基於提示的分類器
僅用於做出有界限決策的代理迴圈
用於瑣碎分類的昂貴推理模型

這些都是潛在的 Jev 插入點。

---

預設不使用 Jev

對於以下情況，偏好使用一般程式碼：

• 算術
• 已結構化表示的確切日期
• 資料庫查詢
• 確切字串比對
• 權限
• 授權
• 架構驗證
• 確定性業務規則
• 已知轉換
• 排序已知數字
• 加密操作
• 已能可靠解決問題的確切解析器

當所需輸出本質上是開放式的時，偏好使用生成式模型：

• 寫作
• 摘要
• 解釋
• 腦力激盪
• 程式碼生成
• 長篇綜合
• 開放式研究
• 多步驟推理

Jev 可以透過在其周圍做出有界限的決策來支援這些系統，但不應強迫它扮演生成式角色。

---

步驟 1 — 找出判斷邊界

檢查從輸入到輸出的工作流程。

標記每個軟體實際上在問的點：

「我有資訊，但我需要了解它的含義，才能知道該走哪條確定性路徑。」

對於每個候選邊界，寫下：

輸入狀態： 存在哪些資訊？

判斷： 需要做出什麼語義決定？

輸出： 什麼有界限值能讓程式碼繼續？

動作： 程式碼將如何處理答案？

風險： 如果判斷錯誤會發生什麼？

不要立即實作 Jev。

首先確定確定性程式碼是否能夠更可靠地解決問題。

---

步驟 2 — 應用 Jev 適合度測試

當以下大多數條件成立時，一個判斷是強烈的 Jev 候選：

• 輸入包含自然語言或上下文資料。
• 所需的輸出可以是有界限的。
• 軟體需要以程式化方式取得答案。
• 知識豐富的人可以快速做出判斷。
• 判斷可以被明確描述。
• 不確定性是有用的資訊。
• 結果可以針對範例或標籤進行測試。
• 程式碼可以在判斷後擁有該動作。

當任務需要以下條件時，應保持懷疑：

• 深度思考
• 長鏈推理
• 許多依賴的中間結論
• 開放式生成
• 自主規劃

先進行分解。

---

步驟 3 — 使問題原子化

一個 Jev 問題應該代表一個連貫的判斷。

不好：

分析此客戶，並確定我們是否應該退款給他們、他們有多生氣、詐騙的可能性有多大，以及哪個部門應該處理此案。

較好：

• topic → Choice
• refund_requested → Noul
• fraud_signal → Noul
• frustration → Score

然後在程式碼中組合這些答案。

目標是：

複雜行為 = 許多小判斷 + 確定性組合

當程式碼可以明確表達該政策時，不要將應用程式政策隱藏在一個巨大的語義問題中。

---

步驟 4 — 選擇正確的原語

Choice

當應該從定義的集合中選擇一個答案時使用。

形狀：哪一個？

範例：

• billing | technical | sales | account
• refund | rebook | information
• python | javascript | rust | other

當提供的選項可能無法涵蓋輸入時，新增一個「other」、「unknown」或「none」結果。

Noul

用於一個命題，其為真的機率是有用的。

形狀：這是真的嗎？

範例：

• 客戶要求退款嗎？
• 這段文字回答了使用者的問題嗎？
• 此訊息要求憑證嗎？
• 履歷表上陳述了專業的 Python 經驗嗎？

將輸出解釋為「是」的機率。

不要將 ~0.5 解釋為「中等強度」。

它意味著「是」和「否」的可能性大致相等。

Score

當判斷存在於有序維度上時使用。

形狀：狀態落在這個定義光譜的哪個位置？

範例：

• 冷靜 / 擔心 / 非常沮喪
• 不相關 / 部分相關 / 強烈相關 / 直接答案

每個級別應描述一個具體的語義條件。

除非其含義被明確定義，否則避免使用 bad / okay / good / great 等未定義的標籤。

---

步驟 5 — 謹慎設計狀態

傳送包含問題所需證據的最小狀態。

偏好結構化狀態：

{
  "ticket": {
    "message": "...",
    "sender": {}
  },
  "customer": {
    "plan": "...",
    "orders": []
  },
  "policy": {
    "refund_policy": "..."
  }
}

而不是一個巨大的散文區塊。

原則：

• 相關 > 全面
• 結構化 > 扁平化
• 觀察到的事實 > 假設的模型知識
• 當前資訊 > 過時的嵌入式知識

保持觀察到的事實與推斷的判斷可以區分。

當問題涉及特定的狀態欄位時，直接指向那些欄位。

---

步驟 6 — 展開獨立的問題

如果多個問題可以從相同的現有狀態中回答，則偏好將它們一起詢問。

                    ┌── topic
                    ├── urgency
狀態 ── JEV ───────┼── refund_requested
                    ├── frustration
                    └── fraud_signal

不要建立不必要的序列化呼叫，例如：

Jev → answer → Jev → answer → Jev → answer

當所有三個問題都可以從原始狀態評估時。

當投機性問題成本低廉且可能在以後有用時，可以詢問它們。

範例：category, bug_severity, reproduction_quality, refund_requested, frustration

如果 category = billing，程式碼只需忽略特定於 bug 的答案。

---

步驟 7 — 僅在真正有依賴關係時使用多個 Jev 階段

當第一個答案需要滿足以下條件時，第二個 Jev 請求是合理的：

• 擷取新證據
• 建構新狀態
• 選擇下一個候選集
• 確定可以有意義地詢問哪些問題
• 遍歷層級結構
• 檢索下一個判斷所需的文件

範例：

步驟 1  哪個產品系列？
   ↓
程式碼檢索該系列中的產品
   ↓
步驟 2  哪個確切產品最符合？

不要僅僅因為工作流程在概念上包含幾個步驟，就將問題序列化。

---

步驟 8 — 將組合保留在程式碼中

Jev 產生語義訊號。

程式碼決定這些訊號在操作上的意義。

範例：

topic = billing
refund_requested = 0.94
frustration = high

應用程式程式碼可以決定：

if topic == billing:
    route_to_billing()

if refund_requested > REFUND_FLAG_THRESHOLD:
    add_refund_flag()

if frustration > PRIORITY_THRESHOLD:
    increase_priority()

業務邏輯應保持可檢查性。

當答案可以從較小的判斷建構出來時，不要問 Jev「我們整個應用程式該怎麼做？」

---

步驟 9 — 將不確定性視為第一級訊號

永遠不要將類型化輸出視為等同於真相。

類型化輸出意味著介面是受限的。

這並不意味著語義判斷不會出錯。

對於 Choice 和 Score，檢查機率和信心。

對於 Noul，直接檢查「是」的機率。

設計如下行為：

• 高確定性 → 自動路徑
• 中等確定性 → 要求確認 / 收集更多證據 / 更強模型 / 標記以供審查
• 低確定性 → 不要猜測 / 升級

閾值是應用程式政策。

它們必須反映誤報/漏報的成本、可逆性、使用者/財務/安全/法規影響。

從範例中複製的閾值並不能證明它適合此系統。

---

步驟 10 — 將信心門檻與風險匹配

不要使用一個通用的信心閾值。

範例：

• show_help_article — 後果低
• route_support_ticket — 後果中等
• cancel_subscription — 後果較高
• move_money — 後果非常高

語義判斷可能是相同的，而所需的確定性和確認路徑卻不同。

對於後果嚴重的動作，Jev 通常應告知一個受控的決策邊界，而不是獨立授權副作用。

---

步驟 11 — 在自動化之前設計評估

在將 Jev 邊界投入生產之前，請確定代表性案例。

包括：簡單正面、簡單負面、模糊案例、缺證據案例、邊緣案例、對抗性案例、罕見但成本高昂的失敗案例。

記錄：狀態、問題、預期行為、Jev 答案、機率/信心、應用程式動作、可用時的基礎事實結果。

評估系統行為，而不僅僅是頂部標籤看起來是否合理。

對於基於閾值的系統，測量多個閾值下的行為。

特別測量：覆蓋率 / 自動化率、誤報率、漏報率、人工審查率、錯誤成本、延遲、成本。

使用實際的目標領域資料來調整閾值。

---

步驟 12 — 集中 Jev 政策

讓 Jev 問題、標準、權重和閾值常數易於查找和審查。

偏好如下結構：

ai/
  jev/
    questions.*
    thresholds.*
    evaluation/
    client.*

或專案適用的等效結構。

不要將語義政策分散在數十個路由處理程式中。

人工審查員應能夠檢查：

• Jev 在判斷什麼？
• 我們提供了什麼定義？
• 什麼閾值會觸發動作？
• 哪些動作是可逆的？
• 當信心低時會發生什麼？

---

步驟 13 — 保留原始判斷

在實際可行時，將有用的原始輸出與從中衍生的動作分開保留。

例如：

refund_probability = 0.91
frustration_score = 1.72
topic = billing
topic_confidence = 0.88

而不是只儲存 priority = high。

這允許重新評估閾值、更改權重、審計行為、比較模型版本、調查失敗以及進行下游分析。

不要保留超出應用程式合法要求的敏感資料。

---

步驟 14 — 在生成式 AI 周圍尋找 Jev

Jev 通常在 LLM 周圍有價值，而不是取代它。

範例：

輸入 → Jev 護欄 → LLM → Jev 引用/品質驗證 → 程式碼決定是否回傳

或：

查詢 → 檢索 → Jev 相關性/注入判斷 → 選定的上下文 → 推理模型

或：

使用者請求 → Jev 意圖/函數選擇 → 確定性類型化函數 → 結果

這可以減少委託給開放式生成式模型的應用程式控制量。

---

架構審查程序

當被要求審查現有系統以尋找 Jev 機會時：

1. 繪製工作流程

識別：輸入、確定性步驟、語義決策、模型呼叫、解析器、路由器、工具呼叫、副作用、人工審查點。

2. 產生 Jev 機會地圖

對於每個候選項目：

• 位置： 當前程式碼/模組/工作流程
• 當前方法： 今天如何做出判斷
• Jev 候選： 是 / 否 / 可能
• 原因： 為什麼有界限的語義決策適合或不適合
• 狀態： 最小所需證據
• 原語： Choice / Score / Noul
• 問題： 提議的原子判斷
• 組合： 程式碼應如何使用它們
• 不確定性： 當答案不清楚時會發生什麼
• 風險： 錯誤判斷的後果
• 評估： 如何驗證

3. 根據槓桿作用進行優先排序

偏好那些 Jev 可以取代脆弱的語義程式碼、重複的 LLM 解析、昂貴的瑣碎推理呼叫、無界代理迴圈、重複的分類器或明顯情況的人工審查 — 同時保持系統行為有界限且可測試的機會。

4. 推薦最小的 v

…

[因翻譯截斷]