微软工程师称“手搓代码”时代结束：AI Coding 正改写 Win11 与应用开发流程
据 IT之家 9 月 6 日消息，在微软任职 18 年的杰出工程师 David Fowler 近日在 X 平台表示，“手搓代码”的时代已经结束。这一说法之所以引发开发者关注，不只是因为它来自微软内部资深工程师，更因为 Fowler 曾参与 SignalR、NuGet、Kudu 等项目，并深度参与 ASP.NET Core 核心部分开发，目前还在微软负责 Aspire 项目。结合微软近年在 Windows 11、WinUI 3 和 AI Coding 上的动作来看，这更像是一次关于软件开发方式变化的公开信号。
“不再手搓”并不等于程序员消失
从来源信息看，Fowler 的观点并不是简单宣称开发者会被 AI 替代，也不是说软件工程岗位会立刻被颠覆。他强调的核心，是传统开发流程中“在 IDE 里逐行敲代码”这件事，正在变成整个软件工程活动中最不具吸引力、也最容易被工具重构的部分。
换句话说，AI Coding 正在把开发者的注意力从“输入代码”转向“定义问题、设计结构、审查结果和迭代系统”。开发者仍然需要阅读代码、理解架构、判断质量、处理边界情况，但代码生成、样板逻辑、重复性实现会越来越多地交给 AI 工具完成。
这种变化对中文开发者同样有参考意义：AI 编程助手不再只是补全函数名或生成几行示例代码，而是在逐步介入项目脚手架、依赖管理、服务编排、测试生成和文档维护等更完整的软件生命周期。
Aspire 项目已围绕 AI Coding 重新设计
来源提到，Fowler 当前负责的 Aspire 项目本身，已经围绕 AI Coding 进行了重新设计。Aspire 面向的是现代云原生和分布式应用开发，天然涉及多个服务、配置、依赖与部署流程。如果这一类项目开始把 AI Coding 作为基础假设，说明微软并不只是把 AI 当作“代码补全插件”，而是试图让 AI 参与到开发框架和工具链的设计中。
这意味着未来的开发环境可能不再围绕单个文件、单个函数展开，而是围绕任务、服务、组件关系和运行状态组织。开发者向工具描述目标，AI 负责生成或调整代码，IDE、框架和运行时再提供验证、调试与反馈。
- 代码输入方式改变：从逐行编写转向自然语言描述、局部修改和自动生成。
- 工程管理方式改变：AI 可能参与依赖配置、测试样例、构建脚本和服务编排。
- 开发者职责改变：更强调架构判断、代码审查、安全性和产品理解。
- 工具链竞争加剧：IDE、框架、云服务与 AI 编程能力会更紧密绑定。
Win11 原生应用回归与 WinUI 3 的信号
值得注意的是，Fowler 此前还曾提到“Win11 原生应用正在回归”。随后，外界确实看到微软重新加强 WinUI 3 自带应用开发，而不是继续在部分场景中过度依赖 Electron。来源显示，微软已经将 WinUI 3 列为新的 Windows 应用推荐开发框架，并推动 WinUI 3 真正开源。
这对 Windows 生态来说是一个重要方向。Electron 的优势在于跨平台和 Web 技术栈复用，但在性能、内存占用、系统一致性等方面长期存在争议。微软重新强调 WinUI 3，一方面有助于提升 Windows 11 原生体验，另一方面也可能与 AI Coding 结合：如果框架、控件、系统 API 和开发规范更加统一，AI 生成高质量 Windows 原生应用代码的难度也会降低。
影响解读：AI Coding 正从“辅助工具”变成开发底座
微软 CEO 纳德拉曾表示，公司内部已有 20%-30% 代码由 AI 编写。虽然目前无法确认今年 Windows 11 的具体改进是否由 AI Coding 完成，但结合微软在开发框架、原生应用和 AI 工具上的推进，可以看到一个趋势：AI 正从提高个人编码效率的插件，走向企业级软件生产流程的一部分。
对开发者而言，这并不意味着基础能力不再重要。相反，当 AI 能快速生成代码时，判断“生成得是否正确、是否可维护、是否安全”会变得更关键。未来更有竞争力的工程师，可能不是打字最快的人，而是能把需求拆解清楚、能驾驭工具链、能审查复杂系统的人。
对微软而言，Windows 11、WinUI 3、Aspire 与 AI Coding 的结合，可能会重塑其开发者生态。如果 AI 编程真正成为默认工作流，操作系统厂商、云平台和 IDE 提供商的边界也会进一步融合，谁能提供更完整的 AI 原生开发体验，谁就更可能掌握下一阶段软件生产的入口。