Microsoft 的 AI 輔助 WinUI 流程：30 分鐘做 App，真正意思係乜

Microsoft 正砌緊一條以命令列為主、由 AI 協助的 Windows 原生開發路線：先用 .NET 10 建立 WinUI 專案，再交由熟悉 Windows 開發慣例的 agent 去寫功能、編譯、測試同反覆修正，最後封裝並發佈。

重點唔係「半個鐘就可以做好一個商業級 App」，而係將建立一個細小原生 Windows App 所需的安裝、範本、框架知識同重複步驟盡量壓低。751

呢條流程有邊幾樣嘢？

Microsoft 的快速入門列出所需組合：VS Code、.NET SDK 10 或以上、Windows App Development CLI（winapp）、WinUI 的 dotnet new 範本，以及 GitHub Copilot。Microsoft 表示教學約需 30 分鐘，而且 Copilot 免費層已足夠使用。51

各工具分工大致如下：

• .NET 範本：建立已封裝的 WinUI 專案。命令列起點可以係 dotnet new winui -n MyApp。5
• WinApp CLI：負責 Windows 特有的開發操作，例如建立專案、執行、封裝、簽署及與發佈相關的工作。新版亦有搜尋可運作 WinUI 介面範例，以及產生方便 agent 閱讀的 UI 錄製資料等功能。2
• GitHub Copilot 加 WinUI 外掛：提供 agent 式編程層。外掛有一個專用 winui-dev agent 及八項專門技能，涵蓋建立骨架、編譯、執行、測試、封裝與遷移。46
• Microsoft Learn MCP Server：讓支援 MCP 的 agent 即時搜尋 Microsoft Learn、讀取完整文件及尋找程式碼範例，減少只靠模型舊有訓練資料的情況。10

如果用 VS Code，WinApp 擴充功能可將 CLI 流程帶入編輯器，處理初始化、執行、除錯、封裝及簽署等工作。55

要分清：VS Code 唔等於 WinUI agent 外掛

整體流程可以用 VS Code，但 Microsoft 文件講得幾清楚：winui@awesome-copilot 外掛現時支援的是 GitHub Copilot CLI 同 Claude Code，未整合到 VS Code 的 Copilot Chat。46

即係話，VS Code 可以繼續做主要編輯器，配合 WinApp 擴充功能同 Learn MCP；但要用專門的 WinUI agent，就要透過其支援的客戶端去跑。5546

點解唔直接叫一般 AI 寫 XAML 同 C#？

一般 coding agent 當然可以生成 C# 同 XAML，不過佢有機會揀咗過時 API、忽略已封裝 Windows App 的慣例，或者喺 Windows 特定的編譯、部署、啟動問題上不斷兜圈。Microsoft 將 WinUI 技能定位為針對整個開發循環與常見失敗情況的操作手冊，幫 agent 用較穩陣的做法完成工作。21

Microsoft 又聲稱，專用 agent 加八項技能完成支援的端到端任務時，比一般 agent 少用 70% token。呢個係工具效率指標，唔係保證每個生成出嚟的 App 都會設計得更好、跑得更快。9

Learn MCP 解決的是另一類問題：文件會更新。Agent 可以在查詢時取得較新的官方指引與範例；但開發者仍然要審核程式碼的正確性、安全性、無障礙支援、資料處理方式及可維護性。10

「約 30 分鐘」實際包咗乜？

Microsoft 的快速入門所講的範圍很具體：由命令列建立 WinUI App，用 winui-dev 加入功能，然後封裝並發佈到 Microsoft Store。51

所以，30 分鐘這個數字比較適合用來衡量上手門檻：由零開始試一個小型新專案，到有一個可以封裝的成果，是否變得容易了。

但它不代表一個可正式投產的 App，可以在 30 分鐘內完成規劃、設計、開發、保安審查、測試、評核、上架與營運；更不代表大型 WPF 或 UWP 舊系統能在同樣時間完成遷移。

真正上線前，通常仍要處理：

• 需求定義與 UX 設計
• 登入、後端及資料整合
• 自動化與人手測試
• 無障礙檢查
• 遙測、私隱及安全審查
• 簽署、發佈及版本管理
• 上線後的監察與維護

遷移功能係「有指引的現代化」，唔係一鍵轉換

WinUI 工具亦包括舊 Windows App 的遷移技能。以 UWP 為例，Microsoft 提供明確替換，例如將 Windows.UI.Xaml.*、Windows.UI.Xaml.Controls.*、Windows.UI.Xaml.Media.* 改為對應的 Microsoft.UI.Xaml.*；調度與視窗 API 亦有相應映射。19

Microsoft 的現代化指引所產生的是一份結構化遷移計劃：包括專案與 manifest 要改的地方、命名空間對照表，以及需要人手覆核的項目。23

呢類協助很有用，但遷移遠唔止改 namespace。團隊仍然要驗證行為差異、執行緒處理、視窗管理、控制項、自訂繪製、封裝方式、相依套件，並跑回歸測試。

尤其是 WPF App，如果現有 UI、平台假設或第三方控制項未能直接對應 WinUI，遷移其實係一個架構工程，而唔係 find-and-replace。

Microsoft 點解要大力推呢套嘢？

Microsoft 將 WinUI 定位為現代 Windows App 的生產平台，並配合範本、命令列工具、開發控制項與 AI 輔助去推動採用。117

策略其實直接：令開發原生 Windows App 更容易起步，亦更少依賴很深的 Windows 平台經驗。較好的 project scaffolding、即時文件存取與任務專用 agent 技能，都可以減低新 App 或現代化項目選擇 WinUI 的阻力。

AI 整出嚟的 WinUI App，會唔會一定比 WebView2 App 慳 RAM？

現有證據未足以支持這個結論。

原生 WinUI App 如果介面本身不需要嵌入瀏覽器，的確可以避開部分瀏覽器 runtime 的成本；但 WinUI 不是效能保證。AI 寫的 App 一樣可以因為視覺樹太大、不必要重繪、保留過多資料、相依套件太重，或網絡與狀態管理差而變得笨重。

Windows 的 MSN Weather 經驗正正令大家關注這個問題。第三方測試曾報告，該 App 在使用期間記憶體用量約為 700 MB 至 1.2 GB，閒置後則較低。3145 不過，這些是第三方觀察，並非 Microsoft 主導的測量，也不是與功能相同的 WinUI 實作作一對一比較。

因此，較嚴謹的結論係：這條工具鏈令開發原生 WinUI App 更容易，在適合原生 UI 的情況下，或有助避開部分 web wrapper 的額外負擔；但它未證明 AI 生成的原生 App 會穩定地比相近的 WebView2 App 更低記憶體、CPU、耗電或磁碟用量。

實際應點樣睇？

可以將這套流程視為加速起步的工具，而不是自動交付產品的機器：

1. 用範本與 WinApp CLI 建立標準、已封裝的 WinUI 專案。
2. 用 WinUI 專用 agent 與 Learn MCP 加快開發，並讓 API 指引保持較新。
3. 用遷移技能產生計劃、處理例行替換，但每個行為改動都要驗證。
4. 在具代表性的電腦與實際工作負載下量度效能，唔好因為「原生」或「AI 生成」就假定一定高效。

對小型、由零開始的 App 而言，Microsoft 的 30 分鐘快速入門的確反映 Windows 原生開發變得更容易試。對認真的產品團隊來說，長遠價值不是瞬間完成軟件，而是一條由構思走到可測試、可封裝 Windows App 的較有結構路徑。517