InfoQ 播客《The Future of Web Apps: Will AI Agents Generate UIs on the Fly?》由 Olimpiu Pop 主持，來賓 Rachel Lee Nabors 曾任 React 核心團隊成員，參與 react.dev 與 reactnative.dev，也長期投入瀏覽器、W3C 標準與開發者體驗。她在節目中介紹自己重回工程領域後打造的 Mima（mima.social）：一個本地優先的社群與新聞聚合器，目標是讓使用者在同一個介面查看、回覆來自 X、LinkedIn、Bluesky、Mastodon 等網路的內容。她指出的問題很具體：各大社群平台形成封閉圈層，使用者被迫在不同 App 間切換；而許多以大型語言模型（LLM）包裝的應用，會把使用者輸入送到第三方伺服器，帶來隱私、成本與延遲問題。
本地優先與小語言模型
Mima 的設計刻意避開「把個人資料集中到伺服器」的模式。Nabors 表示，自己不想持有他人的私人訊息，也不願面對各國政府要求交出特定使用者私訊的風險，因此 Mima 以瀏覽器原生 Web API 為基礎，在裝置端建立個人的社群關係圖，讓資料留在本機。這也帶來離線可用與較低雲端基礎設施成本的優點。她批評早期 LLM 應用常見的「包裝器」做法：使用者輸入被送到遠端推論，資料可能被用於訓練，應用的 API 成本隨呼叫次數線性增加；多模態模型在執行多數工作時，能耗甚至可能達到必要值的四倍。這些成本最後會轉嫁給使用者，也讓 PII（個人可識別資訊）暴露風險升高。
因此 Mima 偏好小語言模型（SLM）。SLM 是參數量較小、可直接在裝置端或低成本環境執行的模型，適合摘要、分類、判斷是否需要呼叫工具等任務。Nabors 一開始用 Claude Sonnet 摘要對話串，但很快對把私人訊息送往雲端感到不安；於是她建立評估流程，搭配後處理，讓 Llama 3.2B 在本機摘要對話的表現追上 Claude Sonnet。她指出，Llama 3.2B 受過大量使用者資料訓練，對人類對話摘要確有優勢，但未必適合偵測毒性內容或判斷圖片是否含有令人不安的內容；這類工作可能需要更小、更專門的模型。Mima 的多個模型功能都採使用者主動開啟，額外模型不會預設下載，因為那會佔用儲存空間與運算資源。
評估、黃金資料集與取捨
Nabors 強調，模型選擇不能靠朋友推薦或當下熱門程度。她引用 Hamel Husain 的評估方法，並把 evals 視為「AI 領域的測試驅動開發」。流程是先準備真實資料，例如自己熟悉的 X 或 LinkedIn 對話串，親手寫下期望摘要，再用大型模型建立基準；接著把 Qwen、Gemma、Llama 3.2B 等小型候選模型放進同一套測試。由於生成結果不具決定性，同一個模型與輸入通常要跑三次，觀察主題是否被完整捕捉、能否指出對話中對應的位置、輸出格式是否正確，以及延遲高低。她也會加入模糊化或人工構造的對話，建立黃金資料集，讓它進入 CI/CD 流程；日後有新模型出現，就能直接放進評估，判斷是否值得替換。
節目中舉例，Gemma 4 在當時很熱門，但實際測試後，它在摘要任務上不但沒有比 Llama 3.2B 好，還會明顯增加延遲。這說明「最佳模型」取決於任務、硬體與資料。評估通常要在準確度與速度間取捨，開發者必須先定義哪個指標更重要，再選擇模型、提示詞與前處理方式。Mima 也使用 Phoenix 這類評估工具來輔助比較。對需要審核留言、檢查不友善內容的社群客戶端而言，摘要模型未必是最合適的工具，可能需要另一組專門模型；但原則是功能必須可選擇、可解釋，且不應預設把使用者資料送出裝置。
本地優先的真實限制
本地優先不等於必然低延遲。Nabors 提到，這是訪談中較反直覺的發現：在本機跑模型，可能比呼叫雲端模型更慢，因為小型模型算力較弱，且裝置效能差異很大。舉例來說，Gemma 4B 在一台效能不錯的 Mac 上執行，仍可能受限於晶片與 Metal 加速能力；舊機器自然不如搭載 M5 晶片的新機。這讓測試必須知道目標使用者是誰。Mima 初期的目標族群是使用現代 MacBook Pro 的專業使用者，但若裝置馬力不足，仍可退回雲端；重點是，開源小模型即使跑在雲端，通常也比直接使用 ChatGPT 或 Claude API 便宜。
另一個限制是資料生命週期。Mima 目前將超過 30 天的內容視為可回收資料，像舊雜誌一樣清除，只保留真正需要的個人偏好與人際關係。Nabors 認為，多數應用本質上是「資料庫加上 API 與 UI 層」，代理也不例外；真正需要長期保存的是使用者喜歡讀什麼、與誰有關係等少量上下文，這些可以緊湊地存成文字檔。不過，這種做法也代表使用者可能面臨本機資料遺失風險，未來或許需要雲端 VM 或備援方案，但那會牽動另一組本地優先的設計決策。
從 OS 代理到 A2UI：介面將被重組
訪談後半把視角拉到應用架構。Nabors 認為，個人代理會成為「殺死所有消費型軟體」的入口，尤其是作業系統層級的代理。Google、Microsoft、Apple 等平台擁有者都想掌握使用者與世界互動的介面，因為那代表廣告、追加銷售與商業機會。節目提到 Amazon 對 Perplexity 的代理瀏覽器 Comet 採取法律行動，背後正是平台不願被降級成單純 API 與價格比較。對使用者而言，他們往往只想要答案或完成一件事，並不想造訪網站或下載 App；這也是為什麼以 Claude 代為搜尋、直接看 Google AI 摘要的行為會持續增加。
在介面生成方面，Nabors 提到 A2UI 這類標準：API 可把資料的 JSON schema 傳給 AI 助理，助理再依設計系統即時組合出符合需求的元件，例如圖片、下一步按鈕與價格。這之所以可行，一部分來自 React 等生態長期把 UI 元件化的成果，讓介面可以像積木般拼接。但她也提醒，代理要可靠地生成介面，前提是資訊概念已被標準化，例如股票代號、漲跌等有共同表示方式。企業對消費者（B2C）市場可能逐漸收斂為 API 與資料庫，競爭重心轉向履約能力；企業對企業（B2B）則相反，互通性與開放標準才是護城河。企業若只用 vibe coding、以自然語言快速生成程式來做自家儀表板，短期可行，卻難以和會計師、供應商、既有生態互通，QuickBooks、Shopify、Salesforce 的價值正來自這種共同語言。
工程師的角色轉變
Nabors 認為，只教人快速生成 App 的訓練營模式已走到盡頭，因為「做出東西」的門檻正在消失，真正的難題是規模化、可維護性與長期品質。她以 React 團隊為例，系統複雜到沒有人能完全掌握每個細節；如今 AI 還能在此基礎上做出更複雜的系統，人類若要參與，必須更懂電腦科學基礎、資料庫、系統設計、加密格式，也要理解 LLM 的數學原理，才能和代理討論延遲、成本與架構取捨。程式碼變得便宜後，品質把關、推理能力與協作能力反而更重要；與代理的關係應是共同修改與提升品質，而不是把輸出直接變成 PR。
整體來看，這場對談把本地優先、小模型評估、硬體限制、OS 代理與 UI 標準串成一條線：AI 不會單純讓 Web 應用消失，而是把競爭從「誰有 App」推向「誰能掌握標準、資料與使用者介面」。本地優先提供隱私與成本優勢，但絕非免費；它需要評估、硬體偵測、雲端備援與清楚的資料保留策略。對開發團隊而言，越早建立黃金資料集、理解模型取捨，並投資開放標準與系統基本功，越能在代理驅動的介面時代保有選擇權。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。