做一款安静产品的几点思考

Mole for Mac 发布约三周后，刚刚越过一个小小的销售里程碑。我不太想写数字，更想记下沿途做过的几个选择。

它们大多违背一个工程师很自然的冲动，却也是我最愿意坚持的决定。如果你正在做自己的产品，也许其中一些能帮你少绕一段路。

每一封邮件都由我自己回复

从发布到现在，退款、重置激活、活动降价后退回差价，以及普通问题，全部由我手动处理。

数量并不大，主动发邮件的用户远不到百分之一。我完全可以在半小时内接入一个 agent，但没有这样做，原因有两个。

第一，支持是产品向你说真话的地方。退款请求告诉你产品怎样让人失望，一个难以回答的问题告诉你应用哪里没有解释清楚。来回几封邮件之后，才会看到用户真正想要什么，而那经常不是第一句话问的东西。

在第一天就用自动化过滤掉这些对话，会在最需要信号时丢掉它。

第二，亲自处理每个案例会让人变熟练。经历足够多轮后，你会知道每类问题怎样回答最好，也会知道哪些问题应该被产品自身吸收，让以后的人不必再问。

以后数量增长、确实需要自动化时，它应该编码这份已经形成的熟练，而不是编码猜测。

我判断是否自动化，不看工单数量，而看三个条件：问题是否重复，答案是否稳定，例外是否已经理解。在那之前，凌乱的对话就是研究。越过这条线后，自动化可以处理已知路径，同时让特殊情况很容易到达真人。

目前这种方式还有效。我没有花钱做营销，增长来自口碑，退款率低于 0.8%。

支撑系统可以晚一点再建

基础设施也是同一个道理。发布前，我没有搭工单系统、客服平台或知识库。

工程师很喜欢先建设支撑机器，因为这是最熟悉的部分。AI 又把它变成半天就能完成的工作，诱惑更大，却一样可能过早优化。半天的搭建成本是真的，之后长期维护一个还不需要的系统，也是真的。

只有当缺少系统开始造成请求丢失、响应时间不可见，或同一个回答变得不一致时，我才会加入它。在那之前，收件箱更简单，也提供更多信息。

决定什么不做

好产品与普通产品之间的差别，大多来自它拒绝做什么。

哪些功能属于哪个版本，哪些请求是真实需要，哪些只是听起来像需要，哪些想法本身很好，却仍然不属于这款产品。我曾经向提出好建议的用户道歉，因为 Mac 有许多很有趣的技巧，Mole 不应该全部执行。

对所有事情都说好，最后会得到一锅杂烩。杂烩很难维护，也更难让用户放心把文件删除权交给它。

我会在头脑里保留大约半年的产品路径：每个版本增加什么，什么继续不做，以及功能应该放在哪里，让第一次打开的人不看说明也能找到。

如果最常见的第一项任务需要读手册，界面就辜负了我最希望服务的人。文档仍然对深度、边缘情况和信任很重要，但不能用来挽救产品基本结构。那条古老原则说得最好：如无必要，勿增实体。

现在，一个功能进入路线图前要通过三项否决：

1. 除非用户主动进入功能，否则不能增加常驻定时器、监听器或采样成本。
2. 不能为了小小便利扩大特权辅助程序，也不能请求新的系统权限。
3. 存在安静合理的默认值时，不能再增加一项设置。

它们不是适用于所有软件的普遍规则，而是这款产品的预算。常驻工作、特权和配置，都是用户需要永远信任的表面积。

产品的位置

Mole 的位置只有一句话：一位安静的 Mac 管家。

它负责清理、卸载、优化、分析和观察，其他时间不打扰你。目标也很容易说：如果每一百位 Mac 用户中有一位愿意把 Mole 留在电脑里，它就已经足够有用。

最近，一些视障用户开始使用 Mole，也遇到若干不够顺畅的地方，所以无障碍修复被放到新功能前面。我很期待应用最终在他们手里是什么感觉。安静的管家，应该对每个人都安静。

在 AI 时代让产品仍然有人味

AI 让这个产品的很多部分成为可能，但它没有取代与使用者交谈，我也不认为它应该这样做。

如今效率很容易购买，开发者与用户之间的感受和信任，仍要通过一次次真实对话慢慢赢得。也许这正是 AI 构建的产品保留温度的方式：代码可以生成，关系不能。

这是我的第一款付费产品，其中一些判断最后可能会证明是错的。如果你在这条路上走得更久，又看见我正在做一件很傻的事，我很愿意听。

Mole 最初怎样来到这里，是另一个更长的故事：从 500 行 Shell 脚本到一款 Mac 应用。