我砍掉了让产品「更聪明」的所有功能

每天说将近两万字，我是这个产品用得最狠的人。

所以当我砍功能的时候，我不需要用户数据——我自己就是数据。

一、第一刀：有人要的功能，我也砍了

做语音输入工具，有两种触发录音的方式：长按和免提。

长按直觉上很自然——按住说话，松开停止，像对讲机一样。确实有用户喜欢这个模式，这不是我推测的，是真实反馈。

但我还是把它砍了。

原因很具体：长按期间，你的手必须一直压着那个键。这意味着在你说话的整个过程里，双手无法同时操作其他按键。对于一个给开发者、创作者用的效率工具来说，这是结构性问题——用语音的场景，往往也是需要同时操作屏幕或键盘的场景。

我可以花时间优化交互细节。但我意识到，优化完之后，这个功能依然只是「勉强能用」，而不是「用起来顺」。

一个需要用户单手挂起的功能，本质上是在制造新的麻烦，只是这个麻烦比它解决的问题更隐蔽。

砍。

长按那刀砍得还算干脆。真正难砍的，是那些听起来很厉害的功能。

我做过一个场景自动切换：检测用户当前打开的软件，自动判断场景，切换对应的后处理风格。在飞书就润色成职场风，在微信就保留口语感，在代码编辑器就识别指令直接执行。

Demo 出来那一刻，我自己都觉得很酷。

然后我开始真正用它。

第一个问题：场景判断需要额外调用一次 LLM，不管怎么优化，至少多花 1 秒。语音输入这个场景对延迟极其敏感——用户说完话，等待的每一毫秒都是摩擦。1 秒不是小事。

第二个问题更根本：这个功能要真正好用，用户得自己配置每个场景的提示词，得理解「职场风」和「口语风」的差别，得记住不同场景触发不同快捷键。

我在做的事情，是把产品的复杂度打包好，然后整个转嫁给用户。

表面上是「更智能」，实际上是「更麻烦」。用户买这个工具，是为了少想一件事，不是为了多管一套配置。

砍。

同期砍掉的还有自定义后处理提示词。逻辑一样：把提示词暴露出来，是在假设用户知道自己想要什么——但如果他们知道，他们早就自己写脚本了。

前两刀砍的是「不该做的功能」。第三刀最难，砍的是「我自己最想要的功能」。

我做这个产品的起点，就是想要 Agent。语音输入作为入口，识别完直接推给 Agent 执行，真正做到开口即完成。为了这个，我研究过 LangGraph，接入过 Claude Code CLI，各种方式都试过。

最后只保留了一个 webhook，留了个口子。其余全砍。

为什么？

有一个问题想清楚之后，答案就很明显了：为什么 Cursor、Claude Code 这些工具都内置了语音输入，但我们几乎没有人真正在用它？

不是因为它们的语音功能做得差。是因为它们的语音输入是锁在应用里的——你必须先打开 Cursor，才能用 Cursor 的语音。

Typeless 能成立，恰恰是因为它是跨 App 的。你在微信里说话，在飞书里说话，在任何地方说话，它都在。它不属于任何一个 App，所以它能出现在所有 App 里。

这个形态决定了它必须是轻量的。一旦往 Agent 方向走，就必须处理长尾任务、维护上下文、管理执行状态——产品从「轻量工具」变成「重型系统」。然后你会发现，你陷进了一个完全不同的竞争赛道，跟 Cursor、Claude Code、各种 AI 助手正面交锋。

不是你做不了，是这不是你该打的仗。

抄一个产品最大的收获，不是学到它做了什么，而是真正理解它为什么这么设计。在你自己动手复刻之前，你永远不知道那些看起来「显然应该有」的功能，为什么它没有做。

砍。

砍完这一圈，我发现这些被砍的功能有一个共同特征：

它们都在试图让产品「更聪明」、「更强大」、「更有存在感」。

但用户买这个工具，不是为了感受到工具的存在。他们买的是「说完话，想要的东西就出来了」这件事本身。

好的工具应该消失在背景里。用户不应该在使用过程中意识到工具的存在——就像打字时不会想到键盘，开车时不会想到方向盘。

每加一个「聪明」的功能，就是在提醒用户：你在用一个工具。每多一层配置，就是多一次打断。工具存在感越强，用户信任感越弱。

这不是反对进化。是说，功能的价值不在于它能做什么，在于它能不能让用户忘掉它的存在。

我把最想要的功能砍掉之后，产品反而变得更清晰了。

不是因为我学会了克制，是因为我终于想清楚了这个产品该是什么。

下篇： 功能想清楚了，产品的边界也清楚了。但「想清楚是什么」和「知道该卖给谁」是两件事。下篇聊我怎么想清楚这个产品的定位——它能替谁解决什么问题，以及我为什么选了那个方向。