当AI助手将点奶茶的流程从5个页面压缩成1句话时，产品经理的设计对象正在发生根本性变革。本文深度解析四大厂AI入口争夺背后的'去界面化'趋势，揭示从页面设计到意图模型、混合UI、过程透明度和容错机制的新设计维度，为AI时代的产品经理提供战略转型路线图。
这两天，关于千问30亿免单、元宝10亿红包、四大厂AI入口争夺的分析文章已经铺天盖地。但作为AI PM，我认为我们不该只盯着谁砸了多少钱、谁登顶了AppStore。
我更想聊一个被大多数分析文忽略的细节。
试着回忆一下，你上一次在手机上点一杯奶茶，经历了什么：打开美团 → 搜索瑞幸 → 找到”生椰拿铁” → 选冰、少糖 → 确认地址 → 支付。5个页面，至少12次点击，大约90秒。
现在，在千问的对话框里输入一句”来杯瑞幸生椰拿铁，冰的，少糖，送到公司”，一张确认卡片弹出来，点一下支付，完成。1个输入框，1次确认，大约15秒。
5个页面被压缩成了1句话。
消失的不是App——飞猪还在、饿了么还在、大麦还在。消失的是界面本身。
这意味着产品经理原本最引以为傲的核心技能——画页面、排动线、磨交互细节——正在失效。不是因为你画得不够好，而是用户根本不再需要看到那些页面了。当服务从”用户打开App去找它”变成”AI在对话框里直接调用它”，产品经理的设计对象正在发生根本性的迁移：从设计”用户看到什么”，变成设计”AI理解什么”。
所以我不想讨论谁赢了春节大战，我更想思考一个问题：当界面消失之后，产品经理到底该设计什么？
围绕春节AI大战的讨论已经很多了，这里不再重复”四大厂各投了多少钱”的宏观叙事。我只想指出两个与产品经理直接相关、但几乎没有人深入讨论的结构性变化。
千问30亿免单的真正产物，不是AppStore排名，不是DAU暴涨——而是跑通了一种叫做”不跳端”的体验。
所谓”不跳端”，是指用户从表达需求到完成服务履约，全程不离开千问的对话界面。你在对话框里说”我要去杭州”，飞猪的车票信息直接以卡片形式出现在对话流中；你说”点杯奶茶”，闪购的商品和支付确认直接在对话框内完成。飞猪、饿了么、大麦、盒马——这些App的前端界面被”折叠”进了千问的对话框，只剩下后端服务通过API被Agent调用。
这就是正在发生的App”Headless化”。
如果你做过前端开发或者关注过CMS领域的演进，对”Headless”这个词不会陌生。几年前，网站领域出现了Headless CMS的趋势——内容管理的后端与前端展示层解耦，内容通过API分发到任意前端（网页、App、小程序）。现在，同样的事情正在App层面发生：服务与界面解耦。 App不再需要用户”打开”它，它变成了大模型背后的一个”技能插件”。
这里有一个值得深入看的路径对比：千问 vs OpenAIOperator。
去年1月，OpenAI发布了Operator，一款模拟人类操作网页浏览器的AI助手。它能帮你预订酒店、餐厅，甚至在线购物。听起来和千问做的事情很像，但路径截然不同：
Operator的路径是”在旧世界的界面上做自动化”。 它本质上是一个”自动化鼠标”——AI替你看屏幕、找按钮、点击、填表单。这意味着它仍然强依赖原有App的GUI层。如果美团改了一个按钮的位置、调整了一下页面结构，Operator就可能识别失败。它的稳定性天花板，被它所操作的那个界面决定了。
千问的路径是”直接绕过界面，建立新连接”。 通过MCP、A2A等协议，千问直接调用服务方的后端API。飞猪不需要”被AI看着操作”，而是以结构化接口主动接入千问的Agent调度框架。这也解释了为什么千问的”一句话点奶茶”能扛住上线9小时破千万单的并发——API调用的稳定性和效率，天然高于模拟GUI操作。
前者是在旧楼里装电梯，后者是直接盖了一栋新楼。
第二个信号更加底层：用户与服务之间的交互语言变了。
在搜索框时代，用户输入的是名词关键词的拼接：”杭州 酒店 亲子”。这本质上是用户在适配产品的信息架构——你必须把自己的需求拆解成产品能理解的关键词碎片，然后在搜索结果中自己筛选、比较、决策。
在Agent时代，用户输入的是自然语言的完整指令：”帮我订一个杭州带儿童乐园的酒店，周六入住，两大一小”。这句话里包含了目的地、偏好、时间、人数等完整的需求信息，是产品必须去适配用户的表达方式，而不是反过来。
以前是”用户去找服务”，现在是”服务来接住用户的意图”。
这两个信号——交互的去界面化和需求的自然语言化——共同指向一个结论：产品经理的核心设计对象，正在从”页面”迁移到”意图”。
但”设计意图”这件事，具体怎么做？下面逐一拆解四个新的设计对象。
核心转变：从画页面流到定义数据流。
传统PM的工作流是设计页面流：Home → List → Detail → Cart → Pay。每一步都是一个页面，PM的工作是设计每个页面里”有什么”以及页面之间”怎么跳”。
Agent时代，这条链路变了：User Intent → Slot Filling → Clarification → Action → Confirmation。不再有”页面”，只有”数据流”——AI需要从用户的一句话里提取出足够的信息，填满所有必要的”槽位”，然后执行任务。
用”一句话点奶茶”来做一次完整的实战拆解。
用户输入：”来杯瑞幸生椰拿铁，冰的，少糖，送到公司”
Agent需要从这句话中识别并填充以下槽位：
这张表就是我认为的Agent时代PM最核心的产出物之一：Intent-Slot矩阵表。
它取代了Axure原型图的位置，成为定义产品行为的”源文件”。PM需要为每个场景回答：有哪些槽位？哪些必选、哪些可选？缺失时是推断还是追问？推断的数据源是什么（历史行为、用户画像、上下文）？
而这里面最关键的设计决策是：追问次数。
来看一组对比——
糟糕的Agent，4轮追问，用户崩溃：
用户心态已经崩了——关掉对话框，打开美团，自己点。4轮追问耗时可能比自己在App里点还慢，Agent产品的核心价值”省事”被彻底摧毁。
优秀的Agent，1轮确认，高效闭环：
完成。
差距在哪？优秀的Agent把”杯数、杯型、温度、甜度”这些可选槽位用历史数据和默认值静默填充了，只把最终结果呈现给用户做一次确认。而糟糕的Agent把每个槽位都变成了一轮对话。
如果用户总是需要 3 轮以上的“Prompt 调优”才能得到想要的结果，说明产品的 SystemPrompt或者 RAG 检索能力存在巨大的缺陷。高 FCR 意味着你的产品“懂”用户，而不是让用户去“教”产品。
这也是我认为我们未来 AI 产品的发展方向——在第一次交互中，就完成对核心意图的判定与路径选择，把理解成本从用户侧系统性地迁移到模型与产品设计侧。
延伸思考：数据是诊断，交互是药方
我们在这里强调 FCR 指标，本质上是在用数据给 AI 的“理解力”做体检。但当体检报告显示 FCR 过低（例如用户总是需要多轮纠正）时，解药往往不在算法层，而在交互层。
许多低 FCR 的 Bad Case，其实是因为产品经理把一个本该 One-Shot完成的任务，设计成了冗长的“查户口式追问”。
如何通过 Intent-Slot矩阵 这种设计工具，从根源上消除废话，将 FCR 指标从 30% 提升到 90%？我在另一篇关于交互重构的文章 《
》 中给出了具体的“手术方案”。
数据是显微镜，帮你发现病灶；交互是手术刀，帮你切除病灶。 感兴趣的读者可以去看一看
核心观点：纯对话交互是”反效率”的陷阱。
当前Agent产品设计中存在一个普遍的误区：既然用户通过对话框表达需求，那所有服务都应该在对话中完成。这是错的。
有些任务天然适合语言。”退掉我昨天的订单”、”查一下快递到哪了”——信息密度低、决策路径简单，一句话搞定。
有些任务天然需要视觉。”选电影院的座位”、”比较3个酒店的图片和价格”——信息密度高、需要空间感知和多项对比。想象一下用纯文字选电影院座位——”第8排15号还是第9排12号？”——没有座位图，任何正常人都无法做出决策。
强行用对话完成所有任务，不是在解放用户，是在折磨用户。
PM需要的是一套LUI与GUI的动态切换框架：
这套框架的核心载体，是”Native Card”。它不是一个完整的App页面，而是嵌在对话流中的交互模块——可以带按钮（确认/修改）、带轮播（多选项浏览）、带输入框（补充信息）。PM的新工作不是设计”页面”，而是设计“卡片库”：定义什么意图触发什么卡片、卡片内承载什么交互逻辑、卡片之间如何衔接。
做过车载系统的人，对这套逻辑不会陌生。
车机是天然的Hybrid UI实验场。驾驶场景下，手不能离方向盘，眼睛不能长时间离开路面，语音几乎是唯一安全的输入方式。但你不可能用纯语音完成所有操作。车机领域用了十年时间验证出来的最佳实践是这样的循环：
语音说意图 → “导航去最近的加油站”。LUI最高效，手不用动，眼不用看。
屏幕做决策 → 地图上弹出3个加油站的位置、距离、价格，司机扫一眼选一个。这一步GUI不可替代——你不可能靠”第一个加油站在你的左前方800米，第二个在右前方1.2公里”这种纯语音描述来做空间决策。
语音确认执行 → “去第二个”。回到LUI，干脆利落。
LUI发起 →GUI决策 → LUI确认——这套循环就是Hybrid UI的底层节奏。现在，Agent产品正在重新发现它。
设计原则一句话概括：LUI负责”发起”和”确认”，GUI负责”展示”和”对比”。二者不是替代关系，而是各司其职的协作。
痛点：当界面消失，”进度反馈”也跟着消失了。
传统App里，页面跳转本身就是进度反馈。你看到搜索结果页加载出来了，就知道”搜索完了”；看到订单详情页出现了，就知道”下单成功了”。页面是天然的”状态标记”。
但在对话框里，这层反馈消失了。用户说了”帮我订明天去上海的高铁，靠窗”，然后盯着一个空白的对话框。3秒过去了，5秒过去了，8秒过去了——AI在搜索？在比价？在锁座？还是卡死了？用户完全不知道。
这就是对话式交互的“黑盒焦虑”。
我观察到一个典型的负面体验：某AI助手在帮用户订酒店时，用户发出指令后，界面只显示一个旋转的loading图标。8秒后，突然弹出一个已完成预订的确认页。用户全程不知道AI搜了几家酒店、比较了哪些维度、为什么最终选了这一家。8秒的黑盒之后，面对的是一笔已经发生的消费，以及挥之不去的疑问——”这真的是最优选择吗？”
解决方案是：把AI的思考过程”外化”。
PM需要为Agent定义一套状态流，让用户在每个关键节点都知道”AI走到哪了”：
三条设计原则：
第一，“理解确认”是信任的基石。 在执行任何动作之前，先展示”AI听懂了什么”，让用户确认或纠正。尤其涉及支付的场景，这一步绝不能省略。上面那个8秒黑盒订房的案例，问题就出在跳过了理解确认，直接”帮用户做了决定”。
第二，分步状态远优于单一loading。 “正在处理…”加一个旋转圈，是最糟糕的进度反馈。用户需要知道AI走到了哪一步、还剩几步。这跟传统App的进度条逻辑一样——只不过从视觉进度条变成了文字状态流。
第三，每一步都应该可以回退。 用户看到车次列表后说”算了，换下午的”，AI应该能从”筛选”那一步重新来过，而不是从头开始。对话式交互的”回退”不是按”返回键”，而是用自然语言修正。PM需要预设好：在每个状态节点上，用户可能说什么来修改、中断或回退。
这可能是目前所有Agent交互讨论中最被忽视的维度。
传统App的操作错误成本极低——点错了一个页面，按”返回”，30秒内就回到正轨，用户甚至不会把它当作”错误”。
但Agent的错误性质完全不同。它不是”页面跳错了”，而是**”替你做了一个错误的决定”**——而且这个决定可能涉及真金白银。
把两种场景的容错成本放在一起看：
一个产品如果只有”聪明”没有”可控”，用户是不敢把真正重要的事交给它的。你可能愿意让AI帮你查个天气，但你敢让它”自动帮你订一张3000块的机票”吗？敢不敢，取决于你是否相信”出了问题能兜住”。
PM必须为Agent设计三层容错机制：
第一层：执行前确认。 涉及支付、预订、发送等不可逆操作时，必须有显式确认步骤。Agent不能”太聪明”地替用户直接下单——哪怕它的理解完全正确。因为用户需要的不仅是”正确”，还有”掌控感”。
第二层：执行中可干预。 在多步骤任务的执行过程中，用户应该随时可以说”等等”、”暂停”、”改一下”来打断流程，而不是只能等AI全部做完再修改。这要求Agent的任务编排是可中断、可恢复的，而不是一条不可逆的流水线。
第三层：执行后可追溯。 提供完整的操作日志——AI做了什么、基于什么信息做的、每一步的决策依据是什么。类似飞行器的”黑匣子”。当结果不符合预期时，用户不只是需要”撤销”，还需要理解”哪一步出了问题”，才能建立起对下一次使用的信心。
设计原则：Agent越”自动”，容错设计越要”保守”。
这看起来矛盾，但其实是信任建立的底层逻辑。用户把控制权让渡给AI的前提，是他们相信出了问题有兜底方案。信任的公式是：信任 = 能力 × 可控性。 只有能力没有可控性的Agent，用户用一次就不敢再用了。
讨论完具体的“设计对象”，最后我想聊聊战略层面的位置感。在当前的Agent生态中，我尝试将其抽象为一个三层结构。这也是我在思考自己职业定位时的一张坐标图：
处于OS层的PM， 面临的挑战不再是设计一个App的功能闭环，而是构建一套“AI时代的调度机制”。我看到的不仅是算法匹配，更是规则的制定——当用户的意图模糊时，该分发给谁？当多个服务冲突时，优先级如何判定？这本质上是在设计AI世界的“交通规则”。
处于编排层的建设者， 正在经历一场隐秘而关键的战争。Anthropic的MCP、Google的A2A、以及各类行业私有协议，都在争夺“标准化”的话语权。这一层往往被产品经理忽视，但我认为，未来五年最有权力的位置可能就在这里——谁制定了标准，谁就定义了服务连接的方式。
而对于更多身处插件层垂类公司的PM们， 我感到一种残酷的生存法则正在显现：如果我们的服务仅仅是信息展示（查天气、看新闻），很容易被大模型自身的知识库吞噬；只有那些拥有独家履约链条的服务——能真正送出一份外卖、出一张票、放一笔贷——才能成为不可替代的“黄金插件”。我们的设计重心，不得不从“各种花哨的各种前端功能”，回归到“如何提供最标准、最健壮的API能力”。
这里分享一个我个人的反直觉判断：短期看，OS层在激烈争抢用户入口。但长期看，真正决定这个生态格局的，或许是编排层。 回顾互联网历史，如果服务与入口之间建立了开放的互通标准（像HTTP协议那样），服务提供方就不会被锁死在某一个超级入口内部。谁控制了编排标准，谁就控制了AI时代的“管道”。这就像移动互联网时代，最终赚到大钱的往往不是应用商店，而是底层的云服务和支付基础设施。
写到这里，我对这一轮AI浪潮带来的职业焦虑，我认为是这样的：
第一，界面没有消失，只是被折叠了。 App正在从“用户直接操作的界面”演变为“Agent背后的能力接口”。这不是末日，而是一次形态的相变。就像网站没有因为移动互联网而消失，只是换了一种存在方式继续生长。
第二，传统PM的技能是在迁移，而非消亡。 当我开始把精力从画页面流转移到设计意图模型、混合UI、状态流时，我发现那些底层能力——准确理解用户需求、定义清晰的系统逻辑、在体验与效率之间找到平衡——反而变得更加重要了。
第三，一个值得时刻自问的问题。 如果明天我的产品被剥去所有界面，只剩下一组API，它还能为用户创造什么独特价值？ 这个问题的答案，或许就是我们在Agent时代真正的护城河。
我也开始意识到，纠结Button放左还是放右的时代过去了。现在，我更愿意花时间去打磨一张Intent-Slot矩阵表，去定义一套稳健的状态流。 Agent时代的产品经理，不是不需要画图了——而是我们面前的画布，变了。
本文由 @浩思AI 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。