# 为 Mole 实测几百款 Mac 软件 > 把 Mac 软件一个个装上，再卸掉，查残留，也查哪些文件不该动，记录这段重复但有用的测试过程。 Published: 2026-09-22 这段时间我在做一个蠢事情，或者也是 AI 时代工程师非常不愿意做的事情，非常重复的事。为了让 Mole 的卸载软件更加彻底，清理残余的能力更加厉害，我整理了国内外 300 多款 Mac 软件，下载下来差不多 100 多个 G，分成 30 组，每次 10 个，让 AI 借助 computer use 的能力去官网下载，然后依次安装到我的电脑，检查目录、检查软件更新 bundle、检查自启动、卸载、查找剩余残留、补充缺失的规则。 ## 从 100 个，到 300 个，再到 549 个 当时想着最多搞 100 个主流软件来测试，结果想着要不再搞 100 个，到 200 个的时候，想着再搞 100 个，就到了 300 多个，后来又增加到 549 个，补充了 App Store 版本和扩展插件。对于平时强迫自己把 Mac 控制在 30 个软件的我，一下子变成了下面这个非常凌乱的页面，哈哈给大伙瞅瞅。
测试期间的真实桌面，打开的软件、权限弹窗和工作窗口挤在一起。
测试期间的真实桌面，打开的软件、权限弹窗和工作窗口挤在一起。
这个过程看着非常无聊，每次安装也会碰到不少麻烦的软件，疯狂弹窗要权限，诱导你去购买，有些还必须输入管理密码。Agent 大部分能自己做，少部分我帮一手，让我非常惊喜的是，AI 还基于此写了自动化安装、卸载、检查残余的脚本，让自己工作更轻松，哈哈我就只能给它打打下手。
安装、卸载、检查残留时的一段真实录屏，视频无声，可手动播放。
## 安装完，还只是刚开始 这里最花时间的其实是把一个软件从头到尾走一遍，下载和安装只是开始，后面还有首次打开、权限弹窗、软件更新、自启动，以及卸载以后留下来的东西。只看安装包里的文件，很容易漏掉运行以后才产生的目录；只把 App 从应用程序里删掉，也看不出来它之前放在别处的东西有没有跟着走。 所以每一组软件都要回到这些具体问题上：这个目录是谁创建的，更新用的 helper 属于谁，自启动项还在不在，卸载以后哪些文件留下来了。先把实际路径和归属看清楚，再决定要不要补到 Mole 的规则里，不能因为名字看起来像，就把一串路径都加进去。App Store 版本和官网下载的版本也要分开看，同一个软件的名字相同，不代表安装方式和数据位置相同。 AI 在这里给我的帮助很大，它能一遍遍做这些重复的检查，还会写脚本把已经摸清的步骤串起来，但遇到权限、管理密码和归属不清楚的文件，依然要停下来处理。还好有 AI，不然这件事如果全靠手工，我估计要多花 10 倍的时间。 ## 有些事情只能装一个查一个 这也改变了我的一些固有观点，本来以为软件工程应该是规范的、有秩序的，跑了 100 个软件后，后面应该没什么可以补充的规则了，结果越往后走，发现完全不是这样。通用规则怎么写都找不见的那种非常多，甚至有些 bundle id 干脆就不是反向域名，看着很规范的约定，可能只是当年某个程序员随手写的，只能装一个查一个。 查残留的过程中，也顺手改掉了一些原本以为要清、其实不该动的地方，这件事对我很有帮助。软件自己的缓存、用户留下的文件、几个软件共用的数据，不能因为都出现在一个目录里，就一起当成垃圾，测得更多，也意味着有更多地方需要留下来。 ## 清得更干净，也要知道哪里不该动 在最初那轮 300 多款软件的测试里，补出了 13 类可以复用的通用规则、90 多条精确的清理路径，也顺手改掉了 30 多个原本以为要清、其实不该动的地方，更新检查、自启动检查都有了补充，还为这些补了 100 多条单元测试。这些数字是当时那一轮的记录，后面软件名单还会继续增加。 其中那些不该动的地方，对我来说和新找到的残留一样有价值。缓存可能可以重新生成，用户自己写的文件却不能，几个软件共用的资料也不能只因为卸载了其中一个，就跟着一起清掉；有些文件看着像残留，实际还在被其他软件使用，归属没有弄清楚时，留下来比猜着删更合适。 如果只追求扫描结果里的数字越来越大，这件事反而容易做偏，真正要补的是判断依据。通用规则负责能复用的部分，特殊软件的路径单独确认，已经发现的不该删除的情况用测试留下来，后面再改规则时，才不容易把今天修好的地方又改回去。 ## 无障碍带来的意外帮助 Mole 刚出来的前几个版本就开始支持视障用户，添加了很多无障碍属性，没想到这次也帮了大忙，AI 可以借助这些属性找到准确的元素和按钮位置，测试顺利了不少。之前无心插柳做的事情，后来又反过来帮到了自己，挺有意思的。 无障碍属性提供的不只是一个按钮的位置，还包括它叫什么、是什么控件、现在是什么状态，界面稍微移动以后，脚本也更有机会找到同一个按钮。只有一张截图和几个坐标时，弹窗一变、窗口一挪，就可能点到别处，这也是这次做真实场景测试时，无障碍支持能帮上忙的原因。 不过它首先是给人用的，按钮能被 AI 找到，不等于视障用户就一定能顺利使用，标签说不说得清楚、焦点能不能按顺序走、VoiceOver 能不能读到结果，仍然需要检查。苹果为不同使用方式留下的这些能力，这次让我更能体会到它的价值，考虑到每个人都可以使用，真好。 原本以为测到 100 个，后面就主要是重复，结果做到 300 个、549 个，还在遇到新的细节。以后应该还会继续做下去，把常用软件一个个装过、查过，把实际碰到的问题补回来，或许正是这些看起来无聊的事情，能让 Mole 在用户真正卸载软件的那一刻更可靠。 对于独立开发者同学，开发 App、网页的时候，也可以让 AI Coding 帮忙把无障碍属性补好，一方面让视障用户用起来更方便，另外一方面，也可能让自己的自动化测试更顺利。这个测试我会继续做下去，具体测过哪些软件，放在[实测软件名单](https://mole.fit/zh/tested-apps)里；有希望继续补充的软件，也欢迎到[讨论帖](https://github.com/tw93/Mole/discussions/1604)告诉我。 --- Canonical HTML page: https://mole.fit/zh/blog/testing-mac-apps-one-by-one Blog index for agents: https://mole.fit/zh/blog/llms.txt Site index for agents: https://mole.fit/llms.txt