【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】

在 Google I/O 2026 賦予開發者能力

Flutter 3.44 登場，這是一個重大版本！此版本慶祝 Flutter 時間軸上的一個里程碑：Android 上的 Hybrid Composition++、Swift Package Manager 成為新的 iOS/macOS 預設值，以及 Impeller 對 Vulkan 的改進支援。我們正在預覽多視窗桌面支援，Canonical 將成為我們新的主要維護者，並透過將 Material 和 Cupertino 從核心框架解耦，開啟一項重要的架構演進。我們正在透過 GenUl 重新定義代理使用者體驗的 UX，並透過 Agentic Hot Reload 和 Dart & Flutter Agent Skills 重新構想開發者體驗。Flutter 正在賦予新一代應用程式無處不在的能力，從 2026 年 Toyota RAV4 多媒體系統到即將推出的 LG webOS SDK。我們非常興奮能與您分享所有新聞和更新；歡迎來到 Flutter 3.44！

今年 Google I/O 上 Flutter 的主題是：Flutter 無處不在，日復一日，由每個人建造，為每個人服務。

「無處不在，日復一日」源於我週二在使用手機上的應用程式時的一個發現：Flutter 應用程式無處不在我的生活中，從在灣區追蹤我的餐點到在日本購物。數字也支持這一點：pub.dev 生態系統比以往任何時候都更受歡迎，僅在過去 30 天內，套件下載量就超過 13 億次。Flutter 現在是兩個主要應用程式商店中 第二受歡迎的行動開發 SDK，每月開發者超過 150 萬，僅一年就增長了 50%。

「由每個人建造，為每個人服務」反映了我與 Google I/O 共同主持人 Kate Lovett 關於我們全球社群喜悅的對話。我們 1,700 多名忠誠熱情的貢獻者 是這項進步背後的引擎，在過去一年中，他們在核心儲存庫中完成了 5,800 次變更。僅在此發佈週期中，我們就完成了來自 178 位獨特貢獻者 的 972 次提交，其中包括 61 位新貢獻者 完成了他們的第一批提交。我們的社群仍然是 Flutter 的命脈，確保它真正由每個人建造，為每個人服務。謝謝！

有很多變化要告訴您。您可能還想查看 Dart 3.12 版本中的變化。

開發者體驗

無論您是手動撰寫程式碼還是使用您喜歡的程式碼代理進行疊代，我們都希望讓使用 Flutter 建立應用程式的體驗盡可能高效。在此版本中，我們正在改進我們現有的開發者工具套件並引入新工具來增強您的開發工作流程。

DevTools 效能改進

我們正在引入細粒度分析以提高效率，並且我們針對包含許多檔案或目錄的專案的分析進行了效能改進。

我們還為 Flutter DevTools 增加了更多的穩定性和效能改進，包括預設使用 WASM 的變更，這使得 DevTools 更快、回應更靈敏。

了解更多：DevTools 2.55.0 和 2.57.0 的發佈說明。

Widget 預覽 (實驗性)

此版本為 Widget 預覽環境帶來了進一步的效能改進和功能：

• 預覽偵測重寫：偵測邏輯現在利用 Dart Analysis Server，顯著減少了 flutter 工具的記憶體使用量。對於 IDE 使用者，整體記憶體使用量應減少高達 50%。
• 預覽篩選：現在可以按群組、名稱以及腳本和套件 URI 篩選預覽，使在具有許多預覽的專案中工作變得更容易。特別感謝社群成員 NamanGoyalK 的 貢獻！

了解更多：Flutter Widget Previewer

無 Rosetta 的原生 Apple Silicon 支援

運行 Apple Silicon 晶片的 Mac 開發人員不再需要安裝 Rosetta 轉譯層來運行 Flutter。所有 macOS 命令列工具，包括我們的 iOS 裝置通訊二進位檔，都已更新為在 ARM 上原生運行。此更新早於 Apple 計畫棄用 Rosetta 轉譯支援，確保您的開發環境在 Apple 硬體上是未來的。展望未來，Flutter 的未來版本將完全終止對 Intel x86 Mac 的支援。如果您的團隊仍然依賴基於 Intel 的 Mac 主機進行開發，您應該開始規劃您的硬體遷移。

了解更多：在配備 Apple 晶片的 Mac 上使用基於 Intel 的應用程式 (support.apple.com)

在 AI 驅動的世界中重新構想開發者體驗

在過去的一年裡，Dart 和 Flutter 生態系統見證了 Antigravity、Gemini CLI、Claude Code 和 Cursor 等基於代理的工具的爆炸式增長，這些工具正在從根本上將開發者的角色演變為與代理進行架構和協調的角色。為了支持這種轉變，我們專注於增強我們的開發者體驗基礎並引入新工具來增強您的開發工作流程。

與 Agentic Hot Reload 無縫整合程式碼代理

在 AI 輔助開發方面邁出了一大步，我們正在推出 Agentic Hot Reload：MCP 伺服器和您喜歡的程式碼代理現在將自動查找並連接到正在運行的 Dart 和 Flutter 應用程式。這意味著 Antigravity 等程式碼代理現在可以立即熱重新載入您正在運行的應用程式！當您提示您的 AI 助理編輯 UI 時，代理會編寫程式碼並自動觸發熱重新載入以立即向您顯示結果，無需手動設定。去試試看吧！我們還……

• 強化依賴搜尋：代理現在可以安全地讀取和搜尋套件依賴項中的檔案，而無需完全存取您的本地 pub 快取。
• 整合工具：我們整合了我們的 MCP 工具定義，顯著降低了您的代理工作流程的 Token 成本。

查看 Agentic Hot Reload 的實際應用：

我們最近還推出了 Dart 和 Flutter 的 Agent Skills，為您的程式碼代理配備了面向任務的生產級領域專業知識。這些技能提升了您的程式碼代理，並在完成諸如添加整合測試或設定本地化等任務時幫助您節省 Token，同時遵守推薦的最佳實踐。

了解更多：Introducing skills for Dart and Flutter，Dart and Flutter MCP server

Flutter 讓 AI 遍布每個螢幕：建立下一代 AI 原生應用程式

隨著 AI 驅動的功能從簡單的內容摘要演變為完全代理式的助理，我們專注於擴展 Dart 和 Flutter 生態系統，以在每個平台上提供這些體驗所需的基礎設施。

Firebase AI Logic

Firebase AI Logic 使您能夠從您的 Flutter 應用程式中呼叫 Gemini API 客戶端。

MacroFactor 是一個 Flutter 應用程式，它使用 Firebase AI Logic 直接連接到 Gemini 模型並利用其多模態功能。我一直在用它來追蹤我的餐點，只需拍照即可。這是一個應用程式的絕佳範例，它使用 AI 將繁瑣的雜務變成令人愉悅、看似神奇的使用者體驗。

Firebase AI Logic 現在提供 伺服器提示範本，無需直接將提示嵌入到您的應用程式程式碼中。

適用於 Flutter 的 Firebase Agent Skills 現已推出，提供逐步指導，幫助您更有效地建立全端 Flutter 和 Firebase 應用程式。

了解更多： MacroFactor 利用 Firebase、Flutter 和 Gemini 革新 40 萬+ 使用者的營養

Genkit Dart 預覽

我們也很興奮地分享 Genkit Dart 的預覽發佈，這是一個用於構建全端、AI 驅動和代理式應用程式的開源框架。它具有模型不可知的 API，支援 Google、Anthropic 和 OpenAI 等提供商。它隨附了您從原型到生產所需的一切，包括類型安全的結構化輸出、工具呼叫、多輪對話和內建可觀測性。

您也可以在 Flutter 應用程式中運行 Genkit Dart 伺服器端或客戶端！

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import 'package:genkit/genkit.dart';
import 'package:genkit_google_genai/genkit_google_genai.dart';

void main() async {
 final ai = Genkit(plugins: [googleAI()]);

 final response = await ai.generate(
   model: googleAI.gemini('gemini-flash-latest'),
   prompt: 'Why is Dart a great language for AI
            applications?',
 );

 print(response.text);
}

了解更多：Genkit Dart：使用 Dart 和 Flutter 建立全端 AI 應用程式

Gemma 3n 影響力挑戰賽

我們非常自豪地看到 Flutter 開發人員正在突破 AI 的可能性極限。恭喜 Gemma Vision 的創建者 Tommaso Giovannini 和 Vite Vere 的創建者 Guido Marangoni 在去年的 Gemma 3n 影響力挑戰賽 中分別獲得第一和第二名。兩者都選擇 Flutter 來建立改變生活的工具：

• Gemma Vision 幫助視障人士感知世界
• Vite Vere 協助認知障礙人士完成日常生活中的任務。

了解更多：Gemma 3n Impact Challenge 獲勝者

Gemma 4

Gemma 4 最近發佈，它是一個輕量級、設備上模型，專為高級推理和代理工作流程、成本、設備上資料限制或網路限制而設計。其多模態功能非常出色，我對它執行多階段規劃和鏈接工具呼叫的能力印象尤為深刻。

歷史上，在不同的硬體上管理這些設備上模型很複雜。這就是為什麼我對 LiteRT-LM 如此興奮的原因。

了解更多：Gemma 4

LiteRT-LM for Flutter

當我深入研究 Gemma Vision 和 Vite Vere 的程式碼時，看到兩者都利用 flutter_gemma（一個可在 pub.dev 上取得的 Plugin）與 Gemma 整合，這真是令人鼓舞。

情況只會越來越好：我們很高興地宣布，針對 Flutter 的完整 LiteRT-LM 支援即將在 flutter_gemma 套件中推出。

LiteRT-LM 是 Google 的生產就緒、高效能、開源推理框架。這將抽象化硬體差異，讓您可以在裝置上運行 Gemma 4 等強大的設備端 AI 模型，同時確保在 Flutter 的所有 6 個穩定平台（Android、iOS、Web、Windows、Linux 和 macOS）上都能透過 GPU 和 NPU 加速實現最佳效能。

了解更多：flutter_gemma 套件和 LiteRT-LM。

Flutter + A2UI = GenUI

當談到 AI 驅動的使用者體驗時，我們都同意我們已經厭倦了 Markdown 文字牆——或者更糟的是純文字。

生成式 UI (GenUI) 是一種 UX 範式，AI 建立並回應即時 UI，而不是僅僅是文字，如 Hatcha Demo 應用程式所示。

在過去一年中，我們的 GenUI 團隊一直在作為專案合作夥伴推動這一進程，定義新興的 A2UI 協定。A2UI 是 Google 的開源協定，定義了代理和客戶端如何協作組合和狀態使用者介面。

自去年底推出 Flutter GenUI SDK 以來，我們看到了令人難以置信的發展勢頭，自年初以來，套件下載量增長了 500%。

一個突出的例子是 Catagay Ulusoy 的 Finnish it (Google Play 商店，Apple 商店)。這個應用程式不僅建立自訂課程計畫來幫助使用者學習芬蘭語；它還會動態為每節課構成完美的 UI。如果您上個月觀看了 Cloud Next 開發者主題演講，您可能已經看到 Flutter DevRel 負責人 Emma Twersky 為該應用程式和 Catagay 做了應得的宣傳！

了解更多：genui 套件

視覺佈局實驗

Google DeepMind 的李特·程和他的團隊是 GenUI 領域的先驅。還記得因為在 2023 年 Flutter 圈子中流傳的紅色調試橫幅而廣為人知的 這個 Demo 嗎？是的，那就是李特·程的團隊！

他加入了我們的 Flutter 最新功能演講，分享了他使用 Flutter 建立 Gemini 應用程式「視覺佈局」實驗的經驗。這是網頁版本：

他談到了為什麼他的團隊傾向於選擇 Flutter 作為他們的首選 UI 工具包……提示：這就是我們都喜歡 Flutter 的原因：

• 美麗的 UI
• 高效的開發者體驗
• 多平台支援
• 一個完美適合 GenUI 的架構（李特·程的話，不是我的！😉）

以下是他的 3 個主要心得，您可以將其用於自己的 GenUI 專案：

1. 依賴具有意見的框架來保持 AI 的一致性
2. 使用「AI 評論家」循環以確保可靠的輸出
3. 使用模板平衡速度和控制。

最後，李特·程挑戰我們超越文字牆和聊天機器人，而是建立豐富、互動、令人愉悅的體驗。

了解更多：Flutter 的 GenUI SDK，如果您想要一個帶導向的教學，請 嘗試 Codelab。

Android 支援

Googlebook 和周邊支援

Flutter 已具備處理由 Gemini 驅動的新 Googlebook 筆記型電腦的能力。由於 Flutter 針對 Android 的大螢幕指南，應用程式可以自然地處理外部硬體輸入。觸控板捲軸、滑鼠懸停狀態、右鍵選單和鍵盤快捷鍵預設都能運作。由於 Flutter 在 macOS、Windows 和 Linux 上都有成熟的桌面支援，因此 Flutter 應用程式在 Googlebook 上會感覺原生且反應靈敏，而不是看起來像拉伸的行動應用程式。現有的行動應用程式在 Googlebook 上會很舒適，無需大量重寫。

了解更多：Introducing Googlebook, designed for Gemini intelligence

Android 17

Android 17 即將推出，團隊正在積極測試 Flutter 與最新的 Android 17 beta 版，以確保您的應用程式繼續按預期工作。我們還主動整合最新的安全性和可用性功能，例如本地網路保護和安全動態程式碼載入。

您可以在 GitHub 上監控我們正在進行的進度。我們鼓勵您 下載 Android 17 beta 版 並立即開始測試您的應用程式。如果您遇到錯誤或發現任何遺漏的功能，請 提交議題！

了解更多：Android 17 GitHub 專案

Hybrid Composition++ for Android

將網頁視圖或地圖等原生 Android 組件嵌入到 Flutter 應用程式中，歷史上一直迫使開發人員在影格速率和保真度之間做出選擇。舊的渲染策略在捲軸時會出現畫面撕裂、文字輸入損壞或高 CPU 開銷等問題。

Flutter 3.44 引入了 Hybrid Composition++ (HCPP) 作為可選功能來解決這些問題。HCPP 不再依賴離線緩衝區或強制 Flutter 引擎處理原生視圖，而是將圖層合成直接委託給 Android OS。該過程利用 Vulkan 圖形函式庫的低階存取，使用硬體緩衝區交換鏈和 SurfaceControl 事務來同步 Flutter UI 與原生 Android 視圖。

結果是高效能的捲軸和精確的觸控輸入。它還為 SurfaceView 組件帶來了可靠的支援，這些組件在舊模式下曾帶來挑戰。

HCPP 有 Android API 和硬體要求，因此即使啟用 HCPP，也並非所有裝置都可以使用 HCPP。沒有新的 API 需要採用，您只需啟用該旗標即可升級現有的平台視圖。您可以透過將 --enable-hcpp 旗標傳遞給運行命令，或將設定旗標新增到 AndroidManifest.xml 檔案中，在未來成為預設渲染模式之前測試新模式：

1
2
3

<meta-data
  android:name="io.flutter.embedding.android.EnableHcpp"
    android:value="true" />

了解更多：使用平台視圖在您的 Flutter 應用程式中託管原生 Android 視圖

Android 顯示器圓角半徑支援

為協助您在現代行動裝置上建立像素完美的佈局，Flutter 現已直接與 Android 硬體整合，以支援顯示器圓角半徑 (#179219)。Flutter 現在可以查詢裝置顯示器的物理和邏輯圓角半徑，並透過 MediaQuery 暴露此資訊。這使您的 UI 能夠準確地遵守硬體幾何，確保內容永不被積極圓角的螢幕剪裁。

了解更多：MediaQueryData.displayCornerRadii

Android Gradle Plugin 9.0 和內建 Kotlin

在 Android Gradle plugin (AGP) 9 之前，Android 應用程式和 Plugin 開發人員必須手動將 Kotlin Gradle plugin (KGP) 添加到他們的建置檔案中，以便系統能夠理解和編譯 Kotlin 程式碼。從 AGP 9.0 開始，Android 建置系統原生處理 Kotlin。由於建置系統已經知道如何處理 Kotlin，手動添加單獨的 KGP 現在會產生衝突並導致建置失敗。此重大變更影響了套用 KGP 的應用程式和 Flutter Plugin。

Flutter 團隊添加了臨時向下兼容性，以確保現有專案安全建置。手動套用 KGP 的支援將在未來版本中移除。

應用程式開發人員說明

如果您開發 Flutter 應用程式，您需要更新您的 Android 建置檔案以移除單獨的 Kotlin Gradle Plugin (KGP)。

注意：如果您的遷移應用程式使用仍然套用 KGP 的 Flutter Plugin，您的建置將會失敗。由於只有 Plugin 作者可以修復此問題，請將 問題回報給 Plugin 作者。

了解更多：有關完整的逐步說明，請參閱 應用程式開發人員遷移指南。

Plugin 作者說明

Plugin 的遷移過程需要類似的 Gradle 檔案變更，以及重要的版本限制更新。為確保相容性，您必須更新 pubspec.yaml 檔案以 設定 Flutter 最低版本限制為 3.44。

了解更多：有關完整檢查清單，請參閱 Plugin 作者遷移指南。

ABI 篩選變更

ABI 決定了您的編譯應用程式支援哪些裝置硬體架構（例如 ARM 或 x86）。Flutter 過去以程式設計方式將 ABI 篩選器應用於每個特定的建置類型，但現在在基本 defaultConfig 區塊中配置一次。由於 AGP 9 將預設配置與特定建置類型和風味結合，而不是覆蓋它，因此使用自訂 ABI 設定需要額外的步驟。

如果您的應用程式在特定的建置類型或產品風味中使用了自訂 abiFilters，您現在需要在建置或運行應用程式時傳遞 -Pdisable-abi-filtering=true 旗標。

了解更多：有關更多詳細資訊，請參閱 風味指南。

iOS 支援

Swift Package Manager 現在是 iOS 和 macOS 的預設值

從 Flutter 3.44 開始，Swift Package Manager (SwiftPM) 取代 CocoaPods 成為 iOS 和 macOS 應用程式的預設依賴管理員。Flutter CLI 會自動處理此遷移。當您建置或執行應用程式時，CLI 會更新您的 Xcode 專案以使用 SwiftPM，從而無需管理 Ruby 或 CocoaPods 安裝！

了解更多：告別 CocoaPods：Swift Package Manager 即將成為 Flutter 的預設值！

Add-to-App 整合也更具彈性。如果您將 Flutter 嵌入到現有的 iOS 應用程式中，新的 flutter build swift-package 命令會將您的 Flutter 應用程式或 Add-to-App 模組打包為 Swift Package，以便在您的原生專案中輕鬆使用。

了解更多：查看 更新的文件，了解如何與 SwiftPM 整合。

如果您的應用程式依賴仍需要 CocoaPods 的 Plugin，Flutter CLI 將會列印警告，並暫時退回到 CocoaPods 以處理這些依賴。我們建議要求這些套件維護者進行更新，因為 CocoaPods 支援最終將完全移除。為了鼓勵生態系統採用，具有 SwiftPM 支援的套件現在會在 pub.dev 評分中獲得額外分數。

如果您是 iOS 或 macOS Plugin 的維護者，您需要將 SwiftPM 支援加入您的套件中。如果您在 2024 年試點期間進行了遷移，請確保您也在 Package.swift 檔案中將 FlutterFramework 加入為依賴項。

如果 SwiftPM 導致您的專案出現重大問題，您可以透過在 pubspec.yaml 中設定 --enable-swift-package-manager: false 來暫時停用它。如果您使用此選擇退出功能，請在 GitHub 上提交錯誤報告並附上您的 Xcode 專案檔案，以便我們進行調查。請注意，此選擇退出功能最終將被移除。

了解更多：適用於 Plugin 作者的 Swift Package Manager

Flutter 支援 UIScene

從 iOS 13 開始，Apple 引入了基於「Scene」的生命週期，以支援多視窗體驗。在 WWDC 2025 期間，Apple 宣布使用最新 SDK 建立的應用程式很快將被要求使用 UIScene 生命周期來啟動。此更新對於滿足 Apple 對即將推出的 iOS 版本的需求至關重要。

Flutter 3.44 中沒有新的變更，但我們想提醒您在 Apple 預設開始強制使用此新 API 之前進行遷移。如果您的 AppDelegate 未自訂，Flutter CLI 會自動遷移您的應用程式。但是，如果您的程式碼修改了 UI 生命週期事件，您應該遵循完整的遷移指南。

了解更多：UISceneDelegate 遷移指南

iOS 預測文字 (實驗性)

我們正在為文字輸入欄位引入原生 iOS 行內預測文字的實驗性支援 (#183650)。此功能預設是關閉的，但您可以透過啟用 TextField.enableInlinePrediction 來選擇啟用和測試它。啟用後，在您的應用程式中輸入的用戶可以透過按下 Space 鍵來接受 iOS 預測的文字（例如，輸入「My n」並接受「ame」）。請注意，此預測文字的視覺樣式仍在積極完善中，我們感謝您在我們完成此功能時提供的回饋。

了解更多：TextField.enableInlinePrediction

網頁

輔助功能

無障礙功能和使用者偏好設定也得到了大幅提升，預設支援瀏覽器的 prefers-reduced-motion 設定以自動停用動畫，同時使用 aria-description 提供表單驗證錯誤的即時螢幕閱讀器回饋。

了解更多：prefers-reduced-motion CSS 媒體功能 (mozilla.org)

平台和工具

開發工作流程和瀏覽器整合從未如此流暢。引擎現在透過在焦點轉換時重複使用 DOM 表單來處理 iOS 26 Safari 中的自動填充，同時改進網頁捲軸和鍵盤事件合成以實現穩健的可靠性。此外，CLI 透過將 --base-href 支援直接帶到 flutter run，簡化了網頁應用程式的編排，與生產建置配置相匹配。

了解更多：PR #182024、PR #179703、PR #180692

桌面支援

我們很高興地宣布與 Canonical 擴大合作關係，Canonical 將擔任 Flutter Desktop 的主要維護者和策略管家。 憑藉其深厚的技術專業知識，Canonical 將主導 Flutter Desktop 路線圖，並監督我們 Linux、Windows 和 macOS 嵌入器的維護。

這次合作僅是更廣泛生態系統擴展的第一步。展望未來，我們正在積極擴大與更多合作夥伴的治理，將 Flutter 的高效能、多平台體驗帶到更多環境和產業。

敬請期待更多關於這次合作的消息！

若要洽詢與 Flutter 團隊合作事宜，請聯絡 [email protected]。

視窗 API (實驗性)

⚠️注意：視窗功能目前僅在 main channel 上可用。它們尚未用於生產用途。

Canonical 在桌面實驗性視窗 API 方面繼續取得卓越進展！新功能包括：

• 工具提示：Flutter 現在支援 Linux、macOS 和 Windows 上的工具提示視窗 (#182348、#180895、#179147)。
• 彈出視窗：Flutter 現在支援 macOS 上的彈出視窗 (#182371)，預計未來版本將支援 Linux 和 Windows。
• 對話框：Material 的 showDialog 函數現在在支援視窗的平台上建立一個單獨的子對話框視窗 (#181861)。

最後，Linux 現在支援內容大小的視圖 (#182924)。這讓您可以根據內容動態調整視窗大小，這對於彈出式或工具提示視窗很有用。

了解更多：若要搶先預覽桌面實驗性視窗 API，請查看 multiple_windows 範例。

Windows 手寫筆支援

使用 Flutter 建立的 Windows 應用程式獲得了針對數位藝術家和筆記記錄者的重大升級！感謝社群成員 CodeDoctorDE 的出色貢獻，Flutter Windows 現在支援手寫筆輸入，包括精確追蹤手寫筆旋轉和壓力感應。

了解更多：PR 165323: 允許 Windows 上的手寫筆支援

嵌入式

Toyota

2025 年 Toyota RAV4 是全球最暢銷的汽車。現在，2026 年 RAV4 將使用 Flutter 為其多媒體系統提供動力。

上個月，我經歷了職業生涯中的一個亮點：有機會前往德州普萊諾，參觀 Toyota Motor North America 和 Toyota Connected 辦公室，與工程團隊討論 Flutter 如何改變他們設計、建造和交付多媒體系統的遊戲規則：從辦公室的測試單元到車道上的汽車。作為一名 Flutter 工程師和在一個只購買豐田的家庭中長大的汽車迷，我很高興看到 Flutter 在 2026 年 RAV4 上運行。我在外面看到了這麼多次。（嗯——無處不在？？）

感謝 Toyota Motor North America 和 Toyota Connected 團隊的熱情款待！

查看展示影片：

了解更多：Toyota 的新聞稿，Toyota 多媒體系統的最新演進即將出現在您的螢幕上

LG

LG 即將推出 webOS SDK，以幫助開發人員輕鬆建立針對 WebOS 裝置的 Flutter 應用程式，賦能 Flutter 在大螢幕及其他領域的應用。

webOS SDK 將包含對 Firebase、影片播放器、遊戲手把等外掛程式的支援。它甚至將支援您熟悉和喜愛的所有 Flutter 功能，例如有狀態熱重新載入和使用 Riverpod 進行狀態管理。

請密切關注未來幾週內這個令人興奮的發佈！

圖形和引擎增強

此版本為 Impeller 後端帶來了有針對性的渲染和效能增強。

Impeller 改進

Vulkan

此版本包括多項 Vulkan 改進，包括更好的快取記憶體管理，以及在掉幀情況下更高效的 GPU/CPU 同步。

使用 SDF 製作更清晰的圓圈

圓圈渲染的數學已更新，以支援使用帶符號距離函數製作更清晰的圓圈。以前它們有時會出現鋸齒，但這個問題已解決。（#183536，#183184）

陰影和透視校正

改進了 Impeller 處理透視矩陣的方式，修正了陰影和透視投影變換的渲染行為。（#181434，#183187）

FragmentShader 改進

感謝以下增強功能，撰寫片段著色器現在更加直觀且不易出錯。

按名稱 API 獲取 Uniform

您現在可以透過名稱而非手動偏移來綁定著色器中的 uniform 變數，大幅簡化著色器程式碼設定：

1
2
3

void setUp(ui.FragmentShader shader) {
  shader.getUniformFloat('foobar').set(1.234);
}

了解更多：撰寫和使用 FragmentShaders，FragmentShader.getUniformFloat

更清晰的著色器編譯器診斷

著色器編譯器現在在編譯與 Skia 不相容的著色器時會產生警告，幫助您在部署前識別跨平台渲染問題 (#182786，#183146)。

框架

此版本平衡了重大的架構轉變與對品質和社群驅動的改進的嚴格關注。當我們開始將 Material 和 Cupertino 函式庫從核心框架策略性地解耦為獨立套件時，核心框架透過網頁渲染的重大更新、基礎穩定性改進和增強的平台整合而繼續成熟。

Material 和 Cupertino 更新

此版本標誌著 Material 和 Cupertino 函式庫的一個重要里程碑。這些函式庫在此版本中已被凍結，代表著這些函式庫在核心框架內的最後一組更新，之後它們將轉換為獨立套件：material_ui 和 cupertino_ui。在下一個穩定版本之前，框架中這些函式庫的版本將被棄用，您將能夠遷移到新的、獨立版本控制的套件。

了解更多：有關此轉換的更多資訊，請閱讀 關於凍結的部落格文章 並追蹤 將這些函式庫從核心框架解耦的主要追蹤議題。

儘管被凍結，這個版本還是包含了許多改進。一個重要的亮點是 Cupertino 函式庫中選單的現代化。新的 CupertinoMenuAnchor Widget 建立在靈活的 RawMenuAnchor 基礎上，為 iOS 應用程式提供了更穩健和原生感覺的選單體驗 (#182036)。這項工作歸功於社群成員 davidhicks980 的廣泛貢獻，他還創建了 RawMenuAnchor Widget。

了解更多：CupertinoMenuAnchor

在 Material 方面，選單也得到了改進，為 MenuAnchor 類別添加了 Material 3 動畫。這些動畫提供了更流暢、更靈敏的感覺，SubmenuButton 上的新 hoverOpenDelay 參數讓您可以更精確地控制子選單互動。動畫預設禁用，透過設定 animated 為 true 啟用。（#176494）。

了解更多：MenuAnchor，SubmenuButton.hoverOpenDelay

此版本還讓 CupertinoSheetRoute 中的可捲軸內容與拖曳動畫無縫協作，實現了捲軸和關閉頁面之間更流暢的過渡 (#177337)。對於需要自訂拖曳區域的開發人員，新的 scrollableBuilder 允許您將受管理的 ScrollController 傳遞給主體的可捲軸區域，以便為您協調頁面拖曳。

了解更多：CupertinoSheetRoute，CupertinoSheetRoute.scrollableBuilder

此版本中，CarouselView 組件在功能上進行了重大改進。它現在支援無限捲軸 (#175710)，讓您可以建立無縫循環的輪播。它還具有新的 onIndexChanged 回調和其控制器上的 leadingItem 屬性，當使用者與輪播互動時，可以更好地了解輪播的狀態 (#180667)。

了解更多：CarouselView

新的設計原始元件讓實現複雜的 UI 效果變得更容易，例如新的 ShapedInputBorder。這允許 Material Widget 透過指定任何 ShapeBorder 來使用形狀建立輸入邊框。例如，這對於使用 RoundedSuperellipseBorder 以 iOS 樣式顯示 Material 輸入邊框非常有用。（#177220）。同樣，CupertinoFocusHalo 現在支援超級橢圓形狀，確保跨不同 Widget 幾何的一致焦點指示器（#180724）。

了解更多：ShapedInputBorder

幾個現有小部件也得到了改進。Expansible 小部件（其底層支援 Material 的 ExpansionTile）現在功能更強大。ExpansibleController 和 ExpansionTileController 上現在都有一個新的 toggle 方法，並附有改進的文檔和範例（#181320，#180273）。此外，Material 的列表圖塊，RadioListTile、CheckboxListTile 和 SwitchListTile，現在正確接受 WidgetStatesController，允許對其視覺狀態進行更多程式化控制（#180367）。

輔助功能：為所有使用者提供更具包容性的體驗

使應用程式對每個人都可存取仍然是 Flutter 框架的核心優先事項。此版本引入了與平台特定輔助設定的更深層次整合，提高了語義公告的精確度，並改進了常見 UI 組件的輔助功能。

對於 iOS 開發人員，此版本新增了對幾項新的輔助動作功能的支援 (#178102)。您的應用程式現在可以回應使用者對以下功能的偏好：

• 自動播放動畫圖片：偵測使用者何時偏好暫停自動播放的 GIF 或其他動畫內容。
• 自動播放影片預覽：通知應用程式使用者是否已停用影片預覽的自動播放。
• 偏好非閃爍游標：允許應用程式為覺得閃爍游標分散注意力或難以追蹤的使用者提供穩定的、非閃爍的文字指示器。
• 這些設定透過 AccessibilityFeatures 物件公開，讓您可以在 iOS 上建立更靈敏和尊重的 UI。

進度指示器也獲得了生活品質的改進。您現在可以使用百分比字串（例如「50%」）作為 ProgressIndicator 的 SemanticsValue (#183670)。這允許螢幕閱讀器以更自然、更易於閱讀的格式公告進度，而不僅僅是原始十進位值。

此版本還完善了核心 Widget 的語義。Slider Widget 的語義節點已被重構，以更準確地反映其大小和位置，從而改善了透過觸摸探索或輔助設備導航的用戶體驗 (#184168)。此外，對捲軸視圖的修復確保不可見的輔助功能元素不再錯誤地呈現在可捲軸內容之前，從而導致更清晰、更可預測的導航流程 (#184155)。

總而言之，這些變更確保 Flutter 應用程式繼續在所有平台上提供高品質、包容的體驗。

零寬度/高度 Widget 的彈性

此版本的一個主要重點是改進框架在 Widget 渲染為「0x0 環境」時的穩定性——即 Widget 被賦予零寬度或高度的情況，這在以前可能會觸發佈局錯誤或意外崩潰。感謝社群成員 ahmedsameha1 的逐步穩定貢獻，我們為許多核心 Widget 添加了零大小覆蓋，包括 Hero (#180954)、Icon (#181021)、AnimatedPadding (#181235) 和 GridPaper (#180906)。這些更新確保您的應用程式在複雜的佈局轉換或高度受限的視窗中保持彈性。

SelectableRegion 改進

我們已解決 SelectableRegion 中的兩個關鍵問題，以改進原生和網頁平台上的佈局保真度和文字選取行為：

網頁佈局限制保留

以前，SelectableRegion 在網頁上渲染時可能會導致其子項意外縮小。它現在正確地將所有佈局限制未經修改地傳遞給其子項，確保一致的大小調整行為 (#184083)。

多行複製精確度

SelectableRegion 中的文字選取現在更加精確——當使用者選取並複製多行文字時，換行符號現在在複製的輸出中正確保留，而不是遺失 (#184421)。

重大變更和棄用

此版本包含幾個重要的棄用和重大變更，作為持續現代化和改進 Flutter 框架的一部分。

RawMenuAnchor 回調調整

RawMenuAnchor 的某些回呼的呼叫順序已調整，以允許更靈活和可預測的自訂。

了解更多：更改 RawMenuAnchor 關閉順序

此版本中的主要棄用項目包括：

• CupertinoSheetRoute：showCupertinoSheet 和 CupertinoSheetRoute 中的 builder 和 pageBuilder 參數現在已被棄用，取而代之的是 scrollableBuilder (#177337)。此變更允許更好地整合可捲動內容與工作表的拖曳動畫。
• ReorderableListView：onReorder 回呼已被棄用，取而代之的是更精確的 onReorderItem (#178242)。新的回呼提供了一個更可預測的 newIndex，該 newIndex 考慮到項目在重新插入之前被移除的情況。
• 工具：Flutter 工具中的 --web-hot-reload 旗標現在已被棄用，因為網頁的熱重新載入現在透過更現代的機制處理 (#181884)。此外，plugin_ffi 模板已被棄用，取而代之的是支援 FFI 的更穩健的 Plugin 模板 (#181588)。

了解更多：有關這些及其他變更的更多詳細資訊和遷移指南，請參閱 flutter.dev 上的 重大變更頁面。

Flutter 無處不在，日復一日。

Flutter 的觸及範圍廣及行動、桌面、網頁和嵌入式系統，儘管個別功能令人印象深刻，但它們共同為開發人員提供了一個強大的平台，賦予超過 150 萬名開發人員能力，建立令人難以置信的使用者體驗，這些體驗無處不在，日復一日地被使用。您可以在從業務工具和日常應用程式中找到 Flutter，例如 NotebookLM、Talabat、Zoho 和 Karaca，到 2026 年 Toyota RAV4 和 LG 的 webOS 裝置資訊娛樂系統等高調嵌入式實作。

Flutter 由每個人建造，為每個人服務。

Flutter 的成功建立在您的回饋之上！我們致力於保持對話——無論是透過評論、議題還是我們即將進行的開發者調查。您的意見是推動您喜愛功能的原因，所以請繼續與我們分享。

這個生態系統依賴於 LG、豐田和 Canonical 等行業領導者，最重要的是，依賴於每天使用 Flutter 建立應用程式的超過 150 萬開發人員。我們非常高興能繼續共同建立和發展這個精彩的 Dart & Flutter 生態系統。

若要試用所有新功能、優化和圖形增強功能，只需簡單地：

1

flutter upgrade

【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】

Flutter 多平台對於代理開發的價值

Flutter 多平台開發的核心價值在於僅使用單一、共享的原始碼庫來構建支援多平台的應用程式，讓開發團隊能夠在所有平台上協同工作。

這在人工智慧驅動的世界中至關重要，因為增強的一致性、減少的令牌使用量和快速的市場觸及變得至關重要。透過維護單一程式碼庫，開發人員可以將其人工智慧助手集中在一個統一的語境中，大幅減少令牌開銷，並最大限度地減少人工智慧幻覺。開發人員無需讓人工智慧在零碎的、平台特定的語言之間翻譯功能，而是可以利用人工智慧在 Dart 中一次性撰寫程式碼並立即部署到任何地方。

現有價值主張

多平台開發依賴於啟用單一、共享的原始碼庫。在我們的第一方 Flutter 應用程式中，95% 到 99% 的原始碼是共享的。這種大量的程式碼重用帶來了以下幾個優點：

• 由於團隊只需要維護一個程式碼庫，因此可以更快地在多個平台上推出產品。
• 保證跨平台的一致性，為公司提供單一、一致的功能集，無論客戶選擇哪個平台，都能獲得支援。
• 原生效能和穩定性，因為 Flutter 程式碼會編譯成每個平台的原生機器碼。
• 語義保護措施提高安全性，因為 Dart 語言是強型別的。

代理價值主張

雖然大型語言模型（LLMs）擅長將需求轉化為程式碼，但使用它們為每個平台構建單獨的原生應用程式的擴展性很差。使用 LLMs 在不同語言之間複製功能會增加生成時間和令牌使用量，並可能很快導致實作方案產生差異。

Flutter 的單一來源解決方案消除了這些問題。但除了程式碼共享之外，Flutter 的特定架構使其成為代理驅動開發的理想框架。這種新興的價值主張是由幾個關鍵優勢驅動的：

• 令牌減少： 透過在 Dart 中一次性生成應用程式，與使用 AI 在平台特定語言之間翻譯功能相比，您可以大幅減少令牌開銷。這消除了在不同程式碼庫之間複製邏輯的需要，這種做法擴展性差且會增加令牌使用量。
• 一致性： Flutter 提供統一的體驗，因為單一來源程式碼庫確保所有平台上的功能集保持一致。這可以防止當 LLMs 產生幻覺且實作方案產生差異時出現的平台差異。
• 自我修正代理： Flutter 由於 Dart 的強型別語言和豐富的開發者工具，具有強大的語義保護措施。當 AI 代理生成程式碼時，透過彈性工具和 MCP 伺服器暴露的嚴格型別系統會充當即時回饋循環，以立即捕獲錯誤。
• 可預測的程式碼生成： LLMs 擅長生成層次化、結構化的資料。Flutter 的組合式、宣告式 UI 與此優勢相符。代理更容易推理並可靠地生成單一 Dart widget 樹，而不是管理其他平台特定框架的零碎邏輯。
• 透過熱重載實現高速驗證： 在代理工作流程中，瓶頸通常是驗證 AI 的輸出。Flutter 的熱重載功能提供了一個工作流程，其中代理所做的任何更改都可以在開發過程中在運行中的應用程式中立即看到。

Flutter 的優勢

Flutter 支援針對多個平台的單一共享程式碼庫，再加上強型別語言和強大的工具，使其成為代理驅動開發的絕佳搭檔。總之，未來一片光明！借助 Flutter，期待您的代理開發應用程式能夠實現低令牌使用量、更快的跨平台開發週期、強大的語義保護措施、跨平台的應用程式一致性以及原生效能。祝您開發愉快！

Flutter 在代理開發中的多平台價值 最初發佈於 Flutter on Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】

生成式使用者介面 (Generative UI，簡稱 GenUI) 是一種使用者體驗模式，其中代理程式不僅會生成內容，還會決定如何向使用者顯示內容並使其具有互動性。對於 Flutter 開發人員來說，實作 GenUI 意味著使用 A2UI，這是一個開放協議，定義了代理程式和客戶端 (或「渲染器」) 之間如何協同合作以組成和維護使用者介面。為了利用這一點，Flutter 團隊開發了 genui，這是一個使用 A2UI 與代理程式連接並為其提供 Widget 目錄以供使用，然後將這些 Widget 呈現給使用者的套件。

genui 套件和 A2UI 協議最近都獲得了更新！

genui 的最新版本引入了架構上的多項變革。受 A2UI 協議 v0.9 採用的推動，此次更新將 genui 從「結構化輸出優先」的理念 (其中 A2UI 訊息透過結構化輸出 API 串流傳輸) 轉變為「提示優先」的方法 (其中代理程式將 JSON 區塊作為文字包含在其回應中)。它還解耦了架構，提供了對應用程式如何與大型語言模型 (LLM) 互動的更直接控制。

如果您要將應用程式從 genui 套件的 v0.7.0 遷移到 v0.9.0，本指南涵蓋了必要的步驟，從依賴項清理到連接新的聊天循環。

架構解耦

在之前的版本中，GenUI 依賴於一系列基於 ContentGenerator 的類別。這些類別隱藏了提示建構、LLM 網路呼叫和回應解析的細節。

package:genui 的最新版本移除了 ContentGenerator。相反，框架現在分為不同的層次：

• 引擎 (SurfaceController)：管理 UI 的狀態和渲染。
• 傳輸 (A2uiTransportAdapter)：在代理程式和渲染器之間串流傳輸訊息。
• 外觀 (Conversation)：提供用於管理聊天狀態的高階 API。

這種解耦意味著您可以控制聊天歷史記錄、重試邏輯和錯誤處理。這也意味著您可以隨意設定與 LLM 的連接。框架不再使用 ContentGenerator「包裝」您的代理程式，因此您可以自由使用您喜歡的模型和提供者，調整生成設定，添加自己的函數等等，而無需透過框架的 API 來完成。

由於 ContentGenerator 已不復存在，因此不再需要特定於提供者的包裝套件。如果您提取套件的最新版本，您會發現諸如 genui_dartantic、genui_google_generative_ai 和 genui_firebase_ai 等名稱不再出現在樹中。

這是遷移中最重要的程式碼變更。您的應用程式負責建立與代理程式的連接，並透過 TransportAdapter 來回傳遞訊息，而不是將 ContentGenerator 傳遞給 SurfaceController。

舊方法：

1
2
3
4
5
6
7
8
9
10
11

// 建立一個 ContentGenerator，封裝與代理程式的互動。
final generator = FirebaseAiContentGenerator(
  catalog: CoreCatalogItems.asCatalog(),
  systemInstruction: 'You are a helpful assistant.',
);

// 建立一個會話，將生成器與管理表面、更新等的 GenUiManager 連結。
final conversation = GenUiConversation(
  genUiManager: GenUiManager(catalog: catalog),
  contentGenerator: generator,
);

新方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

final catalog = BasicCatalogItems.asCatalog();

// 建立一個 SurfaceController 來管理生成表面的狀態。
final surfaceController = SurfaceController(catalogs: [catalog]);

// 建立一個傳輸適配器，將來自 `genui` 庫的訊息路由到代理程式，
// 然後透過 `addChunk` 將回應回傳到適配器。
late final adapter = A2uiTransportAdapter(
  onSend: (ChatMessage msg) async {
    // 使用字串緩衝區準備要傳送給代理程式的 token。
    final buffer = StringBuffer();

    // 迭代 `genui` 套件建立的訊息，並將它們作為 token 添加到緩衝區。
    for (final part in msg.parts) {
      if (part.isUiInteractionPart) {
        buffer.write(part.asUiInteractionPart!.interaction);
      } else if (part is genui.TextPart) {
        buffer.write(part.text);
      }
    }

    // 將內容生成請求傳送給代理程式，包括來自 `genui` 的字串化訊息。
    final response = await myAgentClient.sendRequest(buffer.toString());

    // 收到代理程式的回應後，使用 `addChunk` 將其添加到 `genui` 套件的輸入流中，
    // 在那裡它將被解析以獲取 A2UI 訊息。
    adapter.addChunk(response);
  },
);

您可能會看著這兩個範例並想：「等等，API 改進不應該意味著我必須撰寫 更少 的程式碼而不是更多嗎？」 的確，以前連接代理程式的這部分「連線」程式碼包含在 genui 套件中，隱藏在 ContentGenerator 類別中，但新方法有一些具體的優點：

• 無需 ContentGenerator，您可以按照自己的喜好設定代理程式，將其保留在您喜歡的記憶體中，並管理其生命週期。您還可以幾乎隨意使用任何您喜歡的 AI 來源，而無需等待帶有新 ContentGenerator 的套件更新。
• 您不再需要將與代理程式的連接「注入」到 genui API 中。它們是鬆散耦合的，只有 token 來回移動。
• 測試更簡單。genui 直接接受 token，它們可以來自代理程式、模擬代理程式或硬編碼測試。
• 如果您想將連接封裝到類別中，仍然可以這樣做。事實上，genui 的幾個範例 採用了這種方法。

提示優先

在以前的版本中，genui 套件嚴重依賴 LLM 提供者嚴格的 API 級別限制 (例如「JSON 模式」或複雜的函數呼叫定義) 來強制模型輸出有效的 UI 結構。綱要透過特定的 API 參數帶外傳遞給 LLM，LLM 實際上被鎖定在一個嚴格的結構中。

雖然這引導模型建立可預測、格式良好的 JSON，但深度巢狀的綱要有時可能會混淆模型或與其自然文字生成傾向相衝突。此外，對結構化輸出的依賴限制了目錄的整體大小和複雜性。這也使得偵錯更加困難，因為約束完全存在於網路層中，而不是您可以在純文字中輕鬆讀取和調整的內容。

「提示優先」方法將真相的來源轉移回 LLM 擅長的地方：系統指令。UI 綱要和與 A2UI 相關的指令不是完全依賴嚴格的 API 開關，而是直接以純文字形式注入到 LLM 的系統提示中。LLM 讀取指令，詳細說明如何為客戶端建構訊息。

這種方法有幾個優點。首先，現代 LLM 經過高度優化，可以遵循詳細的系統指令和範例。在提示中提供綱要與它們的「思維」方式一致。此外，由於 UI 綱要現在只是您提示中的純文字，您可以根據應用程式的需求進行更改。

這項變更表示將正確的提示放入代理程式的上下文視窗的責任現在落在您的應用程式上。幸運的是，genui 套件提供了一個新工具來幫助您為應用程式建立正確的系統提示：PromptBuilder。給定一個目錄和您想提供的任何其他指令，PromptBuilder 將建立一個系統提示，其中包含您的 LLM 需要正確格式化 A2UI 訊息的綱要定義和規則。

1
2
3
4

final promptBuilder = PromptBuilder.chat(
  catalog: catalog,
  systemPromptFragments: ['You are a helpful assistant.'],
);

設定完成後，您的應用程式可以使用 promptBuilder.systemPrompt 取得提示的 String 版本，然後將該值傳遞給 LLM。

協定與綱要調整

如果您的程式碼手動建構 A2UI JSON 或依賴特定的有效載荷結構，請注意 A2UI v0.9 更新中的這些重大變更：

• 表面建立： beginRendering 現已更名為 createSurface。
• 平面組件定義： 不再使用巢狀鍵 (例如 {“Text”: {“text”: “Hello”}})，組件現在使用平面識別符號：{“component”: “Text”, “text”: “Hello”}。
• 資料綁定： 綁定已簡化。使用 { "path": "/path/to/var" } 進行路徑解析。

屬性重新命名：

• distribution => justify
• alignment => align
• usageHint => variant
• text (in TextField) => value
• userAction => action

其他項目也重新命名了！

除了其他一些小調整之外，幾乎所有核心類別的 GenUi 前綴都已移除：

• GenUiConversation => Conversation
• GenUiController => SurfaceController
• GenUiSurface => Surface
• GenUiHost => SurfaceHost
• GenUiContext => SurfaceContext
• GenUiTransport => Transport
• GenUiFallback => FallbackWidget

此外，CoreCatalogItems 更名為 BasicCatalogItems，以闡明它作為基準實作而非嚴格要求。

最後，為了與標準 LLM 函式呼叫術語保持一致，GenUiFunctionDeclaration 和對「工具」的引用已更名為 ClientFunction。

新的 genai_primitives 套件

genui 套件不再附帶自己的訊息類型。相反，GenUI 團隊建立了一個新的 genai_primitives 套件，其中包含 GenAI 應用程式所需常見功能的原始類型。此套件包含 ChatMessage、MessagePart 和 ToolDefinition 等類型。

這些新的類型在 genui 套件 API 中使用，它們足夠靈活，可以融入您可能正在開發的其他 GenAI 應用程式或套件中。

還有更多！

除了上述內容之外，最新版本的 A2UI 和 genui 套件還帶來了幾個新功能，例如：

• 自訂函數，用於驗證客戶端上的資料。
• 新的模組化綱要。
• 改進的錯誤處理。

有關這些的更多資訊，請查看 v0.9 發佈部落格文章 並前往 a2ui.org。

總結

genui 的最新更新引入了一種更加慣用、靈活和穩健的架構。如果您尚未開始使用 GenUI，現在是最好的時機！前往我們的 入門程式設計教學 以獲取對該技術的實作理解，並在大約 90 分鐘內建立一個可運行的應用程式。

A2UI 和 Flutter 的 GenUI 套件的新更新 最初發佈於 Flutter 上的 Medium，人們在那裡透過突出顯示和回應此故事來繼續討論。

【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】

透過領域專業知識改進 AI

AI 代理是通才，但對於專業的 Flutter 開發來說，「通才」還不夠。要建構生產級應用程式，您需要一個了解在地化細微差別、最新 Dart 語言功能以及如何新增整合測試的助理。

今天，我們將推出適用於 Flutter 和 Dart 的 代理技能——一種為您的 AI 工具提供領域特定專業知識的新方法。

超越知識差距

AI 開發的主要挑戰之一是「知識差距」。Flutter 和 Dart 發布新功能的速度可能比 LLM 更新其固定訓練資料的速度更快。作為 我們對 AI 的思考 的一部分，我們正在尋找方法，不僅要解決知識差距，還要確保代理應用這些知識以準確有效地完成任務，並遵循最優化的工作流程。

大約一年前，模型上下文協定（MCP）是提供更多 AI 領域特定專業知識的方法。雖然 MCP 讓代理能夠存取專業工具，但代理技能教會代理 如何 使用這些工具來完成特定任務。這樣想：MCP 提供錘子和釘子（工具），而技能則提供建造房屋的藍圖和專業知識。

技能透過「漸進式揭露」提高上下文效率。這類似於 Flutter 中的延遲載入，應用程式可以在需要時載入函式庫，編碼代理在相關時載入技能，以執行您正在嘗試執行的操作。

對於 Flutter 和 Dart，這些技能提供了針對常見工作流程的量身訂製指令，並增強了 Dart MCP 伺服器中提供的工具，以縮小知識差距，從而提高準確性並降低 Token 使用量。

一種任務導向的方法

我們的早期實驗表明，僅提供文件資料的技能並沒有像我們最初假設的那樣增加那麼多價值。由於 Flutter 全面且寫得很好的文件是開源的，現代模型已經能夠高效地為大多數問題和任務找到相關資訊。

因此，我們轉向建立「任務導向」的技能。我們 GitHub Flutter Skills 或 Dart Skills 儲存庫中的每個技能都專注於開發人員任務，例如透過提供代理可靠完成任務的指令來建立自適應佈局。我們已經進行了廣泛的手動評估來定義我們的初始技能集，並且正在開發一個自動化評估管道，我們將很快分享。

使用技能

若要開始在您的工作流程中使用這些技能，請先在您的專案目錄中安裝技能集：

1
2

npx skills add flutter/skills - skill '*' - agent universal
npx skills add dart-lang/skills - skill '*' - agent universal

您將被要求選擇要安裝的技能。選擇全部或選擇您可能覺得最有用的特定技能。

然後選擇您偏好開發的代理。

現在，像往常一樣提示您的 AI 代理。以下是您今天可以使用這些技能的 5 種方法：

技能 #1：flutter-add-integration-test

設定 Flutter Driver 以進行應用程式互動，並將 MCP 操作轉換為永久整合測試。

1

為我的應用程式中的結帳流程添加整合測試

技能 #2：flutter-setup-localization

為您的 Flutter 專案添加在地化支援

1

在我的應用程式中設定在地化

技能 #3：flutter-build-responsive-layout

使用 LayoutBuilder、MediaQuery 或 Expanded/Flexible 建立可適應不同螢幕尺寸的佈局。

1

確保結帳畫面使用響應式佈局

技能 #4：dart-use-pattern-matching

重構程式碼以在適當的地方使用 Dart 的模式匹配語言功能

1

重構我的程式碼，使其在可能的情況下使用模式匹配

技能 #5：dart-collect-coverage

使用 coverage 套件收集單元測試覆蓋率並生成 LCOV 報告。

1

收集我的專案的測試覆蓋率

有關更多提示範例，請查看 GitHub 上的 Flutter Skills 或 Dart Skills 儲存庫中的 readme。

告訴我們您的想法

這些最初的核心技能，旨在處理最常見的 Flutter 開發障礙，僅僅是個開始。我們希望與您，我們的社群，一起建立 AI 輔助開發的未來。當您使用這些技能並為您的專案建立新技能時，請提交議題（Dart Skills 儲存庫、Flutter Skills 儲存庫），並告訴我們您希望看到哪些額外的工作。我們期待幫助您在使用這些技能時提高工作效率！

介紹 Dart 和 Flutter 的技能 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】

從下一個穩定的 Flutter 版本 3.44 開始，Swift Package Manager (SwiftPM) 將取代 CocoaPods 成為 iOS 和 macOS 應用程式的預設依賴管理器。這意味著您不再需要為了運行應用程式而費心 Ruby 或 CocoaPods 的安裝了！

CocoaPods 已正式進入維護模式，其註冊表將於 2026 年 12 月 2 日永久變為唯讀。雖然現有的建置仍將正常工作，但在此日期之後，將不再有新版本或 pod 加入主幹。為了確保您的應用程式持續接收依賴更新並提供 Swift 套件生態系統的存取權，Flutter 正在過渡到 Apple 支援的依賴管理解決方案：Swift Package Manager。

如果您已經將您的 Plugin 遷移到使用 SwiftPM，請閱讀下面的「Plugin 開發人員」部分以了解新的遷移要求。

以下是如何管理過渡。

應用程式開發人員

對於應用程式開發人員，Flutter CLI 會處理遷移。當您運行或建置您的 iOS 或 macOS 應用程式時，CLI 會自動更新您的 Xcode 專案以使用 Swift Package Manager。有關更多詳細資訊，請查看 適用於應用程式開發人員的 Flutter 遷移文件。

如果您的應用程式依賴尚未採用 Swift Package Manager 的 Plugin，Flutter 將列出警告，精確地列出您的哪些依賴不支援。對於尚未採用 Swift 套件的 Plugin，Flutter 將暫時回退到 CocoaPods。由於 CocoaPods 支援最終將完全移除，如果 Plugin 未更新並導致您的建置中斷，請向依賴的維護者提交議題，要求 Swift 套件支援或尋找替代套件。

我們知道遷移有時會遇到問題。如果 SwiftPM 導致重大問題，您可以暫時為您的專案停用它。打開您的 pubspec.yaml 檔案，導航到 flutter 部分，並在 config 區塊下將 enable-swift-package-manager 設定為 false：

1
2
3

flutter:
  config:
    enable-swift-package-manager: false

如果您選擇退出，請使用 Flutter GitHub 議題模板 提交錯誤報告並告知我們！請包含錯誤詳細資訊、您的 Plugin 及其版本列表，以及您的 Xcode 專案檔案副本，以幫助我們在 CocoaPods 完全移除之前解決問題。

Plugin 開發人員

對於維護 iOS 或 macOS Plugin 的 Plugin 作者，如果您尚未添加 Swift Package Manager 支援，則必須添加。到目前為止，前 100 個 iOS Plugin 中有 61% 已遷移。我們需要其餘的 Plugin 加入，這樣應用程式開發人員才不會依賴已棄用的工具。為了鼓勵採用，沒有 Swift Package Manager 支援的套件在遷移之前將獲得較低的 pub.dev 分數。

若要新增此支援，請新增一個 Package.swift 檔案，並移動您的原始碼檔案以符合標準的 Swift 套件結構。如果您已經在 2025 年的試驗期間遷移了您的 Plugin，則需要完成一個新步驟：您必須在 Package.swift 檔案中新增 FlutterFramework 作為依賴項。請閱讀 Flutter Plugin 作者遷移文件 以獲取完整說明。

感謝您協助遷移到 Swift Package Manager。我們希望這能簡化並改善您在 iOS 和 macOS 上的開發體驗！

告別 CocoaPods：Swift Package Manager 即將成為 Flutter 的預設選項！最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】

我們的團隊在今年春天一直努力工作，準備在拉斯維加斯與超過 30,000 名參加 Google Cloud Next 的人見面。對於那些無法親自參加的人，以下是 Flutter 和 Dart 團隊的主要亮點、公告和體驗的詳細介紹。

重大公告

• 全端 Dart： 團隊宣布預覽 Firebase Functions 對 Dart 的支援。沒錯，這表示您可以同時使用 Dart 來開發前端和後端。我們還透過 Dart Admin SDK 引入了與 Firebase 更深層次的整合，以減少上下文切換並提高開發速度。
  請查看公告部落格和文件，並請關注 Google I/O 上關於此功能的完整分組討論。

現場體驗

• GenLatte： 我們在 Next 的中心建立了一個由 AI 驅動的特色咖啡店，使用 Flutter GenUI 打造。與會者使用 GenUI Flutter 應用程式訂購飲料，然後觀看咖啡師製作拿鐵咖啡並在泡沫上列印客製化的 nanobanana 生成圖像。

• Agentic 行動和網頁示範 galore： 展區充滿了活力，包括三個 Dart 和 Flutter 示範，展示了 Fullstack Dart、GenUI，以及我們的朋友 VGV 的特別亮相。

• Builder 中心： 這作為展區開發者社群的「根據地」。它設有 Flutter 以及我們 Firebase 和 Go 朋友的專屬攤位，為開發者提供了與專家聯繫和探索新工具的空間。

主要議程和客戶案例

• 開發者主題演講： Emma Twersky 主持了開發者主題演講，展示了 Flutter 如何成為 Google Cloud 在未來代理商上的重大賭注的一部分。

• 豐田和 Talabat： 真實世界的企業成功是一個主要主題。Abdallah Shaban 與行業領袖一同上台，展示了 Flutter 如何改變他們的核心產品。豐田分享了他們如何使用 Flutter 為下一代資訊娛樂系統革新汽車 UX，而 Talabat 則展示了他們如何使用該框架在中東地區更快地創新和擴展。

• 生成式 UI 深度探討： Yegor Jbanov 和 Andrew Brogdon 主持了一場關於如何透過賦予代理人創建自己的 UI 的能力來超越基於文本的聊天機器人的議程。
  敬請關注 Google I/O，屆時此議程將在 Flutter YouTube 頻道上全球發布。

• 建立全端 Dart： Rody Davis 和 Kevin Moore 分享了您應該對今天 Dart 最大公告感到興奮的原因。
  敬請關注 Google I/O，屆時此議程將在 Flutter YouTube 頻道上全球發布。

我們的社群蓬勃發展

• GDE 峰會： 在主活動之前舉辦的這次峰會匯集了超過 **350 名全球 Google Developer Experts (GDEs)**，他們與核心團隊分享了 Flutter 的回饋，包括關於 Flutter GenUI 的主舞台議程。
• 開發者聚會： 在整個星期中，Expo Meetup Hub 舉辦了非正式聚會。Flutter 協助舉辦了行動開發者聚會，我們與來自世界各地的社群成員見面，並分享了我們認為 Flutter 是最佳建構方式的原因。

這就是總結！但很快… 立即註冊 Google I/O 2026，我們的團隊還有更多計劃。我們迫不及待想給您驚喜。😉

圓滿落幕：Google Cloud Next 上所有關於 Flutter 的內容最初發佈於 Flutter 的 Medium 平台，人們在上面透過分享和回應這個故事來延續討論。

【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】

儘管 Dart 最初是一種網路語言，並且每天都被用於跨平台（包括網路）構建應用程式，但我們自己的網站（dart.dev、flutter.dev、docs.flutter.dev）卻依賴於碎片化的非 Dart 工具組合。這種情況終於改變了。我們已將所有三個網站遷移到使用 Jaspr，這是一個用於使用 Dart 構建網站的開源框架。

結果是一個統一的技術棧，具有一致的開發人員體驗，其中貢獻只需要 Dart。如果您對使用 Dart 構建超越標準 Flutter 網路應用程式的網路體驗感到好奇，這篇文章將探討我們遷移的動機以及 Dart 和 Jaspr 如何使這一切成為可能。

碎片化且不熟悉的技術棧

雖然我們網站之前的設定有效，但它們的實作是碎片化的，並且需要越來越多的精力來更新網站以滿足我們不斷變化的需求。文件網站是使用 Eleventy（一個 Node.js 靜態網站生成器）構建的。同時，flutter.dev 有一個完全獨立的設定，由 Wagtail（一個基於 Python 和 Django 的 CMS）提供支援。

這種碎片化意味著任何想要為我們的網站做出貢獻或維護我們網站的人都需要 Dart 生態系統之外的額外經驗和工具：一組網站需要 Node.js 工具，另一組網站需要 Python。雖然一些周邊基礎設施和互動式組件已經使用 Dart 構建，但獨立的生態系統限制了程式碼共用，顯著增加了設定和貢獻的摩擦，並變得越來越複雜。

我們想改變這種情況。我們想要一個基於我們的團隊和社群已經熟悉的語言和工具的單一、統一的技術棧。我們對網站的互動性也有越來越高的期望和需求，從更豐富的程式碼範例到教學課程的測驗。我們現有的設定使每個新的互動元素都變得困難重重，通常需要一次性的命令式 DOM 邏輯。

在 Jaspr 中尋找統一的解決方案

Jaspr 是一個多功能 Dart 網路框架，支援客戶端渲染、伺服器端渲染和靜態網站生成。除了作為一個傳統的基於 DOM（帶有 HTML 和 CSS）的網路框架並以我們已經知道的語言編寫之外，Jaspr 因以下幾個原因而脫穎而出：

Flutter 技能直接轉換。 Jaspr 框架及其組件模型旨在讓任何 Flutter 開發人員感到自然和熟悉，同時與網路的 DOM 模型相容。如果您以前編寫過 Flutter Widget，您可以閱讀此內容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class FeatureCard extends StatelessComponent {
  const FeatureCard({
    required this.title,
    required this.description,
    super.key,
  });

  final String title;
  final String description;

  @override
  Component build(BuildContext context) {
    return div(classes: 'feature-card', [
      h3([.text(title)]),
      p([.text(description)]),
    ]);
  }
}

使用 Jaspr，貢獻者可以直接將他們已有的 Dart 和 Flutter 經驗應用到新平台，顯著降低了想要改進我們文件和網站的團隊和社群成員的進入門檻。

無縫支援部分水合。 這次探索和遷移的一個主要潛在原因是為了讓在我們的網站上建立和整合互動式體驗變得更容易。Jaspr 內建的部分水合支援允許每個頁面預渲染為靜態 HTML，然後僅為需要它的組件附加客戶端邏輯。這對於像我們這樣的網站來說是完美的，其中大部分內容是靜態的，只需要小部分的互動性，確保快速的頁面載入和良好的 SEO。

Jaspr Content 適用於 Markdown 驅動的網站。 Jaspr 還提供了 Jaspr Content，這是一個支援快速建立內容驅動網站的套件。它提供了足夠的開箱即用功能，可以在幾分鐘內建立一個基於 Markdown 的運行網站，同時也易於廣泛擴展和自訂。這種內建功能節省了大量的時間，而可自訂性使我們能夠保持原始功能和內容實踐不變。

我們獲得了什麼

這次遷移帶來了我們所設想的所有好處，甚至更多，包括網站本身和貢獻體驗。

一個單一、統一的工具鏈。 由於所有內容都用 Dart 編寫，您不僅只需要一個 SDK 即可貢獻，我們還可以使用 Dart 強大、統一的工具。我們可以使用 dart pub 管理所有依賴項，使用 dart format 格式化程式碼，使用 dart analyze 分析程式碼，然後使用 dart test 測試程式碼。現在，管理網站只需要一套工具，一套要遵循的慣例，以及一個要保持最新的生態系統，而且這是我們已經最熟悉的那個。

我們的貢獻者已經熟悉的技術棧。 我們的網站有很多貢獻者，從工程師到技術撰稿人，再到熱情的社群成員。我們希望每個人都能夠做出貢獻，但碎片化的設定對大多數人來說是複雜且不熟悉的。現在，這些網站被實作成標準的 Dart 專案，如果您了解 Dart，那麼您就擁有所需的一切。我們希望這能降低團隊和社群成員想要幫助改進 Flutter 和 Dart 文件的門檻。

需要改變的內容比您預期的要少。 由於 Jaspr Content 開箱即用支援我們所需的大部分功能，例如模板支援、Markdown 和資料載入，我們的內容和撰寫工作流程幾乎不需要改變。我們的樣式也不需要改變，因為我們已經使用 Sass（一種 CSS 擴展語言），它實際上是使用 Dart 實作的，因此比我們以前的設定需要更簡單的設定。

協作遷移

總體而言，網站遷移到 Jaspr 和 Jaspr Content 進行得很順利，但當然也遇到了一些挑戰。我們偶爾會遇到 Dart 的 Web 工具和 Jaspr 本身的問題以及改進機會。

使遷移成為可能的是 Jaspr 的創建者和維護者 Kilian。除了創建 Jaspr，他在整個遷移過程中都支援我們。他作為早期概念驗證遷移了組件，回應了問題，發布了修復，改進了開發人員體驗，甚至以我們的網站為主要用例構建了 Jaspr Content。為了支援這項持續的努力並正式化協作，我們與 Kilian 和他的諮詢公司 Netlight 合作，幫助我們遷移我們的其餘網路存在並繼續直接投資於 Jaspr。這是一個真正的協作過程。我們的網站和 Jaspr 都因此而成長。

在 Dart 和 Flutter 生態系統中，社群就是一切，而 Kilian 透過 Jaspr 為社群提供的正是最好的例子。Jaspr 已證明自己是一個功能強大且現代化的 Web 框架，它維護良好、對回饋反應迅速，並隨時供您試用。謝謝您，Kilian！

若要聽取 Kilian 關於建立和維護框架的觀點，請查看他的文章：Jaspr：為什麼在 Dart 中進行 Web 開發可能是一個好主意。

Dart 和 Jaspr 共同成長

在全 Dart 技術棧上構建最值得稱道的一個方面是，Dart 語言和周圍工具的改進會使所有事物受益。不僅僅是您的 Flutter 應用程式，您的網站也一樣。以下是一些最近的 Dart 功能，它們直接影響並改進了使用 Jaspr 進行構建的體驗。

點簡寫使組件樹更簡潔。 Dart 3.10 引入了對 點簡寫語法 的支援，使您可以在從上下文中推斷出靜態成員存取時省略類型名稱。Kilian 利用這一點，將幾個組件構造函數整合到 Component 類上，並將它們設計為與新語法自然協同工作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Component build(BuildContext context) => const div([
  // API 變更後：
  h1([Component.text('Dash says hi!')]),
  Component.fragment([
    Component.text('First element'),
    Component.text('Second element'),
  ]),
  Component.empty(),

  // 使用點簡寫：
  h1([.text('Dash says hi!')]),
  .fragment([
    .text('First element'),
    .text('Second element'),
  ]),
  .empty(),
]);

結果是一個更一致的 API，具有更好的可發現性，以及在常量上下文仍然有效的簡潔語法。最棒的是，Jaspr 的 CLI 帶有一個 jaspr migrate 命令，可以自動處理遷移到新 API 以及其他變更。

Null 感知集合元素簡化了條件渲染。 Dart 3.8 添加了對 null 感知集合元素 的支持，提供了一種清晰的語法，可以在集合中條件性地包含非 null 值。在 Jaspr 程式碼中，您經常組合子組件列表，它們提供了一種優雅的方式來處理條件 UI 元素：

1
2
3
4
5
6
7
8
9

Component build(BuildContext context) => div(classes: 'header', [
  h1([.text('Welcome to Flutter!')]),

  // 在 null 感知集合元素之前：
  if (eventBanner != null) eventBanner!,

  // 使用 null 感知集合元素：
  ?eventBanner,
]);

不再有冗長的 if 檢查和非 null 斷言混亂您的組件樹。

現代、輕量級 JS 互通與編譯至 WebAssembly。 為了高效存取現代 Web API 並編譯至 WebAssembly，Dart 3.3 引入了新的 JS 互通 函式庫以及 package:web。Jaspr 迅速遷移並支援了新的 API，確保 Jaspr 開發人員可以從其新功能中受益並構建現代 Dart 應用程式。在此基礎上，Jaspr 還支援在客戶端運行時實驗性地編譯至 WebAssembly。事實上，dart.dev 已經在使用並受益於對相容瀏覽器的這種支援。

一個實用、整合的分析器外掛。 一段時間以來，Jaspr 有一個基於 package:custom_lint 構建的實用 linting 套件，幫助開發人員編寫符合慣例且正確的 Jaspr 程式碼。隨著 Dart 3.10 中官方 分析器外掛 支援的發布，Jaspr 遷移以採用該功能。該外掛提供了一個很好的範例，說明了什麼是可能的，提供 Jaspr 特定的診斷和程式碼輔助。例如，它可以轉換組件類型或快速將組件包裝到另一個組件中，類似於您可能已經習慣使用的 Flutter 輔助。

這些功能都不是專門為 Jaspr 構建的。它們是對 Dart 語言和工具的改進，使整個生態系統受益，而不僅僅是 Flutter。其中一些功能，Jaspr 能夠立即利用，而其他功能則需要 Kilian 和貢獻者的框架更改才能釋放其潛力。無論哪種方式，很明顯 Dart 仍在不斷發展，並且這種發展繼續為所有用它構建的東西（包括 Jaspr 和 Flutter）開闢改進和可能性。

接下來是什麼以及如何開始

我們還沒結束。現在我們的網站共享這個新的技術棧，我們可以開始共享更多程式碼，構建新的互動功能，並繼續改進 Dart 的 Web 開發故事。我們還將 Dart 和 Flutter 部落格從 Medium 遷移到直接託管在我們由 Jaspr 提供支援的網站上。您很快就能在上面閱讀這篇文章了。

如果您是一位 Dart 或 Flutter 開發人員，對使用您已有的技能建立網站感到好奇，那麼現在是嘗試的最佳時機。Jaspr 是內容豐富型網站（例如登陸頁面和文件）的絕佳選擇。它甚至可以自然地 與您的 Flutter 網站應用程式整合。立即在 Jaspr 的 線上遊樂場（也是用 Jaspr 構建的！）或依照 Jaspr 快速入門 試用。

或者，如果您有興趣為 Flutter 或 Dart 文件網站做出貢獻，那麼進入門檻剛剛降低了很多。現在有了 Jaspr，您所需要的只有 Dart。

我們用 Dart 和 Jaspr 重建了 Flutter 的網站 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】

Flutter 團隊一直在努力為今年春天的 Google Cloud Next 和 Google I/O 做準備。我堅信社群的力量，無論是數位的線上社群，還是面對面的互動社群。對 Flutter 而言，這意味著一個真正的全球社群和全球數十萬的開發人員。我職業生涯中最有影響力的時刻之一就來自這些——社群在社群主導的活動中蓬勃發展。

隨著我們開啟新的一年以及即將發布的 Dart 3.12 和 Flutter 3.44，Flutter 團隊將在全球各地盡可能多地與您見面。我們的使命是為高效能、全端、多平台應用程式和短暫體驗建構最具生產力的應用程式框架和語言。而要做到這一點，就意味著需要聽取您的意見。

為了保持透明和開放，我們更新了團隊將出席或我們已贊助 Google 開發者專家出席的活動列表。我們的開發者關係團隊透過組織以下活動，不斷與開發人員、創始人、企業和建構者互動：客戶和合作夥伴諮詢委員會、我們的聚會組織者網路、Flutteristas、Flutter 顧問計畫、Google 開發者專家和 Google 開發者社群組織者。

如果您一直在尋找與團隊聯繫、觀看現場演示或親自向我們提供回饋的機會，您可以在今年剩餘時間參加以下活動：

四月

• Google Cloud Next (拉斯維加斯，內華達州) — 4 月 22-24 日

五月

• Flutterconf Spain (馬拉加，西班牙) — 5 月 08 日
• Google I/O (桑尼維爾，美國) — 5 月 19-20 日
• Flutter Flow 開發者大會 (舊金山，加利福尼亞州) — 5 月 27-28 日

六月

• mDevCamp (布拉格，捷克) — 6 月 03 日
• Flutter 技術峰會 (華沙，波蘭) — 6 月 09 日
• Config (舊金山，加利福尼亞州) — 6 月 23-25 日
• I/O Connect 柏林 (柏林，德國) — 6 月 25 日

七月

• I/O Connect 班加羅爾 (班加羅爾，印度) — 7 月 14 日
• Fluttercon USA (奧蘭多，佛羅里達州) — 7 月 16-17 日

八月

• Ai4 (拉斯維加斯，內華達州) — 8 月 4-6 日
• I/O Connect 中國 (中國) — 待定
• RenderATL (亞特蘭大，喬治亞州) — 8 月 12-13 日

九月

• Flutter & Friends (斯德哥爾摩，瑞典) — 9 月 3-5 日
• FlutterConf LATAM (坎昆，墨西哥) — 9 月 22-23 日

十月

• next.app devcon (柏林，德國) — 10 月 7-9 日
• All Things Open (羅利，北卡羅來納州) — 10 月 19-20 日
• Flutter Kaigi/Ninjas (東京，日本) — 10 月 29-30 日
• Google 開發者活動 (DevFest 和 Build with AI) — 2026 年秋冬季。

請持續關注並將 Flutter.dev 的活動頁面加入書籤，因為我們將在全年持續增加更多活動。

您是否正在舉辦未在此處列出的 Flutter 活動或聚會？請聯繫我們的團隊，看看我們是否能在您所在地區參加——我們希望盡可能多地與您見面和分享！

2026 年與巡迴中的 Flutter 核心團隊見面 最初發佈在 Medium 上的 Flutter 上，人們在那裡透過突出顯示和回應這個故事來繼續討論。

【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】

我們一直努力準備將 Material 和 Cupertino 從框架中分離出來，現在我們第一個重要的里程碑已經到來！截至 4 月 7 日，所有對 flutter/flutter 中 Material 和 Cupertino 函式庫的貢獻都已凍結。我們的下一個里程碑將是將這些函式庫重新發布為 material_ui 和 cupertino_ui 套件在 pub.dev 上。

這意味著，在程式碼凍結之後，flutter/flutter 內部不允許再對 Material 和 Cupertino 函式庫進行任何更改。一旦新套件發布，這些函式庫的進一步開發將在 flutter/packages 儲存庫中恢復。

如果您編寫 Flutter 應用程式或 Plugin，但沒有貢獻 Material 或 Cupertino 本身，您現在可以停止閱讀。這不會影響您…目前。

在 3.44 穩定版發布之後，新的套件將會發布，開發者最終需要進行遷移。舊的 Material 和 Cupertino 程式碼將在 3.44 之後 的穩定版中棄用，並在之後的某個時間點刪除。當然，屆時我們將提供有關此遷移的詳細說明。

對於那些積極為這些函式庫做出貢獻或以其他方式投入其開發的人，這裡有一些您應該知道的事情：

如果您的 PR 正在進行中怎麼辦？

儘管程式碼凍結，我們仍希望 Material 和 Cupertino 的開發能以最小的中斷繼續進行！任何涉及 Material 或 Cupertino 的開放 PR 都應保持開放，審查人員將照常繼續審查並提供回饋。一旦新的套件發布，我們將提供有關如何將這些 PR 移植到 flutter/packages 的說明。最終，您的變更將作為新的 material_ui 或 cupertino_ui 發布的一部分推出。

Material 和 Cupertino 相關的新舊議題怎麼辦？

與 Material 或 Cupertino 相關的議題將一如既往地保留在 flutter/flutter 中。這種統一的議題追蹤方法與我們在 flutter/packages 儲存庫中的其他套件和一些其他儲存庫所遵循的模式相同。

為什麼現在凍結程式碼？

當我們發布 material_ui 和 cupertino_ui 套件的 1.0.0 版本時，我們認為為每個準備好遷移的 Flutter 開發者提供無縫的遷移過程非常重要，無論他們來自哪個發布管道。這意味著我們需要將 flutter/flutter 和 flutter/packages 中的 Material 和 Cupertino 函式庫之間的重大變更風險降到最低。我們可以透過提前一個穩定發布週期凍結程式碼並將該凍結的程式碼複製到新套件中來實現這一點。

Flutter 開發者的遷移過程第一步是在任何管道上對 v3.44 或更高版本執行正常的 SDK 遷移。一旦完成，我們就知道他們擁有 Material 和 Cupertino 的凍結副本。即使他們再次升級 SDK，該 Material 和 Cupertino 程式碼也不會改變（直到長期被棄用和刪除）。更重要的是，我們知道凍結的 Material 和 Cupertino 程式碼與 1.0.0 material_ui 和 cupertino_ui 套件中的程式碼相同，或者盡可能接近相同。從那裡，開發者可以以最小的摩擦從其 SDK 副本中的 Material 和 Cupertino 程式碼遷移到 material_ui 和 cupertino_ui 套件。

我們是如何走到這一步的

到目前為止，這是一段漫長的旅程，有來自社群的許多貢獻和回饋。幾個月前，當我意識到我們有測試依賴會阻礙分離時，我發布了一個 議題，並認為我將面臨大量的遷移工作。相反，來自社群的貢獻者立即投入幫助遷移數百個測試。我們從首次貢獻者到資深貢獻者那裡獲得的支持對於我們為分離做好準備至關重要。謝謝您！

接下來呢？

程式碼凍結之後，我們將開始準備遷移到新的 material_ui 和 cupertino_ui 套件。這包括移植程式碼、實作 CI/CD、測試和設定文件基礎設施等任務，以確保我們能夠保持您對 Flutter 期望的相同高品質開發者體驗。

隨著新套件的成熟，我們將發布更多關於如何成功遷移的資訊，請密切關注。此外，如果您發現任何我們可能遺漏的地方，請隨時提出問題或 PR。如果沒有 Flutter 優秀社群的幫助，我們不可能走到這一步，我們迫不及待地想看看接下來會發生什麼。

Flutter 的 Material 和 Cupertino 程式碼凍結 最初發佈於 Flutter on Medium，人們在那裡透過突顯和回應此故事繼續討論。

【文章內容使用 Gemini 2.5 Flash 自動翻譯產生】

上個月，我們發佈了 Flutter 和 Dart 的 2026 年路線圖，這是我們團隊如何實現核心使命的展望：建立最受歡迎、增長最快、生產力最高的多平台 UI 框架。但如果不承認 AI，就不可能談論 2026 年的發展。

為了應對這個時刻，今天我們將分享我們團隊在 2026 年如何處理 Dart 和 Flutter + AI 的數據驅動和誠實想法。這篇文章的目的不是路線圖，而是一系列指導我們策略的想法。透明度是 Flutter 的核心支柱，作為一個開源專案，我們相信公開實驗的價值。請將此解讀為我們目前對 AI 的思考快照；我們重視您的意見和回饋，但我們也認識到，在這個快速變化的環境中，隨著模型、工具及其使用的發展，策略和方法可能會改變。

代理轉變的數字

Flutter 最初的吸引力來自於保持領先地位並靈活適應開發者構建跨平台應用程式的需求。現在，AI 代表了我們思考生態系統的另一個變數。這並不是因為每個開發者都需要使用 AI，而是因為我們需要考慮它如何改變我們對那些使用 AI 的人的目標。

AI 採用不再是未來的趨勢；它已是當前的現實。2025 年 Stack Overflow 開發者調查 顯示，84% 的開發者在日常工作流程中以某種方式使用 AI 工具，而在我們的 2025 年 Flutter 用戶調查 中，我們發現 79% 的 Flutter 開發者明確表示在使用 Flutter 時會使用 AI 助手。

然而，這種快速採用揭示了一個顯著的「信任鴻溝」。儘管 73% 的開發者認為他們的工作效率更高，因為他們可以減少開始新任務的阻力，但 46% 的開發者仍不信任 AI 工具在編寫、偵錯或修復程式碼等關鍵任務上的準確性。這導致了「驗證稅」——工程師花費時間審核輸出或微調指令以達到正確性。

我們的做法：我們為誰而建以及指導我們的原則

作為 Google 領先的多平台 UI 框架，Flutter 獨特地定位於專注於我們生態系統中的 AI 開發者。這些原則確保 Dart 和 Flutter 仍然是開發者構建在任何螢幕上運行的應用程式最可靠的選擇。

我們正在為誰解決問題

我們的策略針對從傳統到代理開發的 AI 採用範圍內的開發者：

• 傳統開發者： 讓那些依賴核心 Dart 和 Flutter 工具的開發者信任 AI。傳統開發者非常關心自己思考問題，並使用開發工具深入了解內部。我們的目標是為他們改進現有的基礎，這反過來又提高了 AI 的品質，並建立對代理開發的信任。
• AI 輔助開發者： 透過 AI 提高那些已在 Dart 和 Flutter 工作流程中採用 AI 編碼代理的開發者的生產力。這些工程師依賴 AI 處理重複、繁瑣的任務和樣板程式碼，這樣他們就可以花更多時間在複雜的功能和架構程式碼上。我們的開發者體驗團隊正在探索 AI 工具，例如 MCP 伺服器、Agent Skills 和此領域中的其他解決方案。
• AI 優先開發者： 讓 AI 為那些尚未發現 Flutter 是構建其應用程式的最佳方式的人服務。這些開發者正在使用自然語言建立應用程式。透過認識到他們的需求與其他角色重疊的地方，我們確保我們的框架為 AI 開發的未來做好準備。此處的合作可能包括使用 Antigravity 進行 Flutter 指導，以及其他反映 Google I/O 2025 上介紹的「Vibe once, deploy everywhere」概念 的 vibe-coding 產品。

我們的指導原則

• 人優先： Dart 仍然是「人優先」的語言。我們優先考慮讓程式碼對開發者來說易於閱讀和管理，即使程式碼是由代理程式生成的。
• 新增，而非取代： AI 工具應新增和改進使用 Dart 和 Flutter 進行開發的體驗。每個開發者都應被賦予權力，根據自己的意願和選擇的時間線使用 AI 輔助。我們打算確保 AI 以我們的文件和基礎工具作為事實的來源。
• 開放標準和代理程式無關： 我們在開發者所在之處提供支援。透過利用像 Model Context Protocol (MCP) 這樣的開放標準，我們確保 Flutter 與您選擇的任何代理程式都能良好配合，而不僅僅是 Gemini。例如，我們最近新增了一個 MCP 工具，以確保在 AI 輔助開發期間可以使用熱重新載入。
• 透過品質建立信任： 我們旨在透過確保 AI 生成的程式碼準確、符合慣例並符合專案標準來解決「驗證稅」問題。與 Google Deepmind 和 Antigravity 在模型評估方面的持續投資和合作，從模型到 AI 開發工具，推動了品質。如果您是模型工程師，請聯繫我們，我們很樂意讓您的模型編寫漂亮的 Dart 程式碼！

讓我們知道您的想法

我們故意公開實驗，因為沒有人確切知道這個領域將走向何方。我們邀請社群加入我們，分享您的回饋，並幫助引導 Dart 和 Flutter 的未來。在此、在社群媒體或透過社群論壇發表評論；我們重視您的想法和這些對話。

…或者繼續不使用 AI 構建應用程式，這也是完全有效的，我們歡迎您在上一篇文章中對我們的開發者路線圖提出回饋。若要深入了解我們的計畫，您可以查看完整的 官方 2026 年路線圖。

Dart 和 Flutter 如何思考 2026 年的 AI 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。