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

原文：https://flutter.dev/blog/try-flutter-web-with-webassembly-week

好的，這是一篇關於「嘗試使用 WebAssembly 的 Flutter Web 週」的繁體中文 Markdown 文章：

嘗試使用 WebAssembly 的 Flutter Web 週

立即選擇 Wasm 編譯，將網頁效能提升 2 到 5 倍

Kevin Moore

2026 年 8 月 17 日 · 閱讀時間 4 分鐘

rss_feed

share

• content_copy複製連結

• 在 X 上分享
• 在 Bluesky 上分享
• 在 LinkedIn 上分享

Flutter 讓您可以使用單一程式碼庫建立富有表現力的多平台應用程式。無論您是要建立儀表板、團隊工具還是完整的網頁應用程式，Flutter Web 都能讓您將應用程式帶到任何瀏覽器。

從 8 月 17 日到 8 月 21 日，我們將舉辦嘗試使用 WebAssembly 的 Flutter Web 週！本週，Dart 和 Flutter 工程師將即時處理收到的問題，以幫助解決遷移障礙，我們的開發人員關係團隊將在社群管道上分享您的勝利。

---

Flutter Web 中的 WebAssembly

我們在 2024 年 5 月的 Flutter 3.22 中透過將 Dart 編譯器與 WebAssembly 垃圾回收 (WasmGC) 搭配使用，穩定支援了 WebAssembly (Wasm)。

從那時起，Wasm 編譯已在實際應用程式中證明了自己。例如，Dart DevTools (dartdevtools) – 一個複雜、高度互動的 Flutter 網頁應用程式 – 自 2024 年底以來預設使用 WebAssembly 交付。今天，超過 97% 的開發人員使用 DevTools 都在 Wasm 上運行它，受益於流暢的 UI 檢查、快速載入和堅如磐石的穩定性。

Wasm 編譯已經過實戰考驗，隨時可用於生產環境。事實上，我們的分析顯示，超過 58% 的現有 Flutter 網頁應用程式今天無需任何程式碼更改即可編譯為 WebAssembly。

當您編譯到 WebAssembly 時，您的應用程式將受益於編譯器加速 (dart2wasm) 和多執行緒渲染 (skwasm)：

• ⚡ 幀時間加快高達 2 倍，並維持 60 FPS：在 JavaScript 幀數下降到約 30 FPS（總幀時間 34.5 毫秒）的繁重 Widget 樹攪動情況下，Wasm 仍能維持流暢的 60 FPS 交付（總幀時間 17.4 毫秒）。
• ⚡ Widget 構建和執行速度加快高達 2.5 倍：原生 WasmGC 結構加速了複雜的 UI 邏輯和狀態更新，將 Widget 構建時間從 29.3 毫秒縮短到 11.4 毫秒。
• ⚡ 多執行緒背景柵格化：Skwasm 將畫布柵格化卸載到專用的 Web Worker，使主瀏覽器執行緒保持空閒以實現響應式 UI 互動。
• 🎯 幀一致性提高 3 倍以上：將幀抖動從 ±1.5 毫秒減少到 ±0.5 毫秒，消除了垃圾回收暫停。
• 📦 最小的打包大小變化：壓縮後透過網路傳輸的應用程式總打包大小不會超過 5%。

自己試試看！您可以使用我們的互動式演示在 flutter-wasm-compare.web.app (原始碼) 上測試和比較您自己的硬體效能。

上述基準指標是在 Google Chrome 151 (151.0.7922.109) 上，於 Apple M4 Pro MacBook Pro (48 GB, macOS Sequoia 15.7.7) 上，在 60 Hz 顯示器更新率上限下，在中等壓力（200 個動畫攪動節點）下測量的。

---

為什麼 JavaScript 仍然是預設的編譯目標

如果 Wasm 提供更好的速度和穩定性，為什麼 flutter build web 仍然預設為 JavaScript (dart2js)？

為數百萬開發人員更改預設編譯器是一項重大舉動。雖然超過一半的 Flutter 網頁應用程式開箱即用 Wasm 構建，但一些 pub.dev 套件仍然依賴於需要更新以實現 Wasm 相容性的舊版 JavaScript 互操作 (dart:html 或 dart:js)。

這造成了一個典型的雞生蛋蛋生雞的困境：

• 在更多生態系統套件更新其 JS 互操作程式碼之前，我們不能將 --wasm 作為預設值。
• 套件作者通常不會優先更新，直到開發人員選擇 Wasm 並請求 Wasm 支援。

---

WebAssembly 遷移資源

為了幫助您遷移，我們更新了網頁文件。在建置之前，請查看以下指南：

• Flutter Web 上的 WebAssembly：了解如何設定伺服器標頭（COEP: credentialless 和 COOP: same-origin）、偵錯生產建置以及在運行時偵測 Wasm 支援。
• 遷移到 package:web 和現代 JS 互操作：擺脫 dart:html 和 dart:js 是 Wasm 相容性的關鍵。本指南說明如何遷移到 package:web 和 dart:js_interop。
• 網頁建置和部署指南：尋找發行建置、原始碼地圖、Firebase Hosting 和 CDN 快取。
• Flutter 網頁技術常見問題：獲取有關 Web Worker、Service Worker 和條件導入的答案。

---

本週嘗試 WebAssembly

無論您是維護 pub.dev 套件、管理生產網頁應用程式還是建置副專案，本週都請使用 WebAssembly 測試您的程式碼！

開始使用

1. 🚀 升級到 Flutter 3.47： 運行 flutter upgrade 以確保您使用最新的穩定版本，其中包含我們最新的 WasmGC 優化和運行時修復。
2. ⚙️ 使用 Wasm 進行建置： 在您的專案終端中運行 flutter build web --wasm。
3. 📝 報告任何阻礙： 如果您遇到套件依賴項或運行時問題，請告訴我們！在 Flutter Wasm 回饋表單上提交報告，以便我們的工程師可以協助解決遷移問題。
4. 🎉 分享您的勝利： 如果您的應用程式能順利建置並運行得更快，請告訴我們！分享您的指標和幀率增益。

在社群媒體上發文時，請使用 #FlutterWasmWeek，這樣我們就能展示您的成果！

---

建構一個預設為 Wasm 的網頁未來

透過本週共同測試您的應用程式並解決套件相依性，我們可以為將 WebAssembly 作為 Flutter Web 的預設編譯器鋪平道路。

運行 flutter upgrade，嘗試 flutter build web --wasm，然後告訴我們結果如何！

更多來自 Flutter

回顧：Google I/O 2026 上的 Flutter 點滴

多麼精彩的一週！Google I/O 2026 正式落幕。是時候回顧 Flutter 和 Dart 社群的一系列更新了。

Emma Twersky

2026 年 5 月 28 日 · 閱讀時間 4 分鐘

回顧：Google Cloud Next 上的 Flutter 點滴

回顧 Google Cloud Next 的 Flutter 議程、演示和社群亮點。

Emma Twersky

2026 年 4 月 27 日 · 閱讀時間 4 分鐘

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

原文：https://flutter.dev/blog/speeding-up-generative-ui-with-async-a2ui

使用非同步 A2UI 加速生成式 UI

生成式 UI (GenUI) 正在改變我建構使用者介面的方式。GenUI 允許 AI 代理程式在執行時使用基於 JSON 的訊息動態組合和更新使用者介面，而不是向每個使用者呈現一組靜態畫面。在 Flutter 中，genui 套件讓我可以即時渲染這些 AI 驅動的組件。

然而，建構代理應用程式會帶來一個熟悉的挑戰：啟動延遲。

如果應用程式在啟動時依賴呼叫大型語言模型 (LLM) 來生成初始介面，使用者將會一直等待該模型生成回應。LLM 必須處理系統提示、進行函數呼叫以擷取資料庫記錄，並建構 UI 負載，所有這些都可能比使用者在導航到新畫面時習慣等待的時間更長。為了讓 GenUI 應用程式感覺即時且反應靈敏，我需要一種方法在使用者甚至打開應用程式之前預先生成和快取這些 UI 佈局。

在這篇文章中，我將向您展示一種透過快取 A2UI 訊息來預先生成使用者介面的技術，然後逐步說明如何取得這些訊息並在代理應用程式中無延遲地顯示它們。

非同步 GenUI 快取的架構

為了將其納入情境，讓我們看看我如何將這種快取技術應用於我的範例應用程式 Commis，這是一個用於商業廚房和餐飲團隊的智慧助理。使用者體驗的核心是一個對話式聊天介面，廚師可以與 AI 助理討論即將到來的餐飲工作，以協調食譜分配和賓客數量。但是，當廚師第一次打開應用程式時，他們不應該從頭開始聊天。相反，我希望代理程式提供預先生成的 UI，其中包含與每項工作相關的資訊和操作。

為了解決生成這個豐富的啟動視圖的延遲問題，我決定將初始 UI 組件的生成過程與客戶端應用程式的執行時生命週期分開。每當資料更改時，在後台非同步生成 UI，允許後端預先快取佈局，使其準備好在啟動時立即載入。

以下是這個後台生成流程的樣子：

當使用者打開 Flutter 應用程式時，我完全繞過 LLM，直接從資料庫中提取預先計算的 UI，並將其加入到我的對話歷史記錄和 genui 傳輸層。透過將這兩個階段分離，使用者可以獲得即時的啟動體驗，但我仍然保留了動態、AI 生成介面的絕對靈活性。讓我們看看我是如何將其組合在一起的。

1. 後端的非同步 UI 生成

解決方案的前半部分位於伺服器端，我正在使用 Firebase 函數中新的（且技術上是實驗性的！）Dart 支援與觸發器。每當餐飲工作記錄更改時，就會啟動一個函數。它會檢索更新的資料，向 Gemini 發送提示以建構 UI，並將產生的 JSON 寫入名為「feeds」的 Firestore 集合中：

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

// functions/bin/server.dart

import 'package:commis_functions/src/content_generator.dart';
import 'package:firebase_admin_sdk/firebase_admin_sdk.dart';
import 'package:firebase_functions/firebase_functions.dart';

void main() {
  final adminApp = FirebaseApp.initializeApp();
  final firestore = adminApp.firestore();

  runFunctions((firebase) {
    // NOTE: Firestore triggers (like onDocumentWritten) are currently
    // experimental in the Dart Cloud Functions SDK and are only supported
    // when running within the Firebase Emulator Suite.
    firebase.firestore.onDocumentWritten(
      (event) async {
        // Read the API key from the environment parameters
        final apiKey = StringParam(
          'GEMINI_API_KEY',
          ParamOptions(
            defaultValue: '',
            label: 'Gemini API Key',
            description:
                'API key to use when accessing the Gemini Developer API',
          ),
        ).value();

        final jobId = event.params['jobId'];
        final jobData = event.data?.after?.data();

        // Ensure we actually have post-write data to process
        if (jobData == null) {
          print('Could not find post-write job data.');
          return;
        }

        final jobBuffer = StringBuffer();

        // ...
        // A whole bunch of lines that turn the job's properties into text for
        // the agent.
        // ...

        try {
          final generator = ContentGenerator(apiKey);
          // Via a class that encapsulates the call to the LLM, generate A2UI.
          final message =
              await generator.generateFeed(jobData.toString());

          if (message == noUiSentinel) {
            // Delete the cached document if the event is no longer upcoming
            await firestore.collection('feed').doc(jobId).delete();
            print('No UI generated; deleting feed for $jobId.');
            return;
          }

          // Cache the generated A2UI message in the feeds collection
          await firestore.collection('feed').doc(jobId).set({
            'message': message,
          });

          print('Wrote feed for $jobId.');
        } catch (e) {
          print('Error generating UI: $e');
          return;
        }
      },
      document: 'jobs/{jobId}',
    );
  });
}

在這個 ContentGenerator 類別中，我封裝了一個系統指令，其中包含我的應用程式的目錄（一系列關於可以生成哪些 UI 組件及其屬性的指令）、我選擇的模型（在本例中為 gemini-3.1-flash-lite），以及如果沒有要顯示的特定工作 UI 則返回其他邏輯。

我還給 LLM 一些嚴格的指示，說明不要包含什麼，事後看來，這讓我看起來像在對它大吼大叫！

1
2
3

**只回應 NavigationCard 或 "$noUiSentinel" 的 A2UI 訊息。什麼都不要。**
**不要包含任何對話文本。**
**不要包含任何關於您正在做什麼的解釋。**

因為這是一個簡單的演示範例，所以我對代理程式可以從目錄中建立哪些項目進行了嚴格的限制。不過，這並不是一個要求。您可以將整個目錄和說明提供給您的代理程式，讓它們盡情發揮創造力，或者縮減可用的選擇以保持嚴格的限制。

在這種情況下，如果餐飲工作即將到來（例如，在接下來的幾天內），Gemini 會回應一條簡潔的 A2UI 訊息，指示客戶端顯示地圖和導航詳細資訊。如果活動時間更長，它會返回我的標記字串 “NO GENERATED UI”，提示函數清除該工作的 feed。

有了這個，我就有一個充滿預先生成的使用者工作卡片的 Firestore 集合，這意味著我的應用程式已準備好顯示生成的 UI，而無需等待模型！

2. 在 Flutter 中使用快取的 UI

在客戶端，目標很簡單：從 Firestore 擷取預先生成的 A2UI 訊息並將它們顯示在螢幕上。

我在代理程式螢幕的初始化期間將其連接起來：

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
30
31
32
33
34
35
36

Future<void> _initAgent() async {
  // This repository is a class I use to hide away queries to Firebase. It's
  // really just grabbing values and providing a stream.
  final repository = context.read<FirestoreRepository>();

  String? feeds;

  try {
    // 1. Fetch active jobs and wait for their cached feed messages
    final jobs = await repository.getJobs();
    final feedFutures = jobs.map((job) => repository.getFeedMessage(job.id));
    final results = await Future.wait(feedFutures);

    // 2. Combine the non-empty cached A2UI messages
    feeds = results
        .map((r) => r?.trim() ?? '')
        .where((r) => r.isNotEmpty)
        .join('\n\n');
  } catch (e) {
    debugPrint('Error initializing agent: $e');
  }

  // 3. Initialize the agent session, passing the cached messages
  _agentService = FirebaseAILogicService(
    repository: repository,
    catalog: _catalog,
    cachedMessages: feeds,
  );

  // 4. Feed the cached messages directly to the transport adapter
  if (feeds != null && feeds.isNotEmpty) {
    _transport.addChunk(feeds);
  }

  setState(() => _isWaiting = false);
}

如果此函式找到快取的 A2UI 訊息，它會將它們發送到兩個方向：

• 首先，它將它們提供給我的代理類別 AgentService。它們被加入到系統指令中（「這些 A2UI 訊息已經在客戶端中…」），以便代理知道 UI 的初始狀態。
• 其次，它透過 addChunk 將它們饋送到 GenUI 傳輸層（仍然是我在整個套件中最喜歡的方法名稱！）。這確保它們被處理，創建正確的表面，並且使用者看到生成的 UI。

完成這兩項任務後，使用者可以立即在螢幕上看到即將到來的餐飲工作卡和地圖 UI——無需等待 LLM 思考。此外，使用者發送給代理程式的後續聊天訊息會在與螢幕上內容的完整歷史記錄的對話中進行。如果使用者看到工作導航卡，他們可以說「實際上，將那項工作的日期更改為下週一」，代理程式就會知道他們正在查看哪個工作並編輯正確的工作。

泛化快取模式

雖然我的特定專案依賴於 Firebase 和 Flutter，但這種預生成和快取模式可以適應您喜歡的任何後端堆疊：

• 觸發器和工作：直接從資料庫寫入事件生成 UI，或運行定期 cron 作業以預先烘焙即將發生的事件的 UI。
• 彈性儲存：您不需要笨重的資料庫。快速的鍵值儲存、簡單的快取表，甚至託管在 CDN 上的靜態 JSON 文件都完美適用。
• 客戶端無關：任何能夠處理 A2UI 的客戶端應用程式（包括使用其他框架建構的應用程式！）都可以讀取這些 JSON 負載並在啟動時渲染它們。

我在這篇文章中使用了相當簡單的範例。它沒有解決多使用者問題或事件結束後的快取失效問題，我想沒有人會對上週末發生的事件的導航幫助感興趣！

話雖如此，我希望這能為您激發一些想法，讓您了解可以使用離線生成的 A2UI 建構哪些體驗，以及如何建立、組合和使用 A2UI 訊息，以充分利用代理應用程式。

試試看！

準備好建構您的第一個 Flutter + A2UI 應用程式或嘗試 GenUI 的非同步模式了嗎？

• 查看官方的 Intro to GenUI Codelab 以了解生成式 UI 的基礎知識。
• 探索 GitHub 上的 flutter/demos 儲存庫，以查看 Commis 廚師助理的完整原始碼和其他 Dart 驅動的 GenUI 模式範例。

祝您建構愉快！

來自 Flutter 的更多內容

Flutter 的代理開發多平台價值

Flutter 多平台開發的基本價值在於使用單一共享程式碼庫建構支援多平台的應用程式。

Michael Thomsen

2026 年 5 月 18 日 · 3 分鐘閱讀

我們使用 Dart 和 Jaspr 重建了 Flutter 的網站

深入了解 Flutter 團隊為何以及如何使用 Dart 和 Jaspr 重建他們的網路形象。

Parker Lougheed

2026 年 4 月 15 日 · 8 分鐘閱讀

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

原文：https://dart.dev/blog/announcing-dart-3-13

隆重推出 Dart 3.13

讓 Dart 程式碼庫、工具和平台更加簡潔易用。

Connie Ooi ・ 2026 年 8 月 12 日 ・ 閱讀時間 9 分鐘

我們很高興地宣布 Dart 3.13！

在此版本中，我們慶祝每個開發者都喜歡的主題：簡潔輕巧的程式碼。Dart 3.13 將此重點帶入開發者體驗的每個層面。在語言方面，主要建構函數消除了重複的樣板程式碼，因此您可以在一行程式碼中定義類別。在開發者工具中，dart format 的改進讓您的程式碼根據 Effective Dart 風格規則 保持整潔，而 dart pub 引入了新的工作區命令，以保持 monorepos 的整潔。在 pub.dev 上，更豐富的文件功能，如 <callout-box> 標籤和 {@example} 指令，使套件文件更易於閱讀。在幕後，原生函式庫樹狀結構刪除 (@RecordUse) 和 WebAssembly 延遲載入有助於讓您的編譯應用程式二進位檔盡可能緊湊。

因此，更新 Dart 或運行 flutter upgrade 並跟隨我們探索 Dart 3.13 中的新功能！

語言更新

主要建構函式

繼 Dart 3.12 的實驗性預覽之後，主要建構函式現在在 Dart 3.13 中正式穩定！

主要建構函式是類別簡潔性方面的一大進步。我們從開發人員那裡聽說，在類別主體和參數列表中重複欄位名稱和類型可能會感到乏味。主要建構函式消除了這種重複，讓您可以在一行程式碼中定義，例如，一個具有兩個欄位和一個建構函式的 Point 類別：

1

class Point(final int x, final int y);

此功能還包括使用 new 或 factory 關鍵字的 建構函式簡潔語法，允許空宣告主體以 ; 結尾。

為了幫助您採用主要建構函式並在整個程式碼庫中保持一致的風格，我們引入了幾個新的 lint，並帶有自動修復功能：

• empty_container_bodies：鼓勵在類別宣告中使用 ; 而不是 {} 以簡潔。
• initialize_in_field_declaration：鼓勵將欄位初始化從主要建構函式移至欄位宣告以提高清晰度。
• unnecessary_const_in_enum_constructor：鼓勵從列舉建構函式中移除 const 以簡潔。
• unnecessary_primary_constructor_body：鼓勵移除不必要的主要建構函式主體以簡潔。
• unnecessary_type_name_in_constructor：鼓勵在建構函式宣告中將類型名稱替換為 new 以簡潔。
• use_declaring_parameters：鼓勵在可能的情況下使用宣告參數以簡潔。

除了這些 lint 之外，我們還添加了新的 IDE 重構功能來自動化您的程式碼遷移：

• 轉換為主要建構函式：將合格的內部建構函式轉換為主要建構函式。
• 轉換為內部建構函式：將主要建構函式轉換為內部建構函式。
• 轉換為宣告參數：將主要建構函式中的非宣告參數轉換為宣告參數。
• 將初始化移至欄位宣告：將欄位初始化從建構函式初始化列表移至欄位宣告。

了解更多： 主要建構函式文件

網路平台更新

WebAssembly 延遲載入預覽

我們一直在努力擴展 Dart 在網路上的 WebAssembly 功能。在 Dart 3.13 中，我們很高興地分享使用 dart2wasm 編譯時對延遲載入支援的早期預覽。您今天可以使用實驗性編譯器標誌啟用它：

1

dart compile wasm -O2 --enable-deferred-loading

在採用延遲載入的大型應用程式中，dart2wasm 與 dart2js 相比，可以顯著改善初始頁面載入 (IPL) 時間，這對 Flutter 網頁應用程式和基於 DOM 的網頁應用程式都有益。

提醒一下，dart:html 和 package:js 等舊版網頁函式庫在 dart2wasm 中不受支援，並在 Dart 3.7 中已棄用（將來在 dart2js 中也將停止工作）。許多套件已經遷移，因此升級您的套件相依性通常會自動解決問題。但是，如果您的程式碼直接使用這些舊版函式庫，請查看我們的遷移指南以立即採用支援的 dart:js_interop 和 package:web 函式庫。

了解更多： WebAssembly 文件

核心引擎和運行時更新

工程亮點

除了我們的 Web 平台進展之外，我們的團隊還在不斷改進 Dart 的基礎。以下是我們過去三個月在幕後工作的一些亮點：

• 類型提升健全性修復：修復了涉及巢狀函式的類型提升的 罕見不健全性 問題。
• 通用前端重構：重構了內部通用前端元件，以實現與 Dart 分析器更大的程式碼共享。
• DDC 模組系統統一：繼續從 Dart 開發編譯器 (DDC) 的工具中移除舊版模組系統，以建立單一、統一的模組系統。
• 原生運行時記憶體安全：透過在 Dart 堆周圍引入記憶體籠，增強了原生運行時記憶體安全。
• 動態模組連結：開始實驗 動態模組 以實現動態程式碼連結，為改進開發工作流程鋪平道路，例如團隊內部的快速原型共享。

工具更新

Dart 格式化程式

保持程式碼庫整潔易讀是 dart format 的首要任務。在 Dart 3.13 中，我們引入了一些樣式調整，以使格式化的程式碼更加簡潔。雖然大多數更改都是微小的，但一些關鍵更新將使您的日常程式碼明顯更容易閱讀：

• 方法調用格式錯誤修復：我們修復了一個錯誤，其中一個優化有時會錯誤地啟動並導致程式碼格式錯誤。它主要出現在包含大型集合常量的方​​法調用周圍：

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

// Before:
await MethodChannelContainer()
    .onMethodChannelInvoke('reportCrash', <String, Object?>{
  'time': nowTime,
  'errorValue': errorName,
  'reason': reason,
  'stacktrace': stacktrace,
});

// After:
await MethodChannelContainer().onMethodChannelInvoke(
  'reportCrash',
  <String, Object?>{
    'time': nowTime,
    'errorValue': errorName,
    'reason': reason,
    'stacktrace': stacktrace,
  },
);

• 方法鏈分割啟發式：我們更改了格式化程式決定是在 . 處分割方法調用鏈還是分割其中一個參數列表的啟發式。如果方法鏈的目標是具有單個元素或參數的集合文字或函式調用，它現在更傾向於分割調用鏈而不是目標：

1
2
3
4
5
6
7
8
9

// Before, split the target:
function(
  argument,
).method().another();

// After, split the chain:
function(argument)
  .method()
  .another();

• 導入區段分離：格式化程式現在會在一系列導入中不同「區段」之間插入一個空行。格式化程式不會對導入進行排序，但它現在會根據 Effective Dart 中的規則 將它們分開：

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

// Before:
import 'dart:io';
import 'dart:math';
import 'package:args/args.dart';
import 'package:test/test.dart';
import 'my_library.dart';

// After:
import 'dart:io';
import 'dart:math';

import 'package:args/args.dart';
import 'package:test/test.dart';

import 'my_library.dart';

dart_style 變更日誌 中描述了一些其他樣式調整，但這些是最明顯的。我們知道格式化更改可能會導致令人煩惱的變動，因此我們在更改樣式時會盡量保守。同時，樣式改進可以使程式碼更容易閱讀，這在我們由於生成式 AI 而審查比以往更多程式碼的時代，是一個寶貴的優勢。除了優化錯誤修復之外，這些樣式更改是 語言版本化 的。您只有在將程式碼升級到 Dart 3.13 後才能看到它們。

了解更多： Dart 格式化程式文件

Pub 更新

套件文件更新

清晰且結構良好的套件文件對於健康的生態系統至關重要。為了幫助套件作者建立更簡潔、更易於維護的文件，pub.dev 現在支援 <callout-box> 標籤和 {@example} 指令的端到端。您可以將程式碼片段直接從範例檔案中提取到您的 API 文件中，同時隱藏不必要的樣板程式碼。

例如，在 example/foo.dart 中定義一個片段區域：

1
2
3
4
5
6
7
8

// example/foo.dart
void main() {
  // #region abc
  // Included in documentation
  foo();
  assert(false); // #hide
  // #endregion
}

然後在您的 Dart 文件註釋中引用該區域：

1
2
3
4
5

/// This is a great function.
///
/// Example usage:
/// {@example /example/foo.dart#abc}
void foo() {}

pub.dev 直接在生成的文檔中呈現指定的程式碼區域。

在幕後，pub.dev 還為 dartdoc 檔案查詢部署了兩級哈希索引。此更新大幅加快了包含 10 萬多個生成檔案的大型套件的文件渲染速度。

了解更多： CupertinoActivityIndicator 類別文件

原生互操作更新

使用 @RecordUse 和 package:record_use 進行原生函式庫樹狀結構刪除

我們對效率的承諾一直延伸到您編譯的應用程式二進位檔案。當使用 dart:ffi 和 Code Assets 構建與原生 C、C++ 或 Rust 程式碼互操作的 Dart 和 Flutter 應用程式時，Dart 編譯器始終會樹狀結構刪除未使用的 Dart 包裝函式。然而，底層的原生二進位檔案傳統上是完整捆綁的。

有了 @RecordUse (在 package:meta 中) 和 package:record_use，Dart 和 Flutter 現在可以像處理 Dart 程式碼一樣對原生函式庫進行樹狀結構刪除。這確保您的最終應用程式捆綁包只包含您的應用程式實際調用的原生程式碼。

運作方式

1. 使用 @RecordUse() 標註原生 FFI 綁定：使用 @RecordUse() 註釋標記您的原生 FFI 綁定 (例如由 ffigen 生成的綁定)：

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

import 'dart:ffi';
import 'package:meta/meta.dart';

@RecordUse()
@Native<Int32 Function(Int32, Int32)>()
external int sqlite3_open(
  Pointer<Utf8> filename,
  Pointer<Pointer<sqlite3>> ppDb,
);

@RecordUse()
@Native<Int32 Function(Pointer<sqlite3>)>()
external int sqlite3_close(Pointer<sqlite3> db);

2. 在編譯期間追蹤可達的呼叫：在 Dart AOT 建置的整個程式編譯和樹狀結構刪除期間，編譯器會追蹤在可執行程式碼中哪些帶有 @RecordUse() 註釋的綁定是可達的。位於未使用的 Dart 程式碼中且被樹狀結構刪除的呼叫會自動排除。

3. 在您的連結掛鉤中修剪未使用的原生符號：在您的套件的連結掛鉤 (hook/link.dart) 中，檢索 input.recordedUses。使用 package:record_use，查詢已記錄的呼叫，並指示您的原生工具鏈 (例如 package:native_toolchain_c 或 Rust 建置腳本) 只保留 Dart 實際呼叫的符號：

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

import 'package:hooks/hooks.dart';
import 'package:native_toolchain_c/native_toolchain_c.dart';
import 'package:record_use/record_use.dart';
import 'package:my_package/src/c_library.dart';
import 'package:my_package/src/record_use_mapping.dart';

void main(List<String> arguments) async {
  await link(arguments, (input, output) async {
    // Extract symbols for functions called in reachable Dart code:
    final symbolsToKeep = input.recordedUses?.calls.keys
        .cast<Method>()
        .map((method) => recordUseMapping[method.name]!);

    await cLibrary.link(
      input: input,
      output: output,
      linkerOptions: LinkerOptions.treeshake(
        symbolsToKeep: symbolsToKeep,
      ),
    );
  });
}

為何這很重要

• 大幅縮小二進位檔案：SQLite、密碼學、影像解碼器或音訊引擎等重量級原生相依性公開了數百個函式。在發行版本建置期間，連結器會刪除未引用的原生程式碼、無用的物件檔案和未使用的匯出。
• 完全省略未使用的原生函式庫：如果您的應用程式從不調用套件的原生綁定，連結掛鉤會將原生二進位檔案從最終應用程式捆綁包中完全刪除。
• 無縫工具整合：ffigen 等工具會自動標註生成的綁定，而 package:native_toolchain_c 則直接與連結掛鉤整合，以實現端到端原生樹狀結構刪除。

了解更多： 原生連結掛鉤文件 和 紀錄使用文件

總結

Dart 3.13 實現了我們對更簡單、更簡潔的開發者體驗的願景。透過將主要建構函式等表達性語言功能與更智慧的工具、更豐富的 pub.dev 文件和緊湊的原生樹狀結構刪除相結合，此版本可幫助您專注於最重要的事情：建置出色的應用程式。

此版本中的所有內容都來自您的實際洞察力、錯誤報告和套件貢獻。Dart 生態系統因您的積極參與而蓬勃發展，我們非常感謝您在塑造語言未來方面的合作。

我們迫不及待想看看您用 Dart 3.13 創造了什麼！立即花點時間 更新 Dart 或運行 flutter upgrade，並在我們的 GitHub 議題追蹤器 上加入對話。感謝您成為如此熱情的社群並與我們一起建立 Dart 的未來！

了解更多： Dart SDK 變更日誌

更多來自 Dart 的消息

隆重推出 Dart 3.12

Google I/O 2026 大幅提升開發人員生產力
Connie Ooi ・ 2026 年 5 月 20 日 ・ 閱讀時間 7 分鐘

隆重推出 Dart 3.11

各位 Dart 開發人員您好！最新的穩定版本 Dart 3.11 正式發布！
Connie Ooi ・ 2026 年 2 月 11 日 ・ 閱讀時間 3 分鐘

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

原文：https://flutter.dev/blog/whats-new-in-flutter-3-47

Flutter 3.47 的新功能

依模組設計：獨立 UI 套件和桌上型 Impeller

Flutter 3.47 登場，帶來了一些令人興奮的更新。

今天，我們很高興地發佈獨立 material_ui 和 cupertino_ui 套件的 1.0 版本。這是一個重要的里程碑，它將設計系統從核心 SDK 中分離出來。

我們還全面提升了效能和工具。此版本將 Impeller 預設引入桌面，為 iOS、macOS 和 Xcode 27 準備了我們的管道，並將 Flutter Widget Previews 升級到穩定版。

所以，在您的終端機中執行 flutter upgrade 開始，或者繼續閱讀以了解此版本中的主要變更。

選擇您自己的 UI 冒險

與解耦 Flutter 的第一步已經到來：Material 和 Cupertino 現已作為獨立套件提供！

Flutter 最強大的優勢之一是它能夠渲染像素完美的 Material 和 Cupertino Widget。然而，由於這些設計庫在歷史上是直接捆綁在核心 SDK 中的，這減慢了它們的開發速度，並使得貢獻或保持它們最新變得更加困難。

雖然核心 SDK 在此版本中仍包含這些函式庫，但您現在可以選擇使用已正式在 pub.dev 上達到 1.0 版本的獨立 material_ui 和 cupertino_ui 套件。

解耦設計路線圖（選擇性加入）

透過選擇加入解耦設計系統，您可以控制您的設計路線圖。因為 material_ui 和 cupertino_ui 現在位於 pub.dev 上，它們可以根據自己的每週排程發佈錯誤修復和新元件，獨立於每季度的 Flutter SDK 發佈。

解耦設計系統為我們帶來以下優點：

• 您可以使用最新的 Cupertino 和 Material Widget 風格，而無需強制升級整個 Flutter SDK 版本。
• 我們可以更快、更頻繁地實現貢獻和更新。
• 我們為風格中立的 Flutter 核心 Widget 目錄奠定了基礎，使未來更容易建立自訂設計系統。

如何遷移

若要將您的專案遷移到新的獨立套件，請執行以下命令：

1

dart fix --apply --code=migrate_design_widgets

此工具會自動將您的 package:flutter/material.dart 和 package:flutter/cupertino.dart 匯入更新為新的獨立套件。

注意： 如果遷移工具在更新您的 pubspec.yaml 時遇到問題（一個已知的早期錯誤），您可以透過手動執行 flutter pub add material_ui（如果您使用 cupertino_ui，則執行 cupertino_ui），然後再次執行 dart fix --apply 來解決。

核心 SDK 中的原始設計函式庫預計將在即將於 11 月發佈的秋季穩定版中正式棄用。如果您正在遷移生態系統中的套件，請將此遷移到獨立套件的過程視為一個主要版本。

彌合遷移差距

為了方便生態系統遷移到新的獨立設計函式庫，material_ui 和 cupertino_ui 提供了遷移工具。MaterialUiCompatibilityBridge 允許您的應用程式立即遷移到獨立套件，即使您的一些套件相依仍在使用舊的核心 SDK 匯入。

例如，您可以將您的應用程式包裝在相容性橋接器中：

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

import 'package:material_ui/material_ui.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: const Color(0xFF6750A4)),
      ),
      builder: (BuildContext context, Widget? child) {
        return MaterialUiCompatibilityBridge(child: child!);
      },
      home: const HomeScreen(),
    );
  }
}

解耦本地化

作為此過渡的一部分，flutter_localizations 也已解綁。Material 和 Cupertino Widget 的本地化委派和翻譯字串現在分別位於 package:material_ui 和 package:cupertino_ui 中。

之前：

1
2
3
4
5
6
7
8
9

import 'package:flutter_localizations/flutter_localizations.dart';
import 'package:flutter/material.dart';

// ...
localizationsDelegates: const <LocalizationsDelegate<dynamic>>[
  GlobalCupertinoLocalizations.delegate,
  GlobalMaterialLocalizations.delegate,
  GlobalWidgetsLocalizations.delegate,
],

之後：

1
2
3
4

import 'package:material_ui/material_ui.dart';

// ...
localizationsDelegates: GlobalMaterialLocalizations.delegates,

將 localizationsDelegates 設定為 GlobalMaterialLocalizations.delegates 現在也包含 Cupertino 和 Widgets 委派，簡化了您的設定。

開放貢獻

透過在四月凍結對 Material 和 Cupertino 函式庫的貢獻，我們得以確保平穩的遷移。material_ui 和 cupertino_ui 中等著您的函式庫與您目前使用的函式庫相同。

現在我們準備解除凍結，期待在新套件中定期推出更多修復和功能，目前計畫每週發佈。我們也很興奮能正式開放這些套件供社群貢獻。

準備迎接下一波 Apple 更新

隨著 Xcode 27、iOS 27 和 macOS 27 將於今年秋天推出，我們一直致力於確保 Flutter 為即將到來的更新做好準備。為了確保您的使用者不會遇到第一天的驚喜，我們建議您現在就針對 Apple beta 版測試您的應用程式。

此外，為了支援 Xcode 27，最低支援的作業系統版本已提高：

UIScene 生命週期強制要求

iOS 27 SDK 現在對所有基於 UIKit 的應用程式強制執行 UIScene 生命週期。使用 Xcode 27 構建但未採用 UIScene 的應用程式將無法在啟動時啟動。

對於大多數應用程式，Flutter CLI 會在建置期間自動處理此遷移。但是，如果您的 AppDelegate 中有自訂原生程式碼或使用仍依賴舊版應用程式生命週期的外掛，則需要手動遷移。在這些情況下，您必須遵循 UIScene/Delegate 採用指南手動遷移。

逐步淘汰 Intel Mac

為配合 Apple 過渡到 Apple Silicon，Flutter 正在逐步淘汰對基於 Intel 的 Mac 的支援。我們已停用 Intel 硬體上的自動測試執行，並且 Flutter CLI 現在在 Intel 主機上建置或鎖定雙架構時會列印警告。這些警告將在未來版本中變成錯誤。

您可以立即透過執行 flutter config --enable-macos-arm64-only 選擇建置僅限 ARM64 的 macOS 應用程式。

Swift Package Manager 進度

社群在過渡到 Swift Package Manager 方面取得了令人難以置信的進展，前 100 個 iOS Plugin 中有 92 個已遷移。如果您之前關閉了 Swift Package Manager，可以透過執行 flutter config --enable-swift-package-manager 再次嘗試。

由於 CocoaPods 現在處於維護模式，未遷移到 SwiftPM 的 Plugin 最終將停止工作。未遷移的 Plugin 也會獲得較低的 pub.dev 分數。如果您維護一個 Plugin，請查閱 遷移指南 並閱讀我們 之前的部落格文章 以獲取更多詳細資訊。

此版本還透過社群貢獻者 @lukemmtt 優化了建置時間，他透過在建置過程早期過濾掉不必要的 SwiftPM 套件方案來改進了建置管道。

預設啟用 Wasm 的路線圖

我們正在積極努力預設啟用 Flutter Web 應用程式的 WebAssembly (Wasm)，為瀏覽器帶來類似原生的效能。如果您尚未用 Wasm 測試您的 Web 應用程式，您可以今天透過向發佈建置命令傳遞 --wasm 標誌來選擇啟用：

1

flutter build web --release --wasm

在您準備這次轉換時，請記住 Wasm 需要將您的程式碼庫遷移到新的 JS interop 套件（package:web），因為不支援舊版的 dart:html 函式庫。升級專案的套件相依性通常會自動解決這些舊版 interop 問題。

為了幫助擴展更大的 Web 應用程式，此版本還引入了對 Wasm 延遲載入的實驗性支援。這在 main channel 上提供了一個旗標，它允許您將 Wasm 應用程式分解為更小、延遲載入的模組，從而優化初始載入時間：

1

flutter build web --release --wasm --enable-wasm-deferred-loading

Impeller 帶來現代圖形到桌面

我們致力於讓桌面平台成為高效能圖形的頭號目標。在 Flutter 3.47 中，Impeller 成為 macOS、Windows 和 Linux 的預設渲染器。

如果您不熟悉 Impeller，它是 Flutter 的下一代渲染引擎，從頭開始構建以取代 Skia。透過鎖定現代硬體 API（例如 macOS 上的 Metal 和 Windows 和 Linux 上的 Vulkan），Impeller 會在建置時編譯一組固定的著色器，而不是在執行時動態編譯它們。這消除了動畫首次播放時短暫的卡頓（稱為著色器編譯卡頓），從第一幀開始提供始終如一的平滑過渡。在 Impeller 渲染引擎文件中了解更多資訊。

如果您需要暫時選擇退出 Impeller，請遵循以下步驟：

• macOS：在 Info.plist 中將 FLTEnableImpeller 設定為 false。
• Windows：在 main.cpp 中新增 project.set_impeller_switch(flutter::ImpellerSwitch::Disabled)。
• Linux：在 my_application.cc 中呼叫 fl_dart_project_set_enable_impeller(project, FALSE)。

未來版本將移除備用選項，因此如果您必須恢復使用 Skia，請提交錯誤。此外，macOS 上預設啟用 Wide Gamut Color，可在支援的硬體上提供豐富、生動、精確的顏色渲染。

實驗性多視窗進度

與 Canonical 合作，並感謝維護者 @robert-ancell 和 @mattkae，我們正在擴展我們的實驗性桌面視窗 API。Linux 和 Windows 現在支援彈出視窗，讓您可以建立原生上下文選單和實用程式調色盤。

您現在還可以在平台特定的控制器上查詢 windowHandle，以獲取指向底層原生視窗（HWND、NSWindow 或 GtkWindow）的直接指針。這啟用了進階原生功能存取，例如 Windows 上的可停靠窗格，例如 @orestesgaolin 貢獻的這個可停靠窗格演示：

我們還解決了幾個視窗焦點和實現錯誤。在 Windows 上，啟動視窗不再會將背景視窗拉到前面或在應用程式恢復時奪回焦點，這要歸功於貢獻者 @9AZX：

在 Linux 上，多視窗建立現在明確地實現視窗，然後它們才從合成器接收第一幀，修復了早期渲染警告和合成器斷言。

我們還新增了一個新的 sized-to-content API，可讓您建立自動調整大小以符合其內容的常規和對話框視窗。

桌面版風格

Windows 和 Linux 現在支援 Flutter 風格。

例如，您的 pubspec.yaml 檔案可以在不同的風格上使用不同的資源：

1
2
3
4
5
6
7
8

flutter:
  assets:
  - path: assets/flavor_a/images
  flavors:
  - flavor_a
  - path: assets/flavor_b/images
  flavors:
  - flavor_c

使用 --flavor 選項來指定您的風格。例如：

• flutter build windows --flavor flavor_a
• flutter build linux --flavor flavor_a

感謝 @AngeloAvv 的精彩貢獻！

• https://github.com/flutter/flutter/pull/187034
• https://github.com/flutter/flutter/pull/187029

更銳利的桌面文字

桌面螢幕通常比行動裝置顯示器的像素密度低，但具有更多的圖形計算能力。為了在桌面上提供更銳利的文字和更清晰的向量曲線，使用 Impeller 的 Flutter 引擎現在在 macOS、Linux 和 Windows 上使用有符號距離函數 (SDF) 渲染。

穩定預覽和 GenUI 更新

Widget 預覽達到穩定版

Flutter Widget Preview 現已穩定，可讓您即時渲染、檢查和疊代個別 UI 元件，而無需建置或啟動整個應用程式。

有了這個穩定版本，您可以期待：

• 更快的啟動時間，這要歸功於 widget_preview/ 資料夾中的本地專案快取，它消除了重複的設定開銷。
• 透過抽象的 PreviewThemeData API 進行更靈活的測試，該 API 支援複雜矩陣測試的順序主題分層。
• 預覽網頁 Widget 時自動同步網頁資源，直接複製您的主專案的 web/ 資源，在使用 Flutter Web 時自動應用任何自訂主題或自訂您的 index.html 檔案。

GenUI 的持續進展

Flutter 的生態系統不斷發展，以滿足使用 GenUI 為其使用者建立新型代理體驗的開發人員的需求。genui 套件的 0.10.0 版本最近發佈，帶來了許多修復和新功能，其中包括：

• 一個新的 a2ui_core 套件，它集中了與協議相關的類別，包括表達式、目錄條目等。
• 支援 A2UI 的客戶端函數，這使您能夠為代理提供函數，代理可以指示客戶端用於驗證、派生值和其他小任務，而無需往返。

優化平台體驗

本節重點介紹了社群和 Flutter 團隊為改善所有平台上的開發人員和使用者體驗而貢獻的針對性改進。

Android

在 Android 上，我們解決了虛擬鍵盤的一個問題，即在事件期間修飾鍵（如 Shift）可能會卡住。鍵盤回應器現在跳過了虛擬鍵盤輸入的物理鍵合成，保持了鍵盤互動的清晰。

Android 相依性矩陣

為了確保穩定的建置，Flutter 3.47 已針對以下 Android 相依版本進行驗證：

• Java：17（最低要求版本）
• Kotlin Gradle Plugin (KGP)：2.4.0
• Android Gradle Plugin (AGP)：9.1.0（與 KGP 2.4.0 相容的最新版本）
• Gradle：9.3.1（AGP 9.1.0 的最低要求）

為了確保您的應用程式在未來版本中成功建置，我們鼓勵您在建置檔案中使用 Flutter SDK 提供的標準 API 等級變數。對於此版本，它們已設定以下預設值：

• flutter.compileSdkVersion (API 36)
• flutter.targetSdkVersion (API 36)
• flutter.minSdkVersion (API 24)

iOS 和 macOS

對於 iOS 開發人員，程式碼簽署現在更加透明。感謝社群成員 @alex-medinsh，CLI 在選擇憑證時會同時顯示 Team ID 和 Team Name。

此外，社群成員 @mozammal-hossain 透過在簽署失敗時提供更清晰的佈建設定檔錯誤訊息來改進疑難排解。

桌面

桌面平台也獲得了有針對性的改進。Windows 上韓語文字組成的插入符號定位問題已解決（感謝 @CHOIgoung），並且 Windows Plugin 現在可以使用 FlutterEngine::PostPlatformThreadTask 將耗時的任務移出平台線程。在 Linux 上，@CodeDoctorDE 加入了觸控筆旋轉和壓力報告。

圖形和引擎

在引擎中，鎖定 OpenGLES 的片段著色器在讀取紋理時不再需要有條件的座標翻轉。現在這在頂點著色器中處理。有關 OpenGLES 渲染到紋理的重大變更頁面，請參閱更多詳細資訊。

框架優化

最後，框架本身更加流暢，主要元件都有改進：

無障礙功能和語義： Android 高對比度和顏色反轉設定現在會自動偵測，感謝 @xxxOVALxxx（MediaQueryData.highContrast 和 MediaQueryData.invertColors）。Text.rich 內部的巢狀文字跨度現在與語義樹中的佈局順序相符，並且為 BlockSemantics 添加了鍵盤焦點阻擋。

文字和選取： 行動裝置上的文字選取控點在輕微捲軸時保持穩定，並且鍵盤快捷鍵現在可以關閉打開的選取選單。在 Android 上，選取控點不再遮擋螢幕頂部附近的上下文選單，這要歸功於 @JhonaCodes。

BEFORE	AFTER

我們還修復了 SelectableRegion 在空可捲軸容器中選取開始時的崩潰問題，並解決了淡入選取文字上的視覺高亮偽影問題，這要歸功於 @ikramhasan。

BEFORE	AFTER

手勢和捲軸： 透過平台視圖嵌入的原生 iOS 視圖的手勢傳播得到改善。EdgeDraggingAutoScroller 現在遵守活動捲軸視圖的 ScrollPhysics，防止在鎖定列表上自動捲軸。

核心 Widget 增強功能： 使用 useOriginalColors: true 保留 ImageIcon 內的原始顏色，在 AnimatedCrossFade 中指定裁剪行為，並使用 ImageStreamListener 直接追蹤圖片串流錯誤。

準備升級

各就各位，基礎已準備就緒。剩下要做的就是將這些升級帶到您的本機：

1

flutter upgrade

當您的 SDK 在背景更新時，我們為您準備了一些作業（有趣的那種）：

• 認識貢獻者：準備好爆米花，收看我們的新影片系列 Introducing: Flutter Notable Commits，慶祝促成此版本發佈的社群成員。
• 檢查詳細資訊：快速瀏覽 重大變更頁面，為獨立 UI 套件遷移做好準備。

我們很高興能看到大家用這個更新改進的 Flutter 版本能建立什麼！

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

原文：https://flutter.dev/blog/flutter-q2-2026-survey

Flutter 2026 年第二季度使用者調查 — 信任、透明度和不斷發展的社群

Flutter 2026 年第二季度使用者調查結果出爐！探索開發者滿意度、信任度、AI 編碼工具採用情況以及 Cupertino widgets 的更新。

Emma Twersky

Aug 6, 2026 · 11 min read

rss_feed

share

• content_copyCopy link

• Share on X
• Share on Bluesky
• Share on LinkedIn

自 2018 年 Flutter 1.0 發布以來，Flutter 團隊每年進行兩次使用者調查。2026 年第二季度調查於 6 月 8 日至 6 月 22 日進行，透過 Flutter 的 IDE 外掛（VS Code、IntelliJ、Android Studio）、X 和我們的網站收集了超過 3,500 份完整回覆。我們詢問了以下內容：

• 整體滿意度和信任度，按重點領域和開發者區段劃分
• 您日常工作流程中使用的編輯器和 AI 編碼代理
• 您對 Flutter 和 Google 的看法

總體而言，超過 3,500 名受訪者中有 93% 表示滿意（前兩名：非常滿意 + 有點滿意），與 2025 年第四季度相比保持穩定。有趣的是，在這個標題數字之下：現在有 58% 的人非常滿意（比 2025 年第四季度的 52% 顯著增加了 6 個百分點），而「有點滿意」則從 40% 下降到 35%。對 Flutter 能夠持續滿足您開發需求的信任度也朝著相同的方向發展，從 77% 上升到 83%。我們為我們的團隊和社群共同推動這些改進所取得的進步感到自豪。

透明度是 Flutter 的核心價值，因此我們希望透過這篇文章來評估我們的工作是否符合您的期望。我們直接根據您的回饋審查了我們最近的版本和 [2026 年路線圖](https://github.com/flutter/flutter/blob/master/docs/roadmap/Roadmap.md)，以了解我們的計劃如何與您的實際體驗保持一致。

滿意度上升，特別是對於新的 Flutter 開發者 🚀

每次調查我們都會追蹤 Flutter 體驗的 16 個部分，因為單一的整體滿意度分數隱藏了重要的差異。這次，我們衡量的每個開發者子群組（按經驗水平、公司規模、團隊規模和平台）都達到了 90% 或更高，這在我們的調查歷史上尚屬首次。

開發者評價最高的重點領域是 Dart 語言（92% 前兩名）、Android 應用程式開發（91%）和核心框架（90%）。這些分數在多次調查中一直保持強勁，反映了在實際使用下穩固的基礎。

新手開發者歷來是我們滿意度最低的群體，因為開始使用任何新框架都會帶來最初的摩擦。然而，這次新手滿意度達到了 90% 的前兩名（比 2025 年第四季度增加了 5 個百分點），我們認為這並非巧合。早在 2 月，我們就推出了新的 [Dart 和 Flutter 入門體驗](https://docs.flutter.dev/learn/pathway)，這是一條結合了教學、影片和測驗的引導式學習路徑，專門針對剛接觸該生態系統的開發者。

儘管如此，當我們將這個群體的滿意度僅限於核心框架時，體驗差距仍然很大：新手為 82%，專家為 93%。這 11 個百分點的差距比調查中幾乎任何其他差距都大，這表明核心框架仍然存在陡峭的學習曲線，單靠入門教學無法解決。雖然入門體驗有所改善，但幫助新開發者掌握核心框架概念仍然是我們正在積極解決的一個獨立挑戰。

有趣的是，一個可能的原因是新手開發者在開發工作流程中對 AI 工具的採用率較低。到目前為止，我們一直有意保持最初的學習路徑為手動，以鼓勵對基礎知識的理解，但鑑於這種趨勢，我們正在探索如何更早地向新手提供 AI 輔助的 Flutter 指導，以改善他們的早期體驗。

AI 編碼工具已從實驗轉變為預設 ✨

我們在本週期首次將程式碼編輯器和代理使用情況加入調查，結果證實了我們都親身經歷過的 AI 熱潮。傳統 IDE 仍大量使用，VS Code 以 66% 領先，Android Studio 以 40% 位居第二。但緊隨其後的是 AI 編碼代理：Claude Code 佔 32%，Antigravity 佔 23%，兩者現在都領先於 GitHub Copilot（19%）、Cursor（18%）和 Codex（17%）。 （方法論說明：受訪者可以使用一個或多個編輯器，因此這些數字加起來遠遠超過 100%。）

大多數編輯器的滿意度都偏高：VS Code 為 88%（前兩名），Claude Code 為 86%，Codex 為 85%。有一個例外：Zed 的滿意度僅為 38%（前兩名），遠低於列表中所有其他工具，即使使用率仍然很小（5%）。我們尚未獲得足夠的定性細節，但我們將繼續探索工具選擇如何影響人們對 Flutter 的整體滿意度。

這對我們來說並不是一個新趨勢。使用 Flutter 進行 Vibe 編碼已經在我們的關注範圍內一段時間了。我們在 2025 年年中推出了 [Dart MCP 伺服器](https://docs.flutter.dev/ai/mcp-server)，Google I/O 包含了 [Flutter 和 Dart 的官方代理技能](https://docs.flutter.dev/ai/agent-skills) 的發布以及 [代理熱重載](https://docs.flutter.dev/ai/antigravity#agentic-hot-reload)（適用於任何代理的任務導向指令）。我們持續出貨，並發布了 [Flutter Antigravity 外掛](https://docs.flutter.dev/ai/antigravity)，並正在與其他主要代理工具合作，以確保 Flutter 外掛開箱即用。

我們希望 Flutter 成為每個主要代理編碼工具的第一方、受良好支援的目標，我們正在與 Google 內部和外部團隊合作，以實現這一目標。我們目前的投資範圍包括核心模型、評估系統，以及技能和 MCP 工具的組合，以確保高品質的 Flutter 代理開發者體驗和程式碼生成。

體驗仍有不足之處

並非每個子系統都表現良好。在此次調查中，Cupertino Widgets、Web、Windows 和 Linux 是我們評分最低的領域。

Web (72%)、Linux (73%) 和 Windows (74%) 的滿意度與 2025 年第四季度相比都有所提高。為了延續這一勢頭，仍有重大的路線圖計畫待執行，包括將 WebAssembly 作為預設的 Web 目標，以及與 Canonical 合作擴展多視窗桌面支援。這些基礎變革需要時間，這就是為什麼儘管總體趨勢朝著正確的方向發展，但滿意度差距尚未完全彌合的原因。

當我們問是什麼更廣泛地導致不滿時，四個主題清晰地浮現出來。以下是我們今天對每個主題的看法，沒有任何粉飾：

• **平台和生態系統成熟度 (44%)**：這是最大的主題，圍繞著升級的痛苦而非入門。開發者描述在升級舊專案時浪費了數小時在版本矩陣猜測上，特別是在 Android 上，當同時處理 Flutter、Dart、Gradle、Kotlin 和 JVM 版本時。

Android 工具和依賴項問題在之前的調查中也曾出現過。我們知道跟上 Android 不斷變化的建構要求是一個主要的挫折，因此我們一直致力於使您的升級更順暢、更可預測。在 **Flutter 3.29** 中，我們移除了傳統的基於腳本的 Gradle 外掛應用程式，以減少新 AGP 版本發布時的中斷。**Flutter 3.32** 將 Gradle 外掛從 Groovy 重寫為 Kotlin，以實現更穩定的建構過程，而 **Flutter 3.38** 發布了跨 Java、Kotlin、AGP 和 Gradle 的官方版本矩陣。最近，**Flutter 3.41** 加入了 AGP 9 支援，而 **Flutter 3.44** 包含了 [遷移到內建 Kotlin](https://docs.flutter.dev/release/breaking-changes/migrate-to-built-in-kotlin)。

為了消除常見的版本匹配猜測，我們現在在 [「Flutter 新功能」部落格](https://flutter.dev/blog?category=release) 中包含一個兼容性矩陣，其中列出了 Java、Kotlin、Gradle 和 Android Gradle Plugin 的支援組合。我們還在我們的建構工具中內建了智慧型應變措施，因此當主要的平台變更（例如 Android Gradle Plugin 9 轉換為內建 Kotlin）發生時，您現有的專案和舊版外掛將繼續安全地編譯。我們的目標是在幕後處理這些複雜的轉換，並在發生衝突時提供清晰、可操作的回饋，以便您可以回到編寫程式碼。

同時，在 iOS 和 macOS 上，**Flutter 3.44** 將 Swift Package Manager 設定為預設的依賴管理工具，以取代 CocoaPods，前 100 個 iOS Plugin 中已有 92 個已遷移。

• **工具和 IDE 體驗 (33%)**：主要圍繞著希望更深入的 Android Studio 整合：更多的 AI 工具、更多的原生支援、更好的視覺化。我們目前的 AI 投資主要集中在建立可與任何代理一起使用的 AI 工具，無論您的 IDE 是什麼。這包括 Dart MCP 伺服器和代理技能工作，這些工作早於本次調查的進行。話雖如此，當我們首次推出 Dart MCP 時，Android Studio 並不支援 MCP，但我們正在努力確保我們的工具也能在那裡運作。

• **錯誤和穩定性 (24%)**：特別指出除錯工具，例如移除後仍存在的斷點，以及一些開發人員發現混亂的效能時間軸視圖。我們想在這裡直言不諱：我們尚未發布修復程式，但如果您有我們可以進一步除錯的詳細資訊或重現步驟，請在 GitHub 上提交議題。

• **UI/UX 美學 (14%)**：就數量而言是最小的主題，但它是與 Cupertino 分數下降最直接相關的主題，因此它值得擁有自己的部分，就在下方。

Cupertino widgets：一個新篇章

Cupertino Widgets 下降 6 個百分點至 61%（前兩名），這是調查中跌幅最大的一個領域，也成為我們評分最低的領域。幾位開發者表示，感覺 Flutter 在原生應用程式的承諾方面未能跟上 iOS 風格設計的步伐，並表示擔心一旦在核心框架內維護變得困難，原生設計系統就會被降級。雖然我們正在密切關注此回饋，但這並不令人意外。我們有意暫停了 Cupertino Widgets 的工作，以執行解耦，從而達到一個更好的世界，我們可以更快地出貨。

在八月份的版本中，我們正在實施解耦的第一步，在 pub.dev 上發布 [material_ui](https://pub.dev/packages/material_ui) 和 [cupertino_ui](https://pub.dev/packages/cupertino_ui) 套件。一旦這些套件上線，原生設計保真度就不再受核心框架發布週期的限制，可以按照自己的時間表進行迭代，貢獻也能更快地落地和發布。這項基礎工作已經解鎖我們開始處理以前無法快速推進的平台保真度工作，例如採用 Material 3 Expressive 和 Apple 的 Liquid Glass 設計語言。這就是解耦的實際好處：Material 和 Cupertino 可以按照自己的時間表發展，而不必等待 Flutter 的核心，這為我們與社群直接合作這些設計系統打開了大門。

對 Flutter 的信任，隨著我們的社群模式不斷演進

我們在這次調查中增加了一個新的部分，以建立以前沒有的東西：開發者對 Flutter 信任度的真實基準，以便我們能夠追蹤隨著社群模式不斷變化而發生的變化。Flutter 一直是 GitHub 上最活躍的儲存庫之一，我們開放運作的方式至關重要。例如，Canonical 現在領導 Flutter 桌面路線圖，我們也提出了一個正式的貢獻者階梯，旨在將維護者基礎擴展到 Google 之外。我們希望在這些轉變發生之前，而不是之後，真正了解目前的信任度。

98% 的人正確識別 Google 為 Flutter 的創作者，因此意識從來都不是問題。對於基準更重要的是，當我們要求您分別評估對 Flutter 的信任度和對 Google 的信任度時，Flutter 每次都領先 20 多個百分點：對 Flutter 的信任度為 83%（前兩名），而對 Google 的信任度為 62%，在不同公司規模之間保持一致。這是一個強烈的訊號，支持我們繼續投資將維護者群體擴展到 Google 之外。

當我們詢問是什麼建立了這種信任時，框架效能和穩定性以 26% 位居榜首，領先於社群規模和活動（20%）和文件品質（19%）。在評估一項全新功能時，更多人表示他們會信任它，因為它經過社群的「實戰考驗」（41%），而不是因為它是由 Google 工程師建立的（26%）。這對我們未來的方向來說是個好消息：我們建立的信譽是透過框架及其社群獨立贏得的。這正是我們希望在進一步開放維護者基礎時保護和成長的信任。

回應速度仍有不足之處

對於 Flutter 在技術問題上積極主動並回應開發者回饋的認同度為 71%，比我們詢問可靠性和安全性的其他所有陳述都低 10 多個百分點。我們的 2026 年計畫描述了對這個差距的結構性回應：擴展諮詢計畫、Google 開發者專家網路、客戶諮詢委員會和合作夥伴諮詢委員會作為正式回饋管道。正式諮詢管道有助於我們在 Flutter 擴展時建立正確的路線圖。同時，我們仍然致力於優先處理 GitHub 和 Discord，讓每個社群成員都能被聽到，同時擴大社群監聽，並確保各級貢獻者都能分享想法和回饋。

在貢獻者方面也存在相同問題的結構性版本，我們正在正面解決這個問題。多年來，獲得 Flutter 信任角色的唯一途徑（例如程式碼審查權限和合併權限）是透過非正式地加入 `flutter-hackers` 群組，由偶然注意到您工作的人逐案決定。Flutter 專案中超過 70% 目前開放的 PR 都來自 Google 以外的貢獻者。我們很高興為這些貢獻者提供一條更清晰、更開放的途徑，讓他們成為 Flutter 專案的正式成員。

在本次調查結束後不久，我們公開發布了一項提案以徵求社群回饋：一個正式的四級 [貢獻者階梯](https://docs.google.com/document/d/1ITkAaE96R1kWgttDFVQYYKvdyHlcOz_Rs1QyiS8JMEY/edit?tab=t.0)（貢獻者 → 審閱者 → 提交者 → 維護者），在新的 `flutter/contributors` 儲存庫中進行公開、數據驅動的晉升，完全取代舊的非正式贊助模式。它還引入了正式的專案領導途徑，不僅僅是程式碼貢獻。這是擴大誰可以領導這個專案的重大一步！因為它在調查結束後才公開，我們不會期望它在這些數字中顯示出來，但它是對本節所述透明度差距的直接回應，我們將觀察它下次是否能改變現狀。

謝謝您 💙

超過 3,500 名的您在六月的兩週內（透過 IDE 外掛、X 和我們的網站）花時間誠實回答，這讓這項工作值得每年進行兩次。這篇文章中的每一條回饋都來自一個本可以關閉調查分頁的人。我們知道這一點，我們不會將其視為理所當然。

下一步是什麼？

這項調查告訴我們 Flutter 處於一個真正強大的位置。滿意度和信任度都上升了，我們正在讓新的 Flutter 開發者更容易加入我們的社群，而且許多您已採用的 AI 輔助工作流程與我們正在建立的內容直接對應。

它還確認了我們需要繼續推進的關鍵領域：發布 `material_ui` 和 `cupertino_ui` 套件，持續改進對 Web 和桌面的支援，以及更多。 讓我們一起繼續建立 Flutter 的未來，與您一起，而不僅僅是為您。在社交媒體上告訴我們哪些引起了共鳴，下次調查再見！

更多來自 Flutter

Flutter 第二季調查

溫馨提醒！請參加 Flutter 第二季調查！調查將於 6 月 19 日星期五結束。

Shams Zakhour

2026 年 6 月 15 日 · 1 分鐘閱讀

A2UI 和 Flutter GenUI 套件的新更新

探索 A2UI 和 Flutter GenUI 套件的更新，以建構動態、由代理生成的介面。

Andrew Brogdon

2026 年 5 月 14 日 · 7 分鐘閱讀

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

1
2
3
4
5
6
7
8
9
10
11

#### 官方 Dart 部落格已遷移至 [**dart.dev/blog**](https://dart.dev/blog)！

<figure>
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*cZZyASylK6dJfEEn8t9Dmw.png" />
</figure>

歡迎來到我們的新家！官方 Dart 部落格已從 Medium 遷移到 [**dart.dev/blog**](https://dart.dev/blog)。未來，您將在此處找到所有語言發佈公告、深入技術文章以及來自 Dart 團隊的工程更新。

更新您的書籤並加入我們吧！

<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=2b9ea40d2a72" width="1" height="1" alt=""><hr><p><a href="https://medium.com/dartlang/weve-moved-the-official-dart-blog-has-a-new-home-2b9ea40d2a72">我們搬家了！官方 Dart 部落格有了新家</a> 最初發佈於 <a href="https://medium.com/dartlang">Dart</a> 的 Medium 上，人們在那裡透過突出顯示和回應這個故事來繼續對話。</p>

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

為 ADK 建立 Flutter 前端

當代理程式使用我從未用過的 SDK 和語言構建時，我該如何為它建立 Flutter 前端？

這是我在處理使用 Agent Development Kit (ADK) 編寫的基於 Python 的代理程式時面臨的挑戰。由於 Python 經驗有限，且以前從未接觸過 ADK 框架，因此構建一個與後端伺服器整合的客戶端帶來了巨大的學習曲線。此外，即使我能讓程式碼代理程式產生一些可行的東西，如果我不理解程式碼，完成專案也是一種失敗的形式。

然而，在幾次失敗的嘗試之後，我找到了答案。我與我的 AI 編碼夥伴 Antigravity 採用了結構化、迭代的工作流程，建立了一個可重複使用的開發人員技能，將我在每次循環中學到的知識編碼化。我從零開始，產生了關於程式碼的筆記，建立了多個連接到 deep_search 代理程式（來自官方 ADK 範例儲存庫的多代理研究協調器）的應用程式，並逐步建立了技能和我的理解。有時，我同時使用了多個代理程式，「作者」代理程式與我一起建立技能，「編碼員」代理程式使用該指南來建立前端。

我最終得到的是一個名為 flutter_frontend_for_adk 的代理程式技能。它包含五個參考文件，引導 Antigravity 經歷一系列階段，每個階段都以可交付成果結束。第一階段產生了以下筆記文件，以便我可以結構化「編碼員」代理程式在分析代理程式並準備產生應用程式時對任務的思考：

• AGENT_INTERFACE_NOTES.md — 在分析代理程式原始碼時所做的筆記。它的目的是什麼，它是如何構建的？這個代理程式公開了哪些介面和 API，它們是如何運作的？
• FRONTEND_USAGE_NOTES.md — 第一個規範。前端應該做什麼，使用者應該如何與它互動？
• FRONTEND_ARCHITECTURE_NOTES.md — 架構計畫。應該建立哪些服務、類別、狀態和模型？
• FRONTEND_DESIGN_NOTES.md — 前端的設計文件。它會是什麼樣子？顏色、字體和其他細節是什麼？

之後，Antigravity 可以產生應用程式的程式碼，運行並測試它。雖然技能（和我）仍在開發中，但我現在已經很好地掌握了 ADK，並且有了一種有用的方法來為現有代理程式建立前端。

這就是它的發生方式。

從他人的工作開始

我不是這裡唯一一個編寫技能的人，所以第一步是從 Google Cloud 和 Flutter 團隊安裝一些技能：

1
2

npx skills add google/agents-cli --skill google-agents-cli-adk-code
npx skills add flutter/skills

這讓我對 ADK 及其 CLI 工具和 Flutter 有了一些基本的了解。由於 Antigravity 的 Dart 擴充功能，我也安裝了 Dart MCP 伺服器。

建立循環

我沒有一開始就要求代理程式產生一個應用程式，而是與它建立了一種「學習循環」。首先，我要求編碼代理程式執行我技能中的工作流程，然後我與作者代理程式合作手動評估編碼程式的輸出，找出技能說明中的漏洞，並更新指南以改進未來的運行。每次迭代後，我會刪除產生的筆記和應用程式，重新開始，然後發現我需要學習的下一件事。

該循環由與 Antigravity 對話驅動的五個不同步驟組成：

1) 執行目前的技能：在一次新的對話中，編碼代理程式執行由目前版本的技能檔案定義的工作流程。

我的提示：這個程式碼庫包含一個使用 ADK 構建的代理程式，但沒有前端或客戶端。我希望您閱讀 flutter-frontend-for-adk/SKILL.md 中的說明並遵循工作流程。不要檢查 git 歷史記錄，不要參考我們進行過的任何其他對話的上下文，也不要更改 git 分支。

2) 評估輸出和規範：在第二次對話中，作者代理程式和我檢查產生的可交付成果，例如架構筆記、設計規範和產生的程式碼結構。我更擅長發現結構問題，而 Antigravity 則幫助我捕捉所有小細節。

我的提示：在我審查筆記和程式碼時，請查看生成的工件並告訴我您認為它們與說明和我們的目標的匹配程度。

3) 識別差距和故障模式：我們識別出程式碼代理程式缺乏特定指導、做出不正確假設或遇到整合問題的領域。

我的提示：我在上次運行中發現了兩個問題：首先，根 gitignore 由於全域的「lib/」忽略規則而忽略了新的 frontend/lib/ 資料夾。其次，程式碼代理程式連續執行所有六個階段而不停止。我們需要一種方法來在每個階段之後暫停並驗證可交付成果。

4) 更新核心技能和參考資料：我們更新 SKILL.md 中的說明或 references/ 目錄中的子指南以解決這些差距。

我的提示：讓我們更新 SKILL.md 中的 Phase 6，明確處理 gitignore 問題，方法是如果「lib/」全域忽略，則添加「!frontend/lib」。此外，在 Phase 1 到 4 的末尾添加一個強制性的「審查」步驟，指示代理程式暫停並等待我的批准，然後再繼續。

5) 清除本地文件並重新執行：我刪除臨時規範文件，重置 git 工作樹，然後回到循環的頂部。

儘管與一對代理程式合作確實加快了速度，但它並沒有使過程瞬間完成。我一次只能吸收這麼多資訊！但在每次迭代中，我都會閱讀筆記和原始碼檔案，查看與 Antigravity 的對話，並且（一旦我產生了真實的程式碼）運行應用程式以查看其效能。

一開始，我主要在閱讀和學習。但到最後，我對正在發生的事情了解得足夠多，足以專注於一直失敗的事情，開始自己研究，並調整程式碼以修復問題。修改完筆記和程式碼庫後，我會詢問 Antigravity 如何更新技能，以使未來的程式碼產生看起來更像我組裝的內容。因此，該技能不僅僅是程式碼代理程式的指令，更是我學習的記錄。

循環迴圈

總共經過 13 次迭代，我才得到一些我不羞於分享的東西。以下是前 6 次，主要用於發現和記錄筆記：

1. 啟動和工作區映射 — 我意識到一個單一的、整體式的 SKILL.md 文件對於代理程式來說太難導航了。我將技能重構為模組化，建立了一個專用的 references/ 資料夾並編寫了第一個專業指南：references/agent_discovery.md。這讓 Antigravity 通過分析代理程式的原始碼並建立 AGENT_INTERFACE_NOTES.md 來記錄它學到的東西。
2. 定義行為和使用者體驗 — 接下來是前端的使用規範：它會做什麼？使用者將如何與它互動？我在技能中添加了一個新階段，指示它閱讀 references/frontend_usage.md 並採訪我以了解平台偏好和功能要求。這讓我在觸摸程式碼之前就得到了 FRONTEND_USAGE_NOTES.md，它定義了應用程式的目的和功能集。
3. 設定結構藍圖 — 架構。我們將 references/frontend_architecture.md 添加到技能中，該技能側重於前端所需的架構細節，我讓代理程式產生 FRONTEND_ARCHITECTURE_NOTES.md。
4. 設計視覺美學 — 我們建立 references/frontend_design.md 來指導代理程式如何定義視覺美學，並將 scaffolding 指令添加到 SKILL.md 中。此指南指示代理程式採訪我以了解主題、斷點和動畫偏好，Antigravity 開始產生 FRONTEND_DESIGN_NOTES.md。
5. 產生並運行應用程式 — 至此，我能夠告訴 Antigravity 開始根據我們收集的所有規範產生實際的 Flutter 程式碼。應用程式以驚人的方式失敗了，我意識到需要某種通用的「最佳實踐」文件來解決可能重新出現的問題。我們將 references/frontend_best_practices.md 添加到技能檔案中以指導實際的編碼，並開始一次修復一個問題。

從那時起，我繼續與 Antigravity 進行迭代，一次解決一個問題，更新程式碼，更新技能以匹配，然後清除產生的前端以再次嘗試。在此過程中，循環變得更緊密，更改更小。我做了七次額外迭代：

1. 應用程式無法進行網路呼叫！ — 修正了 macOS 和 iOS 的權限和資訊。
2. 所有這些 Markdown 都沒有被格式化！ — 利用 flutter_markdown 正確顯示來自代理程式的文字，其中通常包含 Markdown。
3. 為什麼程式碼看起來不對勁？ — 添加了 lint、格式化規則和其他產生後檢查。
4. 密封類別！ — 不同的訊息類型應共用一個基類型，以便應用程式可以使用窮舉 switch 語句。
5. 為什麼聊天不會捲動？ — 添加了 ScrollController，以便在新訊息到達時自動推進訊息列表。
6. 為什麼應用程式在網路上運行時崩潰了？ — 移除了 dart:io，轉而依賴 package:http 進行網路連線。
7. 清單中的部分事件！ — ADK 發送事件流，有時是分段的。前端需要將它們連貫地組裝和呈現，而不是向使用者顯示所有部分（帶有損壞的 Markdown 格式）的列表。
8. 為什麼工具視窗是空白的？ — 在產生時，應用程式沒有正確處理工具命名約定，並且事件處理沒有正確識別何時調用工具。

一個「出錯」的例子

為了讓您了解每次迭代中完成的工作，讓我們來看看其中一個變更：前端如何處理部分事件。

ADK 伺服器會串流事件，這些事件表示一小段內容或部分工具執行階段。但是，如果客戶端應用程式將每個傳入的網路事件都渲染為聊天清單中的獨立訊息氣泡，那麼介面就會變得碎片化。代理程式的一個回應將顯示為數十個孤立的、損壞的文字塊。

舊方法（一個簡單的清單）：

1
2
3
4
5
6
7
8

// 在清單視圖中渲染每個原始事件區塊
ListView.builder(
  itemCount: rawEvents.length,
  itemBuilder: (context, index) {
    // 每個部分文字區塊都在單獨的氣泡中渲染
    return ChatBubble(text: rawEvents[index].contentText);
  },
)

此程式碼導致的 UI 如下所示：

一旦你知道該怎麼做，這個問題的解決方法其實並不難。當然，我不知道，所以我開始向 Antigravity 提出問題，例如「ADK 如何使用 SSE 串流事件？」和「事件的傳輸資料結構是什麼樣的，我怎麼知道它是否是部分事件？」如果「氛圍學習」是真實存在的，我正在這麼做。

事實證明，您只需要檢查一個旗標，所以我調整了前端 AgentProvider 類別中的程式碼，要求 Antigravity 審查它以防我忘記了任何顯而易見的東西，然後運行應用程式進行驗證。我再次向 Antigravity 發出請求，以更新最佳實踐，以便每個新的前端都會使用這種方法。

新方法 (AgentProvider 中的聚合)：

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
30
31
32
33
34
35

await for (final event in stream) {
  if (event.partial && event.contentText != null) {
    // 累積串流文字
    _activeStreamingAuthor = event.author;
    _activeStreamingResponse =
        (_activeStreamingResponse ?? '') + event.contentText!;
  } else {
    // 完成的區塊：清除累加器並加入永久事件清單
    _activeStreamingResponse = null;
   
    final updatedEvents = List<Event>.from(_activeSession!.events)
        ..add(event);

    // 合併狀態差量
    Map<String, dynamic> mergedState = _extractSessionStateMap(
      _activeSession!,
    );
    if (event.actions.stateDelta.isNotEmpty) {
      mergedState.addAll(event.actions.stateDelta);
    }

    // 使用更新的事件和狀態建立 Session 的新副本
    _activeSession = Session.fromJson({
      'id': _activeSession!.id,
      'app_name': _activeSession!.appName,
      'user_id': _activeSession!.userId,
      'events': updatedEvents.map((ev) => _serializeEvent(ev)).toList(),
      'state': mergedState,
    });

    _processCompletedEvent(event);
  }
  
  notifyListeners();
}

親自試試看

我非常喜歡「做中學」，而嘗試完全超出我舒適區的東西（例如一種新語言和一個新 SDK）相當令人生畏。然而，擁有這個循環為我提供了一個可以參考的結構，這非常有幫助，現在我擁有了一個 漂亮的新代理程式技能。

如果您還沒有，請自己下載 Antigravity 並試用一下 — 我只花了幾個小時，而且我確實學到了一些新技巧。

要開始：

1. 下載 Antigravity 以將代理程式編碼助手整合到您的開發環境中。
2. 訪問 AGY 入門 文件，了解如何定義自己的自訂開發人員技能和參考指南。
3. 為您想要探索的框架草擬一個簡單的技能，並不斷循環直到您得到喜歡的東西！

使用 Antigravity 更快學習 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

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

與 Rody Davis 共同撰寫

程式碼代理程式及其使用方式在短短幾個月內就已經發生了巨大的演變。最初，重點主要放在觀察上——逐行審查每個輸出。但隨著模型能力迅速提升，業界轉向了真正的代理工程。如今，開發人員、PM 和設計師身兼多職，專注於崇高的概念目標，讓代理程式處理各個組件。

為了探索這個新領域，我們的團隊希望建立一個能展示這種確切工作流程的體驗。我們想建立一個遊戲，產生其資產，編寫行銷頁面，並部署整個項目，所有這些都使用 Google 首屈一指的 AI 原生平台：Antigravity。

Antigravity 將 Google 的最佳功能匯集於一處，採用規劃、執行和驗證的緊密回饋迴圈。它會建立 Artifact、撰寫程式碼、執行測試，甚至點擊 UI 中的按鈕，以確保它實際正確完成了任務。

我們代理程式冒險的成果是 DashLander——一款設定在程序生成的小行星上的月球著陸器風格遊戲。以下是我們如何建立它的故事。

在 AI 時代為何選擇 Flutter？

很多人可能會想：如果代理程式可以撰寫原生程式碼，為什麼不讓它們完全分開撰寫 Android、iOS 和 Web 應用程式呢？

這是一個合理的問題；這也是最初激發 Flutter 作為「Vibe once, run anywhere」UI 工具包概念的原因。

擁有單一真實來源對 AI 和人類都同樣重要。透過讓代理程式編寫單一的跨平台應用程式，團隊可以消除不同語言或平台特定範式之間不可避免地出現的細微錯誤。此外，Dart 強型別為 LLM 提供了出色的回饋。具有較鬆散型別系統的語言要求 LLM 進行更多的分析，才能知道給定程式碼在所有情況下是否正確。另一方面，Flutter 和 Dart 使用其分析伺服器向您的代理程式發送有關函數簽名或類別形狀不匹配的強烈訊號。搭配有狀態熱重載，Flutter 對代理程式的加速作用與對人類開發人員的加速作用一樣。

而且，儘管代理程式開發大幅降低了生產新軟體的成本，但它仍遠非免費。對於代理程式開發來說，時間就是金錢，這既是比喻意義上的，也是字面意義上的，因為查詢時間越長，意味著更多的令牌；這意味著更多的 AI 開支。有了 Flutter，成功完成編碼任務的代理程式無需重新開始支援另一個平台，從而為您節省了資金。

快速失敗，才能建造更好

我們知道我們想建造一個遊戲，您在其中駕駛月球著陸器，配備動態元素、自訂著色器和粒子效果。(我們不忍心將 Dash 本身置於冰冷的真空空間，所以，您將駕駛一艘船。) 當然，使用 AI 大大加速了這些概念的整合，但這並不妨礙稍後放慢速度並認真編寫高品質程式碼。如果有的話，透過 AI 進行的快速探索階段有助於您更快地達到該階段，因為您的許多失敗實驗可以在幾個提示的生命週期內來去，而不是花費數小時或數天的編程時間，只是為了了解某個特定的想法是否真的很有趣。如果這輩子有一件事無關緊要，那就是從未見天日的實驗性功能的程式碼品質。

最重要的是，我們也知道我們沒有在建造什麼：一款高性能、即時的多人遊戲。即時多人遊戲功能會引入延遲限制並呈指數級擴大基礎設施複雜性。相反，我們意識到可以透過在挑戰模式中重播過去高分的回影來提供 90% 的引人入勝的競爭體驗。這使我們可以依賴靜態儲存和簡單的後端，並巧妙地免費重複使用完美編寫的「AI 對手邏輯」，只需重播最佳使用者已經做過的事情即可。這就是所有程式碼中最好的：您既不編寫也不維護的程式碼。

生成一個資產的宇宙

為了讓小行星著陸器遊戲變得有趣，我們需要出色的資產，我們在很大程度上依賴代理生態系統來獲取它們：

• **音訊：** 我們使用 Google 的 Lyria 生成背景音樂。（不過，Rody 戴上他老音訊工程師的帽子，確實用麥克風、水管和噴霧罐在他家後院錄製了自訂的推進器噪音。多麼有趣的下午！）
• **視覺效果：** 我們在 Stitch 和 Google Canvas 中生成了 UI 設計。Gemini 直接在程式碼中編寫了我們的粒子效果，我們使用 Nano Banana 生成了應用程式圖示。
• **物理：** 因為這個遊戲發生在真空環境中，我們想要精確的反應控制系統 (RCS)。我們釋放了 Gemini Deep Research 來尋找我們需要的精確零大氣物理公式，它將這些公式編譯成 Google Doc。然後我們將該研究納入我們的語境中，Gemini 將方程式直接翻譯成 Dart。這些真的是正確的物理方程式嗎？可笑的是，我們不知道，因為我們不是物理學家！但是當您玩遊戲時，控制感肯定感覺正確。

**疊代原型**

我們從 AI Studio 的沙盒開始建立，以在提交架構之前生成快速、一次性的程式碼。這些豐富的原型可以作為模型以後的上下文壓縮，及早鎖定微觀決策。我們的一些原型具有更有趣的遊戲玩法，有些看起來更具吸引力，還有一些最清晰地捕捉了我們的零重力物理。對於我們的最終遊戲，我們將每個原型中最好的想法融合在一起。

一旦我們將專案載入 Antigravity，我們就為我們的代理程式配備了 Firebase、Flutter、Flame 遊戲引擎和 Gemini API 的 MCP 伺服器。我們啟動了一個新的提示，Antigravity 將任務分配給後端、UI 和遊戲邏輯的專門子代理程式。在五分鐘內，我們就有了一個用 Flutter 和 Flame 編寫的遊戲，這個遊戲通常需要幾天才能編寫。但實際上，它遠未完成。只有三個硬編碼的關卡，攝影機沒有跟隨著陸器，而且數學意味著我們的飛船大約有帝國大廈那麼大。

大約又用了 100 個提示才讓遊戲達到最終狀態。其中很大一部分提示只是關於程式碼組織和增加測試。每個人對閱讀 AI 生成的程式碼都有自己的看法，但 Rody 和我非常重視我所稱的「認知所有權」，並且仍然想了解我們應用程式的深層內部運作方式。我們閱讀了 Gemini 編寫的許多內容，並推動 LLM 進行重構以提高清晰度和可重用性。

我還必須面對一個嚴酷的現實：我不太擅長三角函數，而 DashLander 中確實有很多三角函數。當代理程式告訴我他們完美地實現了一個新的系統，例如著陸計算和得分時，我經常玩遊戲並立即發現差異。不幸的是，無論我在我的程式碼庫中閱讀 Gemini 密集的三角函數多少次，我都無法找出斷開點隱藏在哪裡。為了擺脫這個惡性循環，我要求 Gemini 在鍵盤快捷鍵後面建立一個絕密調試模式。它呈現了疊加層，顯示了確切的地形資料、表面的相對傾斜度和碰撞碰撞框，讓我能夠向自己證明代理程式的計算在哪裡是錯誤的。掌握了確鑿的證據，我能夠與 Gemini 合作解決了密集數學文件中的問題。

**時空旅行的棘手問題**

當我們加入挑戰模式時，Antigravity 在連接資料模型並將它們連接到 Cloud Firestore 方面做得非常出色。但在測試過程中，我發現了一個隱蔽的錯誤。我會與之前高分的鬼魂比賽，視覺上一切看起來都很棒，因為鬼魂飛船順利地漂移。但隨著重播的進行，事實證明鬼魂飛船與過去的自己不知不覺地脫節了。在比賽結束時，儘管原始玩家完美著陸，但鬼魂飛船有時會劇烈撞上小行星。

為了解決這個問題，我必須像 2023 年一樣，開動我的大腦。可怕，我知道。

我意識到核心問題是現代電腦架構的一個基本面向。您看，在現代多處理器 CPU 上，您可以告訴程式在未來精確的毫秒運行一段程式碼，但由於行程排程的性質，CPU 永遠無法保證完美精確度。而且，對我來說不幸的是，在重播期間啟動推進器的一毫秒延遲會從根本上改變飛船的模擬飛行路徑。我意識到，我不能僅僅記錄推進器時間戳，而是必須在每個推進器事件的精確時刻儲存著陸器物理狀態的完整表示，以校正重播期間的不準確性。Gemini 隨後整合了邏輯，以不斷將重播的即時模擬與這些物理檢查點進行比較，自動校正任何微小偏差。結果是完美無瑕、無崩潰的重播。

**從遊戲到發布**

您可能已經感受到在日常工作中身兼多職的壓力，無論您的團隊規模大小。例如，您可能擅長編寫遊戲，但不想推廣它們。或者，您是一位傑出的使用者體驗工程師，但更喜歡不處理圖形設計。好消息是，您不必獨自完成所有事情。

我們使用 Stitch 從單一提示生成了我們的行銷登陸頁面，並將我們正在運行的遊戲截圖作為上下文傳入。（誠然，如果生成優化的登陸頁面是我們的實際目標，我們會對此進行更多疊代。）使用一鍵匯出到 Antigravity，我們隨後下載了 HTML 並開始工作。因為我們是用 Dart 構建的，所以我們希望保持堆疊統一。我們使用 [Jaspr](https://pub.dev/packages/jaspr)（一個將 HTML 直接映射到 Dart 組件的 Web 框架）來無縫整合生成的 HTML。Gemini 完美處理了這種轉換，使我們能夠在遊戲和行銷網站之間共用程式碼，同時保留行業標準的 SEO 索引。

最後，我們使用 Antigravity CLI 來建構我們的 Flutter 網頁應用程式，將建構目錄複製到 Jaspr，執行建構腳本，然後直接部署到 Firebase Hosting——所有這些都在一個不間斷的終端工作流程中完成。

雖然 DashLander 目前以網路優先，以便輕鬆驗證機制，但由於它使用 Flutter 建構，我們只需一個指令即可部署到 iOS、Android、macOS、Windows、Linux，甚至豐田 RAV4 的資訊娛樂面板。截至撰寫本文時，該遊戲目前可在 [dashlander.com](http://dashlander.com) 上玩；但如果您在足夠遙遠的未來發現這篇文章，且該連結已失效，歡迎您直接從 [GitHub](https://github.com/craiglabenz/dashlander) 下載程式碼。

**實現您的願景**

若要開始建構您夢想中的應用程式或遊戲，請前往 [antigravity.google](https://antigravity.google) 獲取 Google 的 Agent Manager 和 IDE；並前往 [flutter.dev](https://flutter.dev) 開始使用 Flutter SDK。

祝您好運，我們迫不及待地想看看您會建立什麼！

使用 Antigravity 和 Flutter 實現一次設計，隨處運行 最初發佈於 Flutter 的 Medium 平台，讀者可在該平台透過高亮和回應此故事來繼續參與討論。

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

如果你開始贈送咖啡，人們就會出現。Flutter 團隊曾嘗試過一段時間，想辦法將這個原則應用到一個從 Flutter 應用程式開始，以一杯熱騰騰美味飲料結束的演示中。問題是如何讓它更有趣、更個人化，而不僅僅是點餐和送餐。咖啡很酷，但它不像「你絕對會記得 Google I/O 的一件事」那麼酷。

那麼，什麼改變了呢？兩種新技術出現了。一個是 Nano Banana，它能夠快速生成客製化圖片。第二個是 GenUI，它能夠在執行時動態生成使用者介面，並為參與者提供個人化問題，詢問他們希望如何修改這些圖片。將這兩者與 Flutter 結合起來，你就可以讓大家有機會點一杯咖啡，上面印著他們快樂地方的圖片，使用噴墨印表機列印出來。那才真是令人難忘。

我們所要做的就是執行。事實證明是兩次——這個演示在 Cloud Next 上被稱為「GenLatte」，在 Google I/O 上被稱為「Antigravity Coffee Co.」。為了簡單起見，並為為您總結這篇文章的代理人節省一些標記，下面將使用「GenLatte」這個名稱。

我們開了一家咖啡店

實現 GenLatte 這樣雄心勃勃的願景需要很多人。真的，是很多人。有團隊來規劃實體空間並決定「顧客」[1] 將如何流動。有品牌和概念團隊來創造美學。當然，還有施工團隊去五金店購買木材。最終，還有軟體工程師將程式碼組合在一起以構建各種應用程式，這就是我碰巧參與的地方。這篇部落格文章只會概述軟體部分，但這並不是要淡化 GenLatte 最終開門所需的許多其他層面所付出的令人難以置信的工作。

[1] 如果不收費，他們還是顧客嗎？

GenLatte 的運作方式

GenLatte 的核心是一個 Flutter 應用程式，帶有 Firebase 後端。

再深入一步，它是一個 monorepo，包含獨立的 Flutter、Firebase 和共用程式碼專案。使用 monorepo 讓我們能夠重複使用依賴項，共用業務邏輯，並執行原子部署。Flutter 應用程式也運行在 iOS 和 Android 上，但客戶只與網頁版本互動。我們使用 Cloud Build 和 Firebase Hosting 來保持我們的部署故事，而不是「某人在他們的筆記型電腦上運行 $firebase deploy」。在伺服器上，我們混合使用了觸發函數和 HTTP 可呼叫函數，賦予應用程式在明確的資料流和反應式資料管理之間靈活性。

在 Flutter 應用程式本身中，我們構建了 5 個獨立的使用者介面：瞌睡的會議參與者點咖啡的 kiosk 螢幕、顯示新訂單的咖啡師螢幕、驗證每個提交內容安全性的協調者螢幕、一個大型隊列螢幕，讓客戶大致了解何時會收到他們的飲料，以及一個純粹異想天開的「近期訂單」螢幕，顯示最後 13 個訂單作為浮動氣泡，讓每個人都有最後一次機會欣賞他們的數位創作。

演示級別的安全性

Google 在任何涉及使用者生成內容的演示中，最主要的一個顧慮是防止志願者「慷慨捐贈」他們的紅隊專業知識，發布不適當的內容供公眾消費。實際上，這體現在幾個不同的方面：

• 防止授權使用者建立 NSFW 內容： 為了防止這種情況，GenLatte 實施了三層方法。首先，原始的「快樂地點」字串被發送到 Gemini Flash 進行快速審核，並附帶大約三十個範例，概述我們希望阻止的令人不快的內容。然後，一旦「快樂地點」獲得批准，我們就開始生成圖片，並依靠 Nano Banana 自己的內部訓練來只生成 SFW 內容。在流程結束時，我們的人工審核員會手動批准每張圖片。有了這一切，我們非常有信心 GenLatte 不會讓 Google 難堪。
• 防止管理員帳戶遭到冒用： 授權使用者可能破壞您應用程式的另一種方式是訪問您不打算共享的授予提升權限的螢幕。鑑於 GenLatte 的後台審核員和咖啡師螢幕，它顯然存在這種風險。我們選擇部署到網頁，使用者可以使用瀏覽器網址欄任意導航，這進一步增加了壓力。為了解決這個問題，我們的 GoRouter 實作具有集中式的宣告式路由檢查，以確保每次頁面訪問對於給定的帳戶都是合法的，這由 Firebase 自定義聲明決定。
• 防止未經授權寫入 Firestore： 授權使用者使用應用程式是一回事，但有人閱讀 firebase_options.dart 的內容，啟動一個新專案，並查看他們能造成什麼破壞，則是另一回事。為了解決這個問題，我們將所有讀取和寫入都綁定到具有嚴格安全規則的嚴格帳戶憑證，您可以將其作為您自己專案的靈感。

傳遞有趣的圖片

一旦我們確信我們的應用程式在演示現場不會被駭客入侵，我們就開始確保 Gemini 可以提供一致的圖片，這些圖片在咖啡上看起來很棒。這個專案部分可能涉及到在辦公室裡過度咖啡因化的下午，所以我們飛快地完成了它也就不足為奇了。

核心是，我們的系統涉及將使用者的「快樂地點」（一個字元上限為 50 個，但通常只有一兩個字詞的提示）提升為四個獨特且高度特定的圖像請求。例如，對於輸入「和家人在家」作為快樂地點的使用者，GenLatte 可能會向 Nano Banana 請求一張「樹林裡古樸的家，壁爐裡有火，餐桌上準備好晚餐。家裡滿是家人和朋友，大家都在慶祝和享受彼此的陪伴。燈光和氛圍是…」（依此類推）的圖像。Gemini 負責這個提升過程，這意味著四個提示都不同；提供了使用者在應用程式中看到的各種圖像。

我們也針對令人愉悅的構圖優化了 Nano Banana；特別是「主體呈現領先的 S 形曲線」，它在道路、河流、山丘、海岸線或其他抽象之間輪流。這個提示技巧大大提高了 Nano Banana 吸引人、可用的圖像的百分比。

為了 GenLatte 的第二次亮相，也就是今年五月在山景城 I/O 的 Antigravity Coffee Co.，我們更新了我們的提示，使其可以在不同的建議構圖之間輪流。這讓每天看到數百張圖片的活動工作人員和只想要為他們的咖啡提供引人入勝的圖片的個別客人都能保持新鮮感。

即時修改圖片

GenLatte 的真正魔力不僅來自於快速製作圖片並將其列印在咖啡上；而是來自於根據個人確切的口味進行精確調整。在「調整」按鈕後面有四個問題，由 Gemini 預先撰寫，用於說明圖片可能如何修改。

這些圖片源自於原始的、升級後的提示本身；因此回到我們之前舒適的家庭快樂之地，Gemini 可能會提供關於餐桌上食物種類、人數多寡，或者慶祝活動是否是為了任何特定人生事件的問題。使用者看到的「和家人在家」的其他快樂之地可能會走向不同的方向，因此調整這些選擇會浮現出適合這些圖片的不同問題。

一旦使用者回答完問題，我們就帶著相同的提示回到 Nano Banana，同時提交多次以獲得新的藝術作品。提示看起來像這樣：

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

在看到來自此原始提示的圖片後：

{{original_prompt}}

使用者要求這些更改：

{{questions[0].body}}: {{questions[0].answer}}
{{questions[1].body}}: {{questions[1].answer}}
{{questions[2].body}}: {{questions[2].answer}}
{{questions[3].body}}: {{questions[3].answer}}

請生成此新圖片。

從拉斯維加斯到山景城，經過數月打造 GenLatte 後，看到人們因修改後的圖片而臉上發光，對我們來說是多麼神奇！

A2UI 和 GenLatte

GenLatte 不僅僅是 Flutter 和 Firebase 演示，甚至不是生成式 AI 演示；它是一個 GenUI 演示。GenUI 可以以許多不同的形式出現，但對於 GenLatte 而言，它連接了向使用者顯示正確的使用者介面以回答 Gemini 問題之間的點。關鍵細節是並非所有問題都最適合相同的 UI。像「您的家人正在慶祝特定的人生事件嗎？」這樣一個開放式問題需要一個文字欄位；但「現在是一天的什麼時候？」可能只有幾個相關選項，因此最適合單選按鈕。

在應用程式中實作 GenUI 有多種方式。保守的一端是嚴格控制、按部就班的體驗，代理程式從粗粒度 widget 目錄中選擇以渲染可預測的 UI。更具冒險精神的應用程式可以給予代理程式更多自由，從更細粒度的目錄中組合 UI，以渲染幾乎任何可以想像的東西。對於 GenLatte，我們選擇了保守的一端：公開一個小的品牌化 widget 目錄，代理程式可以使用它來顯示問題。這讓 Gemini 能夠在當下選擇正確的 widget，同時確保整體構圖符合我們的設計準則。

如果您想了解 Gemini 如何在更大的自由度下發揮作用，請查看 Hatcha，這是一個派對規劃應用程式。它透過將更多的執行時職責委派給 Gemini，進一步深入 GenUI。

三千杯咖啡之後…

在 Google Cloud Next 上供應了 1,200 杯拿鐵，在 Google I/O 上又供應了 1,800 杯，可以肯定地說 GenLatte 取得了成功。在建立這個演示或在這兩個活動中工作期間，我很少像現在這樣咖啡因過量，我也從未見過人們在使用應用程式後立即露出如此愉悅的笑容。

Flutter 讓異想天開的使用者介面建置過程充滿樂趣；從它對動態佈局和自訂著色器的優雅支援，到它無縫地針對多個平台的能力。Firebase 讓後端變得輕而易舉：為我們處理部署和擴展的麻煩，並提供反應式、全棧資料綁定。Gemini 和 Nano Banana（當然）將我們使用者的快樂地點提示變成了奇幻的藝術，看到它實體化令人愉悅。當然，操作真正的英雄是我們的咖啡師，他們製作了出色的拿鐵——因為如果咖啡不好喝，整個活動都會失敗！

若要閱讀 GenLatte 的程式碼，請訪問其在 flutter/demos 儲存庫中的資料夾。但是請注意，該儲存庫中的程式碼未經維護，僅供參考。

我們對 2026 年的應用程式開發未來感到興奮。有了 Flutter、Firebase 和 Gemini 等工具，您可以實際提供給使用者的體驗範圍呈指數級增長。

若要開始使用 GenUI，請訪問 Flutter 的文件。如果您對如何在自己的工作中運用這些模式有任何想法，請告訴我們，在此之前——我們迫不及待想看到您的創作！

我們如何建立一間由 Flutter 驅動的 AI 咖啡店 最初發佈在 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。

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

再次提醒！請參加 Flutter 第二季調查！調查將於 6 月 19 日星期五當天結束。

這不會花費您太多時間，您的回饋將有助於推動我們的發展藍圖！

謝謝您！

Flutter 第二季調查 最初發佈於 Flutter 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。