八個範例出自Matthew Berman 於 9 月 24 日發布的影片將 TypeSafe AI 的 Jev 模型用於熟悉的任務：清理網頁、尋找段落、排列收件匣，以及選取介面元件。示範由不同開發者製作，但共同做法是讓模型只負責狹義判斷，應用程式則負責蒐集輸入並執行結果。

若能將模型判斷與程式碼或其他模型完成的工作分開看，每段影片就更有參考價值。使用者可能察覺的錯誤，也和模型呼叫本身同樣重要。這些仍是示範或早期工具；BIG CHANGE 尚未獨立測試其準確度或日常使用可靠性。

重大變化

  • 有哪些改變：建置者正把具型別的 AI 判斷嵌入既有軟體互動，從瀏覽器捷徑到收件匣檢視皆然。Jev 回傳選擇、分數或機率；應用程式提供候選資料，並依答案採取行動。
  • 為何重要：使用者閱讀、搜尋或分類時，軟體便能即時提供有用判斷，無須把整項工作交給聊天介面。同樣的設計也讓應用程式負責處理錯誤排序、隱藏內容及非預期操作。
  • 接下來觀察：下一步需要針對各項任務取得證據：工具能否選對段落、保留網頁重要控制項、妥善排列重要郵件，並在日常使用中處理不確定情況。單靠快速示範無法回答這些問題。

網頁清理工具呈現分工方式

Kitze 的 Unclutter 瀏覽器擴充功能是最清楚的例子。其專案 README指出，擴充功能會擷取網頁候選元素，再詢問 Jev 哪些元素並非必要。接著由瀏覽器程式碼套用可還原的隱藏規則、按頁面範本儲存，並在不再次呼叫模型的情況下重複套用。使用者可以暫停擴充功能、保留特定元素，或重新分析頁面。Cookie 覆蓋視窗可能會被隱藏，但擴充功能不會代替使用者按下「接受」或「拒絕」。

這是一條重要界線。Jev 可以判斷某個元素是雜亂資訊，但它不會控制瀏覽器、不會替使用者選擇同意選項，也不會決定規則保留多久。實際評估應檢查清理後的導覽、無障礙控制項、付費牆通知或真正的同意選項是否仍可使用。專案提供原始碼建置版本及自備 API 金鑰的設定方式，但 README 未提供這些錯誤的獨立實地研究。

該Made with Jev 網站偵測器在Berman 影片 3:29 處出現，其流程不同。工具說明，其方法是由瀏覽器測量渲染樣式、DeepSeek V4 Flash 描述螢幕截圖，再由 Jev 根據特徵清單判斷設計與文案，最後由另一個 DeepSeek 產生簡短結論。網站為 anthropic.com 顯示 26% 的「slop」分數。這是工具依自身風格規則算出的分數，並不能證明 Anthropic 網站有多少內容由 AI 撰寫，儘管 Berman 在影片中作出該推論。

資訊排序是另一種判斷

Jonathan Unikowski 的收件匣示範提議以即時重要性排序取代反向時間順序。他的貼文表示，這項功能「即將推出」至 Avec，但沒有證明收件匣已部署、沒有說明重要性的定義，也未獨立測量緊急郵件遭漏看的情況。應用程式仍須擷取郵件、呈現排序，並決定是否封存、加標籤或寄出；示範中的 Jev 負責的是優先排序。

Shubham Saboo 的 Needle 擴充功能更清楚呈現兩者的差異。Saboo 表示，Jev 會依讀者的查詢為頁面段落評分，擴充功能則在原文中標示相符文字。他的較完整說明指出，Needle 不會撰寫答案：被標示的句子原本就存在於頁面上。這改變了頁面搜尋捷徑能搜尋的內容，但標示出的句子仍可能不正確。測試時需要採用正確段落已知的查詢，包括包含相似但互相矛盾說法的頁面。

Burhan Usman 的影片剪輯貼文表示，他在一支超過 90 分鐘的影片中找到某主題的片段。在影片 8:34 處，Berman 表示系統可能使用逐字稿；這是他的推測，並非已驗證的流程說明。該貼文未說明 Jev 實際接收或輸出的內容。剪輯應用程式仍須取得來源素材、確定時間範圍並產生可下載片段。貼文所述的時間與成本，是單一建置者的報告，沒有公開準確度測試或完整端到端工作量明細。

介面組合仍須由應用程式負責

Chris Tate 的 json-render 實驗根據應用程式提供的選項組合使用者介面。專案的 Jev 文件有特別清楚的說明：Jev 選擇元件與版面位置；程式碼負責組合並驗證規格；渲染器則將其顯示。互動展示平台使用合成商業資料，動作處理器則在使用者互動時執行。因此，這項示範呈現的是組合受限介面的方式，並非模型獨立撰寫並部署網站。

另外兩個創意範例探索風險較低的選擇。Matt DesLauriers 的色彩實驗在視覺展示中將文字提示對應到調色盤。Stefan 的表情符號實驗（Berman 影片中9:52 處展示）會依據輸入文字將表情符號排序。兩個案例都是由應用程式呈現可選的視覺素材。貼文展示互動構想，但無法證明選擇結果適合品牌、符合對比度要求，或能在不同語言與情境下正常運作。

TypeSafe 的文件說明這些範例為何有相似之處。Jev 會根據提供的狀態，評估具型別的 Choice、Score 及是／否問題。Choice 與 Score 會回傳分布及信心值，供軟體納入自己的規則。該公司建議依實際任務測試門檻；信心值欄位並非獨立的準確度結果。

這些範例有力呈現一種設計模式：當固定規則過於僵化時，軟體可以在適當時機提出一個範圍明確的小問題。特定工具是否適合日常工作，取決於它會犯哪些錯誤、會顯示或隱藏哪些內容，以及應用程式是否提供復原方式。這些都是整體工作流程的特性，不能只看模型的判斷。