AI能不能帮网站自动发现新功能？

去年我做的一件准备工作是把三个来源的原始记录归拢起来：用户发来的邮件、站内搜索框里没结果的词、表单里验证失败的畸形输入。总共几千条，之前一直堆着没看。

丢进去让它聚类，几分钟出了二十几个簇。这个环节它有明显的优势——我没有的那部分是耐心，它正好有。

三个信号里，最值钱的是第三个

用户邮件是最容易处理的：文字表述完整，意图清楚，聚类效果好。缺点是这类人已经是愿意花时间写信给你的少数人。

站内搜索的零结果词很有意思，因为它是"在我们这儿没找到"的直接记录。这里面混杂大量无关词，但挑出来的部分非常准：有人在一个图片工具站里搜某个具体格式名，说明他期待这个格式被支持。

零结果词的清洗有个小技巧：把长度为一两个字的词和明显串台的搜索直接滤掉，剩下的才是真的"想找没找到"。过滤前几千条，过滤完通常只剩几十条，而这几十条一条比一条值钱。

验证失败的输入是三个里面最被低估的。用户在工具里填了一个格式不对的东西然后报错离开，这条记录写的是"他本来想干什么"。我用这批数据发现过一个真实缺口：一批用户反复提交某种输出格式，而这个格式当时根本不支持，表单直接拒绝了。这不是"反馈"，这是行为证据。

三个来源共同的前提是你先把它存下来。

这件事我踩过坑。最开始只把原始字符串写进日志，事后完全没法用——不知道那是一次搜索还是一次失败提交，也没有时间和上下文。

后来改成一条记录带上来源、当时所在页面、以及脱敏后的原始输入。多存这几个字段的成本几乎为零，事后能不能追查全靠它们。

这类数据适合放在本地的单文件库里，跑一个查询就能拉出来，轻量存储这一套够用。

Cakedesk 是这一节的答案。作者 Max Schmitt 一个人做 Electron + React + Node.js 的桌面应用，一次性付费 €69，2025 年卖出 239 份新授权、约 €16000 毛收入。

Cakedesk 首页把 Watch demo 放在评价旁边，没装过的用户先看演示再下单。

同一年他收到 44 个功能请求，完成 13 个。

31 个没做的并不是"没时间做"，是判断不值得做。而判断的依据完全在 AI 的视野之外：提这个请求的人买过没有、他在邮件里描述的场景有多少人会遇到、这个改动会不会让某个平台的打包出问题。

Data Fetcher 更说明问题。Andy Cloak 一个人在伦敦运营，MRR 23000 美元、600 家付费客户，产品是 Airtable 上的扩展。这个量级的付费密度意味着每个功能决策的代价都很高——600 家人的工作流依赖它。

哪个请求来自这 600 家、哪个来自没付过钱的路过者——这一条 AI 永远拿不到，而这恰恰是排序的全部依据。

44 到 13 的筛选里还有一层更难处理的：一部分请求互相冲突。有人要更简洁的入口，有人要更多选项，同时满足是不可能的。这类取舍它完全没有立场参与，而取舍本身就是产品方向。

现在的具体用法是：每周把它跑出来的簇丢给我，我在里面挑。它负责不遗漏，我负责不错误。

它在这个位置上还多做一件事：把每个候选项翻译成"如果做，要动哪些文件"。这部分的价值同样不小。它可以顺着引用关系把受影响的模块列出来，我据此估算一次改动的波及面；更进一步，拿到它给的清单之后我都会手工验一遍相关调用链，顺序可以参考前端调试里那套做法。

每周的原始记录我也会自己翻一遍——聚类会平滑掉异常值，而异常值有时候才是真正值钱的那一条。

验证失败的输入里有一簇提交：用户反复粘贴某种带前缀的格式串。

顺着这条线追下去发现，那是另一种工具导出的默认格式。我们当时没有兼容它，用户不会写信说"请支持某某导出格式"，他只会粘进去、报错、然后走掉。

加上兼容只花了一小段解析代码，但如果在几千条记录里用眼睛看，这条线索大概永远浮不出来。

补完兼容之后我还做了一件事：把这个格式写进首页可接受的格式说明里。它是从用户行为里发现的，但也得让后来的人看见——很多犹豫的人不是觉得不能处理，是不知道能处理。

做工具站的时候这条经验被复用得最多：每个工具的失败输入是它自己最好的需求文档。而要把成千上万条这类记录组织成可执行的东西，站点本身的形态最好是那种每个入口各自独立的在线工具集合结构——工具和工具之间不共享状态，每个入口才能各自长出独立的候选清单。

每周花二十分钟看一遍它整理出来的簇，是我目前在获新功能方向上投入产出比最高的一个动作。

Cakedesk 数据来自作者 Max Schmitt 的 2025 年度总结；Data Fetcher 数据来自作者 Andy Cloak 公开分享。