我只有一台 Mac，却能开发、调试和发布 Windows 原生软件

AI 正在改写客户端开发的技术选型逻辑。过去选跨端框架，很大程度是为了把几套平台的代码压成一套，省人力省成本；现在 agent 能同时写 Swift、Rust、C#，多写一门语言的边际成本骤降，开发者终于可以把系统体验、性能和长期维护成本放回决策前排。

但代码写完只是开始。编译、运行、看界面、修问题，这些事都发生在目标操作系统上。如果你手边只有一台 Mac，过去这基本宣判了 Windows 原生开发与你无关；今天工具链已经把这个缺口补得七七八八。这篇文章把整套闭环拆开讲：远程环境怎么搭、三门语言的跨系统能力各到哪一步、AI agent 怎么把它们串起来，以及哪些边界至今没变。

远程 Windows 环境的三种形态

第一种是一台真机或云上的 Windows 虚拟机，图形界面走 RDP。关键是命令行通道：Windows 10（build 1809）和 Windows Server 2019 起把 OpenSSH 纳入系统组件，按微软文档启用服务端之后，还可以把默认 shell 从 cmd 换成 PowerShell，SSH 连上就是完整的命令行环境，和连一台 Linux 服务器没有本质区别。

第二种是 CI。GitHub Actions 的 windows-latest 现在对应 Windows Server 2025，另有 windows-2022 和 Windows 11 ARM 镜像可选。测试矩阵里的 Windows 兼容性不再需要你自己的机器：push 一次，runner 拉代码、装工具链、跑 dotnet test 或 cargo test，结果直接写回 PR。

第三种是容器。Swift 官方提供 windowsservercore 底座的工具链 Docker 镜像，有 Windows 容器宿主的团队可以直接在容器里跑构建。

三门语言，三种跨系统能力

Rust 的交叉编译走 rustup：rustup target add 为目标平台安装标准库，cargo build --target 产出对应二进制，机制写在官方文档里。变量在链接器：rustup 只装标准库，交叉编译通常还需要目标平台的链接工具，Windows 的 MSVC 目标就依赖 MSVC 侧的链接器，所以不少项目把最终链接放到 Windows 或 CI 上完成。

.NET 最省事。dotnet publish -r win-x64 本身就支持按 RID 发布，跨平台项目在 mac 上直接产出 win-x64 的发布目录；但 WPF、WinUI 这类 Windows 专属 UI 工程仍要在 Windows 上构建，别指望全流程留在 mac。

Swift 最有意思。swift.org 官方维护 Windows 工具链，当前 6.4.1 版本覆盖 Windows 10/11，用 winget 就能安装，依赖 VS 2022、Windows 11 SDK 和 MSVC 工具链，还附带 windowsservercore 的 Docker 镜像；官方仓库里还有一份在非 Windows 主机上交叉编译 Swift 到 Windows 的文档，前提是备齐 Visual Studio 的库文件并用 lld 做链接，门槛不低。真把这条路当日常的是 The Browser Company，这家用 Swift 构建 Windows 浏览器的团队维护着 swift-build 仓库（BSD-3 协议，390 星），持续产出 Swift 的 Windows 工具链构建。

调试、测试、打包签名

编译解决的是出二进制，开发闭环还包括三件事。调试和观察界面：GUI 程序跑在 Windows 侧，RDP 连过去看实际渲染，命令行交互走 SSH；要做界面回归，Windows 侧脚本化截图再回传也不难。自动化测试：放进 GitHub Actions 的 Windows runner，语言原生的 test 命令直接跑。打包签名：代码签名证书和 signtool 都在 Windows 生态里，商店上架的提交流程同样绕不开 Windows 环境，这一步通常放在最后，由脚本或 agent 驱动完成。

Agent 串起闭环：关键不是写码，是跨系统执行

这才是新问题的核心。Claude Code 已经原生支持 Windows（Windows 10 1809 以上或 Windows Server 2019 以上），装了 Git for Windows 就有 Bash 工具，没装则回退到 PowerShell 工具，WSL 是可选项而非必需。换句话说，agent 本身就能跑在你的远程 Windows 环境里。

于是有两种编排。其一是 agent 在 mac 上，通过 SSH 把构建、测试派发到 Windows 侧执行，读回日志再决定下一步；其二是 agent 直接驻在 Windows 机器上干活，你在 mac 上只看它的工作汇报。无论哪种，agent 的关键能力都是观察：拿到编译报错、测试失败、甚至界面截图，它才能自己修。写代码 AI 早就会了，跨操作系统完成执行、观察、修复的循环，才是它新拿到的那块拼图。

边界也要说清楚：这套流程改变的是谁去执行，不改变平台本身的事实约束。商店审核规则、签名要求、WPF 这类工程的构建限制都还在原处，它不是绕过，而是把过去人肉换机器的环节自动化了。

小结

回到选型：当我只有一台 Mac 不再构成放弃 Windows 原生的理由，跨端框架的成本账就得重算。系统体验、性能上限、长期维护这些被跨端权衡压了很久的维度，值得放回前排。先用 SSH 加 CI 把执行闭环搭起来，再让 agent 驻进去，一台 Mac 加一台远程 Windows，就够支撑一套严肃的原生开发流程。