被你扔掉的产品路线图,其实就是那份 Prompt 日志

在你的可观测性栈里某个角落,躺着一张表,记录了上个季度用户向你 AI 功能输入的每一条 prompt。如果你团队跟大多数团队差不多,这张表只被用于三件事:成本归因、滥用检测,以及偶尔在客户投诉答非所问时拿来 debug。产品团队没人打开过它。研究团队没人对它做过聚类。负责 AI 路线图的那位 PM 一行都没读过。

这是你产品组织里最昂贵的一次疏忽。用户输入的那些 prompt——尤其是你的功能没有处理好的那些——是你这辈子能收集到的"用户希望这个产品能做什么"的最高分辨率形式。你正在实时支付推理成本来产生这份信号,然后把它扔掉,只因为没人决定这本该是谁的工作。

prompt 日志里到底有什么

用户调研问卷问大家想要什么。工单记录的是什么坏了。分析仪表盘报告用户点了什么。这些信号每一条都被一层抽象过滤过——用户的记忆、他们是否愿意提工单、产品当初提供给他们的那几个点击选项。

prompt 跳过了这一切。一条 prompt 就是用户、用他们自己的话、在需求发生的那一刻,告诉你的产品他想让它干什么。他没有从下拉菜单里选。也没有被问卷的问题引导。他敲下一个句子,描述他想完成的活儿,然后你的功能要么干成了,要么干砸了,要么拒绝了。

那些"干砸了"的 prompt 就是金子。它们是有人朝你的产品伸手、想解决某个具体问题、而你的产品恰好不是那个形状的留痕证据。在几周里跨越几千个用户聚合,这些 prompt 会聚类成意图。每一个高于复现阈值的簇,都是一个已经被真实需求验证过的功能请求。你不需要再跑一次发现冲刺;需求自己走进来、敲到你日志里。

为什么大多数团队把这份信号扔了

如果信号这么明显有价值,自然的问题就是为什么几乎没有团队系统地挖它。三个原因反复出现。

第一个是归属。Prompt 日志躺在平台团队拥有的数仓里,在 ML 团队拥有的可观测性工具里被展现出来,然后由法务拥有的隐私策略来治理。本应受益的那位 PM 既没有查询权限,工作描述里也不包含"花一两天读用户输入"。没有一个季度 OKR 写着"每月花两天读用户敲了什么"。所以没人去做。

第二个是形态。原始的 prompt 日志很乱。同一个意图会以一百种不同的措辞出现。一半的条目是在测试系统或问鸡毛蒜皮的问题。要把 prompt 聚合成可操作的簇,需要嵌入、聚类、对每个簇做摘要、再按频次和新近度过滤。这些都不难,但它是个需要排人的小型数据项目,而本应排人的团队不把它当成自己的活儿。

第三个是解读。当团队真去看 prompt 失败的时候,他们会归类为"模型质量"——ML 或 eval 团队该通过调 prompt 或微调模型来修的事。但很多失败并不是模型失败。它们是范围失败。用户让 AI 做一件 AI 本来就没被造出来做的事,再怎么 prompt engineering 或升级模型也修不出那个功能来。正确的回应不是再训一轮,而是产品决策:是否要扩大范围。这个决策属于 PM,而 PM 没在看日志。

区分范围失败和质量失败

如果你打算从 prompt 里挖产品信号,第一步分析动作就是把失败拆成两桶。质量失败是用户要的本就是产品该做的事,但 AI 做错了——答案错、格式错、漏了一步、幻觉了一个事实。它们归 eval 和 prompt 团队。

范围失败是用户要的不是产品该做的事。AI 可能拒绝了、给了一个泛泛的道歉、把人转到文档,或者因为缺工具缺数据而把活儿干砸了。它们归 PM。它们是披着皮的功能请求。

范围失败的征兆通常是:请求的形状跟产品文档里任何一项能力都对不上。一个为重构造的编程助手突然被要求脚手架新项目。一个摘要工具被要求做翻译。一个客服 bot 被要求开发票副本。每一个这样的簇,都是顾客在聚合层面告诉你:他们以为你的产品覆盖了一项邻近的工作。有时正确的做法是澄清范围。更多时候是扩大范围。

一个实用的聚类流水线会产出一份周报,两列:质量失败 Top 簇和范围失败 Top 簇。第一列发给改模型的团队。第二列发给 PM,他读它,就像在读一份由顾客写的功能积压清单。

挖掘方法论

把这条流水线搭起来的实际工程其实已经踩烂了路。用通用嵌入模型把每一条用户轮次嵌入。跑一个聚类算法——HDBSCAN 表现很好,因为它能处理变密度并忽略噪声。对每个簇,抽样代表性 prompt,让 LLM 写一句话的意图摘要。按大小、按跨时间的复现、按原始轮次的结果信号过滤——用户点了踩、放弃了会话、还是改写了问题。

高频次、跨多周复现、带负面结果信号的簇,就是你候选的功能请求。一个季度里入围的清单很少超过二十个簇。每个簇有名字、有代表性原句、有计数、有"在当前产品范围内能否解决"的判断。

每周跑一次这条流水线。把这周的簇跟上个月的对比。新出现的簇通常被外部事件触发——竞品发了什么、出了爆款用例、季节。持续存在的簇是未满足的需求。月际之间还在长的持续簇是正在加速的未满足需求。每一条都告诉你一件路线图规划会上原本只能靠猜的事。

当 prompt 日志变成路线图的输入,会发生什么

把 prompt 日志当作发现通道的团队,会发展出几个从外面看挺反常的习惯。

功能提案开始引用 prompt 计数。一次新功能的 pitch 听起来不再像"我们应该建 X,因为这战略对齐",而像"过去 30 天里,1,847 个用户试图用我们当前的功能做 X,这里有十条最代表性的措辞,这个簇环比月增 23%"。规划会上的对话从观点转向证据。

范围决策做得更快。"AI 功能是否也该做 Y"这个反复出现的问题,不再是关于产品身份的哲学辩论,而变成一个事实问题:Y 是不是 Top-10 簇。如果是,需求是真的;如果不是,问题可以等。

Eval 集变得更丰盈。范围失败堆里的 prompt 成了新能力的规约。功能一旦上线,原始簇里的 prompt 就成了回归测试,用来验证这个功能真的解决了用户在问的问题。Eval 集不再是 ML 团队拍脑袋编出来的东西,而成了顾客亲手写出来的东西。

产品团队和 eval 团队之间的关系变得没那么对抗。eval 团队不再是那个守门人,说"模型 X% 的时候在挂,修一下"。两边现在共享同一份制品——聚类过的 prompt 日志——分歧从"模型够不够好"转到"这个簇是质量问题还是范围问题"。

隐私围栏是可解的

对系统化 prompt 挖掘最常见的反对意见是隐私。用户 prompt 里有个人信息。横跨整个产品人群挖它们听起来像是等着发生的合规事故。这个顾虑是真的,但它也是可解的,而且它并不是大多数团队没做这件事的真正原因——它是团队用来给"我们没去试"找的借口。

缓解方案是熟知的。PII 检测和脱敏在 prompt 进入分析流水线之前跑。聚合只在最小簇规模以上发生,这样个体用户无法被重新识别。聚类工具的访问被日志化、被审计。处在受监管层级的客户可以按合同被排除出流水线。基于嵌入的聚类可以在哈希过或脱敏过的 prompt 上跑,且不损失大部分信号。

这些没有一项是新东西。每个在用户内容上跑分析的团队,都已经在做某个版本的这件事。把同样的控制延伸到 prompt 日志,是季度级的工程投入,而不是一个跨年的合规项目。如果你的团队用"隐私"作为不去挖 prompt 的理由,但又欢欢喜喜地拿同一份数据来训练,那"隐私"并不是真正卡你的东西。

这个季度就能搭出来的流水线

这套系统一个合理的起步版本很小。一个定时任务拉上周的 prompt,嵌入、聚类、对每个簇做摘要、关联上点踩和会话放弃这样的结果信号,然后把按规模和结果严重度排序的 Top 簇写到一个 Notion 或 wiki 页面上。PM 和 eval lead 收到一条每周通知,带链接。

这就是整套干预。没有新工具。没有新人头。不依赖平台团队。流水线无人值守地运行;唯一的人工输入是那场会议——PM 走查 Top 簇,决定哪些进路线图、哪些进质量工单、哪些先忽略。

搭出这套流水线的团队几乎一致地反馈:第一个月就会浮出至少一个团队里没人想过的功能簇,以及至少一个 eval 团队没标出来过的质量问题。第二个月会浮出持续性的模式。到第三个月,PM 不再把规划会当作捍卫观点的场合,而开始把它当作按证据分配投入的场合。

prompt 日志从来不是噪音。它一直就是你的路线图。工作只是去读它。