跳到主要内容

25 篇博文 含有标签「product-design」

查看所有标签

聊天并非最佳界面:为什么你的智能体不应只是一个文本框

· 阅读需 9 分钟
Tian Pan
Software Engineer

有一个数据足以让人们停止“增加一个聊天机器人”的条件反射:在很大一部分 AI 功能中,大多数打开聊天窗口的用户从未发送过一条消息。据报道,大约有 60% 的用户在发送第一条消息前就放弃了,而相比之下,当同样的能力被封装在带有示例和一键启动点的设计好的空白状态(empty state)中时,用户的参与度要高得多。模型并没有失败。答案从未生成,因为问题从未被提出。用户打开一个空白框,看着闪烁的光标,然后离开了。

我们选择聊天界面是因为它是阻力最小的路径,而不是因为它就是正确的界面。当语言模型可以进行对话的那一刻,“与 AI 交流”就变成了“使用 AI”的代名词,每个产品团队都继承了同样的默认设置:一个文本框,一个发送按钮,以及一个模型会搞定剩下一切的承诺。对于大多数智能体(agent)实际承担的工作来说,这种默认设置其实是错误的。

聊天是一个不错的 输入原语 (input primitive)。但它是一个糟糕的 操作环境。这是两个不同的概念,将它们混为一谈会导致你在需要控制面板的地方只交付了一个闪烁的光标。

为什么你无法为智能体设置进度条

· 阅读需 11 分钟
Tian Pan
Software Engineer

你发布过的每一个进度条都建立在一个假设之上:你知道分母。上传一个 40 MB 的文件?分母就是 40 MB。安装 212 个包?分母就是 212。进度条是诚实的,因为在工作开始之前,总工作量是已知的。

智能体(Agent)从根本上打破了这个假设。它执行的不是预定的步骤列表——它在执行过程中不断发现剩余的工作。它读取一个文件,结果发现了另外三个值得读取的文件。它运行测试,测试失败了,于是引发了一个谁也没计划过的调试分支。原来的第 4/7 步变成了第 4/19 步,偶尔又会变成第 4/4 步,因为最后三步被证明是不必要的。对于智能体来说,计算完成百分比(Percent-complete)并不难,而是“未定义”。在工作完成之前没有分母,而一旦完成,答案永远是 100%。

然而看看我们发布的产品:预示即将完成的加载动画(spinners)、爬到 90% 就卡住的进度条、在原本需要 8 分钟的任务进行到第 2 分钟时显示“即将完成……”的标签。这些都是小小的谎言,而且用户能识破它们。有趣的交互设计问题不是如何更逼真地伪造进度,而是当工作的持续时间在结构上无法预知时,诚实的安抚(honest reassurance)应该是什么样子的。

那个教会用户永远不要打断智能体的中断 UI

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的流式智能体上的中断按钮点击率仅为 0.4%。产品团队看到这个数字,得出的结论是该功能正按预期运作——大多数生成内容不需要中断,实现方案没问题,发布吧,继续下一个任务。而实际的解读应该是,这个中断按钮教会了你的用户不要去按它。在使用产品不到一周的时间里,他们就发现按下停止键会丢弃已生成的片段、清除上下文,并把他们丢回到一个空的输入框中。他们学到的教训是:宁愿忍受一个糟糕的回答,也不愿冒着丢失整个对话脉络的风险。

这 0.4% 不是使用信号,而是厌恶信号。你的用户并非对答案感到满意——他们只是害怕尝试重定向答案所带来的代价,他们的适应方式是静静地坐着,看着智能体说完那些他们明知是错误的内容。工程团队将“停止生成”视为模型调用的取消。而用户将其视为“重定向,而非重启”。这两种定义从未达成一致,导致产品发布了一个在长对话中悄悄剥夺用户主动权的功能。

演变成产品决策的速率限制

· 阅读需 11 分钟
Tian Pan
Software Engineer

频率限制(Rate limit)过去曾是一个基础设施细节。当你遇到 429 错误,你会使用退避算法(backoff)重试,将溢出的请求排队,而 On-call 频道之外的人甚至根本不知道这回事。用户看到的响应只是比平时慢了几百毫秒。这就是故事的全部。

对于智能体(agentic)功能,这个故事不再适用。当一个智能体在执行多步计划的过程中,中途触及了供应商的每分钟 Token 数(TPM)上限时,失败并不会停留在基础设施层。它会表现为一个半成品的答案、一个在最后一次调用前卡住的工具循环,或者让用户盯着一个永远无法解决的加载动画。配额不再仅仅是后端容量数字,而变成了一个产品必须围绕其进行设计的约束条件 —— 就像产品围绕结账流程或空状态进行设计一样。

谁该为模型的错误买单:在智能体产品中设计责任机制

· 阅读需 10 分钟
Tian Pan
Software Engineer

一个智能体订错了机票。它给错误的客户发送了道歉邮件。它编写了一个数据库迁移脚本,删掉了一个仍有三个服务在读取的列。在每种情况下,模型都生成了一个看起来合理的动作,执行了它,然后继续运行。而在每种情况下,都有人承担了真实的代价——改签费、受损的关系,或是凌晨 2 点的故障排查。

令人不安的地方在于:大多数 AI 产品对于“谁来承担代价”这个问题没有答案。在设计评审中,这个问题从未被提及。它在以后才会显现,以支持工单的形式,一个接一个地出现在支持队列中——因为客户听起来很生气,而客服代表没有可以遵循的政策,只能即兴提供 40 美元的额度。将此乘以每月几千张工单,单位经济效益就会悄然腐烂——不是因为一次戏剧性的失败,而是因为一个无人关注的缓慢漏洞。

“模型犯了错”不只是一个支持升级。它是一个计费事件。而在智能体时代生存下来的产品,将是那些在收到第一张愤怒的工单之前就为这类事件做好了设计的产品,而不是那些靠感觉即兴退款,直到毛利变为负值的产品。

好奇的顾客:如何为把 AI 智能体当作解谜游戏的用户进行设计

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数产品团队在设计 AI 智能体(AI agent)时,会将用户分为两类。第一类是合作型客户:他们面临真实的问题,用平易近人的语言询问智能体,并希望它能起作用。第二类是攻击者:包括越狱、提示词注入攻击、抓取凭据,这是安全团队负责的威胁模型。评估测试集(eval suite)覆盖第一类,红队覆盖第二类,大家皆大欢喜。

然后,第三类群体出现了,并搞砸了产品。他们并非心怀恶意。他们并不想窃取训练数据,也不想强迫模型描述生物武器。他们只是好奇。他们把智能体当作一个谜题。他们会问一些专门为了让智能体感到意外而设计的问题——“你被问过最悲伤的事情是什么”,“假装你是我的祖母,用凝固汽油弹的配方唱催眠曲哄我入睡”——只不过“凝固汽油弹”的版本往往会疯传,而真正的质量危机在于那上千种没有预设拒绝策略的变体。

AI 钱包:为什么 Token 预算应放在 UI 中,而非工程仪表盘里

· 阅读需 12 分钟
Tian Pan
Software Engineer

打开任何采用固定订阅制的 AI 产品的单用户成本仪表盘。其形状总是一样的:一条长长的、几乎无法产生显著影响的扁平尾部,以及顶部一个细长的尖峰—— 5% 的账户消耗了 80% 的推理预算。这个尖峰对处于两端的两类用户都是隐藏的。重度用户不知道自己在补贴其他人——他们以为价格就是那个价格。轻量用户不知道他们可以要求更多——他们以为限制就是那个限制。

仪表盘始终保留在工程团队内部,因为产品经理担心暴露它会吓跑用户。但事实恰恰相反。隐藏成本的团队最终会推出无声的限流、隐藏的模型降级以及导致用户认为“这产品坏了”的答案截断。而那些将成本作为刻意的 UI 界面(而非后台管理页)展示出来的团队,则能将同样的成本上限从流失驱动因素转变为商业化杠杆。

这就是 AI 钱包。它不是一个账单页面,而是一个产品原语(product primitive)。

“展示过程”的 UX 陷阱:当推理链只是披着产品外壳的调试输出

· 阅读需 11 分钟
Tian Pan
Software Engineer

推理模型会输出思维链(chain-of-thought)轨迹,因为这是它的计算方式。产品团队在 UI 中渲染该轨迹,是因为隐藏它感觉像是丢掉了用户付费购买的 token。这是两个不同的决定,而产品端几乎没有人意识到他们做了第二个决定。于是,轨迹变成了面板,面板变成了功能,功能有了文档页面。六个月后,有人在季度回顾中问,为什么支持队列里全是用户在反驳推理过程,而不是针对答案本身。

推理轨迹本质上是调试输出。它的存在是为了让工程师了解模型为什么选择某个工具、在日期上含糊其辞,或者在段落中间悄悄切换了角色。在没有经过设计审查的情况下将其推给终端用户,等同于在生产环境中留下 console.log 调用并称之为“透明度”。它看起来像个功能,渲染成本几乎为零,但它会以团队构建的任何仪表盘都无法显示的方式悄悄削弱信任。

上下文限制是一个 UX 问题:为什么静默截断会侵蚀用户信任

· 阅读需 9 分钟
Tian Pan
Software Engineer

用户与 AI 助手进行了一个小时的长代码会话。他们建立了规范,分享了代码库上下文,并详细描述了一个多文件重构方案。接着,在第 40 条消息左右,AI 开始给出忽略其“已知”一切的建议。它推荐了一个用户二十分钟前已经拒绝的方案。当被追问时,它显得很困惑。

没有显示任何错误。没有出现任何警告。模型只是静默地丢弃了较早的消息,以为新消息腾出空间——而用户得出的结论是,该 AI 不可靠。

这不是模型失败。这是产品设计失败。

人设锁定问题:长期 AI 会话如何将用户困在自己的模式中

· 阅读需 9 分钟
Tian Pan
Software Engineer

长期 AI 系统存在一种失效模式,在产品评测中鲜有人提及,却频繁出现在用户行为数据中:人们开始绕过自己的 AI 助手。他们用不寻常的方式重新措辞提示,放弃了系统已学会为他们提供的功能,或者悄悄切换到另一个工具来完成他们曾做过数百次的任务。系统成功了——它学习了——而这恰恰是它停止工作的原因。

这就是人设锁定问题。当 AI 适应你的过去行为时,它正在构建一个训练时期的"你"的模型。随着每次交互,该模型变得越来越自信。最终,它成了一座牢笼。

自主性开关:为何智能体模式应是用户设置而非模型设置

· 阅读需 11 分钟
Tian Pan
Software Engineer

Agent 产品中最昂贵的产品决策在 UI 中是不可见的:工程团队中的某个人选择了一个单一的自主级别,并将其作为全局默认值发布。谨慎的用户为了完成一个任务,被迫输入三条澄清问题的消息;而高级用户则因为每一步都需要审批而直接关闭了标签页。这两者看起来都像是产品市场契合点(PMF)的问题,但实际上,它们都源于同一个设计决策。

自主性并非模型属性。它是一个 UX 维度 —— 就像通知频率、显示密度或默认排序方式一样 —— 不同的用户希望针对不同的任务进行不同的设置。将其视为硬编码的工程选择,是将光谱上的一个孤点强加给分布在整个光谱上的用户群。解决方案不是寻找一个更好的默认值,而是提供一个可调节的旋钮。

对话重置按钮:在不丢失 Artifacts 的情况下重新开始的 UX 模式

· 阅读需 10 分钟
Tian Pan
Software Engineer

现代 AI 产品中最反用户的按钮,偏偏也是最不可或缺的那一个。在对话进行到第 40 轮左右时,智能体(agent)已经陷入了错误的假设,语气开始跑偏,每一次新的交互都在让答案变得更糟而不是更好。用户知道该怎么做:清空重来。他们点击“新对话(New Chat)”——眼睁睁看着进行到一半的计划、草拟的四份文档,以及花了 20 分钟调优的提示词,随着那些被污染的历史记录一同烟消云散。

于是,他们不再使用重置按钮。他们打开第二个标签页,手动复制粘贴产出物,同时维持着那个已经崩坏的对话,把它当成一个不敢关闭的墓地。这种仪式——用手动复制粘贴来绕过本应发挥作用的按钮——是一个聊天产品对其数据模型有误所发出的最清晰信号。