10个撑不过AI时代的UI模式

AI 正在把 UI 从“执行界面”改写为“判断界面”。

原文信息

• 原文标题：10 UI patterns that won’t survive the AI shift
• 作者：Taras Bakusevych
• 来源：UX Collective
• 原文链接：https://uxdesign.cc/10-ui-patterns-that-wont-survive-the-ai-shift-002cb9b853ae?source=rss—-138adf9c44c—4

开篇导读

很多产品团队今天都在修一个看不见的坑：有些 UI 还“能用”，但它们已经不再值得存在。

过去这些年，我们不断打磨仪表盘、数据录入表单、搜索流程、筛选侧边栏、设置向导、通知流、FAQ 页面和新手引导。

但这些界面都建立在同一个前提上：真正干活的是人。

而现在，AI 正在替换掉这些界面最初存在的理由。不是因为这些模式坏了，而是因为它们的底层假设开始失效了。

设计师过去问的是：

“用户在这里需要做什么？”

而现在，新的问题变成了：

“哪些工作应该由 AI 先做完，再交给人判断、修正和兜底？” 💡

[译者注] 这篇文章最有价值的地方，不是罗列几个“会消失的界面”，而是给出了一条非常清晰的产品判断标准：凡是以“人类手工执行”为默认前提的 UI，都要重新审视。

10个正在失势的旧 UI 模式

作者先给出了一张很有代表性的清单。它不是说这些模式明天就会消失，而是说它们都面临同一种结构性压力：

• 设置向导：从“逐步盘问”走向“意图推断”
• 筛选侧边栏：从“手动指定条件”走向“自然语言表达意图”
• 搜索结果页：从“链接排序”走向“答案合成”
• 数据录入表单：从“人工誊写”走向“AI 抽取后确认”
• 仪表盘：从“指标铺满屏”走向“异常主动浮现”
• CRUD 表格：从“逐行逐列修改”走向“批量意图 + 差异审查”
• FAQ 页面：从“翻文档”走向“上下文感知式 AI 支持”
• 新手引导：从“预设式教学”走向“即时解释”
• 通知流：从“按时间堆消息”走向“AI 编排的决策面板”
• “新建”按钮：从“空白画布”走向“先生成一个可用初稿”

8股力量，正在同时挤压旧 UI

作者认为，旧 UI 模式之所以一起失势，不是因为某个单点功能升级，而是因为 AI 已经跨过了多条能力边界。

1. 执行自动化

AI 已经可以在明确约束内，把多步骤流程从头跑到尾。

所以，凡是那种“指导用户一步步完成、而系统自己本可以直接做完”的界面，都开始承压。

2. 环境上下文理解

系统现在可以读取你的文件、工具、操作历史和行为上下文，而不需要你一项项手动告诉它。

所以，那些本质上只是为了“收集上下文”的界面，也会越来越不合理。

3. 自然语言意图解析

系统已经能把人类非结构化表达，映射成具体动作。

所以，要求用户把目标拆成筛选器、下拉框、布尔查询的界面，都会越来越显得笨重。

4. 多模态上下文注入

机器现在可以同时理解图片、语音、文档和屏幕内容。

所以，只接受“文本框 + 结构化字段”的界面，会越来越受限。

5. 生成式初稿

AI 几乎可以根据一句简短描述，先产出任何内容的第一版。

所以，凡是把用户扔到“从零开始”的界面，都开始显得反人性。

6. 按需解释

系统可以感知你正在卡住的地方，并在那个时刻给出解释。

所以，把大段通用教学预先塞给所有用户的界面，也不再高效。

7. 交互与信息成本压缩

智能体可以把多步流程压成一次动作，也能把高密度信息压缩成摘要。

所以，凡是把一个简单意图拆成多屏、多步、多控件的界面，都在被重新审判。

8. 智能分诊与优先级判断

智能体已经可以根据紧急程度、相关性和上下文，对信息做优先级筛选。

所以，那些“把所有信息都展示出来，再让用户自己筛”的界面，注定会越来越难用。🚀

模式一：多步骤设置向导，正在变成摩擦源

旧模式：Multi-Step Setup Wizards

设置向导本来是为复杂配置而生的。它把过程拆成线性步骤，默认用户必须理解产品术语，并且按顺序亲自执行。

但这个前提已经站不住了。

当 AI 能从一次关键动作里推断上下文时，比如你刚接入了一个代码仓库、上传了第一份文档、发起了一次日历邀请，那么后面的连续“盘问”就几乎只剩下摩擦。

很多时候，用户一句自然语言动作所暴露的意图，远比十个下拉框和开关页更准确。

作者举了一个很典型的例子：在 HubSpot 里创建一张销售报价单，需要穿过 7 个连续页面。销售代表要手动选择联系人、补公司信息、配置商品项、选择签名选项、设置付款条件、挑模板，再预览。

而问题在于：这些信息有很大一部分，CRM 里其实已经有了。

新模式：Intent Inference + Confirmation

替代它的，不是“更漂亮的向导”，而是AI 根据用户第一步有意义的动作先完成组装，然后再让用户审核和纠错。

也就是说，用户不再回答那些系统本可以自己推断的问题，而是改为判断系统哪里猜错了。

Shopify Sidekick 就展示了这种新交互。

它会分析店铺数据，发现商家最畅销的商品并没有被重点展示，于是主动建议创建一个“Best Sellers”合集并配上折扣。

商家点一次 “Get started” 后，Sidekick 会自动完成整条链路：查询销售数据、找出收入最高的商品、创建集合、自动填充、配置折扣并设置活动。

在这个流程里，商家审查的是结果，而不是一串表单字段。

模式二：手动搜索 + 筛选侧边栏，不再是主路径

旧模式：Manual Search + Filter Sidebars

传统搜索有一个很隐蔽的问题：它要求用户做两次翻译。

第一次，把自己的真实意图翻译成关键词。

第二次，再用复选框、滑块、下拉菜单，把这个意图重新拆成系统能理解的参数。

这其实完全违背了人类自然表达需求的方式。

一句自然语言就能说清楚的需求，比如：

“在布鲁克林找一套价格适中、靠近好学校、不是底层的两居室”

过去却要靠一个关键词搜索，再加上 6 次筛选操作才能表达完整。

作者认为，筛选侧边栏曾经是关键词搜索时代非常了不起的 UX 发明；但在语义搜索和向量搜索出现后，它更适合作为兜底层，而不是主入口。

比如 Nike 的商品页会先甩给你 597 双男鞋，然后让你手动继续缩小范围。它提供了 54 个尺码按钮、10 个颜色块，以及价格、宽度、运动类型等筛选面板。

Expedia 在“巴黎活动”搜索里也是同一路数：关键词框、旅客评分单选、推荐项复选框、地点复选框。

但问题在于，用户很多时候其实已经非常清楚自己要什么，比如：

• “黑色足球鞋，42 码”
• “靠近埃菲尔铁塔、适合家庭的游船项目”

界面却逼着他一个筛选器一个筛选器地表达。

新模式：Semantic Intent Resolution

新模式是把自然语言输入面板放到搜索入口的第一位。

用户直接说目标，系统一次性解析全部约束条件。

视觉筛选器不会完全消失，但它会退居为“二级纠偏机制”，不再与主意图输入竞争。

新的交互也不是“重新配置一遍搜索”，而是多轮细化，比如：

“再便宜一点，离海边更近一点。”

KAYAK 的 AI Mode 已经有点这个味道了。

用户直接输入：

“12 月 23 日住一晚，离洛克菲勒中心半英里以内的纽约酒店”

没有表单字段，没有多 tab 反复切换。系统会解析意图、抓取实时价格，并返回可执行结果，同时提供 “Ask follow up…” 让你继续追问。

一句话，干掉了原来三套搜索表单的工作量。

在招聘场景里也一样。

与其配置 15 个筛选字段，招聘人员可以直接输入：

“招聘一位有 3 年以上 SaaS 或 B2B 产品经验的 Product Designer，擅长 UX research、wireframing、prototyping 和 UI design。”

接着，Copilot 去评估 200 位候选人，并返回打分结果：

• 128 位优秀匹配（90%+）
• 50 位高匹配（80% 到 89%）
• 18 位中等匹配
• 4 位低匹配

更关键的是，每个候选人都附带按条件拆解的评分说明，比如：

• SaaS experience: 5
• UX research skills: 5
• Figma-based wireframing: 5

同时解释为什么匹配。

候选人的主要动作也只剩下两个：Hide 或 Shortlist。

这时，筛选侧边栏已经被“单次意图描述 + 可解释的置信度结果集”替代了。

一个必要提醒：筛选器不会消失，只会退位

作者特别提醒，筛选器并不是没用了。

在很多探索式场景里，自然语言并不能替代筛选器的作用。比如用户逛 Nike，并不总是明确知道自己想买什么。他可能只是想看看自己尺码下有哪些可选颜色，或者不同价格带里都有什么货。

这时，筛选器承担的是“让选项空间可见、可浏览”的职责。

所以，真正的变化不是“从筛选器到无筛选器”，而是：

筛选器从主发现机制，退回到次级细化层。

模式三：手工数据录入表单，正在失去正当性

旧模式：Manual Data Entry Forms

如果信息明明已经存在于别处，比如邮件、文档、发票、日历、扫描图片里，却还要用户手工再打一遍，那么这其实就是一笔典型的 UX 债。

文档 AI 出现后，这种债已经可以在“抽取层”被直接消掉。

传统表单一直在优化输入摩擦，比如字段顺序、Tab 流程、校验逻辑，但它几乎从来不追问一个更根本的问题：

为什么还需要人来输入？

真正会留下来的，不是“字段”本身，而是字段的职责变化。

它会从“主数据录入口”，变成“AI 抽取结果的确认面板”。

设计重点也会从“怎么让输入更顺滑”，切到“怎么告诉用户，AI 哪些地方高置信、哪些地方低置信”。

QuickBooks 的手工报销录入就是旧模式的代表。收款方、付款账户、购买日期、付款方式、参考编号、标签、分类、描述、金额，每个字段都要用户自己填或选。

收据虽然作为附件上传了，但系统并不会真正读取它。

结果就是：收据里的信息，和表单里的信息，被用户重复输入了两次。

新模式：AI Extraction + Confidence Signaling

替代方案是：AI 从源文档、邮件或图片中抽取数据，并尽可能预填所有字段。

表单本身不一定消失，但它会变成一个差异视图：

“这是我识别出来的内容，请确认或修正。”

高置信字段应该有明显的视觉状态；低于置信阈值的字段则要明确标记，要求人工复核。

QuickBooks Autofill 就是这个方向。

用户把 PDF 或照片拖进面板后，AI 会在几秒内读出供应商、地址、账单编号、日期、付款条件、行项目和总额。

表单还是那个表单，但用户的角色已经反转了：

不是去输入缺失项，而是去改正错误项。

模式四：静态仪表盘和预制报表，会被异常面板替代

旧模式：Static Dashboards & Pre-Built Reports

无论是定时报表，还是静态仪表盘，本质上都在回答几个月前由设计者和实现者提出的问题。

满屏 KPI 网格展示的是“我们当时觉得重要的一切”，而不是“此刻对用户最相关的东西”。

这种设计优化的是覆盖面，而不是相关性。

于是，用户要自己扫 20 个指标，找出哪个发生了变化；更糟的是，很多变化根本不会被注意到。

AI 分析能力出现后，几乎任何问题都能被实时提出和回答。

因此，仪表盘的角色会从“展示全部”，转为“主动浮现值得调查的异常”。

指标密度会让位给解释、洞察摘要和建议动作。

Cloudflare 会把 requests、errors、CPU time、wall time 这些指标以静态数字块展示出来。

Google Analytics 则把报表类别堆在一个侧边树上，让用户自己钻到 Realtime、Leads、Audiences、Traffic、User engagement 等层级里找数据。

这两种仪表盘都有同一个问题：所有信息的视觉权重几乎一样。

没有任何地方告诉你：

• 到底哪里变了
• 什么最重要
• 下一步应该做什么

用户自己成了异常检测器。

新模式：Exception Surfaces + Conversational Investigation

替代它的，是一种“异常优先”的界面。

系统持续监控，只把“变了什么、为什么变”推到前面。

这类仪表盘只回答一个核心问题：

“我为什么会看到这件事？”

更深层的问题，则交给自然语言查询入口按需展开。

于是，主配置界面也会变化。重点不再是摆图表，而是设阈值、设告警、设升级规则。

Shopify Sidekick Pulse 就在往这个方向走。

它不会先给你一面指标墙，而是直接基于店铺数据抛出机会建议，比如：

• “Hearthside Hoodies 在 90 天内带来了 48.7 万美元自然销售额，可以考虑做一波 Hoodie Season 活动”
• “每月有 257 位购物者进入结账页却没有完成支付，建议建立弃购召回邮件”

每条洞察后面，都直接跟着动作按钮，比如：

• Build new year campaign now
• Build cart recovery strategy

此时，商家响应的是建议，而不是图表。

Amplitude AI Agent 更进一步。

一个 PM 只要提出 “Optimize Conversion”，智能体就会先找出流量和转化率最高的页面，再追问你要聚焦哪个页面。

当你选定定价页后，它继续拉取 session replay 数据，识别具体摩擦点，比如：

• 1,195 次点击套餐标题却无反应
• 340 次 CTA 按钮上的 rage clicks

随后总结根因，并给出 3 个具体策略：

• Clickable Plan Headers
• Modal Popover
• Affordance Banner

而且每个策略后面都带着一个 Generate Variants 操作。

原本可能要数据分析师折腾一整天的调查，被压进了一条对话线程里。

模式五：CRUD 表格，不该再逐条逐格改数据

旧模式：CRUD Data Tables

CRUD 表格的默认假设其实非常单一：

一个人，一次改一条记录，一个字段一个字段地改。

在只改一个联系人、更新一张工单时，这个模型还能工作。

但只要你的意图涉及几十条、几百条记录，它马上就会崩。

真正的断裂在于：用户的思维方式，与界面的操作方式根本不一致。

一个商品运营想到的是：

“把所有 Q3 价格上涨 12%，但入门档不变。”

一个运营负责人想到的是：

“把 Anna 手上的所有未关闭工单都转给 James，并把超期的提升优先级。”

一个 PM 想到的是：

“把所有来自企业客户的功能请求都标成高优先级。”

这些在用户脑中都是一个决策。

但 CRUD 表格只能把它们拆成几十次、上百次独立编辑。

HubSpot 的 Contacts 表就是典型代表。6 条记录，每条都要点进单元格、选下拉值、保存。只是把 6 个联系人的 Lead Status 统一改掉，就要做 6 次独立操作，而且每次都弹一个绿色提示条确认。

Plane 的项目追踪器也是类似模式。每个工作项都要打开成完整详情页，里面有 12 个属性字段：State、Assignee、Priority、Start date、Due date、Labels 等等，全都一次改一个。

如果团队重组后要把 20 个任务重新分配给别人，你只能：

• 打开
• 修改负责人
• 关闭
• 重复

界面把每条记录都当作独立编辑会话。

新模式：Bulk Intent + Diff Review

替代方案是：用自然语言一次性描述批量意图，再用差异审查界面确认变更。

比如用户说：

• “把所有 Q3 价格上涨 12%，但 starter tier 不变”
• “把所有 Anna 的未关闭工单转给 James，并把优先级改成 high”

系统会先生成完整变更集。

用户接下来看到的是摘要：

• 一共改了 184 条记录
• 涉及 2 个字段
• 每一类变更的前后差异是什么

然后再选择：

• 全部接受
• 按组接受
• 驳回单条
• 调整指令后重新生成

这时，用户的角色会从“逐行操作者”，变成“意图作者 + 变更审查者”。

表格本身仍然有价值，但它更适合作为验证界面，而不是主编辑界面。

整个交互模型被倒过来了：

以前是“先做完，再祈祷别出错”；

现在是“先描述清楚，再确认它确实正确”。 ⚠️

作者还给了 Airtable 的例子。

当你输入：

“Create agents to research company differentiators and estimated revenue”

Airtable 的 AI 会自动扫描 Competitors 表，对每家公司做网页研究，然后批量补全两列：Differentiators 和 Estimated Revenue。

Nestle、PepsiCo、Coca-Cola、Mondelez、Kraft Heinz，每一行都会拿到定制化摘要和收入估算，整个过程不需要任何手工改单元格。

Field Agents 已经不只是 Autofill 了，它还能分析附件、从网页上找图、分类素材、研究人物。

表格负责描述需要什么，智能体负责逐行把活干完。

模式六：静态 Onboarding、FAQ 和帮助文档，正在退居后台

旧模式：Static Onboarding, FAQ & Help Docs

产品导览、气泡式 walkthrough、教程遮罩层，默认假设是：每个用户都需要在同一时刻、用同一种方式接受同一套介绍。

帮助中心这种“可搜索的静态文章库”也默认用户能把自己的具体问题，拆成文档分类，再读一篇通用文章，然后自己把它映射回眼前的问题。

但现实是，多数用户描述的是症状，不是系统架构。

静态 FAQ 回答的是写文档的人预想中的问题。

上下文 AI 支持，回答的是用户在此刻、带着当前账号状态、当前错误上下文和前置操作历史真正遇到的问题。

因此，帮助中心会越来越像 AI 的训练语料和知识底座，而不再是用户必须亲自浏览的主要终点。

Attio 的支持界面就是传统文档树：Reference -> Managing your data -> Lists -> Bulk update lists and views。

用户得自己在嵌套侧边栏中寻找关于 CSV 导入和 Entry IDs 的说明。

Notion 的首次使用体验也类似，它会直接给你一份 checklist：

• “Click anywhere below and type /”
• “Type /page to add a new page”
• “Find, organize, and add new pages using the sidebar”

这些都是在预设时刻投放的通用说明。

问题在于，清单并不知道用户究竟想搭什么；文档也不知道用户刚刚做了什么、失败在哪里。

新模式：Contextual AI Support

替代方案是对话式 AI 支持，而且答案必须是上下文化的。

系统应该知道：

• 用户当前在哪个页面
• 遇到了什么错误
• 用的是哪个套餐
• 在提问前刚做过什么

系统还应该观察行为，只解释“现在有用”的东西，而不是“也许以后有用”的内容。

随着用户熟练度上升，解释还应该越来越短。

而当 AI 置信度跌破阈值时，升级给人工支持应该是设计好的兜底机制，而不是默认路径。

换句话说，FAQ 的存在，是为了喂 AI，不是为了让用户自己一篇篇翻。

作者还提到一个更激进的方向：屏幕共享型 AI 支持。

用户有 3 种输入模式：

• Talk
• Webcam
• Share Screen

点开 “Share Screen” 后，AI 能直接看到你的 IDE、电子表格、设计工具。

你只需要口头描述问题，就能得到基于实时上下文的语音指导，不需要打字、不需要搜索，也不需要再跳进帮助中心。

这种模式还没有在产品里大规模普及，主要受制于成本、延迟和隐私问题。

但它明确指向了一个方向：

未来的支持系统，会优先“看见你的上下文”，而不是等你费力描述上下文。

模式七：传统通知流，正在被 AI 决策面板替代

旧模式：Traditional Notification Feed

通知这种“拍一下肩膀”的产品设计，诞生于一个信息稀缺时代。

当时，一个产品一天可能只发生几件值得提醒的事。

但今天，一个用户可能同时在几十个产品里收到上百条通知。

于是，“推送越多，参与越高”这套逻辑已经彻底反过来了。

真正理想的通知，是那种能替代另外 10 条低价值通知的通知。

传统通知流的根本问题在于：

它把所有事件都当成同等重要。

同事给你点了个赞，和生产系统挂了，可能在视觉上拿到的是同样的权重。

然后用户自己去扫描、忽略、错过真正重要的东西。

Jira 会把每条任务更新都列成独立条目。

Sprout Social 会把同一个人发来的 14 条近似通知并排展示，审批、驳回、回复都差不多一个样。

一个失败的发布，和一个例行审批，看上去同样“值得一看”。

用户只能自己翻完整个列表，才能找出什么真正重要。

新模式：AI-Curated Decision Surfaces

新模式里，AI 充当的是分诊层。

它基于上下文、紧急程度、与用户当前目标的关系以及系统状态，来判断什么值得打断你。

低优先级更新被打包成结构化摘要。

高优先级事件则被升级展示，而且必须附带足够上下文，让用户能立即行动。

通知不再只是：

“出事了。”

而必须进化成：

“出了什么事，为什么重要，你现在该怎么做。”

这样，通知就从“提醒流”变成了“决策面板”。

Watchdog 的呈现方式就是这个方向：它把一次事故串成因果链。

• Root Cause
• Critical Failure
• Impact

一次部署破坏了某个接口，4 个服务随之退化，183 个用户受影响。

工程师看到的不是一长串告警，而是一条完整叙事：发生了什么、为什么发生、影响有多大。

[译者注] 原页面最后一张事故图与前一张通知流图片在抓取结构里出现了资源复用，导出时保留了现有链接位置。若后续你希望我进一步做“图文一一校对版”，我可以再单独补一次。

模式八：“新建”按钮，不该再把用户丢到空白页

旧模式：“Create New” Buttons

“New Document”“New Slide”“New Project” 这类按钮，默认用户要从零开始。

它假设创作一定起始于：

• 一张空白画布
• 一个闪烁光标
• 一张空电子表格

这种默认路径，其实只对非常熟练、非常明确自己想要什么的专家用户友好。

而对绝大多数人来说，它制造的是“空白恐惧”。

新模式：Generate / Suggest / Continue Flows

替代方案是：

Generate / Suggest / Continue

也就是从意图开始，而不是从零开始。

用户不再先面对一块空白区域，而是先描述：

• 主题
• 目标
• 参考
• 约束

然后系统给出第一版草稿，用户基于它反应、修改、挑选。

于是，“创作”会越来越像“策展”：

第一个创造性动作，不再是从无到有，而是对已有候选结果作出判断。

这个变化并不只发生在文档里，还会扩展到：

• 演示文稿
• 图片
• 邮件
• 代码
• 表格
• 工作流

这不是切换，而是一场迁移

作者反复强调：这些旧模式不会一夜消失。

Zillow 还会保留筛选侧边栏，PowerPoint 还会保留空白幻灯片，HubSpot 还会保留 7 步报价向导。

而且它们也确实应该保留。

因为并不是每个用户都能用 AI，也不是每个场景都值得跨过信任门槛，更不是每个边缘情况都已经被覆盖。

真正发生的，不是开关式替换，而是迁移：

• 旧模式从默认项，退成 fallback
• AI 模式从实验项，升成 primary

设计师今天真正该做的，是判断你产品里的每一块屏幕：

• 它现在处在这条光谱的哪里
• 6 个月后又应该处在哪

最终能存活下来的界面，不是那些还要求人类像计算机一样执行步骤的界面。

而是那些让人类判断力更强的界面。

从执行型 UI，迁移到判断型 UI

这是作者给出的最有用判断框架，也是整篇文章最值得记住的一句话。

Execution UI

帮助人类执行确定性工作：

• 录入数据
• 配置规则
• 跟着流程走
• 做重复操作

它的空间正在缩小。

因为一旦 AI 能自动执行，这些界面的存在理由就会不断减少。

Judgment UI

帮助人类评估、引导和纠正机器完成的工作：

• 审查输出
• 验证变更
• 理解推理过程
• 在异常情况下介入

它的空间正在扩大。

因为 AI 接手的自主工作越多，人类就越需要更好的监督界面。

[译者注] 如果你做的是 AI 产品，这段几乎可以直接拿来做设计评审的判断标尺：

• 这个页面是在帮助用户“执行”工作？
• 还是在帮助用户“判断”AI 的工作？

未来真正值得投入的，往往是后者。

文章结语

作者提到，这篇文章最初发布在自己的 Substack 专栏 Syntax Stream，主题聚焦在人机协作设计原则上。

而这篇文章真正点破的是一个经常被忽视的事实：

AI 不是在给旧界面加一个聊天框，而是在重写界面的职责分工。

UI 不再只是操作机器的面板，而会逐渐变成人类监督 AI 的工作台。

笔者锐评

国内很多产品现在做 AI 化，常见动作还是“旧页面不动，右下角塞个对话框”，看起来像升级，实际只是贴皮。

真正的改造，不是给老 UI 加 AI，而是老老实实重问一句：这一步到底还该不该让人亲手做？

谁先把“执行界面”改造成“判断界面”，谁才更可能做出下一代 AI 产品；否则，大概率只是把 2020 年的表单，换成了 2026 年的提示词入口。

---

求点赞 👍 求关注 ❤️ 求收藏 ⭐️你的支持是我更新的最大动力！