过去几年，如果你想用JavaScript写一个Windows桌面应用，路径是这样的：先用Electron搭好UI框架，然后需要调用Windows原生功能。弹个系统通知、调个本地AI模型，这时候你就得停下来。去写一段C++或C#的桥接代码，再编译成原生模块，再小心翼翼地把它塞进你的Electron项目里。每一步都可能踩坑：node-gyp编译失败、版本不兼容、API签名翻译出错。很多开发者干脆放弃了这条路。
2026年7月27日，微软在官方开发者博客上宣布了一件事，让这条路彻底变了。一个npm包，一行命令，JavaScript开发者就能直接调用Windows原生API。不需要再碰C++，不需要再编译原生模块，不需要再写桥接代码。
一个npm包，拆掉C++的墙
微软发布的这个工具，官方名称叫“面向Node.js的动态Windows Runtime语言投影”，目前以公开预览形式提供。它包含两部分：一个npm包@microsoft/dynwinrt，和一个基于Windows API元数据（.winmd文件）的代码生成器。开发者安装这个包后，工具会自动读取Windows提供的API描述数据，生成对应的JavaScript接口和TypeScript类型定义。然后，在Electron或普通Node.js进程里，直接用JavaScript调用这些接口。
微软项目经理Leilei Zhang在博客中写道：
“Electron和Node.js让构建Windows桌面应用变得简单，但调用Windows Runtime API一直不那么简单。设备端AI等特性往往需要C++或C#桥接、手动翻译WinRT类型和异步行为，以及为每个暴露的API编写包装代码。”
这个工具的核心差异在于：它不是在生成原生绑定，而是在生成JavaScript包装器。Windows Runtime此前已经支持C++/WinRT、C#/WinRT、windows-rs（Rust）和PyWinRT等静态语言投影，但Node.js的投影是动态的。它不把每个API编译成原生模块，而是通过一个共享运行时在JavaScript层派发调用。
当前支持的API范围以非UI功能为主，涵盖三大类：
- 设备端AI：文本生成、摘要、改写、文本转表格、图像描述、文字识别、图像缩放、目标提取与移除，以及Windows ML模型和执行提供程序目录
- 应用和内容API：通知（支持进度条、操作按钮和输入字段）、文件和文件夹选择器、存储、图像解码、富文本剪贴板
- 系统和设备API：网络、传感器、全球化和密码学
微软同时展示了两个Demo：一是在Electron应用中创建带有进度条的Windows原生通知；二是在Copilot+ PC上调用本地Phi Silica语言模型进行文本摘要。
Phi Silica是微软专为NPU（神经网络处理单元）调优的小型语言模型，采用推测解码技术加速文本生成。它使用一个较小的草稿模型并行提出多个候选Token序列，再由主模型验证，能够在完全本地运行，数据不出设备。但应用若要使用Phi Silica，开发者需要声明受限的系统AI模型权限，且仅适用于Copilot+ PC硬件。
WinUI等UI套件和WebView2默认不在生成范围内。微软明确表示，这是非UI API的投影，UI层面的交互仍需开发者自行处理。
Electron的最后一公里
Electron是当下最流行的跨平台桌面应用框架之一。VS Code、Slack、Discord、Figma、Notion、1Password、ChatGPT桌面版，这些你每天都在用的应用，底层都是Electron。2026年7月最后一周，npm上electron包的下载量超过522万次，是竞品Tauri的2.5倍。
但Electron有一个长期存在的“最后一公里”问题：跨平台UI可以做得很好，但一旦需要调用操作系统原生能力，开发体验就急转直下。Electron本身提供了部分原生API，比如系统托盘和原生菜单，但Windows Runtime API中那些更强大、更贴近硬件的能力（设备端AI、高级通知、传感器）一直被挡在C++和C#的墙后面。
对于一个小型Electron开发团队来说，为每个需要的Windows API写一个C++桥接模块，意味着三件事：团队里得有C++开发者；得维护一套独立的原生模块编译流程；每次Windows API更新，都得重新编译和测试。这不是技术难题，这是资源浪费。
从编译到生成，一次技术哲学的对调
微软的解决方案不是“再给你一个更简单的C++桥接方式”，而是从根本上改变了交互模型。
传统语言投影是静态的：编译时生成原生绑定，每个API对应一个独立的原生模块。如果API发生变化，你需要重新编译。动态投影完全不同。它通过读取Windows API元数据（.winmd）在运行时决定如何调用，JavaScript包装器由代码生成器自动产生，无需手动维护。
这意味着三件事。第一，开发者不需要在自己的项目里引入任何原生编译工具链，所有依赖都通过npm管理。第二，当Windows API更新时，开发者只需重新运行代码生成器，而不是等待某个原生模块的维护者发布新版本。第三，任何符合WinRT规范的自定义组件也可以被投影。你不只是消费微软的API，你自己的WinRT组件同样能被JS调用。
这套机制背后还有一个更底层的支撑：WinApp CLI。这是微软2026年1月发布的Windows应用开发命令行工具，统一管理Windows SDK、应用清单、证书和打包流程。动态WinRT投影被集成在WinApp CLI v0.5.0中，让整个开发流程从“安装SDK、写桥接代码、编译、打包”压缩为“安装CLI、生成JS接口、调用”。
AI才是真正的终点站
在所有支持的API中，设备端AI能力是最值得关注的。这不是巧合。
2026年的微软，正在做两件大事：把AI塞进Windows的每一个角落，以及让更多开发者能够使用这些AI能力。Copilot+ PC是这场战役的硬件载体，规定NPU算力不低于40 TOPS、16GB内存起步，而Phi Silica等本地模型则是软件核心。但这里有一个矛盾：AI能力最强的本地模型，过去只能通过C++和C#的Windows App SDK访问。那些用Electron写了ChatGPT桌面版、用JS构建了AI客户端的开发者，反而无法直接在Windows上使用本地AI模型。
现在，这个矛盾被打破了。通过动态WinRT投影，一个Electron应用可以调用Phi Silica进行文本摘要，用Windows ML运行自定义模型，用OCR做文字识别。全部在本地执行，全部从JavaScript直接调用，全部不需要数据离开设备。
这对于Copilot+ PC战略的意义不言而喻。微软在2025到2026年全力推动的Copilot+ PC，核心卖点就是本地AI能力：NPU、40+ TOPS算力、本地模型推理。但如果这些能力只有C++和C#开发者能用，那这个生态就永远只是Windows原生开发者的后花园。JS开发者，全球约2800万人，是最大的开发者群体，才是真正能让Copilot+ PC的AI能力长出应用的人。
不是锁死，是加杠杆
一个微妙的问题浮出水面：微软这是在锁死Windows生态，还是在开放？
从表面看，这似乎是一种锁死。让JS开发者更依赖Windows原生API，不就把他们绑在Windows平台上了吗？但仔细看，逻辑恰恰相反。Electron本身就是跨平台的，一个Electron应用在macOS和Linux上也能运行。动态WinRT投影只是让开发者能够按需调用Windows独有功能，而不是迫使他们把整个应用都迁移到Windows技术栈。
微软的算盘是：你继续用跨平台框架，你继续用你喜欢的语言和工具链，但当你想用Windows独有的能力（特别是本地AI）时，我们给了你一条最顺畅的路。这不是锁死，这是加杠杆：用JS生态的杠杆，撬动Windows AI能力的普及。
信号与方向
动态WinRT投影的推出，传递了几个清晰信号。
第一，微软正在用JS开发者听得懂的语言说话。npm包、TypeScript类型定义、代码生成器，这些是JS开发者日常使用的工具和概念，而不是微软传统开发者生态中的Visual Studio、MSBuild、NuGet。这说明微软在认真思考如何让JS开发者觉得Windows开发是友好的。
第二，设备端AI是Windows生态最重要的差异化能力。在云端AI被几大巨头把持的今天，微软选择的差异化路径是本地AI。通过Copilot+ PC的NPU和Phi Silica等模型，提供低延迟、隐私安全、可离线的AI体验。而要让这个差异化落地，就需要让尽可能多的开发者能够调用这些能力。动态WinRT投影瞄准的正是这个缺口。
第三，Electron的开发者体验正在被认真对待。过去几年，Tauri等轻量级框架一直在挑战Electron的地位，压缩包体积和内存占用是它们的主要攻击点。微软没有去解决Electron的“胖”问题，而是解决了它的“短”问题，补上了调用原生能力最不顺畅的那块拼图。对于已经投入Electron生态的团队来说，这是一个留在平台上的理由。
目前这个工具还只是公开预览。支持的API范围有限，UI组件不在其中，WebView2也不在投影范围内。对于生产环境的使用，还需要更多稳定性和兼容性验证。但方向已经明确：微软想让JS开发者成为Windows AI生态的卖水人，而2800万JS开发者中的每一个，都可能成为下一个AI桌面应用的创造者。
微软修了一条通往Windows原生能力的桥，桥的另一头，是2800万JavaScript开发者，以及他们手中正在改变的每一款应用。
快报