分类：科技 标签：客户端开发、大模型、跨平台、软件工程

在 AI 辅助编程能力日益成熟的今天，客户端开发的规则正在悄然改变。很多开发者好奇：如何在 Mac 上高效开发 Windows 软件？当下的桌面端和多端应用又该如何进行技术栈选型？本文将结合实际项目的开发经验，聊聊多端技术选择的思考、AI 时代的开发工作流，以及如何利用多语言混用来破解技术难题。

Web、跨端还是原生：技术选型的不可能三角

在客户端应用开发中，技术方案长期面临着“研发效率、体验、性能”的不可能三角。

  1. Web 技术栈：以网页直接打包或套壳为主，开发最省心、效率最高，但系统底层调优和性能表现上限较低。
  2. 跨端开发：包括早期的移动端方案 React Native、Flutter，以及桌面端的 Electron、Tauri 等。跨端开发旨在寻找效率与性能的平衡点。以 Electron 为例，虽然自带 Chromium 引擎导致包体积大、内存占用高，但它凭借渲染一致性和极高的开发效率，成为了许多 AI 桌面端应用的常见选择。
  3. 原生开发：如 Swift + SwiftUI、Kotlin + Jetpack Compose、C# + WinUI 3。原生开发前期投入大，但能带来最佳的性能体验和深度系统集成。

在 AI 介入之前，一个人维护两套原生客户端的代码成本极高。但在 AI 时代，编写多端原生代码的成本大幅下降，“研发效率”这一劣势被明显补齐，使得开发者可以重新回归体验与性能更优的原生路线。

Windows 版的架构抉择与开发实践

以跨平台应用 Mole 为例，其 Mac 版本采用了原生的 Swift + SwiftUI，而在 Windows 平台上，则选择了目前微软主推的 C# 加上 WinUI 3（运行于 .NET 10）。

1. 架构设计：代码各写各的，规则保持一致

为了兼顾开发效率和代码质量，该项目采用了四层架构设计：

  • Core 层：只依赖 .NET，不碰任何 Windows 接口，核心清理规则和安全检查逻辑均在此处，甚至可以在 Mac 的内存文件系统中直接运行测试。
  • Platform 层：处理注册表、文件系统等真正的系统接口。
  • ViewModel 层：管理界面状态，与 Mac 版本保持一一对应。
  • WinUI 界面层：负责最上层的界面渲染与编译。

通过这种架构，大部分业务逻辑和测试都可以在 Mac 上完成，只有最顶层的界面需要放入 Windows 环境编译。两端通过统一的设计 Token（颜色、字号、间距）与多语言文件生成脚本来保证视觉和文案的一致性。

2. 跨平台开发工作流：Mac 作为主力舱

为了保持在习惯的 Mac 环境中开发，可以通过 Parallels Desktop 运行 Windows 11 虚拟机。

  • 代码与 AI 辅助：代码和 Claude Code 均保留在 Mac 端，通过共享文件夹直接挂载到虚拟机。
  • 编译与测试：利用脚本通过命令行在虚拟机中自动完成编译、日志捕获与测试。
  • 真机兜底：配合一台 ThinkPad 真机处理高分屏、电池及应用商店签名等虚拟机无法精确模拟的场景。

语言混用与跨语言通信：打破边界的 Hack 技巧

在实际开发中，单一语言往往难以完美解决所有场景的问题。充分利用不同语言生态的特性进行混用，可以带来意想不到的效果：

  • Swift 与 JS 的结合：在开发 Mac 笔记应用“妙言”时，利用 JavaScriptCore 在 Swift 中直接调用 JS 的 Markdown 格式化能力，省去了手写复杂解析引擎的麻烦。
  • Rust 与 Web 的互补：在使用 Rust 开发桌面打包工具 Pake 时，通过跨语言通信让 Rust 调用前端的 JS 来动态渲染通知弹窗，兼顾了性能与视觉效果。
  • 多语言协同：无论是通过 C 语言开源库 cmark-gfm 实现编辑与预览的高效同步滚动，还是在终端工具 Kaku 中让 zsh、Lua 与 Rust 形成闭环处理自然语言指令，这种跨语言的“通信桥梁”设计，往往是解决复杂工程难题的关键。

结语

归根结底，技术始终是为业务服务的。无论是选择原生、跨端还是 Web，抢占用户心智、解决真实的痛点才是核心。

在 AI 时代，代码编写的门槛已被大幅降低，但架构设计、测试验证以及对产品本质的思考依然是工程师的核心价值。合理利用各语言生态的特性，选择最适合场景的技术栈，才能打造出真正好用的优质软件。