微软承认了什么
2026 年 3 月 20 日，微软 Windows 与设备事业部执行副总裁 Pavan Davuluri 在 Windows Insider 博客上发表了一封公开信。这不是一次常规的功能预告，也不是新版本发布的节奏。信的开头写道：”过去几个月，我们花了大量时间分析你们的反馈。我们听到的，是一群深切关心 Windows、希望它变得更好的人的声音。”随后，他列出了一连串改进承诺。
这些承诺包括：任务栏将恢复顶部和侧面定位；Copilot 将从截图工具、照片应用、小组件和记事本中移除，集成将变得”更有针对性”；文件资源管理器将获得更快的启动速度、更低的搜索延迟、更可靠的大文件操作；Windows 更新将不再强制在关机时安装，用户可以在设备初始化时跳过更新，暂停更新的时间也将延长。微软还承诺减少操作系统级别的崩溃，提升驱动和应用稳定性，并将更多核心体验迁移至 WinUI3 框架以降低交互延迟。
如果你仔细看这份清单，会发现一个尴尬的事实：这里没有一项是新功能。任务栏位置自定义在 Windows 10 时代是标配，Windows 11 发布时被砍掉了。文件资源管理器的缓慢和卡顿是多年来的已知问题。更新机制的强制性早已引发广泛抱怨。换句话说，一家市值超过三万亿美元的公司，在 2026 年需要郑重其事地向用户承诺——我们会把你们本来就有的东西修好。这本身就是一个信号。
用户感知到的技术债
要理解微软为什么需要写这封信，需要回溯 Windows 11 过去四年的轨迹。
2021 年 10 月，Windows 11 正式发布。微软把它定位为一次设计语言的全面刷新：居中的任务栏、圆角窗口、新的 Snap 布局。但刷新的代价是功能退化。任务栏失去了拖拽文件到应用图标上直接打开的能力，失去了右键菜单中的任务管理器入口，失去了移动到屏幕顶部或侧面的选项。这些不是边缘功能，而是大量用户依赖的日常操作。微软给出的解释是”简化体验”，但用户收到的信息是：你们习惯的东西没了，而且我们不打算还给你。
右键菜单是另一个经典案例。Windows 11 重新设计了上下文菜单，采用了更简洁的新样式。但由于大量第三方应用仍依赖旧版菜单接口，新菜单底部不得不保留一个”显示更多选项”的入口，点击后弹出旧版完整菜单。两套菜单系统并存至今，成了 Windows 技术债最直观的视觉标本——新的做不完，旧的删不掉。
文件资源管理器的问题更加深层。微软在 Windows 11 中将其迁移到了 WinUI3 框架（也就是微软当前主推的 UI 技术栈），但迁移后性能反而下降。搜索功能的延迟长期被用户诟病，导航时的闪烁和卡顿在社区中有大量报告。微软在这次博文中承诺”大幅降低搜索、导航和上下文菜单的延迟”，但没有解释为什么一个已经迁移到最新框架的核心组件，在基本性能上还需要”大幅改进”。
然后是 Copilot。从 2023 年下半年开始，微软以近乎强迫症的节奏将 AI 助手 Copilot 塞进 Windows 的每一个角落。记事本获得了 AI 重写功能，照片应用获得了 AI 擦除，截图工具获得了 AI 识别，小组件面板被 Copilot 入口占据，甚至 Windows 搜索也开始默认调用 Copilot。这背后的商业逻辑很清晰：微软向 OpenAI 累计投入超过 130 亿美元，急需在自有产品矩阵中创造 AI 使用场景来证明这笔投资的回报。但用户感受到的不是”智能化”，而是一个不请自来的弹窗和入口，出现在自己不需要它的每一个地方。
现在微软自己承认了这一点。博文中写道，Copilot 的集成将变得”更有针对性”，仅限于”真正有用且集成良好”的场景。截图工具、照片应用、小组件和记事本中的 Copilot 将被移除。这在商业语境中是罕见的——一家公司公开撤回自己花了两年时间推进的核心战略落地动作，本质上是在说：我们知道做过头了。
开发者感知到的技术债
如果说普通用户感受到的是”东西变慢了、东西被砍了、不想要的东西被硬塞进来了”，那么开发者感受到的是一个更根本的问题：微软反复推翻自己的技术栈，每一层都没做完，然后就开始建下一层。
2026 年 3 月，前 Google Chromium 工程师 Domenic Denicola 发表了一篇博文，记录了他尝试用微软最新推荐的技术栈（WinUI 3 + Windows App SDK）开发一个简单 Windows 桌面工具的完整经历。这个工具叫 Display Blackout，功能极其简单：在多显示器设置中，把不用的屏幕变黑。它需要的能力一共六项——枚举显示器、创建无边框窗口、拦截全局快捷键、开机自启、存储设置、显示系统托盘图标。
结果是：六项能力中，WinUI 3 只能原生支持两项（开机自启和存储设置）。其余四项全部需要回退到 Win32——也就是上世纪九十年代的 C 语言 API——通过 P/Invoke 机制手动桥接。他总结道：”如果你一半的代码都是在跟旧 API 做互操作胶水，那用微软最新框架的意义是什么？”
这不是个别现象，而是微软 UI 框架历史的结构性产物。从 2002 年至今，微软的 Windows 原生 UI 框架经历了七次迭代：Win32 C API → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3。每一代都是某种程度的”推翻重来”：新的 API 设计、新的控件库、新的打包和分发方式。而每一代推出时，上一代的功能并没有被完整移植过来。WPF 有的东西 UWP 没有，UWP 有的东西 WinUI 3 又丢了。开发者被迫在新旧 API 之间反复跳跃，写出的代码一半是业务逻辑，一半是跨层胶水。
分发问题同样荒诞。微软推荐的现代分发格式 MSIX 重度依赖代码签名证书，而证书费用是每年 200 到 300 美元。未签名的侧载体验极差，需要通过管理员终端执行一条晦涩的 PowerShell 命令。Domenic 试图把应用提交到 Microsoft Store，被拒绝了，理由是”没有提供独特持久价值”。与此同时，Windows 11 预装的 .NET 版本仍然是 4.8.1，而当前 .NET 已经到了第 10 版。微软不愿通过 Windows Update 分发现代 .NET，这意味着每个使用现代 .NET 的应用要么要求用户手动安装运行时，要么把整个运行时编译进二进制文件。Domenic 选择了后者，结果一个黑屏小工具的体积是 9MB。
微软自己也曾尝试为 Windows App SDK 提供 Rust 绑定——这本来可以给开发者一条内存安全且轻量的路径。但这个项目已经被归档放弃了。与此同时，CsWin32（微软推出的现代 P/Invoke 封装工具）连结构体中的字符串字段都处理不好，在 Domenic 看来，这是一个”资金不足、永远停留在 pre-1.0 阶段、几年后大概率被放弃”的项目。
这就是为什么越来越多的 Windows 桌面应用选择了 Electron——用 Chromium 内核加 Node.js 来写桌面应用。不是因为 Electron 好，而是因为微软自己的原生开发路径太烂了。当你的框架七代推翻重来、最新一代连系统托盘图标都不支持、分发机制要么贵要么难用、官方推荐的互操作工具半成品、连 Rust 绑定都放弃了的时候，开发者用脚投票是必然的。
这不只是 AI 的锅
一个容易犯的错误是把 Windows 当前的困境全部归因于 AI 军备竞赛——微软投了上百亿给 OpenAI，急着变现，所以把工程资源从基础体验转移到了 Copilot 集成。这个叙事有一定真实性，但它过于简化了。
Copilot 硬塞是 2023 年之后的事。但文件资源管理器的性能问题从 Windows 11 发布起就存在。右键菜单双层并存是 2021 年的遗留。任务栏功能被砍也是 2021 年的决策。而开发框架七代推翻重来的历史，从 2002 年就开始了。这些问题都远早于微软的 AI 转向。
微软真正的结构性问题，是一种反复出现的工程模式：每隔几年推出一套新的技术栈，承诺这是”未来的方向”，要求开发者和用户迁移过来；但新栈推出时功能不完整、工具不成熟；还没等这一层做完做好，公司的战略重心又转移到下一个方向，于是上一层的坑留在那里，永远不会被填上。从 WPF 到 UWP 是这样，从 UWP 到 WinUI 3 也是这样。Copilot 硬塞只是这个模式的最新一轮表演——而且这次连用户侧的基础功能都被波及了，所以引发的反弹格外剧烈。
AI 军备竞赛确实加速了这个过程。当华尔街最看重的叙事是”谁能最快把 AI 变成产品收入”的时候，文件管理器的启动速度和右键菜单的统一性显然不会排在优先级列表的前面。微软在 2023 到 2025 年间的工程资源分配，明显向 Copilot 倾斜——否则你无法解释为什么一个记事本需要 AI 功能，而文件管理器的搜索延迟却几年不修。但 AI 不是病因，它是催化剂。病因是微软的工程文化：永远在追下一个大方向，永远不把当前这一层做完。
这种模式在科技行业并不罕见。Google 也有类似的倾向——Gemini 正在被塞进 Gmail、Google Docs、Google Search 的每一个界面，用户是否需要它并不在第一优先级。但 Windows 的特殊性在于它的不可替代性。你可以不用 Google Docs，但全球超过十亿台 PC 运行 Windows，大量企业的核心工作流依赖于它。当一个不可替代的基础设施产品累积了这么多技术债，用户没有”用脚投票”的余地——他们只能忍，或者抱怨，直到微软自己也扛不住了。
这次承诺靠谱吗
微软的这封公开信，语气是诚恳的。Pavan Davuluri 直接用第一人称面对 Insider 社区，承认问题存在，给出了具体的改进方向，并且已经在部分领域采取了行动——新版反馈中心已经上线，任务栏位置的调整也已在 Insider 预览版中开始测试。这比那些含糊其辞的”我们一直在倾听”要好得多。
但问题在于执行。微软不是第一次发表这样的公开承诺。Windows 10 时代就有过类似的”我们听到了反馈”的沟通，随后真正落地的改进并不总是与承诺一致。更关键的是，微软承诺的这些改进——文件管理器提速、搜索延迟降低、大文件操作更可靠——都不是简单的功能开关，而是深层的工程优化。微软自己在博文中说要把更多核心体验迁移到 WinUI3，但 WinUI3 本身就是那个连系统托盘图标都不支持的框架。用一个尚未完善的工具去修复它造成的问题，这里面有显而易见的矛盾。
真正的考验不在于微软能不能修好文件管理器的启动速度——以这家公司的工程能力，这是做得到的。真正的考验在于，当下一个战略热点出现的时候，这些基础工程的投入会不会再次被挪走。以微软过去二十年的记录来看，每一轮新战略都曾经从基础体验手里抢走过资源。如果明年 AI Agent 成为华尔街的新宠，或者微软需要在混合现实领域跟 Apple 正面竞争，文件管理器的优化团队会不会再一次被抽调？
这封公开信的价值不在于它承诺了什么，而在于它承认了什么。微软承认了过去几年的资源分配出了问题，承认了 Copilot 被过度集成，承认了基础体验的退化。这是修复的第一步。但从承认到修复，中间隔着的不是一篇博文，而是一次工程优先级的真正调整——而这恰恰是微软最不擅长坚持的事情。
公开信：https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/
Windows Native App Development Is a Mess