一個 API 引發的陣營對立
2025 年 5 月，Chromium 團隊在 blink-dev 郵件列表上發布了「Intent to Prototype: Prompt API」——一個讓網頁開發者直接透過 JavaScript 呼叫瀏覽器內建語言模型的 API。幾個小時內，Mozilla 在自家的 standards-positions 倉庫中給出了明確的回應：反對。
這不是一次簡單的技術分歧。它觸及了瀏覽器生態系統中最敏感的命題——當 AI 能力深入瀏覽器本身時，誰來決定開發者可以怎麼用它、用戶的資料去了哪裡、以及這個功能會不會讓網路變得更加封閉。
Chrome 的 Prompt API 提案，簡單來說，就是讓網頁透過一行 LanguageModel.create() 就能在瀏覽器端直接操作一個本地語言模型，不需要引入任何第三方套件或雲端 API。開發者可以 prompt、可以 streaming、可以設定 system prompt，所有運算都在用戶的裝置上完成。
聽起來很方便，對吧？但 Mozilla 看到的，是一個潛在的標準災難。
一場醞釀已久的對抗
Mozilla 的回應由工程師 bgrins 代表提交，不是輕描淡寫的「我們不確定」，而是完整的反對立場聲明。他明確指出，Mozilla 對 Prompt API 的態度與先前對 Writing Assistance APIs 的看法一致——這些 API 鼓勵開發者依賴特定模型的輸出行為，從而破壞了跨瀏覽器的互操作性。
這個論點不是憑空而來。Prompt API 的設計目標之一是「允許開發者控制語言模型的取樣參數（temperature、topK）」，但這些參數在不同模型之間的行為可能完全不同。Chrome 用的是 Gemini Nano 的變體，Edge 用的是 Phi-4-mini，兩者對同樣的參數設定反應迥異。開發者若為了某個瀏覽器寫死 prompt 格式，換到另一個瀏覽器就可能完全失效。
Mozilla 的立場文件寫道：
「開發者很可能希望根據模型微調 prompt 和其他功能，這會導致他們針對特定實現進行開發——例如 Edge 的 Phi-4-mini——這會使得在其他瀏覽器或模型上的表現更差。」
這不是一個理論上的風險。在實際開發中，這種現象已經出現：某些網站為了 Chrome 的翻譯 API 做了最佳化，結果在 Firefox 上綁手綁腳；一些使用 Chrome 專屬擴充功能 API 的網站，直接在非 Chromium 瀏覽器上顯示「不支援」。如果 Prompt API 進入標準，同樣的模式會在 AI 領域重演。
Chrome 正在醞釀什麼
要理解 Mozilla 為何如此警戒，需要先看清楚 Chrome 正在做的事情。
Chrome 的 Prompt API 提案透過 W3C 的 Web Machine Learning Community Group 推動，發起人是 Chrome 團隊的 Domenic Denicola。根據他在 blink-dev 上的說明，這是一個 JavaScript API，允許開發者：
- 建立一個語言模型會話（
LanguageModel.create()） - 傳入文字 prompt（
session.prompt()） - 串流輸出（
session.promptStreaming()） - 設定 system prompt 和初始對話歷史
- 控制取樣參數（temperature、topK）
- 使用結構化輸出（JSON Schema 約束）
根據 Chrome Platform Status，這個 API 預計在 Chrome 137（2025 年中期）開始桌面版和 Android 版的 DevTrial。
Chrome 團隊的動機來自一個關鍵觀察：開發者已經在用各種方式把 AI 塞進瀏覽器，從 WASM 跑模型到 WebGPU 推論，再到呼叫各種雲端 API。與其讓開發者各自為政，不如提供一個統一的瀏覽器 API，讓語言模型成為瀏覽器基礎設施的一部分。
他們在提案中列出了明顯的優勢：本地處理敏感資料、無伺服器往返延遲、離線可用、降低成本、混合架構（免費使用者用本地模型，付費用戶用雲端服務）。
但 Mozilla 的擔憂從更深層次出發——一旦語言模型成為瀏覽器 API 的一部分，瀏覽器廠商就能決定用戶可以看到什麼 AI 功能、開發者可以使用哪些能力。 這不只是一項技術標準的爭論，而是瀏覽器權力結構的再分配。
Mozilla 的替代方案：從 Web Extension 出發
值得注意的是，Mozilla 不是單純反對「把 AI 放進瀏覽器」這件事。他們自己也在做。
2025 年初，Mozilla 發布了一個實驗性的 Web Extension API，讓開發者在擴充功能中執行本地推論。更重要的是，他們在 W3C 的 Web Machine Learning 群組中提交了一個提案（proposal #9），建議透過 Web Extension 將 Prompt-like API 暴露給網頁，允許開發者指定自己的模型。
這個方案的關鍵差異在於：模型由開發者提供，而不是瀏覽器綁定。
Mozilla 的想法是，瀏覽器不應該預設一個語言模型的選擇。相反，瀏覽器應該提供一個標準化的推論執行環境，至於用哪個模型，應該由開發者和使用者決定。這種鬆耦合的設計，從根本上避免了「開發者綁定特定瀏覽器」的問題。
bgrins 的留言明確提到了這個觀點：
「我們認為這需要更多在 userland 中的實踐，然後才能推出 Web API。」
換句話說，先讓開發者在擴充功能層級玩一玩，累積足夠的經驗和反饋，再考慮是否要拉高到瀏覽器內建 API 的層級。這是一個穩健的、漸進的路徑。
Mozilla 工程師 Domenic Denicola 的回應也很有趣。他感謝 Mozilla 的快速回應，同時提出一個關鍵問題：
「我很想知道你認為使用 Web Extension 收集反饋，與使用 Origin Trial 機制收集反饋之間的差異是什麼。」
這個問題精準地擊中了雙方分歧的核心。對 Chrome 而言，Origin Trial（允許開發者在前端試用實驗性 API）已經足夠驗證 API 設計。但對 Mozilla 來說，Origin Trial 仍然是在「瀏覽器內建 API」的框架下進行的驗證，從根本上就排除了「我們也許不需要這個 API」的可能性。
這不只是技術問題
從技術角度來看，Chrome 和 Mozilla 的立場都有道理。
Chrome 的說法成立：讓開發者直接呼叫本地語言模型確實能解決很多實際問題。不需要載入數百 MB 的模型檔案、不需要處理 WebGPU 的兼容性、不需要管理模型更新——瀏覽器幫你搞定一切。對許多中小型網站來說，這能讓 AI 功能的導入門檻大幅降低。
Mozilla 的說法也成立：一旦 API 固定下來，語言模型的選擇權基本上就被瀏覽器廠商壟斷了。如果 Chrome 說「我們用 Gemini Nano」，Edge 說「我們用 Phi-4-mini」，開發者為 Chrome 寫的 prompt 在 Edge 上跑不通，最終倒楣的是使用者——他們被迫根據瀏覽器選擇能用的網站。
但這個爭論背後有一個更根本的問題：誰來為瀏覽器中的 AI 行為負責？
傳統的 Web API 是確定性的。document.querySelector() 在任何瀏覽器上回傳一樣的東西。但語言模型從本質上就是不確定的——給同樣的 prompt，不同模型、甚至同模型不同版本，都可能給出不同的結果。
這意味著，如果一個網站基於 Prompt API 提供某項服務（例如自動摘要、內容審核、語言翻譯），這個服務的品質和行為將直接取決於使用者的瀏覽器選擇。一個 Chrome 使用者可能得到 A 結果，Firefox 使用者可能得到 B 結果——而且雙方都不知道對方看到了什麼。
Chrome 團隊在 Intent-to-Prototype 中坦承了這個風險：
「這個功能存在明確的互通性和兼容性風險。因為對給定 prompt 的輸出因語言模型而異，開發者有可能寫出脆弱的程式碼。」
他們也提出了一些緩解措施：API 設計了明確的可用性檢測機制、要求開發者提前聲明所需能力（如模態和語言）、結構化輸出功能幫助開發者不依賴特定格式。
但 Mozilla 的立場文件已經表明：這些緩解措施還不夠。
瀏覽器 AI 的權力遊戲
把時間拉遠來看，這場爭論其實是更大趨勢的一部分。
Google 近年來的策略很明確：讓 Chrome 不只是瀏覽器，而是 AI 的入口點。 從 Chrome 內建的翻譯、寫作輔助、到 Prompt API 提案，每一步都在把 AI 能力直接整合到瀏覽器體驗中。
而 Mozilla 的策略則傾向於：保持瀏覽器作為中立平台，讓 AI 能力以可選擇、可替換的方式存在。
這兩種路線沒有對錯，但它們決定了未來網路生態的樣貌。
如果 Chrome 的路線勝出，我們可能會看到一個「瀏覽器決定 AI 能力」的世界。開發者針對 Chrome 的 Gemini Nano 寫程式，使用者如果想要更好的 AI 體驗就得用 Chrome——這和過去 IE 時代的「最佳瀏覽於 Internet Explorer」沒有本質區別。
如果 Mozilla 的路線勝出，AI 能力會更像現在的 Web API 生態——基礎的推論環境由瀏覽器提供，但具體的模型選擇權回到開發者和使用者手中。瀏覽器變成一個執行平台，而不是 AI 的掌控者。
從 Microsoft Edge 的動向來看，這場角力只會越來越激烈。Edge 不僅支援 Prompt API，還推出了基於 Phi-4-mini 的實作，並提供了自己的開發者文件。微軟顯然也在押注「瀏覽器內建 AI」的未來。
對開發社群意味著什麼
對開發者來說，這場爭論不應該只是旁觀者的消遣。
如果你正在開發需要 AI 功能的 Web 應用，Mozilla 的反對應該讓你停下來思考一個問題：我願不願意為了一個瀏覽器 API，讓我的應用綁定特定的瀏覽器生態？
這個問題沒有標準答案，但你可以根據自己的情況選擇策略：
短期策略： 如果 Prompt API 的便利性對你的專案至關重要，可以先用 Chrome 的 Origin Trial 進行實驗。但同時保持一個抽象的介面層，讓未來可以輕鬆切換到其他方案。
中期策略： 關注 Mozilla 的 Web Extension 提案。如果它們成熟，這可能是比瀏覽器內建 API 更靈活的選擇——開發者可以指定模型，使用者可以選擇是否安裝。
長期策略： 如果跨瀏覽器兼容性對你的產品很重要，現在就開始為「沒有 Prompt API」的情境做準備。設計備援方案，當使用者在 Firefox 或其他瀏覽器上訪問時，可以優雅降級到雲端 API 或自帶模型方案。
標準之爭才剛剛開始
截至 2026 年 4 月，Mozilla 在 standards-positions 上的反對立場已經發布了近一年。這段期間，Chrome 的 Prompt API 開發並沒有停下——DevTrial 已經在 Chrome 137 中可用，部分網站已經開始實驗性整合。
但值得注意的是，這場爭論的結果最終可能不由技術決定，而是由市場決定。
如果開發者大規模擁抱 Prompt API，Mozilla 要維持反對立場會越來越困難——最終可能被迫支援，就像當年 Firefox 最終支援了 WebRTC 和 Service Worker。如果開發者選擇觀望或轉向 Mozilla 的 Web Extension 方案，Chrome 可能會重新考慮這條路徑。
對台灣的開發者來說，這場標準之戰帶來的最大啟示可能不是技術本身，而是一個更深層的提醒：不要讓瀏覽器選擇你的架構。
五年後回頭看今天的 Prompt API 爭論，我們會說什麼？是「當時擔心太多了」，還是「我們早該知道」？答案在於開發社群現在做出的每一個選擇。
如果你正在開發 Web 應用，現在就是時候問自己這個問題：我選擇的 AI 路徑，是讓產品更好，還是讓產品更封閉？
這個問題不只在於技術，更在於我們對開放網路的想像。Mozilla 和 Chrome 的分歧，本質上是一個價值觀的選擇：我們要一個由少數廠商決定 AI 能力的網路，還是一個讓開發者和使用者保有選擇權的網路？
或許對多數開發者來說，眼前更現實的問題是：當 Chromium 市佔率已經超過 65%，Mozilla 的反對真的有意義嗎？
答案是——非常有意義。
回顧瀏覽器歷史，每一次「這個瀏覽器佔了大部分市場，專屬 API 也沒差」的時期，最終都導致了整個生態的退化。IE6 時代的 ActiveX、WebKit 時代的 -webkit- 前綴——每次壟斷都讓開發者花費數年清理遺留問題。
AI 時代的風險更高，因為語言模型本身就是黑盒子。如果 Prompt API 的實作差異導致一個網站在 Chrome 上功能完整、在 Firefox 上完全失效，使用者不會怪瀏覽器——他們會怪網站開發者。
目前社群中有幾個值得關注的中間路徑。W3C 的 Web Machine Learning Community Group 正在討論是否可能制定一個「模型無關」的推論 API 規範——瀏覽器只提供標準化的推論介面，模型由使用者或開發者選擇。這個方向的挑戰在於：如果沒有統一的模型規範，標準化推論介面的意義就會大打折扣。
另一條路是 Apple 正在探索的方案：將 AI 能力限制在作業系統層級，而非瀏覽器 API。iOS 上的 Apple Intelligence 就是這個思路——AI 功能由系統提供，瀏覽器只能呼叫系統的服務 API。這條路的好處是模型選擇由作業系統管理，瀏覽器不需要承擔 AI 相容性的責任，但代價是 Web 開發者失去了直接控制 AI 行為的能力。
對台灣的開發者來說，觀察這個趨勢有一個很實際的角度：台灣有大量的網站接案公司和中小型數位代理商。這些團隊通常沒有資源為不同的瀏覽器維護不同版本的 AI 功能。如果 Prompt API 成為主流但 Firefox 不支援，這些團隊將面臨艱難的選擇——是放棄 Firefox 使用者，還是維護兩套 AI 邏輯。
從這個角度看，Mozilla 的 Web Extension 路徑也許是最務實的中間解：瀏覽器提供標準化的推論執行環境（擴充功能層級），開發者負責提供模型，使用者決定要不要安裝這個擴充功能。三方各司其職，沒有人被綁死。
這場標準之戰不會在短期內結束。Chrome 的 Prompt API 已經在 DevTrial 階段，Mozilla 的立場短期內不會鬆動。未來一年，我們很可能會看到一個分裂的瀏覽器 AI 生態——部分瀏覽器內建原生 AI API，部分瀏覽器只支援擴充功能層級的方案。
對開發者來說，最好的策略不是選邊站，而是做好抽象層，讓你的 AI 功能可以在任何環境中優雅降級。瀏覽器戰爭的歷史告訴我們一件事：專屬 API 永遠是短期的便利、長期的麻煩。AI 時代也不例外。