在普遍认为企业还不知道该如何真正利用 AI 的当下，微软却已经制定了一套计划：借助 AI，让更多原生 WinUI 应用进入 Microsoft Store。

　　微软近日发布了一份新的快速入门指南，帮助开发者利用 AI、VS Code 和自家的 winapp CLI，从一个空文件夹开始，一步步创建并发布 WinUI 3 应用。微软表示，整个流程大约只需要 30 分钟，而且无需安装 Visual Studio，使用的工具也都是免费的，包括 GitHub Copilot 的免费版本。

　　这份简单的 30 分钟指南，本质上是在吸引初学者为 Windows 11 开发应用，而且不必再经历传统开发中那些“繁重”的编码工作。

　　现在，任何人都可以借助 AI 创建一个新的 WinUI 应用，让 AI 智能体添加功能、测试结果，将应用打包成 MSIX，然后提交到 Microsoft Store，整个过程免费，而且所需人工操作非常少。

　　不过，更值得关注的是微软随指南提供的 AI 辅助迁移指南，尤其是针对现有 WPF 和 UWP 应用的迁移方案。这才是微软解决 Windows 长期以来原生应用问题的真正思路：让 WinUI 应用更容易开发，让老应用更容易迁移，同时让 AI 处理这两个过程中那些繁琐的工作。

　　不能将这里的 WinUI Agent 与微软此前推广的通用聊天机器人 Copilot 混为一谈。WinUI Agent 配备了针对 WinUI 设计、代码审查、UI 测试、应用打包以及框架迁移等任务的专门能力。

　　微软还建议将该 AI 智能体连接到 Microsoft Learn MCP 服务器，这样它就可以在执行查询时获取最新的 WinUI API 文档。考虑到 WinUI 3 的普及程度相对较低，可以合理推测，AI 模型在 WPF 和 UWP 方面积累的训练材料要多得多，而且时间跨度也更长。

　　WPF 迁移指南并没有把这件事包装成简单的查找和替换工作。例如，System.Windows.* 需要转换为 Microsoft.UI.Xaml.*。微软为 AI 智能体提供了一整套替换对照表，涵盖控件、线程处理、窗口管理、DPI 处理和数据绑定等内容，同时还提供了一段初始提示词，告诉 AI 智能体需要重点检查哪些问题。

　　微软针对 UWP 迁移到 WinUI 3 的指南则开门见山地指出，UWP 已经不再处于积极开发状态，而 WinUI 3 和 Windows App SDK 才是它的后继方案。有意思的是，微软特别提醒，由于 AI 模型已经基于多年来积累的大量 UWP 示例进行了训练，如果迁移技能没有明确告诉 AI 应该采用哪些替代方案，模型很可能会继续生成传统 UWP 的代码模式。

　　长期以来，Windows 上不断出现 Web 应用，而不是原生应用，一个重要原因就是跨平台 Web 框架的开发成本更低。开发者可以复用一套代码，在不同平台上运行，而不必专门针对 Windows 的开发框架编写代码，更不用担心这个框架未来可能像过去那样再次发生重大变化。

　　在 Build 2026 大会上，微软明确表示希望改变开发者的这种看法，并将 WinUI 称为“Windows 应用的生产平台”。同时，微软还从名称中去掉了“3”，试图向开发者社区传达一个信号：未来不会再把整个框架推倒重来。

　　微软还承诺降低内存占用，增加 DataGrid 和图表支持，改善 WPF 互操作能力，并进一步扩大开源参与度。事实上，如今 WinUI 已经完全开源。

　　WinUI 的作用也不仅仅是帮助开发者制作应用。微软一直在用 WinUI 3 替换 Windows 11 中一些历史悠久的界面组件，最近的例子包括自动播放、打印管理等功能，未来还会有更多组件进行替换。如果微软自己都不愿意使用这套技术，那么要求第三方开发者采用它显然也不太公平。

　　微软推广原生应用，并不是因为它认为 WebView2 或 Electron 是糟糕的技术。微软的官方文档将 WebView2 视为开发混合应用的一种合理方案，并表示应用的资源占用最终取决于开发者对 Web 内容的优化程度。

　　讽刺的是，Windows 11 的天气应用就是基于 WebView2 构建的。它在空闲状态下就会占用约 1.2GB 内存，大约是苹果原生 macOS 天气应用的 5 倍，而且后台还运行着 9 个 Chromium 子进程。

　　尽管微软一直采取企业优先的开发思路，但 Teams 在经历了多年的用户抱怨之后，才终于加入“效率模式”。

　　一些热门第三方应用也面临类似问题。例如 WhatsApp 的 Windows 应用一直存在加载速度较慢的问题，同时还会大量消耗内存。Discord 甚至承认自己的 Windows 应用属于“资源消耗大户”，并测试了一项功能：当内存占用超过 4GB 后自动重启应用。

　　也就是说，微软一方面要求第三方开发者开发更加轻量的原生应用，另一方面，它自己的一些应用以及 Windows 的部分界面却仍然建立在 WebView2 之上。

　　微软负责 Aspire 项目的杰出工程师 David Fowler 最近表示，“手写代码”已经彻底成为过去。没错，在微软目前展示的 WinUI 开发工具中，AI 代理可以生成代码、理解整个项目、运行测试，并修复出现的问题，而不是要求开发者亲手敲出每一行代码。

　　但 AI 降低代码生产成本，并不等于代码质量也会随之提高。微软自己也很清楚这一点，这也是为什么 WinUI Agent 会配备专门的代码审查和 UI 测试能力。

　　如果微软希望借助 AI 生成更多 Windows 软件，那么这些软件依然必须足够高效。否则，让原生应用变得更容易开发，只会导致 Windows 上出现更多优化糟糕的原生应用。

　　多年前，微软需要让史蒂夫 · 鲍尔默站在台上高喊“开发者、开发者、开发者”，如今情况已经发生了变化。现在，越来越多开发者倾向于使用 Linux 开发环境，而大量 AI 应用开发者则选择 MacBook，因为它拥有强大的硬件性能。

　　微软现在试图做的，是让 Windows 应用开发直接发生在一个围绕 AI Agent 打造的 Windows 开发环境中。如果这套方案能够成功，Windows 或许就能获得更多原生应用，同时开发者也不必再手动重写大量代码。

　　但微软仍然需要证明一点：这些由 AI 构建的 WinUI 应用，真的能够比它想要取代的 Web 应用运行得更快、占用更少资源。