# 用户教会我怎样做一个更值得信任的 Mac App

> 一次重复购买、温度单位、无法阅读的深色界面和坦率的价格反馈，让我重新理解软件里的信任、本地化、无障碍与支持

Published: 2026-08-16

Mole 从一条 Shell 命令变成 Mac 应用时，我原本以为最难的是界面，真正开始面对普通用户后，才发现更难的是放下自己那些想当然的判断。一位用户不小心买了两次，我提出退回第二笔，他却希望留下来支持产品，一位用户纠正了我按地区选择温度单位的做法，还有一位用户因为看不清固定的深色界面，根本无法使用 Mole，另一次很直接的价格质疑，也让我重新思考，明明已经有免费工具，一款付费应用究竟需要靠什么赢得购买。

这些都不是整理好的功能需求，每次对话只是让我看见，脑海里想象的用户和真正使用产品的人之间有一道缝，而这道缝带来的输入，比多看一张功能对比表或数据图更有用。

## 信任就是功能的一部分

那次重复购买让我记了很久，处理方式并不复杂，钱可以退回去，难的是如何接住这份信任。对方已经付过一次，因为操作失误又买了一次，最后仍愿意把第二笔留下来支持产品，这很温暖，也会让我感觉更有责任把产品做得清楚一点、安全一点。

清理工具比普通软件多一道信任门槛，用户需要相信扫描结果归属正确，不确定的项目不会被默认选中，误删后还有机会恢复。一个漂亮界面承担不了这些承诺，产品需要把计划展示出来，说明为什么跳过某些项目，保护共享数据，在需要恢复空间时使用废纸篓，这些并不是功能之外的售后工作，它们就是功能本身。

这也改变了我看待好评的方式。被夸当然开心，但更有用的问题是，对方把什么事情放心交给了产品，如果答案是「清掉文件，又不让我担心」，下一个版本就应该先让确认和恢复更可靠，而不是再增加一种扫描类别。

## 地区不等于使用习惯

我曾经想当然地认为，美式地区的 Mac 应该用华氏度显示硬件温度，一位用户告诉我，天气和体温会用华氏度，芯片、风扇这类技术场景仍然习惯摄氏度，突然看到一百多度，带来的不是熟悉，而是惊吓。

现在 Mole 在所有地区都默认显示摄氏度，需要时可以明确改成华氏度，代码改动很小，背后的纠正却很重要。地区可以帮助产品决定语言、日期和数字格式，却不能代替用户在每一个专业场景里的习惯。

更稳妥的方式，是先遵循被测对象所在领域的常见做法，再和真实使用这些单位的人确认，如果两种方式都有价值，就保留一次明确选择。根据国家自动猜得越多，看起来越像个性化，也可能离熟悉的体验越远。

## 无障碍从「我无法使用」开始

Mole 已经做了 VoiceOver 标签、焦点顺序、减少动态效果和提高对比度，我一度会觉得，这款产品已经很认真地在做无障碍，直到一位视力不太好的用户告诉我，固定深色界面里的白字很难阅读，他的系统一直使用浅色外观，也只会留下跟随系统外观的应用。

这句话改变了问题的分类，浅色外观不再只是审美偏好，也不是再加一个设置项，对这位用户来说，它决定了应用能不能用。Mole 的主界面今天仍然固定为深色，所以这还是一个没有解决的缺口，而不是一段已经圆满的改进故事。

无障碍不是加够一些标签后就能点亮的徽章，一款产品可以很好地支持 VoiceOver，也可能因为对比度、颜色、动态效果、点击范围或外观决定，让另一位用户无法完成任务。比起问产品是否「支持无障碍」，更有用的是确认谁在哪一种系统设置下，仍然做不了哪件事，具体是哪一层界面挡住了他。

## 价格质疑也是产品研究

有一位用户很直接地说，免费应用也能完成这些事情，这个价格对他来说太高了。最容易做的事情，是解释价格、马上降价，或者继续增加功能，让对比表看起来更长，但这些都没有回答这条反馈里更重要的部分。

免费工具确实能解决许多 Mac 维护问题，开源的 Mole CLI 一直免费，macOS 也自带活动监视器、存储空间、Finder 和废纸篓。付费应用需要靠反复使用时更省心，把散落的信息放到一起，也让永远不会打开终端的人，在操作前看得懂将要发生什么，来赢得自己的位置。如果免费工具已经把一个人的问题解决得很好，诚实地推荐它，比硬找一个理由再卖一款应用更好。

所以这条质疑没有直接变成降价或扩功能，而是变成一道定位检查：哪些人确实会从原生应用里得到足够多的帮助，如果不用它，需要自己拼起哪些工具，这些差异能不能在试用过程中看见。如果这些问题答不好，宣传很难补回来。

## 把故事变成被纠正的假设

每封来信都照原样放进待办，很快就会变得嘈杂，有人想要一个开关，有人希望价格低一点，还有人描述了一次可能再也不会发生的失误，如果把它们都当成功能投票，最有价值的背景反而会消失。

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/feedback-to-product-decision.webp" width="1360" height="454" loading="lazy" alt="用户反馈从无法完成的任务开始，先找到产品里失败的假设，再判断问题是否属于产品，最后成为默认值调整、针对性修复或明确拒绝，而不是把每个请求直接放进待办列表">
  <figcaption>一场有用的对话会先修正产品对用户的理解，再改变路线图，结果可能是新默认值、一次针对性修复，也可能是更清楚地说不。</figcaption>
</figure>

现在处理一场对话时，我会尽量带走四件事：对方原本想完成什么，产品里的哪一个假设错了，这个问题影响的是一类人还是一台机器，更好的默认值能否解决，还是需要一次明确修复，或者产品应该解释为什么不接下这项请求。

这样做比统计需求数量慢，却会少留下不少设置项和半成品。温度单位纠正了默认值，外观反馈暴露了还没完成的无障碍工作，价格质疑讲清了免费 CLI 和付费应用的边界，重复购买不需要任何新功能，只是让我重新看见，一款被允许接触个人文件的产品，需要承担怎样的认真。

## 让对话多走一会儿

我现在仍然自己处理支持，因为早期对话很少能在第一封邮件里整理清楚，开始问的是授权，真正的问题可能是设备数量的说明不够明白，退款背后可能是官网承诺没说清楚，看起来在要设置项，也可能说明默认值对所有人都不够好。

只有当一个问题反复出现，答案已经稳定，例外也被理解，自动化才真正有用，在那之前，过早缩短对话，很容易顺手删掉那个本来可以改进产品的细节，关于这条边界，我在[怎样做一款安静的产品](https://mole.fit/zh/blog/notes-on-building-a-quiet-product)里写过更多。

这些判断我仍然会做错，温度默认值已经改好，固定深色外观还没有，有些反馈最后会变成代码，有些会变成产品边界，也有一些会留下尚未完成的责任。有价值的部分并不是答应每一个人，而是每次聊完，都能更准确地理解谁在使用产品，以及他凭什么愿意信任它。

Mole 从私人脚本走到今天的过程，写在[从 Shell 脚本到 Mac 应用](https://mole.fit/zh/blog/the-story-of-mole)里，确认后再删除、保护路径和可恢复操作背后的取舍，则写在[让 Mole 安静地待在一边](https://mole.fit/zh/blog/the-design-of-mole)里。

---

Canonical HTML page: https://mole.fit/zh/blog/what-mac-users-taught-me
Blog index for agents: https://mole.fit/zh/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
