每天都有人用 MeTool，但我不知道他们真正想要什么

每天都有不少人打开 MeTool，用完一个工具，再关掉页面。

我能在 GA4 里看到访问量、停留时间和按钮点击，也能在 Clarity 里分析用户的交互行为、什么时候离开。数据越来越多，但我一直有一种不踏实的感觉：我看见了用户做什么，却不知道他们在想什么。

某个按钮没人点，是因为位置不明显，还是这个功能根本不重要？用户处理到一半离开，是遇到了错误，还是发现缺少关键能力？一个工具每天都有人用，他们最希望我下一步优化什么？

这些问题，单靠行为数据只能猜。

所以我给 MeTool 做了一个公开需求广场。我想试试另一种产品开发方式：让用户直接说出想要什么，让其他人补充和投票，再由我和 AI 一起把其中真正有价值的需求做出来。

数据告诉我发生了什么，却不一定告诉我为什么

之前我写过，自己开始用搜索词和行为数据决定 MeTool 下一步做什么。这比纯靠直觉可靠得多。

搜索数据能告诉我哪些问题有人在找，行为数据能告诉我页面上发生了什么。它们很适合发现信号，例如某类工具有自然流量、某一步流失异常、某个按钮几乎没人用。

但它们天然缺少一块：用户没有说出口的上下文。

一个退出动作背后，可能是功能不够，也可能是任务已经完成；一次重复点击，可能是按钮没有响应，也可能是用户不理解结果。即使录屏把操作过程完整还原，我仍然需要替用户解释动机。

这不是分析工具做得不够好，而是观察行为与表达需求本来就是两种信息。

我不打算放弃数据。相反，我想把两种信息接起来：

1. 行为数据负责发现异常和验证结果。
2. 用户反馈负责解释原因、补充场景和提出期待。
3. 投票与讨论帮助判断这是一个人的偏好，还是一群人的共同问题。

数据让我少拍脑袋，直接反馈让我少猜。

我不想再做一个反馈邮箱

最简单的做法，是在页脚放一个表单。用户提交，我在后台收到一条消息。

但这种方式对用户几乎是黑箱：建议有没有人看、其他人是否也需要、最后为什么做或不做，都不知道。对我来说，它也只是把散落在邮件、私信和评论区里的信息换了一个收件箱，并没有形成真正的产品闭环。

所以这次我把反馈做成了一个公开广场，而不是私密工单：

• 用户可以针对具体工具提交标题、详细说明和图片。
• 其他人可以投票，告诉我“这个问题我也遇到了”。
• 大家可以在详情页继续讨论，把一句模糊想法补成真实使用场景。
• 每条需求都有公开状态：新讨论、已采纳、开发中、已完成或暂不考虑。
• 关注者能看到状态变化，需求不会提交之后就石沉大海。

这里最重要的不是多了几个按钮，而是信息关系变了。以前是一位用户单独告诉开发者；现在是一个想法被放到公共空间里，经由其他用户补充、验证和推动。

投票也不是命令。票数高说明问题有共性，但我仍要判断它是否符合 MeTool 的定位、能否在浏览器端可靠完成、会不会引入过高的维护或安全成本。做不了的需求，我也希望明确标成“暂不考虑”，而不是假装没有看见。

AI 让“听见需求”这件事开始值得做

过去，公开收集更多需求也可能带来另一种压力：听见了，却没有能力及时实现。

需求整理、方案拆解、编码、测试和上线，每一步都需要时间。对独立开发者来说，反馈越多，待办列表可能越长。最后用户得到一句“感谢建议”，开发者得到一座越来越高的需求债务。

AI 改变的是这笔账。

现在拿到一条描述完整的需求后，我可以让 AI 帮我梳理真实痛点、检查现有代码、比较实现方案、完成初版代码，再补上测试和边界检查。以前可能因为开发成本太高而一直搁置的小改进，现在更容易快速验证。

但页面里的“AI 实现”不是说我把产品决策交给一个无人值守的机器人。当前的真实流程是：

1. 用户提出需求，其他人投票和讨论。
2. 我判断它解决的是不是一个真实问题，是否适合 MeTool。
3. AI 协助分析需求、编码、测试和检查。
4. 我验收结果、承担取舍，并决定是否上线。
5. 需求状态公开更新，参与者能看到结果。

AI 降低的不只是写代码的成本，也降低了认真倾听用户之后，把反馈兑现成产品的成本。

这也是我现在愿意把反馈入口做得更公开、更显眼的原因。不是因为 AI 能替我理解所有人，而是因为当我真正听懂一个需求后，终于更有机会把它完成。

用户不只是“被研究的人”

做产品时很容易把用户抽象成数字：日活、留存、转化、跳出率。

这些指标当然重要，但用户本人不会因为某条曲线变好了而产生参与感。相反，如果一个人提出的建议被其他人支持，后来进入开发，再变成所有人都能使用的功能，他会清楚地知道：这里面有一部分是我推动的。

这种感受和普通的“产品更新了”不一样。

对用户来说，他不再只是被观察、被分析的对象，而是可以影响产品方向的参与者。对 MeTool 来说，我得到的也不只是一条需求，而是需求背后的场景、优先级和共同程度。

这是一种更直接的双赢：

• 用户得到表达、参与和看见结果的机会。
• 项目更早接触真实问题，减少靠猜测开发的浪费。
• AI 把经过验证的想法更快转化成可以试用的版本。
• 上线后的行为数据再回来验证：这个需求是否真的解决了问题。

于是整个循环变成：观察行为 → 听见需求 → 公开讨论 → AI 协助实现 → 上线验证 → 再回到用户。

这套模式还需要真实需求来验证

现在我做完的只是入口和流程。它会不会真的带来更好的产品决策，还不能只靠我自己宣布。

我需要继续观察几个问题：用户是否愿意花时间把需求说清楚；投票能否反映共同痛点；讨论会不会让需求变得更具体；我和 AI 是否真的能缩短实现周期；完成后的功能有没有被更多人使用。

我也不准备承诺“每个需求都会实现”。有些想法不适合纯浏览器工具，有些成本与收益不匹配，还有些需要更长时间验证。公开共建不等于把路线图交给票数，而是让判断依据和处理过程比过去更透明。

但至少，从今天开始，我不必只隔着一张数据面板猜用户在想什么了。

如果你正在用 MeTool，哪里让你觉得别扭，或者还缺一个真正能帮上忙的功能，可以直接去需求广场说出来。

也许下一次上线的功能，起点就是你写下的那句话。