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

每个 Agent 功能都有一个自主性上限，一旦超过这个上限，用户就会开始检查工作、进行干预，或者彻底放弃该功能。这个上限并不是你模型的属性，而是由你的用户、领域以及出错成本决定的。它不会因为发布演示稿说它该移动就移动。大多数团队都是通过惨痛的教训才发现这个天花板的：发布的功能被设计为完全自主，但采用率却停滞在“Agent 建议，人类批准”的阶段，指标把责任推给模型，而接下来的一个季度则花在调整一个从未成为瓶颈的旋钮上。

这个上限的形状在各种产品中都足够一致，以至于它值得拥有一个名字。Anthropic 自己关于 Claude Code 的使用数据显示，新用户在约 20% 的时间内使用完全自动批准，只有在经过大约 750 次会话后，这一比例才会攀升至 40% 以上。PwC 2025 年对 300 名高管的调查发现，79% 的公司正在使用 AI Agent，但大多数生产部署都运行在“协作伙伴”或“顾问”级别——即模型提议，人类决策——而不是营销所暗示的全自主层级。这些数字背后的故事并不是用户胆小，而是信任是根据可挽回错误的成本进行校准的，而你的产品几乎肯定没有以用户需要的方式让他们看到、撤销或限制这些成本。

对话隐喻有一个引信，大约在 30 秒左右就会燃尽。超过这个时间，加载动画不再是进度指示器，而变成了一种承诺机制——做出承诺的是你的用户，而他们中的大多数人都会选择放弃。你可以在会话回放中看到这一幕：正在输入指示器出现，用户等待，在 12 秒左右切换标签页，其中一半人再也没有回来。产品团队看到一个已完成的 Agent 运行，而另一端没有人类在场，便将其记录为一次成功。这不叫成功。这是一个碰巧完成了的、被遗弃的产物。

这是一个结构性问题的初步显现，大多数 Agent 产品都用加载动画和流式文本来掩盖它：对话界面是为回合制的人类和快速模型设计的，当这两个前提中的任何一个失效时，它就会悄无声息地失败。如果你的 Agent 需要几分钟才能运行完，那么你交付的就不是一个等待时间较长的对话功能。你交付的是一个不同的产品，它需要一种不同的 UI 原语。

用户向你的智能体提问。Token 开始流式输出。写到第三句时，模型写道“实际上，让我重新考虑一下——”并转向一个不同的答案。修改后的答案更出色。用户却关闭了标签页。

这就是输出承诺问题（Output Commitment Problem），它是已发布 AI 产品中被低估得最严重的 UX 失败案例之一。工程师思维将自我修正视为一项特性——模型注意到了自己的错误，这意味着系统正按预期运行。而用户感知思维则将其视为一场灾难——产品现场演示了其最初自信的断言是错误的。这两种解读都是正确的，且它们本身无法调和。

核心的不对称性在于，流式传输让思考过程变得清晰可见，而清晰的思考就是可审计的思考。一个静默地产生幻觉然后给出简洁最终答案的模型看起来很专业。而同一个模型，如果流式输出每一个不成熟的想法，看起来就像是在胡言乱语。答案的质量是相同的，但感知却截然不同。

你发布了 AI 功能。你将其内置于产品中。你编写了帮助文档。然而，六个月后，你最资深的企业用户仍然在将文本复制粘贴到 ChatGPT 中，以完成你的功能原本就能原生实现的事情。这不是培训问题。这是一个可发现性（discoverability）问题，也是当今企业软件中 AI 投资浪费最普遍的来源之一。

这种模式已有详尽的记录：49% 的员工表示他们在工作中从不使用 AI，74% 的公司难以从 AI 部署中扩大价值。但有趣的失败模式并不是那些明确抵制的后期采用者，而是那些每天打开你的产品、却从未意识到原本值得他们付费的 AI 功能就潜伏在光标一键之遥处的活跃用户。

大多数 AI 产品上线时都带着一个点赞/踩组件，并将其称为反馈基础设施。但它并不是。实际上，它是一份调查问卷——只有不满意或格外认真的用户才会去填。而且这份问卷无法告诉你正确的输出应该是什么样的。

其结果是：数据集的形状不由用户想要什么决定，而是由哪些用户愿意点按钮决定。这种选择偏差会渗透到微调、奖励模型和 DPO 流水线中，悄悄地将模型导向极少数且缺乏代表性的少数人的偏好。而隐式信号——编辑率、重试率、会话放弃——则覆盖了所有接触产品的用户，无需任何点击，只是使用软件这一行为本身就能产生这些信号。

以下是如何设计反馈界面，将高保真训练信号作为产品使用的自然副产品生成，以及如何将这些信号接入训练流水线。

在 AI 产品开发中，有一个常见的假设：如果一个模型能处理难题，它就一定能处理附近的简单任务。这个假设是错误的，它导致了一类生产环境下的失败，而无论你读多少基准测试报告都无法为此做好准备。

这一潜在现象的研究术语是“破碎边界”（jagged frontier）——AI 的能力边界并不是一条平滑的线，并非难题在界外、简单任务在界内。它是一个参差不齐、不可预测的形状。AI 系统可以编写生产级别的数据库查询优化器，却仍然会算错图中两条线段是否相交。它们可以通过博士级别的科学考试，却在涉及空间关系的儿童谜题上失败。它们可以综合 50 页的文档，然后对自己刚刚读过的一段文字产生充满自信的幻觉。

你的产品在第 10 秒到第 45 秒之间存在一个“空洞”，在这个时间段内，你设计的任何东西都不再起作用。用户在 10 秒左右就会放弃无响应的 UI —— Jakob Nielsen 在 90 年代就确定了这个阈值，现代的眼动追踪研究显示的偏差也不过一两秒。现代智能体（Agent）的工作通常需要 30 到 120 秒。多步规划、检索、几次工具调用，可能在最终输出前还要经过一轮反思 —— 延迟预算不再只是预算，而是一个巨大的深渊。

大多数团队在第一次发布智能体功能并查看会话录像时都会发现这一点。用户疯狂点击提交按钮。他们将查询粘贴到第二个标签页中。他们关闭窗口并从头开始重试，坚信系统已经崩溃。功能本身没问题，但等待过程出了问题。“加载动画出现”与“答案送达”之间的空白地带是 AI 产品设计中最被忽视的环节，而它正是决定用户认为你的智能体是聪明还是死机的关键。

大多数工程团队默认将 AI 功能构建为聊天界面。用户输入内容，模型做出响应。这种模式感觉很自然，因为它映射了人类的对话，而且工具链也让实现变得简单。但当你观察生产环境中的这些基于聊天的 AI 功能时，你经常会看到同样的功能失效：用户界面处于闲置状态，等待着那些太忙、太分心或根本不知道该问什么的用户。

聊天是一种“拉取”（pull）模式。由用户发起，AI 做出反应。对于任何产品中具有价值的 AI 工作的一个重要子集——监控、异常检测、工作流自动化、主动通知——“拉取”模式都是错误的形态。无论用户是否记得打开聊天窗口，这些工作都需要进行。

大多数 AI 产品复盘都聚焦于同一个故事：模型错了，用户发现了，信任瓦解了。修复方法显而易见——提高准确率。但有一种更隐蔽的失败模式，复盘很少能捕捉到，因为标准的准确率指标无法反映它：模型是正确的，但原因却是错误的，而那些检查了推理逻辑的高级用户再也没有回来。

称之为“过度声明陷阱”（overclaiming trap）。在这种失败模式下，正确的最终答案是由捏造的、事后修补的或结构不合理的推理链支撑的。它比普通的错误更危险，因为它看起来像是成功，直到你最专业的用户开始悄悄离开。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E8%BF%87%E5%BA%A6%E5%A3%B0%E6%98%8E%E9%99%B7%E9%98%B1%EF%BC%9A%E5%BD%93%E2%80%9C%E5%9B%A0%E9%94%99%E7%9A%84%E5%8E%9F%E5%9B%A0%E8%80%8C%E6%AD%A3%E7%A1%AE%E2%80%9D%E6%91%AC%E6%AF%81%20AI%20%E4%BA%A7%E5%93%81%E4%BF%A1%E4%BB%BB"]"

你上线了一个 AI 功能。模型表现良好——你量化过它。精确率达 91%，召回率扎实，P99 延迟低于 400ms。三个月后，产品分析给出了一个令人沮丧的数字：高级用户已将其完全关闭，而另一批用户则不加修改地接受每一条建议，包括那些明显错误的。

这就是信任校准差距。它不是模型问题，而是设计问题——而且比大多数 AI 产品团队愿意承认的更为普遍。

两家公司的两个产品团队，各自构建了同一款 AI 写作助手。相同的模型，相近的功能面貌，相当的准确率指标。一个团队在上线时迎来创纪录的激活率，另一个团队则在三个月的沉寂推广和一次尖锐的全员大会质疑后，悄悄下线了这个功能。

那家苦苦挣扎的公司在工程复盘中聚焦于显而易见的变量：延迟、准确率、交互打磨。但这些因素都无法完全解释这道鸿沟。真正的关键变量是信任——更具体地说，是这个 AI 功能能否借用足够多的既有信任，换来在证明自身价值期间犯错的权利。

信任转移（Trust Transfer），是决定一个 AI 功能能否落地生根的无形力量。而大多数正在打造 AI 产品的团队，从未为此进行过明确的设计。

麦当劳将其 AI 语音点餐系统部署到了 100 多个网点。在测试中，它达到了似乎可行的准确率—— 80% 左右。客户开始发布系统在未经提示的情况下向订单添加九杯甜茶、在冰淇淋上放培根，以及信誓旦旦地听错简单要求的视频。两年内，合作伙伴关系解散，该技术从所有网点移除。实验室的准确率是真实的，但现实世界的数据分布并非实验室所测试的那样。

这就是准确率阈值问题。存在一个区域——大约 70% 到 85% 的准确率——在这个区域内，AI 功能的精确度足以让它看起来有效，但在没有持续人工干预的情况下，其可靠性不足以真正发挥作用。团队之所以发布这个区域的产品，是因为数字看起来足够接近。用户会感到困惑，因为该功能刚好足够好到诱使他们产生依赖，又刚好足够差到在关键时刻失效。