204 个工具。两年多时间。从最简单的文本去重，到复杂的 PDF 转换，从 JSON 格式化到图片压缩，我做了一个工具站，里面塞满了各种"我觉得有用"的小工具。
很多人问我："你是怎么做到 204 个的？" 答案是：我没有去"做"204 个工具，我只是在修复自己做错的 204 次。
每一个工具背后，都有一段决策失误、用户反馈、数据打脸的历史。这篇文章，我想分享我从这些错误中学到的最重要的五条产品教训。如果你也在做产品，或者计划做产品，我希望这些教训能帮你少走一些弯路。
教训一：用户要的不是工具，是结果
我最早做的一个工具是一个"JSON 格式化器"。功能很简单：用户粘贴 JSON 字符串，点击格式化，输出整齐的结果。
我花了很多时间优化这个工具：支持缩进自定义、支持彩色高亮、支持折叠节点、支持导出……我甚至加了一个"树形视图"的功能，让用户可以用树状结构浏览 JSON。
结果呢？使用率最高的功能始终是"粘贴 + 格式化"。其他功能几乎没人用。
但更让我意外的是，有用户给我发邮件说："你的工具很好用，但我真正需要的是在格式化之后，能直接复制粘贴到代码里。"
我恍然大悟：用户打开 JSON 格式化器，不是为了"格式化 JSON"——他们是在调试代码，他们需要的是"能让不规范的 JSON 数据变成可读的格式，然后复制到代码里继续工作"。格式化只是这个任务中的一个步骤，不是终点。
从那以后，我给每个工具加了一个"一键复制"按钮。这个按钮的使用率，比所有其他功能加起来都高。
用户想要的从来不是工具本身，而是工具帮他们完成的结果。你的工具只是一个中间步骤，不要让用户觉得他们需要"学习使用你的工具"——他们只想拿到结果就走。
教训二：界面越简单，用户越信任
我做过一个"在线图片压缩"工具。第一版的设计包含了大量参数：压缩质量、输出格式、是否保留 EXIF 信息、是否缩放尺寸…… 我觉得这些参数很专业，用户会喜欢。
实际上，用户打开页面，看到这么多选项，他们不敢用了。他们担心自己设置错了参数，压缩出来的图片不能用。
后来我把这些参数全部隐藏，只保留一个"拖拽图片 → 自动压缩 → 下载"。用户打开页面，把图片拖进去，等 2 秒，下载。
这个改动之后，工具的使用率翻了 3 倍。更关键的是，用户在压缩完成后，不再反复检查压缩结果了。他们信任这个工具会做出正确的选择。
我意识到：界面上的每一个选项，都是一次信任的考验。用户每看到一个选项，心里都会想："这个选项意味着什么？我选错了会怎样？" 选项越多，不确定性越大，信任感越低。
简单不是简陋，简单是替用户承担决策的焦虑。
教训三：做少比做多难
204 个工具听起来很多，对吧？但回头看，如果让我重新选择，我会做 20 个工具，把它们做到极致。
在做了 100 多个工具之后，我陷入了一个奇怪的循环：用户反馈说"能加个 XXX 功能吗"，我就去加。但加了之后，下一个用户又反馈说"能不能加个 YYY 功能"。我越做越多，每个工具都越来越臃肿，但没有任何一个工具能让用户觉得"这就是我想要的"。
直到有一天，我删掉了 30 个几乎没人用的工具。删掉它们之后，整体流量不但没有下降，反而上升了。原因是：用户不需要翻 30 个无聊的工具才能找到他们真正需要的那个。
做 204 个工具很容易——你只需要不断地"加"。但做 20 个真正有价值的工具，需要你不断地思考和判断，不断地拒绝。拒绝用户的需求，拒绝自己的想法，拒绝那些"看起来很不错"的方向。
做多是加法，做少是乘法。加法的天花板是线性的，乘法的天花板是指数的。
教训四：文档比功能重要
这个教训来自一个让我特别尴尬的反馈。
我做过一个"正则表达式测试工具"。功能本身不复杂，但我在页面上写了一句"支持所有正则语法"。然后有用户发邮件说："你写'支持所有正则语法'，但我在 JavaScript 里能用的语法，在你这儿用不了。你骗人。"
我一看，确实——我的工具用的是浏览器的正则引擎，和 JavaScript 原生正则完全一致，但用户在其他语言（比如 Python 或 Java）里用的正则语法，有些细微差别。
问题不在于我的工具"不支持"——问题在于我没有告诉用户"支持什么、不支持什么"。用户不是因为功能不好用而离开，而是因为我在文档里写了不准确的信息，让他们产生了错误的预期。
从那以后，我给每个工具写了三样东西：支持什么、不支持什么、常见用法示例。这三样东西，比功能本身更影响用户对你的看法。
一个功能有缺陷，用户可以接受。但文档不准确，用户会觉得被欺骗了。功能是骨骼，文档是神经——骨骼可以不够强壮，但神经一旦出问题，整个体验都会瘫痪。
教训五：数据比直觉可靠
我做工具的第二年，已经积累了不少数据。我开始分析用户行为，发现了一个让我震惊的事实：我凭直觉"觉得会火"的工具，只有 20% 真正获得了用户的使用。而我"觉得一般般"的工具，反而有 60% 成为了稳定的流量来源。
最典型的例子是一个"颜色转换工具"——把 HEX 颜色值转换成 RGB 或 HSL。我当初做这个工具，只是因为自己需要，顺手就做了。当时我觉得它太简单了，不值得认真推广。
结果它成了我工具站上最稳定的流量来源之一。为什么？因为全网有大量前端开发者在 Google 上搜索"hex to rgb"、"rgb to hsl"这样的关键词。这个工具天然匹配了他们的搜索意图。
而我自己觉得"一定会火"的一个"番茄钟工具"，花了我两周时间，加了各种定制选项，结果上线后几乎没人用。不是因为它不好，而是因为番茄钟工具的市场竞争太激烈了，用户没有理由在我的工具站上用一个番茄钟，而不是去用他们手机里已经装好的 App。
这个教训让我养成了一个习惯：在做任何新工具之前，先看数据。看搜索量、看竞品情况、看用户真实在找什么。数据不撒谎，但直觉经常撒谎。
总结：错误是最好的老师
204 个工具，204 次错误的集合。但正是这些错误，让我理解了产品设计中最核心的几个原则：
- 用户要结果，不是要工具
- 简单是信任的基础
- 做少比做多更需要勇气
- 文档的准确性比功能的丰富性更重要
- 数据比直觉可靠
如果你也在做产品，我的建议是：不要怕犯错，但要确保每次犯错都能学到东西。最好的产品经理，不是那个从不犯错的人，而是那个犯错之后能最快修正的人。
204 个工具教会我的，不是"怎么做对"，而是"怎么做不会错"。这两者之间的差距，就是成长。