太长不读 在代码没啥壁垒的年代，我们需要多做一点不可扩展的事情来让自己的产品形成一些自己的特色。 好比大模型把所有产品默认加到 60，也即之前我们认为的及格等于现在的 0 分。

假如把我的 AI Coding 经验沉淀成一些最佳实践规则，可以给到大伙复用，会是怎么样的，于是乎，今天一下午我就在琢磨这个事情，手写反复调整后给到大伙，可以让你和你的 Agent 一起去学习。 需求 1. 从技术实现细节编程转变成许愿式编程，现在模型能力已经住足够强大，你只需要大胆把自己想法说出来，给它提足够高的要求和任务，不要担心 AI 实现不了。 2. 多给你的 Agent 讲做这件事情的背景和目标，少替他考虑技术细节，告诉它为什么要做，是给谁用的，做成什么样子你认为是最好的，具体的技术细节让它自己去判断，学会放手。 3. 优先用业界最好的模型，用差模型浪费的时候，一来回让你很不高兴的干活，二来也浪费了很多时间。 4. 要不要做一个新功能以及加一个新配置、开关的时候，让 Agent 来先问你找你确定，没有人用的功能、开关、文案都不要让他去加，慢慢把这一套你的产品规范让他沉淀起来。 5. 你的想法可以很大，但是让 Agent 干活的时候，尽量让他每次拆分成最小的可用功能版本，不要一次写非常多的代码，即使提交，这样出问题了你可以随时撤回。 规则 6. 让你的 Agent 了解你的说话风格，比如说看看、分析一下这个问题的时候，它只需要去读代码分析问题不要去改代码，你说修复、修改的时候才去动手，每次提交、发布和删除的时候都找你确定。 7. Agent md、CLAUDE md 里面除去重点的项目型要求外，只写代码里面看不出来的那种规则，以及之前被否决过的方案也可以分流进去。对你而言密钥和 token 不要贴给 Agent，贴了就当已经泄露了，立马去更换一个。 8. 对于Agent必须遵守的规则不要完全信 prompt，可能会拦不住，一定要用规则脚本去限制，让它真实跑一遍通过后才算完成了。 编码 9. 开始写代码之前，先让 Agent 讲清楚要改什么地方，会影响到什么功能和效果，这样是为了补充你的上下文，方便后面更好判断决策做什么。 10. 一定要让 Agent 基于项目补充一个能够让自己验证各种结果的脚本，每次特定的时候需要去跑一下验证效果，完成功能后需要检查，让他输出结果给你看，并基于此逐步沉淀你的项目 Agent 测试功能集。 11. 假如有多个 Agent 同时干活的时候，让他们各自用一份独立的 worktree 代码目录，同时提交的时候只提交自己改的代码，不要碰他人的代码，等到各自改完合到一起，再完整跑一遍测试。 排查 12. 修 Bug 的时候先找到原因再去动手，假如两次都没有修好，就去加一些日志看真实的数据以及运行效果，不要盲目去猜问题在哪儿。 13. 假如尝试修复了3次还不对，直接清空上下文重新写清楚你的问题、诉求，以及尝试过的解法让 Agent 重新开始。 审查 14. 让写代码的 Agent 和 Review 审查代码的 Agent 分开，保持解耦，这样一方不会被另一方带偏。 15. Review 代码的时候最多让 Agent 跑 3轮，防止跑着停不下来，第二轮开始只看新改动的地方，不要再把之前 Review 的再看一遍。 16. 对于你和 Agent 判断危险的改动，越危险让他查得越深，特别对于删除、付费、发布这种单向门改动你都需要自己去看一遍，点一下，看实际效果。 发布 17. 每次提交的时候，让Agent 写清楚做了什么，怎么去验证这个改动，除了问题怎么来回滚，用于给到后面开发过程中 git 记录本身就是 Agent 的一个非常好的上下文。 18. 需要对外的功能，可以先给自己用，或者给一批愿意尝鲜的用户使用，不要一上来就全量，可以在你的软件里面假如 beta 更新的开关，防止全量有问题，也是对用户负责。 18. 先给自己和愿意尝鲜的人用，没问题再发给所有人。 复盘 19. Agent 需要对每一个线上 Bug 和用户反馈的问题都留一个测试案例，每次上线前都来跑一遍，防止继续踩坑，包括你换模型的时候也可以把这些旧问题全部都跑一遍，看看模型是否还行。 20. 修复问题的时候，让 Agent 学会举一反三，把同类的问题一起修复掉。优化功能的功能，完善视觉的时候也是一样，防止只改一个地方，忘记了其他的地方。

书接上回，接着聊昨晚聊的多端技术选型，今天我们来聊第二篇，说说我是怎么在 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 开发的小伙伴也可以一起聊聊你们的最佳实践，假如还有空，下一篇我想着给大伙聊聊怎么在研发过程中借其他程序语言的生态来补桌面端的短板，这里也非常有意思。

发现不少小伙伴很好奇我是怎么用 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 自己脑袋里面的技术栈选择，挺有意思。

教大家如何享受纯净舒服的推特时间线，不错过你的好友的高质量信息流。 给到 Grok Bot 的提示词大概是这样，大伙也可以玩玩。 每天晚上8点，帮我整理今天中文推特圈的精选 来源是我关注的中文账号，加上你觉得不错的中文账号。只用 X 官方 API 读帖子，跟前一天去重。 排版： - 开头放「今日主线」，3 条短句 - 每个人单独一节，写上名字和 @，节和节之间加分隔线 - 每节 2 到 4 条要点，格式是「加粗主题：内容 + 原帖链接」，每条写两到四句，讲清楚他说了什么、关键细节和背景 - 每节最后用一句话写你的看法 - 零碎工具放到最后的「小工具」一节 - 大约 10 到 15 节，不写破折号，少用句号，不要有 AI 腔，简单清晰就好 然后我每天就可以收到这个非常有用的消息了，让我少刷推特，更加专注一点。

最近给我每天都在使用的工程师合集技能 Waza 加上了一个很有用的操作以及回复规则，来源于 ASD-STE00，一套最开始用于航空维修文档的简化技术英文标准。 最开始是看到 Andrej Karpathy 的推荐，让大模型参考这一套规范来解释事情，回复会更加易读，刚好晚上有空，我顺着看了看规范和官方的 AI 白皮书，发现它对于词语、条件、和操作顺序的要求，真的非常适合拿来检查 AI 到底有没有把话讲明白讲清楚，想着基于我的理解给大伙更好懂的解释一下。 可以理解飞机维修手册其实面向阅读的人来源于各个国家，英文不一定是对方的母语，比如说修飞机的时候，拆哪一个零件、什么时候可以操作、前一步做到什么地步才可以继续做下一个步骤，是不是感觉非常像现在我们让 Agent 去做一些事情，我们也是想着尽可能 Agent 非常准确快速的做好，并把我们的诉求理解到位。刚好就和这个飞机维修手册上的说话操作规范非常像。 很多时候，一个词语换一个意思，一句话里面漏掉一个条件，面对说明书操作的人可能会做成不同的操作。好比大公司里面，CEO 的想法是经过多轮传递，很容易会导致很多信息失真，最后做出来的东西可能会当时想的完全不一样。 这套标准从我的理解正是用来解决这种说话和执行偏差的问题，它由协作规则和词典组成，词典会限制一个词可以用什么词性、表达什么含义，包括这个行业里面的哪些技术属于可以允许使用。同一个东西也不会为了避免重复就换一个名字去做，操作的步骤会需要写清楚条件和顺序等等这样的要求，其实这些放到技术文档里面也非常好理解。 我在 Waza 里面为了让 AI 更好理解，比如说在 write 写作技能里面我放了这样的例子，让 AI 写出来的内容更加清晰明白。 比如“上传完成后，删除本地文件”，如何被 AI 简化成“开始上传，然后删除本地文件”，会很容易出问题，可能文件还没有传完就被删除掉了，这里的“完成”就是决定了什么时候能删除，是必须存在的词。 再比如“只有检查通过，才允许重启” 和 “检查通过后就重启”，前一句就符合这个要求，后一句没有执行要求的动作容易多出很多可能，“才允许”在这里就是那个保持原意的关键词。 这正是我希望 AI 在日常回复和帮我干活时候要注意的地方，把做的结果讲明白、讲清楚，让它和我都不困惑不懵逼，说到点上，不要我再去多问一句更多的才好。比如说代码改好了、测试通过了、已经推送了、用户可以下载了都是对于结果的详细表述，假如它只回一句“已经修复并验证”，这种情况下，我肯定会继续问，到底解决了啥都好了没。 不过我认为，这里没有必要让 AI 去完整参考所有的标准，归纳起来的规则其实非常短，「同一个对象保持同一个名称，指代不清时写明对象，把条件和例外放在对应动作附近，保留先后关系，分清建议、要求和可能性。已经清楚的话就不改，不要为了简短删掉原因和边界。」 当然你也可以直接安装 Waza 的 clarity 规则来使用，或者直接去这里看看。

看到任何 Claude 的奖励、问卷、邮件，建议不要点击、不要点击、不要点击，比如这个 250 刀的云额度，不要去点击，这家公司虽然模型非常厉害，但是行为可能不那么正派。

收尾一下，最终 Mole 1.15 已上线，欢迎小伙伴去升级，最终测试了 709 款软件，包括特别难卸载的 Adobe 系列，以及各种带牛皮癣的 App，还有杀毒软件，以及我们工程师经常用的大部分软件，各种 AI 工具，也体验了一些值得学习的好软件，下一期我正确做到 1000 个自测软件。

今天终于把拖了很久的事情，放到一天给做了，我把 Mole 从开售到9月底所有没有激活的用户全部发送了一封邮件，这个过程挺有感触，顺便又做了一个有趣小魔法功能。 用 AI 写了一个简单的本地脚本把用户邮箱、Key 给列了，然后一封一封根据月份、国家语言把 license key 重新发了出去，不是促销邮件，也不是催促激活，更多就是发一个微信一样告诉用户不要忘记了。 有意思的是，陆陆续续收到了非常多各个国家用户的回信，比我预想的要有意义很多。 有用户说买来就是想支持你的开发，自己更喜欢用 terminal 版本；还有人完全忘记了 GUI，一直在使用 CLI； 也有用户非常用心，买了两个，一个给自己，一个给家人，打算当圣诞节礼物，没有没有激活，已经存到了自己的密码管理器，让我这个世界真美好。 也有用户最开始公司的电脑可以用，但是由于对未在公司范围的软件进行的禁止使用，他一直在等他自己的新 Mac，等新 Mac 到了他就可以用了；也有用户是在我打折的时候买的，现在还没有 MacBook，等自己新机到手就立马去激活。 不过其中有一些用户其实是邮箱填写错了,可能是打太快了，把邮箱写成了 gmai、con、cloud 这一类 ，也没有找我；也有用户是第一封邮件没有收到，想着更快使用又继续买了一遍。 虽然这里没有收到激活码的用户占总用户比例非常小，也有不少在每日的答疑邮件中帮忙解决了，可能对于不少做 App 售卖的公司而言，会认为收到钱以后这段关系就结束了，不过对于Mole而言，我感觉才刚刚开始，后续和用户持续共建可以做非常多有趣的事情。 用户买到软件以后，也不一定会里面用，并不是我们开发者自己想的「看到->买->立马用」，其实也有是随手买一个，key 进来收件箱，想到了再去用，或者付钱但没有收到 key，这里好比有一段购买到真正使用的空白在开发者和用户之间的，有不少用户会主动往前一步找开发者问我的key呢，但是也有部分用户没有迈出这一步，对于这种情况，开发者应该多迈出去。 做产品的人，特别是工程师出身的，非常用于在产品功能上较劲，疯狂开发功能，很容易忽视从购买流程数据去看用户的真实使用，真实体验，以及围绕非产品功能的体验去做优化，这也是和用户交流的一个非常好的场景和渠道，真实的交流很重要，也会让你对自己做的产品更有成就感。 程序员天然会喜欢做可扩展的事情，任何事情想着尽可能工具化、自动化、AI 化来解决，让自己“偷懒”，但是我反而认为在这个代码没有啥壁垒的年代，我们可以多做一点不可扩展的事情，只有自己手动去走一遍才知道如何更好的优化用户体验，单纯想其实想不出出来的。 所以我会在下一个 Mole 的版本上线一个有意思的功能，用户付款结束后，会自动跳到 Mole 官网的一个激活 key 的页面，当然支付平台也会同步发送邮件给用户，由于有这个激活页面，即使用户邮件填错了，即使是被用户邮箱拦截了，用户会第一时间在购买后看到，我还做了一个有意思的功能，用户在网页上点击激活，我会一键把 Mole 客户端唤起来，自动的在许可证激活页面填充这个 Key，用户啥也不用干，点下确定按钮就好了。 对于写过客户端和前端的工程师可能会认为这个唤起填充技术实现其实很简单，但是会对我们大部分用户会感觉卧槽、神奇、魔法、让我好简单，这个产品帮我多做了些事情。 或者这是我做产品非常追求的一个点，就是多做一些有趣的功能让用户感觉到这类”魔法”，也是一直想追求的黑客与画家的那种工程师的感觉。

马上 Mole App 就可以帮助大家清理和维护 AI 工具在本地产生的东西了。 利用这个假期，想着继续给大伙上一个 Mole 有用的功能，帮大家清理不再需要的 AI 缓存、旧会话和 worktree，卸载之前装过、很久没有用的 AI 工具。 起源于之前一段时间，我一直在测试 700 多款软件的卸载清理残留，确保能够彻底清理各种你电脑上的垃圾，想着借助这个过程，加上之前非常多的小伙伴提过的 AI 垃圾清理诉求，当时这些“垃圾”在我看来是有用的，比如你的全部 AI Coding 会话记录，我认为是非常重要的资产，所以这一块之前更多只是支持清理真正的缓存和旧版本。 不过随着 AI 的使用，我本地机器也有非常多没有那么大用的 AI 产物、会话以及 worktree 一直留在本地，还是非常有必要做这个事情，于是就开始弄了，我测试了 30 多款 AI 软件，包括之前一直不愿意下载的国内 AI 工具，以及各种命令行工具，全部装到我的电脑，登录账号，进行真实使用测试产生会话，然后去找垃圾、对话、缓存、worktree、临时文件、安装位置等信息，记录在案，整理到 Mole 里让大家可以更好地清理维护，差不多完工了，当前在 Preview 版本，还需要继续测试，下一个版本再放出来给大伙使用。 这个过程也发现了，还是 Claude、Codex、Cursor 这类产品在克制上保持得比较好，也是我常用的 3 个，测试过程中发现了非常多软件的乱象，比如下载安装包的时候，默认在你的剪贴板写一点东西，用于跟踪安装渠道、做数据统计，这种我感觉有点过了，也有安装后，给你弹窗让你去做活动获取 Token 的，牛皮癣满天飞，有一种捏着鼻子用的感觉；甚至还有软件一启动就是 41 个进程，占用高达 4.49 GB，非常卡顿难用，还是大公司做的也搞不懂。但是整个过程中让我感觉不错的是居然 Qoder，保持住了自己的克制，审美在线，没有乱来，产品上挺让人惊讶，期待国产多一些这样的软件，加油加油。 加上之前测试那 700 多款软件的过程，发现了还是有不少软件没有遵守住一些软件工程开发的基本原则，也没有大家想的那么专业、纯净。更加让我想着 Mole 一定要保持住现有的简洁、把能力做深、不乱搞、不乱获取不该获取的东西，不上传用户的本地文件和会话内容，甚至任何使用统计都不加，唯一使用网络地方只有更新检查和软件激活这两块，继续保持强迫症的方式走下去应该会更加长远。 最后，大伙有任何对于 AI 清理和维护的诉求，欢迎告诉我，我给放到测试里面去做，确认适合清理的就加到这个功能里面去，这一块应该会持续迭代维护很长时间。

继续补两家 一家是黄氏椰子鸡，非常非常好吃鸡肉很嫩，我喜欢他们家蘸料加一点黄灯椒，芋头放里面也好吃 还有一家是海南东方烤乳猪，吃过的最好吃的烤乳猪，非常香，还有酸辣蟹也非常好吃。 此外一定要试试陵水的炒冰，用水果加奶还有冰做的，很好吃！

果然，听劝非常有用，很多时候用户的反馈非常重要，于是我又优化了版本图标，非常感谢提建议小伙伴。 之前有几个图标我自己觉得挺好，小伙伴却觉得不够好看或者不太习惯，我都继续优化了一个版本，比如「检查更新」之前用了一个下载的图标，被读成了下载，GPU 的小方块看不出是显卡，压缩包的图标看不懂，两根叠在一起的内存条也不太像内存，还有人说清洁屏幕的海绵和关于的挥手看不懂，仔细想了想，的确会有点看不懂，图标第一用意应该是表意，而非装饰。 于是这几个都按大家的建议又改了一轮，检查更新换成了顺时针的箭头，GPU 画成了双风扇的显卡，压缩包换成了归档盒，音频从音符换成了耳机，清洁屏幕回到了最早系统图标那把刷子的意思，关于最后还是换回了最正统的 ⓘ，只是按整列的线宽重新画了一遍，内存也回到了芯片，其中不少前前后后改了三次，很有趣，最后终于更舒服一点了。 欢迎小伙伴们继续建议，很有用，一起交流学习挺好！

想给大伙随便聊聊如何给产品进行一次图标升级，有哪些需要注意的以及可以优化的点。 早上给 Mole 的图标进行了一次精细化的升级，之前使用的是系统的图标，对于简单的产品场景我感觉完全够用，不过细看会感觉缺少一点灵性的感觉。 经过调研，比较适合做 App 产品 Icon 的有 Remix Icon 和 Phosphor Icon这两个，之前写 Web 的时候用 Remix 很多，简单舒服，但是放到 App 上我感觉不是很好看，于是就换上了 Phosphor 这个，展示效果很有灵性，非常不错，差不多有 70% 左右，可以不修改直接使用，然后有 30% 的图标是我用 opus 5.5 来写SVG 自绘的，这样整体更加一致。 可能大伙直接看下面的对比图很难感觉到两者的区别，很多时候需要实际放到真实的产品里面去，我一般还会考虑到本身这个模块下一组图标的搭配感，有时候全部图标单个都好看，组合到一起就不好看的情况也有，好比一个人每一个五官单独出来都好看，但是放到一个脸上却不那么好看，这里建议就是图标的根更换你一定要放到实际的产品里面去看，放到一起去看，才会有比较好的效果。 其次，我一直想着，我们做的产品应该是有灵性的，有生命的那种感觉，而非直接 AICoding 不经任何你的思考出来的那种冷冰冰的编译产物，这个时候小细节比如icon会是给这个产品带来生命力的一个很好的切入点，比如大伙看 保持常亮我使用的是 一杯咖啡，这里会有一种 Caffeine 比喻，就是让你的电脑好像喝了咖啡一样睡不着的感觉，然后关于一般会用一个感叹号，但是我想着应该是 hello，所以就用的挥手的标志，诊断正常会有排查的那种标志，但是这里使用的是一个听诊器的标志，更像是给你的问题做一次医生检查，类似这样，很多时候，可以在产品里面加入不少你的小巧思，会让整体有趣很多。 最后，好看的设计几乎都离不开对齐、整齐、错落有致这些原则，如何在人眼看到的场景下让图标和内容以及上下模块看起来是整齐的、大小一致的，甚至是上下居中对齐的，都需要一个一个去看，去调整，包括字体和icon的对齐，以及字体里面中英文本身也没有垂直对齐应该如何优化，类似这样的，可以精雕细琢很久，非常有意思。 这种看似无用功，其实是我很喜欢做的事情，AI 可以给优秀编码、及格审美带来非常大的促进，人看着好像不要做啥了，只要动动嘴就好，反而我认为不是的，人在这里的作用更大了，AI 帮你节约的时间，刚好可以放到打磨产品上，让1%的用户有种用你产品的时候，时不时有一种秒懂、卧槽、变魔术的感觉，那就非常非常有价值和意思了，或许这也是我认为做独立产品有意思的地方。

正在使用 Mole 的小伙伴，一定不要错过菜单栏的 Runner的这个设置，里面有非常多的小动物，我最喜欢阿龙和阿鸡，还有阿鱼，非常感谢 Runcat Neo Apache开源项目提供的能力！

在陵水找到了一家非常好吃的酸粉 看着非常苍蝇馆子 甚至碗都是塑料袋套起来了 但是味道一绝，酸粉、虾饼、清凉补都很不错 下次小伙伴去陵水玩可以试试这家亚毛酸粉，很有海南特色

发现不少小伙伴对 Mole 的菜单栏有诉求，一早起来我进行了一版优化。大伙可以看一看。 因为平时我只展示 Runner 动画，其他的都不展示，对于菜单栏有强迫症的用户，或者有显示指标诉求的用户欢迎给我提各种建议，非常需要，放到下一个版本上线。

去年的刚好的这个时候，Mole Cli 开源版本诞生于三亚的一个泳池边，当时 Mac 在泳池边上的躺椅上，游一圈刚好一个对话。 今年国庆假期的这个时候，Mole Windows 版本诞生于陵水酒店的泳池边，不过 Mac 在房间书桌上，那个会话应该还在跑，现在游玩刚好一个会话结束。

重新给新朋友介绍一下我过年期间做的 Kaku，一个安装后无需配置就可以使用的 Mac 终端，对于 AICoding 友好，性能体验均不错，结合我自己的编程习惯做了不少顺手的优化，也是我做过的最复杂的一个项目，开源持续至今迭代 21 个版本，保持 0 issue 问题，欢迎体验。

收尾一下，最终 Mole 1.15 已上线，欢迎小伙伴去升级，最终测试了 709 款软件，包括特别难卸载的 Adobe 系列，以及各种带牛皮癣的 App，还有杀毒软件，以及我们工程师经常用的大部分软件，各种 AI 工具，也体验了一些值得学习的好软件，下一期我正确做到 1000 个自测软件。