整理 | 郑丽媛 出品 | CSDN（ID：CSDNnews） “ 敲代码 的时代， 彻底结束了（Typing code is absolutely over）。 ” 9 月 4 日，微软杰出工程师 David Fowler 在 X 上发了这么一句话。18 年微软老兵、SignalR 联合创建者、NuGet 和 Kudu 部署引擎的创始开发者之一、ASP.NET Core 等项目核心贡献者—— David Fowler 的履历，让这句话迅速引爆了开发者社区。 他并非在预言开发者会消失，他的意思是：当 AI 能包揽越来越多的重复性编码工作时，开发者花在逐行敲代码上的时间会越来越少，转而把精力投入到系统架构、需求分析、安全审核这些更有价值的事情上。 而真正让网友坐不住的，其实是另一个被反复提及的联想：微软工程师都这么说了， 那 Windows 11 那些没完没了的 B ug ， 是不是就因为微软在用 AI 写代码？ 从“帮我写代码”，到“帮我把软件做出来” 这个猜测并非空穴来风。 微软 CEO 纳德拉曾公开表示 ，公司内部已有 20% 到 30% 的代码由 AI 编写。 而且，不同于过去主要还是代码补全的 AI Coding，如今微软正在把 AI 推向完全不同的方向： 现在，GitHub Copilot 的 Coding Agent可接收一个开发任务，自行准备环境、修改代码仓库、运行测试、检查构建结果，最后创建 Pull Request（PR），交给人类开发者审核。 今年 2 月，GitHub 又为 Coding Agent 增加了 Windows 开发环境支持，Agent 可直接构建、测试 Windows 项目，运行 Linter，并验证 Build 是否成功。 与此同时，Copilot Agent 也开始进入 WSL，让 AI 可以参与 Windows 与 Linux 混合开发。 微软自己的 Aspire 也在做类似的事情（正是 David Fowler 负责的项目）。通过统一的应用模型、CLI 和 MCP 支持，AI Agent 可以获得比单个代码文件更多的上下文，甚至能启动服务、查看日志、检查 Telemetry、重启故障组件，然后再次测试。 也就是说， 微软正在把 AI 从“代码生成器”变成能参与完整开发闭环的 Agent。 而且，仔细观察微软最近对 Windows 开发工具的调整，会发现它正在推动一件非常明确的事情：让 Windows 本身变得更加适合 AI Agent 开发软件，其中一个重要变化就是 WinUI 3。 微软目前 把 WinUI 3 列为开发新一代原生 Windows 应用时推荐使用的框架 ，且 WinUI 3 已经开源。这看起来只是开发框架的变化，但对于 AI Coding 来说却非常重要——因为 AI Agent 要想真正参与软件开发，需要大量上下文： 一个封闭、混乱、文档不完整的开发环境，很难让 AI 理解；而一个拥有开放源代码、清晰 API、完善文档以及标准化项目结构的开发框架，则更容易被 AI“读懂”。 连运行 AI 的 Windows 开发机器都准备好了 如果说 Copilot 和 WinUI 解决的是“AI 如何参与开发”，那微软最近公布的 Project Zenith，则开始解决另一个问题：AI 到底在哪里运行？ 9 月 4 日， 微软正式推出了 Project Zenith ——针对开发者打造的一套精简版、开发者优化的 Windows 11 运行环境。微软希望它减少与开发无关的系统干扰，并预配置 VS Code、GitHub Copilot、WSL、PowerShell 等开发工具，让开发者拿到机器后能够更快进入 Coding 状态。 Project Zenith的硬件门槛也相当硬核：至少 64GB 统一内存、250GB/s 以上的内存带宽，首批适配 AMD Ryzen AI Halo 芯片。 问题来了：为什么开发一套 Windows 11，还要对内存提出如此高的要求？答案很简单： 为了在本地运行 AI 模型 ，微软希望开发者可以直接在本地跑起 300 亿参数以上的大模型，不用再为每次 AI 辅助编程付云端 Token 费。 因此，Project Zenith 更像是微软对未来开发环境的一次尝试：Windows 11 + 本地大模型 + Copilot Agent + WSL + 开发工具， 组成一个 AI 原生的开发环境。 问题是：AI 写得越多，Win11 真的会更好吗？ 虽然 Windows 内核，目前仍由资深工程师用 C/C++ 严格维护，不太可能贸然交给 AI——但在内核之外，大量用户界面组件、系统服务和配套功能， 采用 AI 辅助开发已经没什么悬念了。 而 Windows