乐于分享
好东西不私藏

为什么用户不爱万能 AI 助手:先砍掉这 3 类功能

为什么用户不爱万能 AI 助手:先砍掉这 3 类功能

用户打开一个「什么都能聊」的入口,本想改签、查状态、确认退款。对话框很大,却不知道该交代什么;出错之后,也不清楚谁能撤回、谁能接手。

产品经理这边的压力通常是反过来的:先把 AI 助手做「更全能」,再谈边界。功能清单越写越长,确认页越来越薄,人工出口越来越远。

我的裁决是:在高责任任务里,真正危险的往往不是功能不够多,而是缺少三张表——能力范围表、确认与撤回表、人工出口表。标题里的「用户不爱万能助手」,先当作待验证假设;本文能硬写的,是「缩小全能承诺」的设计理由,以及一张可自查的 AI Assistant Scope-Cut Matrix。

真正坏掉的是五个变量

把「看起来很智能、用不下去」拆开,通常坏在这五项:

如果你最近差点给预约、查询或支付流程直接挂一个「全能对话框」,停一下:先问这五个变量,再问模型选哪家。

我不选的四条路

我选第五条:范围裁剪(Scope Cutting)——先把全能承诺裁成可控承诺,再谈加功能。

两个公开案例,只说明一件事

Google Bard 首秀曾给出关于 JWST 望远镜的错误事实;Google 发言人承认这凸显了严格测试的重要性。媒体报道当日 Alphabet 市值约蒸发千亿美元——那是多重因素叠加,不能单因归因成「一个错误答案打掉市值」。它能支撑的判断只有一句:公开演示里的能力承诺,一旦超出可靠性,成本会非常显眼。

Apple 在 2024 年 WWDC 演示过更个性化的 Siri 能力;2025 年承认可靠性不够,主动延期。Craig Federighi 的原话大意是:这还不够可靠,达不到 Apple 产品的标准。延期后,媒体还报道了相关集体诉讼的存在——这里只写「诉讼存在」,不写成法院已认定虚假宣传。

两个案例共同指向的,不是「功能多的 AI 一定讨人厌」,而是:当承诺跑在可靠性前面,产品要么主动砍能力,要么在公开市场里被动付账。

为什么先砍范围,而不是先堆能力

NIST AI RMF Playbook 的 Map 函数要求:系统的 intended purpose、known limitations、prospective settings 必须被理解并文档化。换句话说,任务边界不是上线后补丁,而是设计阶段就该写清的表。

安全侧也同向。OWASP Top 10 for LLM Applications 2025 把 Excessive Agency(过度自主)列为风险:根因常是功能、权限、自主性过大;缓解包括缩小能力面,并对高影响动作要求人类确认——比如删除文档前必须用户点头。

Google PAIR 的 Errors 章节提醒:用户如何定义「错误」,深层连接着他们对系统的期望;为错误提供前进路径,有助于维持体验。User Autonomy 原则则写得更直白:人们更愿意保持对「工具执行哪些任务、如何执行、执行到什么程度」的控制。

把这些框架翻译成产品语言:

    人工出口不是「AI 失败了才丢人补救」。Intercom Fin 的官方文档写得很清楚:找不到清晰或有信心的答案时可以交接人工;也可为退款、取消、敏感数据等话题配置 escalation rules。NIST Govern 同样强调人类审查与问责要被文档化。在高责任场景里,人工出口是设计,不是降级。

    一张分流图:风险决定走哪条路

    文字版最短路径:

      交付物:AI Assistant Scope-Cut Matrix

      按「保留 / 降级为规则 / 明确拒绝」三类处理。砍功能不是目的;目的是把全能入口裁成可控承诺。

      保留:AI 作为受控组件参与

      能力
      判断条件
      产品设计动作
      非结构化输入翻译
      用户说人话,目标却是结构化字段
      AI 译成参数,用户确认后提交
      规则解释 / 政策说明
      退改、资格等条件很长
      抽取相关条件,展示来源与置信度
      低责任多步编排
      可预览、可撤销、失败后果低
      逐步展示预览,逐步确认
      只读跨源检索
      结果不改变业务状态
      检索整合,标注来源与时间戳

      降级为规则:让位于确定性系统

      能力
      判断条件
      产品设计动作
      字段 / 状态查询
      答案来自权威数据源,确定
      规则引擎 + API,不走开放式生成
      时段 / 余量检查
      离散选项,需要实时准确
      表单 + 日历 + 余量 API;AI 最多做输入翻译
      简单资格判断
      if-else 能覆盖
      规则直接返回,AI 不参与裁决
      支付 / 扣款确认
      资金变动,零容错
      独立确认页 + 二次验证,AI 不参与

      明确拒绝:AI 不应承担

      能力
      判断条件
      产品设计动作
      高责任动作直接裁决
      支付、改签、取消、资格终审等不可轻易撤销
      明确告知需人工确认,并提供人工出口
      开放式全能承诺
      入口不说明能力范围与限制
      入口展示能力清单、限制说明、人工出口
      无确认的跨 App 动作
      直接改别的 App 数据
      每个跨 App 动作独立确认页
      替用户做长期决策
      投资、医疗、教育等超出当前任务
      明确拒绝,提供专业资源入口

      Fallback 链:谁做、谁降、谁接手

      层级
      职责
      权限边界
      异常处理
      Human
      最终确认、高责任裁决、接收升级
      通过确认页、撤销、客服入口交互
      在约定 SLA 内响应
      Agent
      意图识别、编排、置信度评估
      不直接执行支付 / 取消 / 改签等高责任动作
      低置信降级;异常升级
      System
      数据源、规则引擎、审计、权限校验
      不生成开放式承诺
      数据不可用时返回明确错误与替代路径

      一句话:Agent 可以准备与编排,人确认与担责;确定性答案优先走 System。

      四类反例,提前躲开

      反例
      表面很 AI
      改写方向
      入口文案:「我能帮你做任何事」
      听起来强大
      改成能力清单 + 限制 + 人工出口
      支付 / 取消由对话框一句话完成
      路径最短
      独立确认页;AI 最多填草稿
      出错只说「抱歉,请重试」
      有礼貌
      给前进路径:撤回、改参数、找人
      所有查询都塞进 LLM
      统一入口
      确定性查询降级为规则 / API

      也要承认反例另一面:探索型任务(旅行规划、开放调研)可以容忍更多不完美输出;低频高复杂、失败后果低的场景,全能入口有时确实更省事。前提变了,矩阵答案也要变。本篇的适用范围,优先是高责任、低容错的任务容器。

      给你一张 A4 自查表

      下次评审「再加一个万能助手」时,抽当前能力清单,逐项问:

        • 这项能力写进了能力范围表吗?不能做的是否也写了?
        • 失败后果是只读尴尬,还是改状态 / 动资金 / 不可撤销?
        • 确定性答案是否仍走 LLM,而不是规则或 API?
        • 高影响动作前,有没有独立确认页(而不只是聊天里的「好的」)?
        • 用户执行后,能否在窗口内检查、撤销或停止?
        • 低置信、敏感话题、用户明确要人时,能否升级到 Human?
        • 升级后有没有响应 SLA,还是「转人工」变成黑洞?
        • 入口是否仍在做开放式全能承诺?
        • 跨 App / 跨系统动作是否各自有确认?
        • 审计日志能否回答:谁授权、做了什么、谁确认?

        适用边界:本文讨论的是高责任任务容器里的范围裁剪与兜底设计,不承诺砍功能必然提升留存或转化,也不主张所有 AI 产品都该一律砍能力。金融、医疗、政务、未成年人等高风险场景,需要额外的专业、安全与合规审核。Apple / Google 案例只说明「承诺与可靠性错位」的公开成本,不能直接复制成中小产品的具体排期决策。

        砍功能不是目的。把全能承诺裁成可控承诺,用户才敢把下一步交给你。

        同系列接着看

        如果你刚在想「万能入口该留什么、砍什么」,可以顺着同一条判断链接着看:

          下篇

          本篇把「留什么、砍什么、谁兜底」写成了 Scope-Cut Matrix。下一篇可以继续拆:确认页最小字段怎么定,或人工升级的触发条件与 SLA 如何写进产品规格。