# 影片筆記：I’m using Jev more than Opus 5.5 or GPT-6. Here’s why.


<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->
## ⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

- 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

## 一句話總結

講者介紹並演示了 Typesafe AI 推出的決策模型 **Jev**，強調其作為「快速、便宜、不生成自由文本」的特性，透過返回類型安全值（Choice, Score, Vote）來處理大規模數據分類、聚類與路由決策，成本極低且速度極快，適合實時循環與智能條件判斷，而非內容生成。

## 核心重點

1.  **Jev 模型定位**：
    *   Jev 是一個決策模型（Decision Model），具有高代理權（High Agency）。
    *   核心優勢：**極低成本**（僅對輸入 Token 收費，輸出幾乎為零，約每百萬輸入 Token 4 美分）、**極高速度**（適合實時循環）、**高有效性**。
    *   與傳統 LLM 不同，Jev 不生成自由文本，而是返回預定義的「類型安全值」（Type Safe Values）。

2.  **技術架構與輸出類型**：
    *   **輸入**：接受非結構化數據和文本輸入（不接受圖像，但可接受圖像的文本描述）。
    *   **輸出**：
        *   **Choice（選擇）**：從預定義列表中選擇一項。
        *   **Score（評分）**：對嚴重程度或等級進行評分（如 1-5 分，或 Bug 分類）。
        *   **Vote（投票/布林變數）**：判斷問題答案為「是」的可能性百分比。

3.  **適用與不適用場景**：
    *   **適用**：需要智能條件判斷、數據分類與聚類、實時處理、路由決策（如好轉給某人，壞轉給支援）。
    *   **不適用**：需要生成大量內容（如聊天機器人對話生成、代碼生成）或自由文本輸出的場景。
    *   **工作流建議**：使用 Jev 進行大規模數據的標籤、分類、聚類和過濾，再結合其他 LLM（如 Gemini Flashlight）對精確簇執行具體 AI 動作。

4.  **實戰應用案例**：
    *   **GitHub PR 分析**：利用 Jev 進行兩兩比較判斷相關性，聚類後由 Gemini Flashlight 標記主題。成本極低（幾美分），速度快。
    *   **本地雲端代碼會話分析**：分析本地 Cloud Code 和 CodeC sessions 數據，了解時間分配趨勢（如從純工程轉向 Agent 開發）。
    *   **個人郵件分類**：對 Gmail 主題行和片段進行刪除評分與分類。
    *   **複雜數據產品架構**：結合 Jev（分類/標籤）、Astra（分析/策略）、Soul/Luna（生成）處理大量數據信號，成本大幅降低。
    *   **即時應用**：AI 觀眾信號分析（YouTube 評論情感分類）與情緒驅動的名言生成器（結合 OpenAI 即時語音 API）。

## 詳細大綱

### A. Jev 模型概述
*   **背景**：近期 AI 領域新模型頻發（提及 Opus 55, GPT6 Soul, GPT6 Luna, Muse, Grock bots），但 Jev 因其「快速、便宜、不生成系統一決策模型」的特性受到關注。
*   **定義**：Jev 是一個決策模型，具有高代理權。
*   **核心優勢**：
    *   極低成本：僅對輸入 Token 收費，輸出幾乎為零，價格約為每百萬輸入 Token 4 美分。
    *   極高速度：適合實時循環。
    *   高有效性：在個人生產力、代碼、產品用例中爆炸式增長。

### B. Jev 與傳統 LLM 的技術對比
*   **輸入**：兩者均接受非結構化數據和文本輸入。Jev 不接受圖像，但可接受圖像的文本描述。
*   **輸出差異**：
    *   傳統 LLM：輸入文本，輸出字符串/生成文本（Text in, Text out）。
    *   Jev：輸入文本，輸出「類型安全值」。這些值是預定義的，Jev 從中選擇並返回。
    *   Jev 的三種返回類型：
        1.  **Choice（選擇）**：從預定義列表中選擇一項。
        2.  **Score（評分）**：對嚴重程度或等級進行評分。
        3.  **Vote（投票/布林變數）**：判斷問題答案為「是」的可能性百分比。

### C. Jev 的應用場景與價值主張
*   **適用場景**：需要智能條件判斷、數據分類與聚類、實時處理、路由決策。
*   **不適用場景**：需要生成大量內容的場景、需要自由文本輸出的場景。
*   **工作流建議**：使用 Jev 進行大規模數據的標籤、分類、聚類和過濾，結合其他 LLM 對 Jev 分類後的精確簇執行具體 AI 動作。

### D. 實戰案例演示（Codeex 環境）
1.  **GitHub PR 分析（行銷網站）**：
    *   數據量：112 個 PR。
    *   成本：約 1.1 美分（或 1 penny，疑點）。
    *   方法：Jev 進行兩兩比較判斷相關性，聚類後由 Gemini Flashlight 標記主題。
2.  **GitHub PR 分析（Chat PRD App）**：
    *   數據量：約 2,000 個 PR，分析 1,700 個 PR，進行 17,000 對比較。
    *   成本：9 美分。
    *   耗時：約 2 分鐘。
    *   結果：揭示工作投入比例。
3.  **本地雲端代碼會話分析**：
    *   數據來源：本地存儲的 Cloud Code 和 CodeC sessions。
    *   發現：時間分配從 1 月幾乎全為工程任務，轉變為 9 月不到 40% 的工程任務，增加 Agent 開發、媒體發布、客戶交付等。
    *   價值：對桌面數據進行元分析，成本幾乎為零。
4.  **個人 Gmail 分類**：
    *   方法：基於主題行和片段，評分是否可刪除，生成乾淨標籤。
    *   結論：Jev 單獨使用尚可，但與 LLM 夥伴結合更強大。

### E. 複雜數據產品架構與即時應用（片段 2）
1.  **Chat PD 產品洞察圖譜**：
    *   數據規模與來源：約 1,100 個信號（PR、支援工單、Granola 對話、Linear 票證）。
    *   模型分工策略：
        *   **Jev**：負責分類、聚類、標籤分配。
        *   **Astra**：負責大腦分析、策略、洞察提取、配對集群。
        *   **Soul / Luna**：負責生成任務。
    *   成效與成本：處理 200,000+ 分類與成對分組，Jev 側成本約 4 美元。
2.  **即時應用案例一：播客觀眾信號儀表板**：
    *   數據來源：YouTube V3 API 抓取約 4,500 條評論。
    *   處理流程：情感分類（正面、負面、中性）、靈感提取。
    *   輸出結果：情感儀表板、觀眾請求板、即時搜尋功能。
3.  **即時應用案例二：情緒驅動的名言生成器**：
    *   技術堆疊：OpenAI 即時語音 API、Jev、API Ninja Quote API。
    *   運作邏輯：輸入語音，Jev 判斷情緒並對應到 HEX 顏色值，根據顏色篩選名言 API，對名言進行情感評分並顯示。
    *   演示結果：即時回應疲倦、快樂、興奮、戀愛中等情緒。
4.  **總結與後續預告**：
    *   Jev 101 核心回顧。
    *   預告週中將播出與熱門嘉賓的 Jev 專題訪談。

## 工具 / 模型 / 名詞整理

*   **Jev / Jeb / Jeb**：Typesafe AI 推出的決策模型（逐字稿中名稱拼寫有變異，標記為疑點）。
*   **Typesafe AI**：Jev 模型的開發公司。
*   **Opus 55**：提及的新模型（疑點，需查證）。
*   **GPT6 Soul**：提及的新模型（疑點，需查證）。
*   **GPT6 Luna**：提及的新模型（疑點，需查證）。
*   **Muse**：提及的新模型。
*   **Grock bots / Grock / Brockbot**：提及的模型/產品（疑點，可能為 Grok 的誤聽或特定產品）。
*   **Open Art Arena**：創意智能全球排行榜平台。
*   **Versel**：提供 AI gateway 的公司（疑點，可能指 Vercel）。
*   **Codeex**：講者演示代碼的環境或工具。
*   **GitHub**：代碼託管平台。
*   **Gemini Flashlight**：用於對 Jev 聚類結果進行最終分類的模型。
*   **Cloud Code**：雲端代碼環境。
*   **CodeC sessions**：本地存儲的代碼會話數據。
*   **Chat PRD app / Chat PD**：講者提到的應用程序/產品洞察圖譜。
*   **Chat Pured**：提及的應用程序名稱（疑點，可能指 Chat PRD 或其他）。
*   **Gmail**：電子郵件服務。
*   **Astra**：用於分析、策略、洞察提取的模型。
*   **Soul / Luna**：用於生成任務的模型。
*   **YouTube V3 API**：用於抓取評論的 API。
*   **Google Console**：用於啟用 API 的平台。
*   **OpenAI's real time voice API**：用於即時語音輸入的 API。
*   **API Ninja Quote API**：用於獲取名言的 API。
*   **Linear**：提及的票證系統。
*   **How I AI**：播客名稱。
*   **Howiaipod.com**：網站。
*   **Apple Podcasts / Spotify**：播客平台。
*   **Granola conversations**：提及的數據信號類型（疑點，可能為聽寫錯誤）。
*   **margin accretive**：商業術語，指增加利潤/價值。
*   **auto wiki**：提及的上下文功能（疑點）。

## 操作流程整理

### 流程一：GitHub PR 分類與聚類
1.  **數據獲取**：從 GitHub 獲取 PR 列表（如 112 個或 1,700 個 PR）。
2.  **兩兩比較**：使用 Jev 對 PR 進行兩兩比較（Pair-wise relations）以判斷主題相關性。
3.  **聚類**：根據相關性進行數據聚類。
4.  **最終分類**：將聚類結果輸入 Gemini Flashlight，由該模型標記具體主題（如維護、內容、工具等）。
5.  **結果分析**：分析成本（幾美分）與時間，並檢視工作投入比例。

### 流程二：本地雲端代碼會話分析
1.  **數據收集**：從本地存儲獲取 Cloud Code 和 CodeC sessions 數據。
2.  **Jev 處理**：使用 Jev 對會話數據進行分析。
3.  **趨勢洞察**：識別時間分配趨勢（如工程任務比例變化、Agent 開發增加等）。
4.  **元分析**：對桌面數據進行元分析，獲取以往難以獲取的洞察。

### 流程三：複雜數據產品架構（Chat PD）
1.  **信號收集**：收集 PR、支援工單、Granola 對話、Linear 票證等數據信號（約 1,100 個）。
2.  **Jev 分類**：使用 Jev 進行快速且準確的分類、聚類與標籤分配。
3.  **Astra 分析**：使用 Astra 進行高階分析、策略與洞察提取、配對集群。
4.  **Soul/Luna 生成**：使用 Soul 或 Luna 進行生成任務。
5.  **成本與成效評估**：監控分類與分組成本（約 4 美元），評估原型開發成本降低效果。

### 流程四：即時應用 - 情緒驅動名言生成
1.  **語音輸入**：透過 OpenAI 即時語音 API 接收用戶語音。
2.  **情緒判斷**：Jev 判斷情緒並對應到 HEX 顏色值。
3.  **名言篩選**：根據顏色篩選 API Ninja Quote API 的過濾器。
4.  **情感評分與顯示**：對名言進行情感評分並即時顯示。

## 值得注意的限制或風險

*   **模型名稱不確定性**：影片中提及的模型名稱（如 Opus 55, GPT6 Soul, GPT6 Luna, Grock bots, Brockbot）可能存在辨識錯誤，實際產品名稱需查證。
*   **Jev 名稱變異**：Jev 在逐字稿中被聽寫為 Jeb/Jeb，需確認正確名稱。
*   **成本描述不一致**：關於行銷網站 PR 分析成本，逐字稿先說 1.1 cent 後說 1 penny，需確認實際計費邏輯。
*   **數據比較對數語法混亂**：關於比較對數的描述（17 found 17,000 pairs），語法略顯混亂，需確認是否為 17,000 對。
*   **術語辨識疑點**：如 "99% nule" 可能為 "99% value" 或 "99% vote" 的聽寫錯誤；"Granola conversations" 可能為特定術語或聽寫錯誤。
*   **Jev 不適用場景**：Jev 不適用於需要生成大量內容或自由文本輸出的場景，錯誤使用可能導致效能低下或結果不符預期。

## 逐字稿辨識疑點

*   **Jev / Jeb / Jeb**：逐字稿中模型名稱在 "Jev", "Jeb", "Jeb" 之間跳躍，需確認正確名稱。
*   **Opus 55**：模型名稱，需查證是否存在此版本或型號。
*   **GPT6 Soul**：模型名稱，需查證是否存在此版本或型號。
*   **GPT6 Luna**：模型名稱，需查證是否存在此版本或型號。
*   **Grock bots / Grock / Brockbot**：模型名稱，需查證是否為 Grok 的誤聽或特定產品。
*   **Versel**：公司名稱，可能為 Vercel 的聽寫錯誤，但依規則標記為疑點。
*   **Chat Pured**：應用名稱，可能為 Chat PRD 或其他名稱的誤聽。
*   **1.1 cent / 1 penny**：關於行銷網站 PR 分析成本的描述，逐字稿先說 1.1 cent 後說 1 penny，需確認實際計費邏輯或口誤。
*   **17 found 17,000 pairs**：關於比較對數的描述，語法略顯混亂，需確認是否為 17,000 對。
*   **99% nule**：可能為 "99% value" 或 "99% vote" 的聽寫錯誤。
*   **Jab**：在結尾處提及 "What I like to do with Jab"，可能為 Jev/Jeb 的聽寫錯誤。
*   **Granola conversations**：逐字稿中提及 "these are granola conversations"，在數據信號語境下，"granola" 可能為聽寫錯誤，需查證其具體指涉。
*   **margin accretive**：講者使用此詞形容功能對業務的貢獻，雖為商業術語，但在技術討論中較少見，確認其語境為「增加利潤/價值」。
*   **auto wiki**：講者提到 "context like auto wiki"，可能指自動生成的維基百科式內容或特定功能名稱，需查證是否為特定產品功能。

## 可延伸追問

*   Jev 模型的具體定價結構與計費方式為何？
*   Jev 與傳統 LLM 在技術架構上的根本差異是什麼？
*   如何優化 Jev 與其他 LLM（如 Gemini Flashlight, Astra, Soul, Luna）的協作流程？
*   Jev 在哪些特定行業或應用場景中表現最為出色？
*   如何確保 Jev 返回的類型安全值的準確性與可靠性？
*   Jev 的實時處理能力對系統架構有何要求？
*   如何監控和評估 Jev 在大規模數據處理中的成本效益？
*   Jev 的未來發展路線圖與 Typesafe AI 的戰略規劃為何？