標籤: WebGPU

  • 讓電腦自己看螢幕幹活的小工具

    讓電腦自己看螢幕幹活的小工具

    📌 本文重點

    • 開源工具可把螢幕變成「可程式化」工作桌
    • 支援本機 LLM 與瀏覽器 LLM,兼顧隱私與便利
    • 透過 GUI 預設規則,非工程師也能自動化桌面任務
    • 可搭配 Webhook、雲端 LLM 打造微型 agent 工作流

    只要先把規則設好,這個開源小工具就能在背景「看著」你的螢幕,等畫面出現特定文字或按鈕,就自動幫你通知、截圖、點擊甚至重啟程式。

    工具原帖(作者自述):r/LocalLLaMA 原文連結


    核心功能:把螢幕變成一張「可程式化」的工作桌

    1. Observer MCP:一個控制台管理多個觀察任務

    這個工具的核心是一個叫 Observer MCP 的控制器,可以同時管理多個「觀察任務」(micro-agents)。

    你可以做的事:

    • 任務 A:監看模擬器視窗,畫面出現「Not Responding」就自動
    • 截圖
    • 關閉程式
    • 重新啟動模擬器
    • 任務 B:盯住下載器介面,偵測到「Download complete」就
    • 彈桌面通知
    • 或發一個 Webhook 給你自己的 Telegram/Slack bot
    • 任務 C:每天早上 9 點打開 BI 報表,如果畫面中出現「error」「failed」字樣
    • 立即截圖
    • 寄信給負責人

    操作邏輯很像「IFTTT 版的螢幕監控」:

    • IF 螢幕上出現某段文字 / 某個按鈕
    • THEN 執行通知、按鍵、滑鼠、呼叫 API、丟給其他 CLI 工具

    你可以在工具內的 GUI 列出多個任務,分別開關,不需要改程式碼,只要改設定。


    2. 本機 LLM + 瀏覽器 LLM:llama.cpp + transformers.js

    這個工具內建兩種推理引擎,讓你可以選擇 AI 要跑在哪裡。

    • llama.cpp 模式:
    • 在你的電腦本機跑 LLM
    • 適合已經有 GPU 或願意下載模型的人
    • 好處:完全離線、資料不出機器,適合隱私敏感場景

    💡 關鍵: 使用 llama.cpp 本機模式時,所有資料都留在自己的電腦裡,特別適合處理敏感畫面與內部數據。

    • transformers.js + WebGPU 模式(跑在瀏覽器):
    • 利用瀏覽器的 WebGPU,在前端執行模型
    • 不需要架後端,也不必裝一堆依賴
    • 搭配 Hugging Face 開源的高速 WebGPU kernels,可以在 Chrome/Edge 之類的瀏覽器上流暢運作

    你可以這樣配置:

    • 輕量任務(純文字判斷、簡單判讀畫面):用瀏覽器版 LLM,完全零部署
    • 重度任務(複雜畫面理解、長報表分析):切換成本機 llama.cpp 模式

    實際操作動作:

    1. 在設定頁選擇 Local LLM 或 Browser LLM
    2. 如果選 Local LLM,指定你的 GGUF 模型路徑(例如從 Hugging Face 下好的模型)
    3. 如果選 Browser LLM,只要開對應的 Web UI,直接在瀏覽器跑

    3. 預設規則 + 簡單 GUI:不會寫程式也能配置

    作者在 v3.0.0 的重點,就是讓「他媽媽也會用」。

    工具提供:

    • 預設規則模板(例如「偵測錯誤字樣」「下載完成通知」「程式崩潰自動重啟」)
    • 圖形介面 GUI:
    • 下拉選單選「要看哪個視窗」
    • 文本欄位填「要找的關鍵字」
    • 再選「觸發後要做什麼動作」

    你可以這樣設定第一個規則:

    1. 打開工具 > 新增任務
    2. 選擇「觀察區域」:整個螢幕,或某個應用程式視窗
    3. 在「條件」輸入關鍵字,例如 error 或 download complete
    4. 在「動作」選擇:彈出桌面通知 + 播放提示音
    5. 儲存後按「啟動」

    從這一刻開始,電腦就會在背景幫你盯畫面,只要滿足條件,就幫你處理重複的提醒工作。


    適合誰用:三種典型場景

    1. 辦公桌面自動化:BI 報表 / 下載器 / 排程任務

    如果你工作中常遇到:

    • 要盯 BI 報表更新,一有錯誤就要截圖回報
    • 等大型檔案下載完成才能進下一步
    • 排程報表生成,有時悄悄失敗沒人發現

    你可以這樣做:

    • 建一個任務專門看 BI 報表頁面
    • 條件:畫面包含 Error / Failed / Timeout
    • 動作:截圖 + 寄 Email 給團隊
    • 再建一個任務盯住下載器視窗
    • 條件:出現 100% 或 Download complete
    • 動作:桌面通知 + 呼叫你的 CLI 腳本開始後續處理

    💡 關鍵: 透過關鍵字條件搭配自動通知與截圖,可以避免「排程失敗卻沒人發現」的情況默默發生。

    2. 遊戲 / 模擬實驗監控

    對玩家或研究員:

    • 模擬器長時間跑實驗,一掛掉就浪費幾個小時
    • 練功、排隊、排程任務,需要特定事件時才回來動手

    可設定:

    • 任務:觀察模擬器畫面
    • 條件:出現 Not responding 或畫面變黑
    • 動作:
      • 截圖留證
      • 關閉程式
      • 再重新啟動模擬器
      • 發 Telegram / Slack 通知你

    3. 重視隱私,又不想把畫面丟雲端的人

    如果你在處理:

    • 內部財務報表
    • 客戶名單
    • 研究實驗數據

    又希望 AI 幫忙看畫面,但不想傳到雲端:

    • 開啟 Local LLM(llama.cpp) 模式
    • 所有畫面截圖、文字解析都在你的電腦裡完成
    • 即使你用 WebGUI 管理,也只是本機 Web 介面,資料不會被上傳

    怎麼開始:最快上手路線

    注意:原始專案為開源,實際專案名稱 / 下載方式請以作者 GitHub 為準。以下是一條通用、接地氣的上手流程。

    步驟 1:從 GitHub 下載與安裝

    1. 打開作者提供的 GitHub 連結(可從 Reddit 原文找到):
    2. r/LocalLLaMA 貼文
    3. 在 GitHub 右側 Release 區塊,下載
    4. Windows:*.exe 或 *.msi
    5. macOS:*.dmg
    6. 安裝後啟動程式

    首次啟動時通常會:

    • 要求螢幕錄影權限(macOS)或類似權限(Windows)
    • 這是為了截圖與讀取畫面內容

    步驟 2:只用瀏覽器版的「零部署」玩法

    如果你不想先搞本地模型,建議先用 瀏覽器版 LLM。

    1. 在工具設定裡選擇 Browser / Web LLM 模式
    2. 工具會指示你打開一個本機 Web UI(例如 http://localhost:xxxx)
    3. 確保你的瀏覽器支援 WebGPU(最新版 Chrome / Edge 通常可以)

    這種玩法的好處:

    • 不用裝 CUDA、不用拉模型
    • 先體驗「螢幕被 AI 盯著」的感覺
    • 確認需求後,再決定要不要搬到本地 LLM

    步驟 3:建立你的第一個觀察規則(關鍵字通知)

    目標:只要畫面出現某關鍵字,立刻彈出通知。

    操作示範:

    1. 在工具主畫面點 New Task 或「新增任務」
    2. 名稱:BI 報表錯誤偵測
    3. 觀察來源:選擇
    4. 目標應用程式視窗(例如 Chrome 中某個 tab)
    5. 或整個螢幕
    6. 條件設定:
    7. 模式:關鍵字比對
    8. 關鍵字:Error, Fail, Timeout(可多個)
    9. 動作設定:
    10. 桌面通知+提示音
    11. 按「儲存」並「啟動」任務

    接著打開你的 BI 報表頁,試著手動製造一個錯誤(或用假資料),確認工具會彈通知。


    步驟 4:接 Slack / Email Webhook,變成小工作流

    當你熟悉基本規則後,可以往「微型工作流」走。

    1. 在工具中新增一個動作類型:
    2. HTTP Webhook
    3. 填入你的 Slack Incoming Webhook URL 或自架的 Webhook endpoint
    4. 設定內容:
    5. 傳送 JSON 包含:任務名稱、觸發時間、螢幕截圖連結(如存到本機再由你自己的服務處理)

    範例工作流:

    • BI 報表錯誤 → 工具截圖 + 呼叫 Slack Webhook → 團隊頻道收到「報表錯誤 + 圖片」
    • 模擬器當機 → 工具重啟程式 + 呼叫 Email 發送服務 → 你手機立刻收通知

    如果你熟 CLI 工具,可以再加一層:

    • 工具觸發時執行某個 shell script
    • Script 裡再呼叫 curl、ffmpeg、python 等,組成一條完整 pipeline

    💡 關鍵: 透過 Webhook 或 shell script,這個螢幕監控工具可以無縫接到你原本的自動化腳本與團隊通知渠道。


    和雲端 LLM 混搭:把它當成練習用的「微型 agent」場

    雖然這個工具主打本地與瀏覽器 LLM,但你也可以:

    • 在設定裡新增 OpenAI / Claude API key
    • 把「畫面描述」或 OCR 結果,丟給雲端 LLM 做更複雜判斷

    例如:

    • 本地 LLM 負責:
    • 每幾秒截圖 + 基本文字偵測
    • 雲端 LLM 負責:
    • 分析整份畫面內容(例如圖表、表格)
    • 決定要不要通知你,或要不要執行下一步

    這樣的搭配好處:

    • 你可以在一個「單機環境」裡,練習設計 agent workflow
    • 之後要搬到更大規模的多 agent 系統(如企業自動化平台),概念是相通的

    建議學習路線:

    1. 先用預設 GUI + 本地 LLM 完成 2–3 個任務
    2. 再加上 Webhook,試一次和 Slack / Email 整合
    3. 最後才接 OpenAI / Claude,看整條流程能否穩定跑通

    這樣,你就多了一個很實際的「AI 工作桌」,幫你把螢幕上的重複瑣事自動化。


    🚀 你現在可以做的事

    • 前往 r/LocalLLaMA 原文 找到作者 GitHub 連結並下載專案
    • 安裝後建立一個簡單任務,例如監控 BI 報表錯誤並彈出桌面通知
    • 設定一個 HTTP Webhook,把觸發事件發到你的 Slack 或 Email,實際跑通一條小型工作流
  • 用瀏覽器跑大模型:WebLLM 實戰指南

    用瀏覽器跑大模型:WebLLM 實戰指南

    📌 本文重點

    • WebLLM 讓瀏覽器直接跑開源大模型
    • 透過 WebGPU 在本機硬體上做推理
    • 純前端 API,像用本地版 OpenAI 一樣簡單
    • 適合前端工具、教育場景與快速原型

    在瀏覽器本地跑 LLM 的好處,可以一句話說完:不用後端、跨平台、資料留在自己電腦裡——而 WebLLM 就是讓你用這種方式跑大模型的工具。

    💡 關鍵: WebLLM 讓你只用一個前端網頁,就能在本機私有環境中跑開源大模型,完全不需後端與 API 金鑰。


    核心功能:把 LLM 變成一個 <script>

    1. 直接在瀏覽器跑多種開源模型

    WebLLM 把多個主流開源模型打包成「瀏覽器可用版本」,你可以像引入前端套件一樣使用。

    • 支援模型示意(依官方更新為準):
    • Llama 系列(如 Llama 3、Llama 2)
    • Mistral / Mixtral 等英文、多語模型
    • 部分中文優化模型(需看官方 Model Zoo)
    • 不用自己轉權重:官方已提供 Web-friendly 模型格式(MLC 格式),可透過 CDN 或 GitHub 直接載入。

    可行動:
    1. 打開 WebLLM Model Zoo:https://github.com/mlc-ai/web-llm/tree/main/model
    2. 選一個輕量模型(如 7B 或以下)作為第一個嘗試,避免太大造成載入時間過長。


    2. 利用 WebGPU 在前端做推理

    WebLLM 的效能關鍵是 WebGPU:它讓瀏覽器可以直接用顯示卡算模型,而不只是 CPU。

    • 效能大概在哪個等級?
    • 筆電內建顯示卡(Mac M 系列、Intel/AMD iGPU):足夠跑小模型做聊天、摘要、翻譯
    • 獨顯桌機(RTX 系列):可跑較大模型,輸出速度接近簡單雲端 API
    • 你需要:
    • 支援 WebGPU 的瀏覽器(目前主力是新版 Chrome、Edge、Firefox Nightly、Safari Tech Preview)
    • 打開 WebGPU flag(某些瀏覽器仍在實驗階段)

    💡 關鍵: 只要啟用 WebGPU,你的瀏覽器就能用顯示卡跑 LLM,效能從「勉強可用」直接升級到「接近雲端 API」。

    可行動:先確認瀏覽器 WebGPU

    以 Chrome 為例:

    1. 更新到最新版本
    2. 在網址列輸入 chrome://flags
    3. 搜尋 WebGPU,將 Unsafe WebGPU 設為 Enabled
    4. 重新啟動瀏覽器
    5. 前往 https://webgpureport.org/ 檢查是否顯示已啟用

    3. 純前端 API:像呼叫本地版 OpenAI

    WebLLM 封裝了一套前端 API,你可以在 JS 裡這樣用:

    import { CreateMLCEngine } from "https://esm.run/@mlc-ai/web-llm";
    
    const engine = await CreateMLCEngine("Llama-3-8B", {
      initProgressCallback: (progress) => {
        console.log("載入進度", progress);
      },
    });
    
    const reply = await engine.chat.completions.create({
      messages: [
        { role: "user", content: "用繁體中文解釋什麼是 WebLLM" },
      ],
    });
    
    console.log(reply.choices[0].message.content);
    

    風格接近 OpenAI API,但完全在前端執行,不依賴後端。

    可行動:在 Codesandbox / StackBlitz 開一個空白 HTML + JS 專案,直接貼上上述範例測試。


    適合誰用:三種最常見場景

    1. 前端工程師:純前端 AI 小工具

    你可以把 WebLLM 當成「瀏覽器版 Ollama」,但只需前端。

    • 範例功能:
    • 文件上傳後,做摘要、關鍵字擷取
    • 表單輸入文字,即時翻譯或重寫
    • Chrome Extension 內建一個小型 AI 助理

    可行動:挑一個現有前端 side project(例如備忘錄、閱讀器),嘗試加一個「本地 AI 摘要」按鈕,只用 WebLLM,不建後端。


    2. 教育與隱私敏感場景

    如果你是:

    • 老師/家教:希望學生在課堂上用 AI,但不想所有問題都送到雲端
    • 企業內部:要處理合約、簡報草稿,不方便使用外部 API

    這時 WebLLM 的優點是:

    • 所有內容都在瀏覽器內運算,不上傳到第三方伺服器
    • 只需發一個 HTML 檔或內網服務給同事/學生即可使用。

    可行動:
    – 建一個簡單頁面:左側輸入、右側 AI 回覆,放在局域網,替代市售雲端聊天工具。


    3. PM / 設計師:快速原型 AI 功能

    你想 demo「這個產品如果有 AI 助理會長什麼樣」。

    • 不想等工程師建 API、串模型
    • 不想申請一堆金鑰

    WebLLM 的實用點:

    • 一個 HTML 檔就能 demo 聊天、問答、寫文案
    • Demo 完再決定要不要接正式後端 API。

    可行動:
    – Figma 設計完流程後,自己做一個「原型聊天頁」,用 WebLLM 模擬最終效果,拿去跟團隊溝通。


    10 分鐘跑起一個 WebLLM 聊天頁

    以下是一個最小可用範例,從 0 到能聊天,大致流程。

    步驟 1:建立 HTML 檔

    建立 index.html,放入基本 UI:

    <!DOCTYPE html>
    <html lang="zh-Hant">
    <head>
      <meta charset="UTF-8" />
      <title>WebLLM 本地聊天</title>
      <style>
        body { font-family: system-ui; max-width: 800px; margin: 20px auto; }
        #log { border: 1px solid #ccc; padding: 10px; height: 400px; overflow-y: auto; }
        .msg-user { color: #0055aa; margin: 4px 0; }
        .msg-ai { color: #333; margin: 4px 0; }
      </style>
    </head>
    <body>
      <h1>WebLLM 本地聊天</h1>
      <div id="log"></div>
      <textarea id="input" rows="3" style="width: 100%;"></textarea>
      <button id="send">送出</button>
      <script type="module" src="app.js"></script>
    </body>
    </html>
    

    步驟 2:在 JS 中載入 WebLLM

    建立 app.js:

    import { CreateMLCEngine } from "https://esm.run/@mlc-ai/web-llm";
    
    const logEl = document.getElementById("log");
    const inputEl = document.getElementById("input");
    const sendBtn = document.getElementById("send");
    
    function addMsg(text, cls) {
      const div = document.createElement("div");
      div.className = cls;
      div.textContent = text;
      logEl.appendChild(div);
      logEl.scrollTop = logEl.scrollHeight;
    }
    
    let engine;
    let messages = [];
    
    async function init() {
      addMsg("正在載入模型,請稍候……", "msg-ai");
      engine = await CreateMLCEngine("Llama-3-8B", {
        initProgressCallback: (p) => {
          console.log("載入進度", p);
        },
      });
      addMsg("模型載入完成,可以開始聊天", "msg-ai");
    }
    
    sendBtn.onclick = async () => {
      const content = inputEl.value.trim();
      if (!content) return;
      inputEl.value = "";
      addMsg(content, "msg-user");
    
      messages.push({ role: "user", content });
    
      // 控制上下文長度:只保留最近 10 則對話
      if (messages.length > 10) {
        messages = messages.slice(-10);
      }
    
      addMsg("AI 正在思考……", "msg-ai");
    
      const reply = await engine.chat.completions.create({
        messages,
        max_tokens: 512,
      });
    
      const text = reply.choices[0].message.content;
      messages.push({ role: "assistant", content: text });
    
      // 刪掉「AI 正在思考……」那一行
      logEl.lastChild.remove();
      addMsg(text, "msg-ai");
    };
    
    init();
    

    步驟 3:用本機開啟頁面

    1. 在資料夾中放好 index.html、app.js
    2. 用 VS Code Live Server、或簡單的開發伺服器開啟:
    3. Node 環境下可用 npx serve .
    4. 開瀏覽器(已啟用 WebGPU)訪問 http://localhost:3000 或對應網址。

    如果顯示模型載入成功,就能開始聊天。


    優化建議:讓速度和體驗更順

    1. 控制上下文長度

    • 不要用整個聊天紀錄,每次只帶最近 N 則對話
    • 實作方式如上範例,用 messages.slice(-10) 保留最近 10 則
    • 好處:
    • 減少推理時間
    • 降低記憶體消耗

    2. 壓縮 UI 日誌

    • 不需在 UI 顯示完整系統 prompt、或太長的技術訊息
    • 可以把多輪簡短問答整合成一段摘要,定期替換舊內容。

    3. 選模型時兼顧容量與速度

    • 初次嘗試優先選小模型(例如 4B、7B),觀察效能
    • 若顯示卡記憶體不足,載入過程可能失敗或非常緩慢,換更小模型即可。

    總結:先用 WebLLM 做一個小工具,再想後端

    WebLLM 的定位,可以簡化成一句話:讓你在瀏覽器裡,像呼叫 OpenAI 一樣用 LLM,但完全不需要後端與金鑰。

    💡 關鍵: 從一個靜態 HTML + JS 開始,你就能在瀏覽器裡跑大模型,快速驗證想法,再決定是否接入雲端服務。

    最實際的做法:

    1. 選一個你現在就想做的 AI 小功能(翻譯、摘要、助理)
    2. 用本文的聊天頁範例改成自己的需求
    3. 在團隊或課堂中 demo 本地 LLM 效果,再決定要不要接雲端 API。

    從一個 HTML 檔開始,你就能把「在瀏覽器跑大模型」變成真正可用的功能,而不是只停留在技術新聞上。

    🚀 你現在可以做的事

    • 在瀏覽器啟用 WebGPU,測試官方 WebLLM Demo 或 Model Zoo 中的 7B 模型
    • 建立一個最小版 index.html + app.js,照範例跑起本地聊天頁
    • 選一個現有前端專案(例如閱讀器或筆記),嵌入 WebLLM 按鈕實作「本地 AI 摘要」功能
  • HashAgent:一鍵分享、在地跑的 AI 代理

    HashAgent:一鍵分享、在地跑的 AI 代理

    📌 本文重點

    • HashAgent 用一條 URL 分享可用狀態代理
    • 所有設定編碼進網址,在瀏覽器本地跑模型
    • 適合團隊共享工具、PoC demo、隱私文本處理
    • 開發者可當無後端前端容器做快速試驗

    用一句話說清楚:HashAgent 是一個「用 URL 分享、在瀏覽器本地跑」的 AI 代理容器,讓你不用架伺服器,就能把一個預先設定好的 AI 小工具分享給同事或客戶。

    工具網址:https://hashagent.pages.dev/


    核心功能:把「會動的代理」裝進一條網址

    1. 用一條 URL 分享一個預先配置好的代理

    HashAgent 的設計很直覺:所有代理設定都被編碼進 URL,像是:

    • 使用哪個模型
    • 預設系統 prompt
    • 任務腳本(例如:「請幫我總結貼上的文件」)

    你只要:

    1. 打開 HashAgent:https://hashagent.pages.dev/
    2. 在設定區填好:
    3. 模型名稱
    4. 系統提示(System prompt)
    5. 任務描述或腳本
    6. 點擊產生/複製 URL,丟給同事

    對方打開連結就直接進入一個「可用狀態」的代理,不用再解釋怎麼切模型、怎麼寫指令。

    💡 關鍵: HashAgent 把完整代理配置嵌入網址,任何人點開就能直接用同一套設定。

    👉 可立即行動:

    • 想像你現在有一個固定的「會議紀錄總結」工作,把提示寫好,生成 URL,貼到團隊 Slack,讓大家以後都用這一個入口。

    2. 在瀏覽器端用 WebGPU 本地推論

    HashAgent 依賴瀏覽器 WebGPU 能力,在使用者的電腦上直接跑模型,好處很明確:

    • 文字內容不會送到外部伺服器
    • 沒有額外 API 費用
    • 測試 PoC 不用再申請雲端資源

    要讓它順利運作,你可以這樣檢查與調整:

    1. 使用支援 WebGPU 的瀏覽器:
    2. 建議:Chrome / Edge / Brave(版本越新越好)
    3. 在 chrome://flags 搜尋「WebGPU」,確認是啟用狀態(若已預設開啟可忽略)。
    4. 打開 HashAgent 頁面時,留意是否有「WebGPU not supported」類似提示,有的話換一個瀏覽器或機器測試。

    💡 關鍵: 使用者的瀏覽器與硬體決定推論是否能在本地完成,這是 HashAgent 的隱私與免伺服器優勢來源。

    👉 可立即行動:

    • 用自己的筆電和桌機各打開同一條 HashAgent URL,感受不同 GPU/CPU 下的速度差異。

    3. 支援自訂 Prompt 與任務腳本

    HashAgent 不是只有一個對話框,而是可以預設「代理該怎麼工作」:

    典型可設定內容包括(實際欄位以官方頁面為準):

    • System prompt:定義代理角色,例如:「你是一個專門做長文摘要的助手,只輸出三段摘要與三個行動建議。」
    • 任務腳本:針對一個固定流程,例如:
    • 接收使用者貼上的原文
    • 先輸出 3 句話摘要
    • 再輸出一個行動清單

    你可以把這些寫死在設定裡,然後一鍵分享:

    • 同事只要打開網址、貼文本,就能得到同樣格式的輸出
    • 測試不同版本的提示時,只要多產幾條 URL 對比

    👉 可立即行動:

    • 做兩條代理 URL:
    • A 版:摘要偏「精簡」
    • B 版:摘要偏「詳細」
    • 實際讓同事在會議前後各用一次,收集哪一版更好用。

    適合誰用:三類典型場景

    1. 團隊共享小工具:一鍵文檔總結代理

    情境:公司裡大家都在用 ChatGPT / Claude 檢查文件,但每個人 prompt 都不一樣,輸出品質參差不齊。

    用 HashAgent 可以:

    • 把「標準版」文檔總結流程寫成 system prompt
    • 固定輸出格式(例如:摘要、風險點、下一步行動)
    • 用一條 URL 分享到團隊 wiki / Notion

    效果:

    • 新人只要打開網址+貼文件,就能用同一套「公司標準」摘要模板。

    2. 內部 PoC:不用伺服器就能 demo 的代理

    情境:你是內部 AI 團隊,要給老闆看一個新的代理 workflow 構想,但還不想花時間架後端。

    做法:

    • 在 HashAgent 裡設定好流程 prompt
    • 選一個本地可跑的模型
    • 把生成的 URL 直接在會議現場打開 demo

    效果:

    • 不用申請雲帳號、API Key
    • Demo 環境就是瀏覽器,任何人都可以當場打開運行

    3. 個人隱私場景:本地處理敏感文本

    情境:

    • 合約書、履歷、公司內部簡報,不想丟出去雲端
    • 但又想用 LLM 做摘要、改寫、潤飾

    HashAgent 的本地推論特性很適合:

    • 打開自己的「合約總結代理」
    • 把 PDF 文本複製貼上
    • 整個過程只在自己機器上運算

    👉 可立即行動:

    • 做一條專門處理「履歷優化」的 HashAgent URL,只在求職階段自己用,且資料不離開裝置。

    實作教學:幾分鐘建立一個簡單 HashAgent

    以下用「一鍵文檔總結代理」當示範,步驟會以官方頁面目前常見結構為例(未來若 UI 調整,以頁面為準)。

    步驟一:打開 HashAgent 並選模型

    1. 進入:https://hashagent.pages.dev/
    2. 找到模型選擇欄(例如「Model」或類似欄位)。
    3. 選擇一個支援 WebGPU 的本地模型(通常會有預設選項)。

    如果頁面提供多個模型:

    • 選較小的模型:載入快、推論快
    • 選較大的模型:推論慢,但輸出品質可能更好

    步驟二:寫任務描述(System Prompt)

    在「System Prompt」或「Agent Prompt」欄位填入類似內容:

    你是一個專門為知識工作者服務的文檔摘要助手。
    使用繁體中文回答。請依照以下格式輸出:
    1. 三句話總結本文重點。
    2. 列出 3-5 個可行的下一步行動建議。
    3. 若本文有任何風險點或注意事項,請額外列出。

    這樣一來,任何人打開這條 URL,再貼入文本,都會得到相同格式的輸出。


    步驟三:生成分享 URL

    在 HashAgent 頁面通常會有某種「Share」或「Copy URL」按鈕,底層邏輯是:

    • 把你的設定序列化寫入 URL hash 或 query string
    • 例如:https://hashagent.pages.dev/#... 或 ?config=...

    操作方式:

    1. 點擊「Generate / Copy URL」
    2. 取得一條很長的連結
    3. 貼到:
    4. Slack / Teams 群組
    5. 公司內部 wiki
    6. 產品 demo 文檔

    👉 可立即行動:

    • 做好第一條代理後,請兩位同事用它來總結同一份文件,觀察輸出是否一致,微調 prompt。

    如何在不同瀏覽器 / 機器上測試效能

    HashAgent 的效能很依賴硬體與瀏覽器,以下是一個簡單測試流程:

    1. 準備一條相同的 HashAgent URL
    2. 在以下環境各測一次:
    3. Windows + Chrome
    4. macOS + Chrome / Safari(視 WebGPU 支援情況)
    5. Linux + Chromium 或支援 WebGPU 的瀏覽器
    6. 測量兩個指標:
    7. 模型載入時間(從進入頁面到可以輸出第一段文字)
    8. 單次完整回應時間(例如處理同一篇 1,000 字文章)

    若遇到太慢或無法運行,可以:

    • 換較小的模型
    • 確認瀏覽器版本已更新
    • 在設定裡調低生成長度或溫度(根據 UI 選項調整)

    💡 關鍵: 透過在不同環境測量載入與回應時間,你可以實際評估 HashAgent 是否符合團隊或產品 demo 的效能需求。


    與其他工具搭配:向量庫、Obsidian、VSCode

    HashAgent 目前偏「單體代理」,但你可以把它當作前端容器,搭配其他工具:

    • 搭配本地向量庫:
    • 在後端用你熟悉的工具(如 LlamaIndex、Local vector DB)先做檢索
    • 把檢索後的上下文貼到 HashAgent 中,由代理負責總結/解釋

    • 搭配 Obsidian:

    • 在 Obsidian 裡選一篇筆記,複製內容
    • 貼到 HashAgent 的「摘要代理」裡
    • 把輸出貼回新筆記,形成標準化摘要

    • 搭配 VSCode:

    • 將部分程式碼或 log 貼入 HashAgent 的「debug 代理」URL
    • 以預先設定好的 prompt 輔助 debug 或重構

    👉 可立即行動:

    • 建兩條代理 URL:一個專門負責「Obsidian 筆記摘要」、一個專門負責「程式碼解說」,分別收藏在瀏覽器書籤列。

    給開發者:把 HashAgent 當成前端容器

    如果你在做 LLM workflow、agent framework,HashAgent 可以扮演:

    • 「無後端 Demo 殼」:
    • 把整個 workflow 壓縮成一組 prompt + 設定
    • 用 HashAgent 的 URL 形式丟給使用者試用

    • 「早期用戶回饋管道」:

    • 你可以快速產出多個版本(不同 prompt、不同模型)
    • 用多條 URL 做 A/B 測試

    • 「內部教學模板」:

    • 把教學代理(例如:教如何寫公司標準文件)包成 URL
    • 給新員工在瀏覽器裡直接操作

    當你準備好要產品化時,再把這些代理邏輯搬到自己的前端 + 後端架構裡即可。


    小結:先從一個「可分享的摘要代理」開始

    如果你不知道從哪裡開始,建議順序:

    1. 打開 https://hashagent.pages.dev/
    2. 選一個預設模型
    3. 寫一個「公司標準的文檔摘要 prompt」
    4. 生成 URL,貼到團隊群組

    當你能用 HashAgent 成功分享第一個「會動」的代理給同事,你就掌握了這個工具的核心價值:用 URL 把 AI 工作流程裝起來,讓任何人打開就能用,且資料留在自己的裝置上。

    🚀 你現在可以做的事

    • 立刻打開 HashAgent,建立一條「公司標準文檔摘要」URL 並分享到團隊 Slack 或 Teams
    • 在兩台不同設備上用同一條代理 URL 測試 WebGPU 效能,確認是否適合正式使用
    • 為個人敏感資料(履歷或合約)設計一條專用 HashAgent 代理 URL,加入瀏覽器書籤以便重複使用
  • 在手機跑 27B 模型:Bonsai 27B 實戰上手

    在手機跑 27B 模型:Bonsai 27B 實戰上手

    📌 本文重點

    • 27B 模型壓到 3.8GB
    • 本地跑在 iPhone 與瀏覽器
    • 數學與程式推理仍可用
    • 適合隱私優先的 AI 場景

    用一句話說完:Bonsai 27B 讓一個原本要 50GB 以上的大型推理模型,縮到不到 4GB,在你的 iPhone 或瀏覽器裡本地跑推理。

    原始資訊與 Demo:


    核心功能:為什麼 1-bit、4GB、WebGPU 很關鍵?

    1. 1-bit dense 量化:54GB 壓到 3.8GB,還保留 90% 能力

    Bonsai 27B 原始是 27B 參數的大模型,正常 fp16 大概要 50GB 以上。PrismML 用自家的 1-bit dense 量化,直接把模型縮到約 3.8GB(-93%),官方與社群測試顯示:

    • 整體表現:約保留 90% 原始性能
    • 在數學與程式碼推理上的分數,幾乎不受影響

    💡 關鍵: 27B 級模型從 50GB+ 壓到 3.8GB,代表大型模型首次更接近一般裝置可本地部署的範圍。

    這對你代表什麼?

    • 一般高階筆電、桌機的 GPU/WebGPU 就能跑 27B 級模型
    • iPhone 等手機只要有足夠 RAM,也能載得下整個模型
    • 做產品 PoC 時,不用再想「我要租幾張雲端 GPU」才能展示效果

    你可以立刻做的事:

    2. 本機 / 手機 / 瀏覽器推理:速度與隱私的平衡點

    Bonsai 27B 的壓縮搭配 WebGPU + 客製 Kernel,讓它可以在:

    • 桌機瀏覽器(Chrome、Edge、Arc 等支援 WebGPU 的版本)直接跑
    • iPhone 上透過支援 WebGPU 的瀏覽器或 App 跑本地推理

    實際體感: 依硬體而異,但大致區間如下:

    • 答案生成速度:中高階筆電可達 20~40 tokens/s,接近雲端中階模型
    • 手機上:會慢一些,但仍能用於聊天、寫作輔助、簡易程式碼推理

    💡 關鍵: 本地推理不只是能跑,速度已進到可互動使用的區間,隱私與延遲也因此開始有實際優勢。

    隱私優勢:

    • 所有輸入(聊天內容、筆記、程式碼)都留在裝置上,不經過雲端 API
    • 適合公司內部敏感資料、個人私密日記、會議記錄摘要等情境

    你可以立刻做的事:

    • 打開支援 WebGPU 的瀏覽器,跑官方 Demo:確認你的硬體大概能跑到什麼速度(Demo 入口通常在 PrismML 新聞頁或 Hugging Face Space)。

    3. 數學與程式碼推理表現:不只是「能跑」,而是「能用」

    依據 PrismML 自家基準測試(見 Reddit 討論:https://www.reddit.com/r/LocalLLaMA/comments/1uwm2hd/prismmls_bonsai27b_benchmarks/),Bonsai 27B 的量化版本:

    • 在數學、程式碼題目上的分數,與原始模型接近
    • 部分測試甚至優於廣為討論的 Qwen 3.7 27B 量化版本

    💡 關鍵: 有趣的是,這類極端壓縮不一定先犧牲數學與程式碼推理,實際上它在這兩類任務仍維持可用水準。

    實際體感上,它適合:

    • 解 LeetCode 等級的題目、協助理解他人程式碼
    • 做數學證明草稿、檢查推理步驟是否有漏洞

    你可以立刻做的事:

    • 準備一段你自己寫的程式碼或演算法題目,在 Demo 裡測試它的 debug 能力,看它能不能說出具體修改建議。

    適合誰用?具體場景與做法

    1. 個人使用:離線寫作、私密筆記與聊天

    場景:

    • 不想把日記、心理對話丟到雲端模型
    • 在飛機、車上等無網路環境寫作

    可以怎麼用:

    • 在桌機瀏覽器開 Bonsai 27B WebGPU Demo,寫文章時讓它幫你改標題、想小節架構
    • 在支援的手機上安裝對應 App 或透過瀏覽器,做離線聊天與筆記整理

    2. 開發者:簡易 coding 助手與邊緣 AI PoC

    場景:

    • 做一個「本地程式碼助手」Side project
    • 想給客戶看「產品內嵌 on-device 聊天/推理」的原型

    可以怎麼用:

    • 使用 Bonsai 27B 的 gguf 版本,搭配像 llama.cpp 或其他本地推理框架,在筆電上跑一個命令列助手
    • 在 Web 前端整合官方 WebGPU 推理程式碼,做一個「瀏覽器內跑的大模型聊天框」,無需後端 GPU

    3. 產品團隊:在 App 裡塞 on-device 聊天 / 推理

    場景:

    • 筆記 App 想加「在本機摘要筆記」功能
    • 知識庫產品想做「邊緣 FAQ 助手」,部署在客戶內網而不是雲端

    可以怎麼用:

    • 以 WebGPU 版 Bonsai 27B 做前端推理引擎,後端只處理權限與資料存取
    • 在 iOS App 裡預載或動態下載壓縮模型,讓使用者自主選擇是否開啟「完全本地 AI 模式」

    什麼時候考慮不用它?

    • 若你需要 GPT-4 級別的長上下文寫作、極高準確度的工具調用
    • 若手機使用者硬體普遍較舊,無法提供足夠 RAM 或 WebGPU 支援

    怎麼開始:從 WebGPU Demo 到 iPhone 實跑

    Step 1:在桌機用 WebGPU Demo 跑起來

    1. 確認瀏覽器支援 WebGPU
    2. Chrome / Edge:版本需在 113+,建議更新到最新穩定版
    3. 在 chrome://flags 搜尋 WebGPU,確保已啟用(某些平台預設已開)

    4. 進入 Demo 網頁

    5. 從 PrismML 新聞頁:https://prismml.com/news/bonsai-27b 找到 WebGPU Demo 連結
    6. 或在 Hugging Face 上搜尋 Bonsai 27B WebGPU 找到 Space

    7. 測試推理

    8. 選擇 Bonsai-27B 1-bit 模型版本
    9. 輸入一個你熟悉的程式題目或寫作題目,觀察回答速度與品質

    常見坑:若載入卡住或速度極慢,通常是 WebGPU 未啟用,或顯示卡太舊。換瀏覽器或更新驅動是第一步。

    Step 2:在 iPhone 嘗試跑 Bonsai 27B

    目前 iPhone 端的整合仍在快速變動階段,Apple 也被報導正在測試 PrismML 技術(參考:https://www.reddit.com/r/LocalLLaMA/comments/1ux4cn2/apple_in_talks_with_startup_prismml_that_shrinks/)。以下是一般建議路線:

    1. 確認機型與系統
    2. 建議使用 A17 / M 系列晶片的機型,RAM 越大越好(Pro 機型優先)
    3. iOS 更新到最新版本,以取得最佳 WebGPU / Metal 支援

    4. 嘗試透過瀏覽器 Demo

    5. 使用支援 WebGPU 的 iOS 瀏覽器(未來 Safari 正式支援後會更穩定)
    6. 開啟 Bonsai 27B Web Demo,選最低階參數設定,測試生成速度

    7. 留意記憶體與耗電

    8. 模型雖然不到 4GB,但推理仍會吃 RAM;建議在單一 App 裡跑,不要開太多背景程式
    9. 長時間推理會發熱,適合短對話與輕量寫作,而非長時間批量任務

    常見坑:

    • 推理中 App 被 iOS 回收:代表 RAM 不足,只能調小 context 長度或改用桌機。
    • 首次載入模型時間偏長:正常現象,可考慮在 App 中做「背景預載」。

    Step 3:整合到你的應用(基本架構示意)

    以 Web 應用為例,一般做法是:

    使用者瀏覽器
     ├─ UI:聊天框 / 筆記編輯器
     ├─ WebGPU 推理:載入 Bonsai 27B 壓縮模型
     └─ 本地記憶體:暫存對話與提示
    
    後端伺服器
     ├─ 使用者認證 & 權限
     ├─ 資料索引(向量庫、文檔)
     └─ 僅在用戶同意時返回資料,讓前端本地推理
    

    你可以:

    • 直接參考 PrismML 提供的 WebGPU Kernel 實作,把它包成一個 JS/TS SDK
    • 將模型檔放在 CDN,首次使用時下載到瀏覽器 IndexedDB 或 App 沙盒中

    本地 Bonsai 27B vs 雲端 API:成本與隱私快速比較

    項目 Bonsai 27B 本地推理 雲端 API(如 GPT-4)
    成本 一次下載模型,之後幾乎零邊際成本,主要是硬體耗電 依 tokens 計費,流量大時費用顯著
    延遲 裝置好時可達 20–40 tokens/s,無網路也能用 需經網路與伺服器排隊,遇高峰時延遲高
    隱私 所有內容留在本機,適合敏感資料 對話上傳到雲端,需信任供應商
    維護 需自己管理模型更新與相容性 供應商幫你維持最新模型與基礎設施

    簡單判斷:

    • 若你重視隱私、成本可控、願意接受略低於頂級雲端模型的效果,Bonsai 27B 是合適的本地方案。
    • 若你的產品主打極高準確度、長上下文、工具調用整合,仍需要雲端 API 作為主力,Bonsai 27B 可做輔助或離線備份模式。

    小結:下一步你可以做什麼?

    1. 用桌機開 Bonsai 27B WebGPU Demo,測試寫作與程式碼題目,感受性能。
    2. 若你是開發者,下載 Hugging Face 量化模型,在本地框架中跑一個簡單聊天助手。
    3. 思考你的產品裡哪個功能最需要「本地推理+隱私」,從那一點開始嘗試嵌入 Bonsai 27B。

    🚀 你現在可以做的事

    • 打開 PrismML 官方新聞頁,直接進 WebGPU Demo 測你的裝置速度
    • 到 Hugging Face 搜尋 prism-ml/Bonsai-27B-gguf,下載量化模型做本地測試
    • 拿一段你自己的程式碼、筆記或寫作題目,驗證它是否符合你的實際場景
  • 用瀏覽器跑 Gemma 4 控機器人

    用瀏覽器跑 Gemma 4 控機器人

    📌 本文重點

    • 只用瀏覽器即可完全離線跑 Gemma 4
    • 結合 WebSerial 可直接控制機器人與 IoT
    • 純前端即可實作迷你 AI agent 控制硬體

    不想把資料丟雲端、又想用 LLM 控機器人?Gemma 4 + Transformers.js + WebGPU 讓你只靠瀏覽器就能離線跑模型、還能直接控制硬體。

    參考實作影片:Gemma 4 fully offline + WebGPU + Reachy Mini(Reddit)
    https://www.reddit.com/r/LocalLLaMA/comments/1ta9mmd/gemma_4_running_fully_offline_on_webgpu_with/


    核心功能:一台電腦 + 一個瀏覽器就夠

    1. 完全離線的瀏覽器 LLM

    這套組合的核心是:

    • Gemma 4:Google 開源 LLM 系列,支援多種量化格式(GGUF / ONNX / JS)。
    • Transformers.js:在瀏覽器裡跑 Hugging Face 模型的 JavaScript 函式庫。
    • WebGPU:用你電腦的顯示卡在「前端」跑推理,不用後端伺服器。

    你可以做的事:

    1. 在本機開啟支援 WebGPU 的瀏覽器(Chrome / Edge / Brave)。
    2. 把公司文件、程式碼丟進前端頁面,讓 Gemma 4 在本機推理,不經過任何外部 API。

    實際效果:隱私資料留在電腦裡,沒有雲端 API log,也不需要申請 OpenAI Key 或部署後端。

    💡 關鍵: 只要一台支援 WebGPU 的電腦與瀏覽器,就能完成完全離線、無雲端依賴的 LLM 推理與控制。


    2. 透過 WebSerial 控制機器人 / IoT

    Reddit 的 demo 裡,用 Transformers.js 跑 Gemma 4,搭配 WebSerial API 直接控制 Reachy Mini 機器人。

    流程概念:

    1. 使用者在瀏覽器輸入:「向右揮手打招呼」。
    2. Gemma 4 把自然語言轉成一段控制指令(例如 JSON 或簡單 DSL)。
    3. JavaScript 把指令透過 WebSerial 傳給機器人控制板(例如 Arduino / microcontroller)。

    你可以照做的行動:

    • 先用 Arduino + USB 線,把一顆 LED 或伺服馬達接到電腦。
    • 寫個簡單的序列通訊協議,像:LED_ON、LED_OFF、SERVO:45。
    • 在網頁裡用 JavaScript:

    js
    const port = await navigator.serial.requestPort();
    await port.open({ baudRate: 115200 });
    // 把 LLM 產生的指令寫進 serial

    先從「LLM 控燈」,再慢慢升級到「LLM 控機器人手臂」。


    3. 純前端的迷你 AI Agent

    有了本地 LLM + WebSerial,你可以在瀏覽器裡做一個小型 AI agent。

    • 理解任務:使用者輸入「每 10 分鐘幫我量一次溫度」。
    • 規劃步驟:Gemma 4 產生一段 JSON 計畫,例如:

    json
    {
    "action": "loop",
    "interval": 600,
    "task": "read_temp"
    }

    • 執行控制:前端 JS 解析 JSON,呼叫對應的 serial 指令。

    可以做的練習:

    1. 先讓 LLM 只輸出固定格式 JSON(用 system prompt 約束)。
    2. 前端寫一個 parser,檢查 JSON 格式合法才發送給硬體。
    3. 加上「模擬模式」(不連接硬體),先在 console 測試 agent 邏輯。

    適合誰用?三種場景舉例

    1. 教學場景:高中 / 大學生的 AI + 機器人課

    • 不用架伺服器,電腦教室只要能開 Chrome。
    • 學生可以:
    • 改 prompt 看機器人動作改變。
    • 寫自己的小指令語言(例如 MOVE LEFT 10)。
    • 觀察 LLM 如何把自然語言轉成這套語言。

    行動建議:

    • 用一台 Reachy Mini 或任何 Arduino 小車當教材。
    • 提供學生一個預先寫好的 HTML + JS 專案,只讓他們改 prompt 和指令 mapping。

    2. 實驗場景:研究邊緣運算 / 隱私的工程師

    • 需要在醫療、工廠、或無網路環境下跑 LLM。
    • 想測試「模型就在裝置上」的延遲和可靠性。

    行動建議:

    • 把現有的 Python LLM pipeline,拆成:
    • 前端:Transformers.js + WebGPU 跑推理。
    • 後端(選配):只收集匿名統計,不傳原始輸入。
    • 對比雲端 API 與本地推理在速度、穩定度上的差異。

    💡 關鍵: 在醫療或工廠等高隱私、高可靠場景,本地 LLM 能在不傳輸原始資料的情況下提供近乎即時的推理與控制。


    3. 家用場景:DIY 簡易家電自動化

    • 例如:
    • 「用自然語言控制窗簾、風扇」
    • 「讓 LLM 幫你排家中設備的定時腳本」

    行動建議:

    • 先用 USB 連接一塊 ESP32 / Arduino 開發板,只控制一顆繼電器或 LED。
    • 設計簡單語句:
    • 「晚上 10 點關燈」→ 轉成 SCHEDULE:22:00:OFF。
    • 用 LLM 把上面這種語句自動產生,再由 JS 解讀和排程。

    怎麼開始:從開啟 WebGPU 到控制第一顆 LED

    步驟一:開啟瀏覽器 WebGPU

    以 Chrome 為例:

    1. 更新到最新版(至少 120 以上會較穩定)。
    2. 在網址列輸入 chrome://flags。
    3. 搜尋「WebGPU」,啟用:
    4. WebGPU(或 Unsafe WebGPU 視版本而定)。
    5. 重新啟動瀏覽器。

    行動檢查:


    步驟二:從 Hugging Face 抓 Gemma 4 模型

    常見三種格式:

    格式 名稱示例 特點 適合誰
    GGUF gemma-4b-it-q4_0.gguf 量化後較小,適合 CPU/GPU 混合 已熟悉 ggml / llama.cpp 生態的人
    ONNX gemma-4b-it.onnx 通用,很多推理引擎支援 想跨平台跑推理的開發者
    JS Transformers.js 專用權重 直接在瀏覽器載入 前端工程師、想快速起跑的人

    操作建議:

    1. 到 Hugging Face 搜尋「Gemma 4」模型庫(例如 google/gemma-2-2b-it,實際名稱依官方更新為準)。
    2. 找到有 transformers.js 或 onnx 標籤的 repo。
    3. 把權重檔放在自己的靜態網站(或本機 dev server)供前端載入。

    Transformers.js 官方文件:
    https://huggingface.co/docs/transformers.js

    💡 關鍵: 透過 Transformers.js 專用權重,可直接在瀏覽器載入 Gemma 4,省去自建推理後端的成本與複雜度。


    步驟三:在瀏覽器跑起簡單 Chatbot

    最低限度的前端結構:

    <script type="module">
      import { pipeline } from '@xenova/transformers';
    
      const chat = await pipeline('text-generation', 'path/to/gemma4/model');
    
      async function ask(prompt) {
        const out = await chat(prompt, { max_new_tokens: 128 });
        console.log(out[0].generated_text);
      }
    
      ask('你現在是一個 Arduino 助理,請用 JSON 說明如何讓 LED 閃爍。');
    </script>
    

    行動建議:

    • 先在 console 裡確認模型可以正常回答,再加上簡單的 <textarea> + <button> 當聊天介面。

    步驟四:把 Chatbot 接到 WebSerial(Arduino)

    1. Arduino 端草稿:

    “`cpp
    void setup() {
    Serial.begin(115200);
    pinMode(13, OUTPUT);
    }

    void loop() {
    if (Serial.available()) {
    String cmd = Serial.readStringUntil(‘\n’);
    if (cmd == “LED_ON”) digitalWrite(13, HIGH);
    if (cmd == “LED_OFF”) digitalWrite(13, LOW);
    }
    }
    “`

    1. 前端 WebSerial + LLM:

    “`js
    async function connectSerial() {
    const port = await navigator.serial.requestPort();
    await port.open({ baudRate: 115200 });
    const writer = port.writable.getWriter();
    return writer;
    }

    async function sendCommandFromLLM(userText, writer) {
    const response = await chat(使用者的指令:${userText}
    請只回應一行指令,LED_ON 或 LED_OFF
    );
    const cmd = response[0].generated_text.trim();
    await writer.write(new TextEncoder().encode(cmd + ‘\n’));
    }
    “`

    1. 實際試用:

    2. 在頁面輸入「開燈」→ LLM 產生 LED_ON → 燈亮。

    3. 在頁面輸入「關燈」→ LLM 產生 LED_OFF → 燈熄。

    這就是從「純前端 LLM」到「瀏覽器裡的迷你 AI agent」的第一步。


    小結:從簡單控制開始,一步步加功能

    建議的練習路線:

    1. 第一階段:在瀏覽器跑起 Gemma 4 chatbot,確認 WebGPU 正常。
    2. 第二階段:用 WebSerial 控制一顆 LED 或一個伺服馬達,先用固定按鈕測試。
    3. 第三階段:讓 LLM 產生中介指令(JSON 或簡單 DSL),由 JS 驗證後再送給硬體。
    4. 第四階段:加入簡單記憶和排程,做出「瀏覽器內的小型 AI agent」。

    只要一台支援 WebGPU 的電腦、一顆開發板,就能在客廳或教室裡體驗「完全離線的 LLM 控機器人」。


    🚀 你現在可以做的事

    • 到 Hugging Face 下載一個支援 Transformers.js 的 Gemma 4 模型,放到本機靜態伺服器測試載入
    • 依文中示例寫一個最簡單的前端 Chatbot,確認在你的瀏覽器上能透過 WebGPU 正常推理
    • 準備一塊 Arduino 或 ESP32,照示例建立 LED_ON / LED_OFF 協議,實作第一個「LLM 控燈」實驗