跳到主要内容

22 篇博文 含有标签「ai-product」

查看所有标签

那个因为你的智能体表现得过于自信而流失的客户

· 阅读需 10 分钟
Tian Pan
Software Engineer

用户向智能体问了一个常规问题。智能体用一种胸有成竹的语调回答了。用户信任了这个答案,采取了行动,结果整个下午都在撤回一封基于错误信息发送给客户的邮件。六周后,续约谈判无疾而终。在流失分析报告中,这一项被归类为“参与度低”。而真正的理由——“我再也不敢相信它了”——从未出现在任何仪表盘上,因为用户根本没有打开那个本该询问该问题的 CSAT 调研。

这是大多数交付 AI 产品的团队系统性忽视的失败模式。不是幻觉——幻觉只是显露出来的冰山一角。深潜于水面之下的是置信度失准(confidence miscalibration):模型实际掌握的信息与它表达时的确信程度之间的差距。而这种差距带来的代价并非体现在调研问卷中,而是在续约谈判定夺的那一刻。

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

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

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

对话中途耗尽的 Token 预算:为什么免费用户觉得你的模型变笨了

· 阅读需 12 分钟
Tian Pan
Software Engineer

我认识的一位产品经理,花了两周时间排查公司 AI 写作助手的流失激增。免费用户的会话长度骤降 30%,客服收件箱挤满了"你们的模型以前很聪明,现在变懒了"的各种变体,团队第一反应是把锅甩给同一周上线的模型升级。模型其实没有变。变的是财务在季度中途悄悄收紧了按用户分配的 Token 预算,应用在用户跨过新阈值时,正在静默截断系统提示词、丢弃工具调用、缩短回答。从用户的座位看,AI 退化了。从仪表板看,一切正常。两边都对,这就是失败模式。

这种模式现在到处都是。ChatGPT 免费版触达上限后会切到一个更小的模型,产品里除了"接下来一段时间回答可能会短一点"之外没有任何标识。Anthropic 的免费层行为类似。你在任何一家之上做功能,再叠加一层自己的按用户 Token 预算用来控成本,于是你串联了两道隐形悬崖——平台的,加上你的——而用户只看到一个聊天框,无从分辨自己刚才到底踩到了哪一道。

那位通过反复试验摸清你 Prompt 的高级用户

· 阅读需 10 分钟
Tian Pan
Software Engineer

此刻,你的产品里有一位用户,体验远好于中位数用户。不是因为他付得更多,不是因为他在不同的订阅层,也不是因为他被分到了某个特殊的实验组。他通过耐心地试探,发现这个 AI 功能只要换种方式提问,就会给出漂亮的回答。他知道哪些动词能触发结构化输出。他知道一个词的追问会得到精简版本,一整句话则会得到展开版本。他知道某些话题如果不包装成假设性问题,助手就会戒备起来。这一切,你的网站上没有一处写过。他是逆向工程出来的。

有意思的不是这种用户存在,而是这种用户现在成了你的产品文档。你的 AI 功能跟用户之间签了一份契约——一份没公开的契约,完全编码在系统 prompt 里——而了解这份契约的唯一方式就是反复试验。只有一小部分用户有耐心去做这些试验。其余人拿到的是一个更糟糕的产品。

当两个 AI 功能争夺同一次点击

· 阅读需 9 分钟
Tian Pan
Software Engineer

用户落到一个搜索结果页面。A 团队的智能摘要在顶部横幅里弹出:"这是要点 —— 跳过列表吧。"B 团队的内嵌助手在侧边脉冲跳动:"留在这里,我陪你继续阅读。"两个提示争夺同一段 800 毫秒的注意力,用户被惹烦了,关掉了标签页。第二天早上,A 团队报告摘要点击率提升 6%;B 团队报告助手打开率提升 4%;会议室里没有人是错的,而产品却比一个季度前更糟。

这就是那种"独立功能团队 + 单一功能 A/B 测试"的标准打法看不见的失败模式。每个团队都针对自己的指标做了局部最优。用户 —— 只有一份注意力预算、一份心智模型、一次可以给出的点击 —— 替两个团队都不愿做的整合,买了单。

聚合指标隐藏的首次用户断崖

· 阅读需 10 分钟
Tian Pan
Software Engineer

你的 AI 功能看起来很健康。周活跃用户持平或微涨,满意度评分为正,仪表板告诉你应该多做这类功能。PM 在下一轮规划会议上引用了这个指标,工程主管点头同意,路线图上又多了一个相邻功能。

然后有人按用户使用时长对图表进行分段,画面瞬间反转。老用户——那些在功能上线时就已存在的用户——每天都在深度使用它。首次用户在两次交互内就跳出了。那条"持平"的曲线其实是两个队列在相互抵消:一条向上倾斜的幂律曲线,和一条向下倾斜的流失曲线,加总成一个谎言。

免费层级流量才是你真实的评估集

· 阅读需 11 分钟
Tian Pan
Software Engineer

针对付费用户群追踪数据进行模型优化的团队,其实是在一个“简单分布”上给自己打分。付费用户已经形成了一套工作流。他们之所以选择这款产品,是因为产品中的某些特质证明了刷信用卡付费的合理性,这意味着当他们进入评估集(eval set)时,已经学会了哪些提示词(prompts)有效,哪些功能给力,以及哪些“坑”不该踩。而免费层用户完全不是这样。他们是匿名的、探索性的,通常带有对抗性,且往往是非英语母语者,正在用第二语言对产品进行压力测试,他们触发了评估集从未涵盖的长尾失败模式。

这种不对称性正悄无声息地吞噬着每一个免费增值(freemium)AI 产品的转化漏斗。团队针对主要从付费追踪数据中提取的精选样本对模型进行评分。而免费层的那些“古怪”追踪数据——那些没有模板、用户正真诚地试图搞清楚产品能做什么的数据——从未被标注,从未进行回归测试,也从未为下一次提示词修改提供参考。模型在付费分布上变得越来越好,但在决定免费用户是否升级的分布上却慢慢变差。

用户信任半衰期:为什么一次糟糕的体验会抹除数周的信任校准

· 阅读需 11 分钟
Tian Pan
Software Engineer

用户对 AI 功能的校准(calibration)是你交付的最昂贵的东西之一。这耗费了他们数周的注意力:学习哪些提示词有效、模型在何处可靠、何时需要复核,以及哪些内容应完全忽略。然后,一次显而易见的失败——生成的报告中出现错误数字、用户粘贴到演示文稿中的幻觉引用、或者是他们根据一个自信但错误的建议采取了行动——都可能在一次会话中让这一切化为乌有。恢复曲线是不对称的。用户的先验预期(prior)是“这是可靠的”,而这次更新并不是作为一个数据点出现的。它更像是一种背叛。

测量 DAU 的团队在数周内看不到任何异常。用户出于习惯继续打开应用,运行几次查询,不对输出结果采取行动,然后悄悄地停止使用。等到参与度指标(engagement metrics)出现波动时,导致这一结果的信任事件已经发生了两个月,团队中甚至没人记得当时发布了什么。

安静放弃模式:AI 参与度指标为何在说谎

· 阅读需 11 分钟
Tian Pan
Software Engineer

有一种特定的失效模式正在悄悄破坏 AI 产品的数据指标,却没有人察觉。你的仪表盘显示建议接受率为 34%、DAU 强劲、功能参与度持续增长。仪表盘没有显示的是:60% 被接受的建议随后被立即重写,参与度最高的用户正是那些点击 AI 输出、全选,然后自己重新输入的人;这个功能对下游任务完成率零可测影响。

这就是"安静放弃"模式:用户系统性地绕过 AI 功能,同时产生活跃用户的全部表面指标。他们不会禁用该功能——他们只是忽略其输出。在你的分析系统中,他们与最佳 AI 用户看起来完全相同。

在 AI 功能感觉准备好之前就发布它

· 阅读需 10 分钟
Tian Pan
Software Engineer

大多数 AI 功能发布延迟,并不是因为它们有缺陷。它们延迟,是因为团队仍在针对一套不能反映真实用户行为的测试集进行优化。每周基准分数都在提升,评估指标持续向好。而"实验室表现"与"生产价值"之间的差距,却在悄悄扩大。

令人不安的事实是:最初的 500 名真实用户,在两周内发现的可操作问题,远比再花四周调优提示词要多。这不是在为发布劣质产品辩护,而是在说:你当前对"准备好了"的判断,几乎肯定是错误校准的——只有真实的使用数据才能纠正它。

为什么每周会话记录审查优于你的 AI 仪表板

· 阅读需 14 分钟
Tian Pan
Software Engineer

在你的 AI 团队中,被低估最严重的资产是每周一小时,由三个人坐在房间里阅读你的产品实际对用户说了什么。不是综合评分。不是移动平均值。不是仪表盘。而是实际的对话记录。逐字逐句的输出。模型悄然形成的懒散措辞。你的分类体系中未涵盖的意图。用户尝试了三次,用三种不同的方式表达需求,而你的评估准则(eval rubric)却将这三次对话都评为“满意”。

将这一小时制度化的团队,能够建立起仪表盘永远无法呈现的 AI 功能心理模型。跳过这一步的团队,会根据看起来不错的指标发布六个月的产品,然后在下一次季度业务回顾(QBR)中发现,在无人察觉时,中位数体验已经漂移到了令人遗憾的境地。

70% 可靠性恐怖谷:AI 功能丧失用户信任的深渊

· 阅读需 13 分钟
Tian Pan
Software Engineer

一个故障率高达 70% 的功能是无害的。用户在一周内就会发现他们必须验证每一条输出,将系统视为一个不可靠的助手,并做出相应调整。而一个成功率达到 70% 的功能则更糟糕。它正确的频率足以让用户停止验证,而错误的频率又足以让失败变得集中、显眼且具有针对性。用户的心理模型会崩塌为“我不知道什么时候该信任它” —— 这种产品体验从根本上比“我知道不要信任它”更糟糕。

这就是 70% 的恐怖谷,也是过去两年中构建的大多数 AI 功能所处的位置。团队衡量综合准确率,看着数值超过某个“足够好”的阈值,然后发布。实际的用户体验并不随着这个数字单调提升。在大约 60% 到 85% 的准确率之间,产品随着准确率的提高反而变得更差,因为用户因疏于检查而导致的错误成本,超过了他们无需验证正确答案所带来的价值。

那些在不考虑可预测性问题的情况下发布 70% 准确率产品的团队,发布的并不是一个 95% 产品的拙劣版本。他们发布的是一个完全不同的产品:一个主要的失效模式是隐形的产品。