不聊天、只会涂答题卡的 AI：Jev 讲明白 Jev 其实发布有一阵了，还是值得科普一下，做了个简单的科普视频。 视频2 是中文版 Jev 只干一件事：像我们考试涂答题卡一样，在程序出好的选项里涂圈，涂的深浅就是它有几成把握。 这期用一张答题卡讲清楚： 只会做选择题有什么用？ 它为什么能快几十倍、便宜到读一大堆字才几美分？ 官方说它「幻觉率为零」，这个零是怎么来的？ 独立研究又发现它会在哪儿涂错、哪些事它干不了。 最后说说它适合干什么活，以及 OpenAI 等跟进的同类产品。

书接上回，接着聊昨晚聊的多端技术选型，今天我们来聊第二篇，说说我是怎么在 Mac 上来开发原生 Windows 软件的，以及我是如何搭建编译、测试环境的，还有最近一个月做 Mole Windows 版踩过的一些有意思的坑。 技术栈上，Mac 版本的 Mole 使用的也是原生的 Swift + SwiftUI，能够让我很好调用系统能力以及非常好的性能体验，想着不将就，所以在 Windows 上我也是想着直接用本身写 Windows 软件最直接的语言， C# 加 WinUI 3，跑在 .NET 10 上，过程虽然难搞，但是相比十年前我了解轮子哥谈的 Windows 开发要简单好理解一些了。 Windows 上的原生界面框架其实挺多的，包括很多年前了解过的 Win32、WinForms、WPF、UWP 这一波，WPF 是 2006 年出的，到现在还在维护，但控件和设计语言不是很好看，非常上一代的感觉，然后 UWP 又被沙盒和应用商店给绑定住，现在微软主推的是 Windows App SDK 里的 WinUI 3，界面框架从系统里面拆出来单独发版，这样就有一个好处，普通的 Win32 程序也能用，基础组件就是 Windows 11 自己的 Fluent 风格，我还挺喜欢，高分屏缩放和 ARM64 都是原生支持。 然后这里 .NET 10 是去年 11 月发的长期支持版本，打包时我把运行时一起打进去，用户不需要另外装 .NET，x64 和 ARM64 这里各出了一个原生安装包，骁龙的 Windows 笔记本就不要走转译了，相当于尽量让用户使用简单不折腾。这里安装和更新用的是开源的 Velopack 框架，可以很方便做增量更新，也很好用。 工程师开始写代码时候肯定会想到能复用尽量复用，所以我开始写的时候也非常想复用 Mac 的 Swift 代码，后面让 AI 分析了一下，十几万行代码 Swift 代码可以脱离 AppKit、SwiftUI 这些系统框架使用的20%都没有，处理的逻辑也是 ~/Library 这类 macOS自己的路径规则，基本用不上，所以 Windows 版几乎是从零开始写的。 两边的关系其实非常简单，外观和交互我尽量完全一致，尽可能让大家意识里面认为的 Windows 软件不那么精致美观的感觉在这里也保持我认为好的水平，然后底层代码各写各的，关于视觉的一致性还原有了AI以后很简单，我把原本的 Mac 版写在 Swift 里的颜色、字号、间距、圆角这些设计 token，直接写了一个脚本生成为 Windows 里面XAML 资源，文案也是从 Mac 的多语言文件转成 Windows 的格式，11 种语言一起转过来，甚至大家看到的菜单栏里面的那个runner动画也是用的同一个脚本同步来的。 虽说同步，可能大家会觉得很简单，其实这里需要花点精力防止 AI 直接给你跑偏了，每次同步其实我会记录对应的是Mac的哪一个提交，这样两边就不会走偏去，然后功能上会有一份 SYNC.md 当做对账表，Mac 每加一个功能、修一个安全问题，Windows 这边都会标清楚哪些是已经实现、哪些是刻意不同还是不适用，以及为什么这样判断。 通过这两个机制，我可以很好的让两边的底层完全各写各的，但是又能很好地保持功能对齐，完全不需要刻意去硬写一层兼容去磨平，反而会变复杂，这里能复用的反而是设计、文案以及踩坑后定下来的各种规则，反而这些是 AI 非常喜欢的“能力抽象层”，也就是说随着时代发展，慢慢所谓的代码抽象没有那么重要了，反而是规则抽象更重要。 另外 Windows 开发还有一块比 Mac 要麻烦不少，就是证书签名，没有签名的，一打开会出现「Windows已保护你的电脑」，甚至 Windows 11 的智能应用控制会直接不让运行，国内不少安全软件也会把没签名的程序当成可疑报毒，这和 Mac 上没签名、没公证的软件提示「已损坏」差不多，平时 Mac 上大家还可以跑一条命令解掉，Windows 上想正规分发，这一步没有啥好办法，就是需要。 调研下来微软的签名生态的确比苹果差太多了，微软有自己的 Azure Artifact Signing，一个月 9.99 美元最省事，居然个人只开放给美国和加拿大的开发者，没办法使用，很奇葩的规定，然后行业还规定从 2023 年起签名私钥必须放在硬件或者云端 HSM 里，不能再是电脑上的一个文件，今年起单张证书最长只能用 460 天，差不多一年多就得换一次证书 最后我买的是 Certum 的云端 OV 证书，3 年 3百多美元，签名时登录电脑上的 SimplySign，再用手机上的 App 给一个动态码，SmartScreen 的信誉也跟着证书上审核过的名字慢慢积累。刚开始一段时间的签名包在 ThinkPad 上也会一样被 SmartScreen 拦了下来，后来我每次发版都把安装包提交到微软的恶意软件分析门户，让信誉慢慢积累起来，而且 SimplySign 的登录会话闲置几个小时就会断开，需要再次输入动态码才能继续签名，所以这里其实很难做成云端自动打包。 证书搞定后，就是开发环境的事情了，我的研发要求是代码和 AI 的上下文必须全留在 Mac 上，Mac 用习惯了，真的很难使用 Windows 去研发，这里 Windows 只负责编译和验证效果和各种测试，所以我在 Mac 上装了 Parallels Desktop，大概 3 百多块一年，之前也挺不少小伙伴吐槽过这个软件，不过在我的 M5 Pro 上跑 Windows 11 还挺顺滑，让我感觉这个钱花得很值。 它最好用的一点是我的 Claude 能很顺手地操作它，仓库直接作为 Parallels 的共享文件夹挂进虚拟机，变成一个 X 盘，Mac 上改完代码，虚拟机里直接编译，不需要来回 Copy 文件，只是两边的编译产物要分到不同的目录，对于编译、启动、看日志的工作都被我写成了脚本，通过 Parallels 自带的 prlctl exec 直接在虚拟机里执行，程序启动就崩的时候 Windows 只给一个 0xc000027b，Mole 会把真正的异常写进日志，脚本跑完顺手打印出来，Claude 直接就能读到。相当于写代码还是在 Mac 上的 Claude Code 里，调试和运行都在虚拟机里，脚本不能解决的地方，直接用 Codex 的 computer use 去点，只有少部分那种系统确定弹框点不了，我在这里就是这个职责，点点系统弹框确定，哈哈。 说到这里，可以和大伙分享一下 Mole Windows的架构分层，一共四层，最底下的 Core 只依赖 .NET，不碰任何 Windows 接口，清理规则、路径安全检查、卸载残留的判断都放到这里，测试用的是一个按 Windows 路径规则模拟出来的内存文件系统，这样在 Mac 上也可以很好的跑；往上是 Platform 层，注册表、文件系统、Win32 调用这些真正的系统接口都放在这一层，打开 EnableWindowsTargeting 以后，Mac 上也能编译通过；再往上就是写过应用同学非常熟悉的界面状态的 ViewModel 层，这里和 Mac 版本会一一对应，这样也能够在 Mac 上测，只有最上面这一层的 WinUI 界面必须去 Windows 里编译。 这也是让我一个月时间可以写8 万多行 Windows 代码、4000 多个测试，但是几乎大部分可以在 Mac 上完成的一个很方便的地方，也是架构设计的巧妙处，当然这里我只提供之前做架构时候的想法建议，大部分是 Opus 5.5 去帮我整的，很牛逼。 接着可以聊测试了，我反而认为 在 AI 时代，工程师最大的价值，除了架构设计外就是这个测试验证了，所以为了保证产品是可以售卖的，肯定需要在真实环境测试验证，反复找体验问题去修复的，所以我整了一台 ThinkPad X1 Carbon，这个机器质感还不错的，我把它当成真机环境，设置永不休眠，可以让我和我的Agent 24 小时去验证测试回归，包括获取各种真实系统环境的参数验证，400 多款 Windows 软件的卸载、残留清理、注册表、启动项测试，大部分在虚拟机里跑，x64 安装包、真实的高分屏、电池、SmartScreen 这些虚拟机看得不准确的，就直接放到这台机器上验，所以这台机器让我感觉也非常值。 然后为了不想在两台机器拷来拷去，最后还是用了 UU 远程，直接在 ThinkPad 那边开一个远程终端，我这边在 Mac 上直接操作，然后还把 ssh 连接当做备用，大部分软件的安装、卸载和调试，都是通过命令行脚本去完成的，剩下需要看界面的，直接通过远程桌面让 computer use 去操作，非常方便，最终相当于我还是在 Mac 上做的所有的事情。 差不多就是这些啦，这个过程下来，到最后成品让几个 Mole 天使用户去试用，大伙用着很爽，感觉这个过程的开发非常值，很有意思，而且可以帮助大家解决不少痛点，加上 Windows 上小白用户应该比 Mac 要多不少，让他们也享受到好软件的体验其实很值得开心。 差不多这两天这两篇文章算是把我这一个月的思考和想法聊完了，欢迎交流，有在做 Windows 开发的小伙伴也可以一起聊聊你们的最佳实践，假如还有空，下一篇我想着给大伙聊聊怎么在研发过程中借其他程序语言的生态来补桌面端的短板，这里也非常有意思。

Perplexity Computer can now run fully local on your Mac. Work with your native Mac apps and local files, and run tasks without sending sensitive data to the cloud. The model and the agent both run on your Mac. Available now in the Perplexity Mac app.

Claude 官方选出了过去几周最让他们眼前一亮的 6 个项目： 从野火分析、手写字体到医学教学，这些作品展示了 Claude 正在如何把想法直接变成可交互的工具。👇 1/用 Opus 5.5 制作的野火分析原型 来自 Dilum Sanjaya

发现不少小伙伴很好奇我是怎么用 Mac 来开发Windows软件的，以及Windows软件现在一般用什么技术栈来实现，刚好有空，来和大伙随便聊聊关于多客户端下技术选择的思考以及我的一些想法。 以下是第一篇，给大伙介绍介绍各种桌面、移动端开发技术的选择以及对应选择的思考。 做过前端客户端的小伙伴应该都知道，这些年端的开发一般是这三条路。 第一种最简单方便的是，直接写 Web 代码，塞到浏览器就能跑，包括早年的 PhoneGap、Cordova 就是把网页塞进一个原生壳里，然后提供一些bridge的能力让js可以调用到一些原生的能力，比如唤起手机摄像头这类的 Web 不好做的事情。 第二种是跨端开发，也就是好多年前大家经常听到的一码多端，当时移动端有 React Native、Weex 这一类技术，当时主要是为了解决 Web 性能差的问题，一份代码同时打包出 iOS 和 Android，这里国内大厂使用跨端技术还有一个非常大的原因就是动态化和热更新，讲的土一点就是可以绕过商店审核直接下发新页面，这也是国内跨端在当时移动互联网高速发展时特别流行的重要原因。 桌面端大家熟悉的就是 Electron，大家熟知的现在不少AI桌面端、VS Code、Slack 是用这个做的，代价是相当于每个应用都自带一份 Chromium 和 Node.js，安装包一百多 MB，内存也占得多。但好处是在 Chromium 渲染引擎的统一下能够很好的保持多端的展示一致性，加上里面写的代码非常好写，后续不少桌面的速成就会用这个技术。 跨端后面也慢慢延伸出更多有趣的解决方案，类似Flutter 自己实现一套渲染引擎，早期靠 Skia，现在换成了自研的 Impeller 渲染引擎来保障多端一致和性能效率的均衡，包括桌面端上老牌的 Qt，和 Flutter 一样自己画界面。 这两年桌面跨端也出现了用 Rust 写的 Tauri、Go 写的 Wails，他们和 Electron 不一样的地方就是，他没有塞一个Chromium进去，而是使用的系统自带的 WebView，包会小非常多，但是整体还是基于 Web 这一套研发思路和对应实现语言去进行桥接交互，但是由于系统 Webview 每个平台不一样，Windows 上是 WebView2，Mac 上是 WKWebView，Linux 上是 WebKitGTK，所以多端显示的一致性反而不如 Electron，还是要写兼容代码。所以这种情况下，即使 Electron 很大内存占用也不低，还是会被选择更多。 第三种是原生开发，也是没有 AI之前，大家觉得开发难度很大的一种方式，特别是之前的苹果系使用的 Objective-C，Android 系使用的 Java、Windows 系 C、C#，均是我认为需要科班花非常多时间去学习、看书、手编代码，要想做得好，需要花大量时间研究对应的系统底层原理，能够方便你写出相比普通研发性能更好更稳定的代码，在我看来是前期投入大，后期用户很享受的技术，我当时17年时候刚工作 2 年多的时候，职业发展比较爽的一个很大原因是我抽了半年时间学习 Objective-C 和 iOS 研发，让我自己本质前端的工作提前往跨端方向走了，刚好可以解决一些这两个工种结合的不能解决的难题，也是我当时做一线开发非常快乐有趣的时间。 等到后面 Swift + SwiftUI、Kotlin + Jetpack Compose、C# + WinUI 3 慢慢出来成熟后，这些原生端语言的写法也慢慢像高级语言靠齐，也更易写了，声明式代码更短、更好读了。但是在国内完全被 React Native、Flutter、Electron 的广泛使用被盖过去了，导致开发者不多，生态发展完全靠官方推动，从而出现了出活很快，但是大家普通感觉怎么用久了卡卡的缘故的一个很大的原因，同时还占大头，而且想迁移到原生假如之前架构实现不好大概率只能重写，完全不能复用，实现得好比如说你把业务逻辑早就抽出，类似 Kotlin Multiplatform 这类方案把业务逻辑共享、界面各写各的原生，算是第四条路，也是最近几年的趋势。 聊到这里大家应该大概明白了，这里也有一个不可能三角，就是研发效率、体验、性能这三者，选择 Web 是多效率少性能，选原生是多性能体验少效率，选跨端就是刚好是这三者取一个中间，做得好容易都占，做得不好，容易没有一边占到好处的尴尬局面。 那么在 AI Coding 写代码已经不是问题的情况下，我们应该选择啥技术呢？很多时候也取决于你的场景，比如你就是一个 Web 场景的浏览、点点按钮、阅读这一类 Web1.0 阶段的东西，那还是非常建议直接 Web 技术来弄；假如你需要调用到系统底层的能力，或者需要操作更顺手更好分发，以及本身就是一个应用的场景，我还是非常建议使用原生技术来实现，这样可以第一时间享受到系统官方本身的众多调优，以及最原生的交互效果、最低的内存占用，加上 AI 让写两份原生代码的成本大幅下降，三角形的效率那一边被补上了，只是两个平台的调试和验证变成了新的成本，这里正是人需要重点做的事情了。 当然假如实在技术选型不那么重要，工作量非常之大，以及业务效果远大于技术体验选择，选择跨端技术也是可以的，这样快，迭代发布也快，可以第一时间让你的用户收到你的最新的特性更新。 不过说到底，技术是给业务服务的，最终还是需要往解决问题方向走，好比抢演唱会门票，大家不会关注你这个客户端怎么这么卡，只会关注我用你能不能抢到票，即使你做得十分顺畅，但是抢不到票也是会被骂得很惨，技术栈的选择在这里就选的好变成了锦上添花的工作，最终还是需要优先保障用户的最真实需求的解决，然后做好这里，再去想，我如何让用户体验更好，接下来才是考虑我是否需要使用原生技术来实现。 一下子居然写了这么多，明天继续来聊，想给大伙来分享我是如何在 Mac 上搭建了一套研发 Windows 原生软件的环境，以及我对于 Windows /Mac 多端研发上的一些踩过的坑以及最佳实践，哈哈，欢迎交流，我们来聊聊不问 AI 自己脑袋里面的技术栈选择，挺有意思。

New DeepSeek just dropped. WorkBuddy Intl is updated to the latest too, and it's free through Oct 31. Take it for a spin.