微軟的 AI WinUI 流程，並不等於 30 分鐘做完一款正式產品

微軟正把原生 Windows App 開發整理成一條更適合命令列與 AI 代理協作的路徑：以 .NET 10 建立 WinUI 專案、交由具備 Windows 專門知識的代理協助開發與迭代，最後完成封裝與發布。它要解決的，是「做出一個小型原生 App」的環境設定與框架學習門檻，而不是讓專業軟體工程、效能調校或遷移驗證從此消失。751

「約 30 分鐘」究竟包含什麼？

微軟的快速入門明確列出範圍：從命令列建立 WinUI App，以 winui-dev AI 代理新增功能，接著封裝並發布至 Microsoft Store；官方估計完成時間約 30 分鐘，且 GitHub Copilot 免費方案即可使用。51

因此，這個數字可用來衡量上手與示範流程是否順暢，但不能理解為一款正式產品能在 30 分鐘內完成。需求釐清、UX 設計、登入與資料串接、自動化與人工測試、無障礙檢查、遙測、隱私審查、簽章與上架流程，以及後續維護，都仍是不可省略的工作。

對於既有的大型 WPF 或 UWP 系統，更不代表能在半小時內完成移轉。

這套流程由哪些工具構成？

快速入門所需的核心包括 VS Code、.NET SDK 10 或更新版本、Windows App Development CLI（winapp）、WinUI 的 dotnet new 範本，以及 GitHub Copilot。51

各工具的分工大致如下：

• .NET WinUI 範本：負責建立已封裝的 WinUI 專案。微軟文件示範可從 dotnet new winui -n MyApp 開始。5
• WinApp CLI：處理 Windows 特有的開發操作，例如建立專案、執行、封裝、簽署與發布相關流程；新工具也支援搜尋可運作的 WinUI 介面範例，以及產出供代理讀取的 UI 錄製資料。2
• GitHub Copilot 與 WinUI 外掛：提供代理式開發層。外掛包含專屬的 winui-dev 代理與 8 項專門技能，涵蓋建立骨架、建置、執行、測試、封裝與遷移等環節。46
• Microsoft Learn MCP Server：讓相容的 AI 代理可即時搜尋 Microsoft Learn、讀取完整文件與尋找程式碼範例，降低只依賴模型既有訓練資料而使用過時資訊的風險。10

若偏好在編輯器內操作，VS Code 的 WinApp 擴充功能可將初始化、執行、偵錯、封裝與簽署等 CLI 流程帶進編輯器。55

一個容易混淆的地方：VS Code 不等於 WinUI 專用代理

整個工作流程可以搭配 VS Code，但目前 winui@awesome-copilot 外掛支援的是 GitHub Copilot CLI 與 Claude Code，尚未整合 VS Code Copilot Chat。46

換句話說，VS Code 可以繼續作為撰寫程式、使用 WinApp 擴充功能與設定 Learn MCP 的環境；但專用的 WinUI 代理，需要透過其目前支援的用戶端執行。5546

這項差異對實際導入很重要：不要把「可在 VS Code 開發」誤解成「VS Code 裡的 Copilot Chat 已能直接執行所有 winui-dev 專屬工作流程」。

為何要用 WinUI 專用代理？

通用程式設計代理也能生成 C# 與 XAML，但可能採用過時 API、忽略已封裝 App 的慣例，或在 Windows 特有的建置與啟動問題上反覆卡住。微軟將 WinUI 技能定位為聚焦式操作手冊，用來引導代理走完開發迴圈，並辨識常見失敗模式。21

微軟也宣稱，專屬代理與 8 項技能在支援的端到端任務中，所需 token 可比通用代理少 70%。這是工具使用效率的主張，並不等於每一個生成的 App 都會有更佳架構、設計或效能。9

Learn MCP 處理的是另一個問題：文件與 API 指引會改變。它能讓代理在查詢當下取得現行官方文件與範例，但開發者仍必須檢查正確性、安全性、可及性、資料處理方式與可維護性。10

舊 App 遷移：是有引導的現代化，不是一鍵轉換

WinUI 工具也包含面向舊版 Windows App 的遷移技能。以 UWP 為例，微軟提供了清楚的對應替換，例如將 Windows.UI.Xaml.*、Windows.UI.Xaml.Controls.* 與 Windows.UI.Xaml.Media.* 換成 Microsoft.UI.Xaml.*；同時也列出派發執行與視窗 API 的變更方式。19

微軟的現代化指引將輸出定位為一份結構化遷移計畫，內容包含專案與資訊清單調整、命名空間對照，以及需要人工檢視的項目。23

這很有價值，但遷移不只是取代命名空間。團隊仍須驗證行為差異、執行緒處理、視窗管理、控制項、自訂繪製、封裝、相依套件與回歸測試。特別是 WPF App，若既有 UI、平台假設或第三方控制項無法直接對應 WinUI，遷移本質上會是架構調整專案。

微軟為何投入這套流程？

微軟正將 WinUI 定位為現代 Windows App 的正式生產平台，並以專案範本、命令列工具、開發控制項與 AI 協助來配套推進。117

策略並不難理解：讓原生 Windows 開發更容易開始，不必一開始就具備深厚的平台知識。更好的專案骨架、可即時存取的官方文件，以及任務導向的代理技能，都能降低新 App 或現代化專案選擇 WinUI 的阻力。

AI 生成的 WinUI App，會比 WebView2 App 更省記憶體嗎？

目前證據不足以得出這個結論。

當介面不需要嵌入網頁執行環境時，原生 WinUI App 的確可能避開部分瀏覽器執行階段負擔；但 WinUI 並不是效能保證。AI 生成的 App 仍可能因視覺樹過大、不必要的重繪、資料保留過多、昂貴的相依套件，或不佳的網路與狀態管理設計而效率不佳。

Windows 的 MSN 天氣 App 之所以引起討論，正是因為第三方測試曾觀察到它在使用期間的記憶體用量約落在 700 MB 至 1.2 GB，閒置後則較低。3145 不過，這些是非微軟控制的觀察結果，也不是與功能相當的 WinUI 實作所做的同條件比較。

較嚴謹的結論是：這套工具鏈讓開發者更容易建立原生 WinUI App；在適合使用原生 UI 的情境下，也可能避開部分網頁包裝層的額外成本。但它尚未證明 AI 生成的原生 App 能穩定地在記憶體、CPU、耗電或磁碟使用上勝過相同功能的 WebView2 App。

實務上該如何看待？

可以把新流程視為一個加速起點，而非自動化交付產品的按鈕：

1. 先用範本與 WinApp CLI 建立標準化、已封裝的 WinUI 專案。
2. 再用 WinUI 專用代理與 Learn MCP 加速實作，並取得較新的 API 指引。
3. 利用遷移技能產出計畫、處理例行替換，但逐一驗證每個行為變更。
4. 在具代表性的硬體與工作負載上量測效能，不要因為「原生」或「AI 生成」就先假定它一定高效。

對小型的新專案而言，微軟的 30 分鐘快速入門確實顯示原生 Windows 開發正變得更容易嘗試。對嚴肅的產品開發來說，長期價值不在於瞬間產生軟體，而是更有結構地把想法推進成可測試、可封裝、可發布的 Windows App。517