以后还需要打开App吗?从ChatGPT的新界面说起

图中把直角边输入、斜边结果和滑杆放在一起。按设计，用户可以调整数值，观察斜边如何变化。原本只能读的知识，由此有机会变成可以探索的东西。

这组截图里，类似的变化还出现在旅行建议中：目的地比较、城市详情、筛选条件，都能接在同一段对话里。

我更关心界面背后的产品变化：回答开始长出完成当前任务所需的形态。ChatGPT 最近公开推出的 Intelligent UI，正把这件事变成产品能力。

如果软件能围绕任务临时组织界面，未来的 App 会是什么样？

界面的设计单位，正在从页面转向任务

过去，我们使用一个 App，通常要先判断需求，再找到对应的应用，理解菜单，进入某个页面，最后填写表单。产品经理和设计师要提前把大多数路径画出来，用户沿着路径往前走。

这套方法没有过时。它让高频操作稳定、可预期，也让用户能记住“要做这件事就去那个页面”。但它有个成本：用户得先知道软件把功能放在哪里。

固定页面还有一个作用：把功能边界清楚地展示出来。用户知道这里能做什么，也知道操作后大概会发生什么。任务型界面要获得信任，同样需要交代这些信息。

现在，入口可以先从一句话开始。用户表达目标和限制，系统再决定用文字、图片、比较卡片、表单，还是更完整的交互界面来回应。

OpenAI 在 2026 年 10 月 7 日发布 Intelligent UI。公告介绍 ChatGPT 可以把文字、视觉和交互元素组合起来。

回答可能包含图形、按钮、表单、图表或交互体验。

模型需要判断什么问题适合什么形式，简单文字也仍可能是最佳答案。

这组素材里的勾股定理图，是“理解”问题的一种界面：把抽象关系变成可以观察的变量。旅行比较卡片则把开放问题整理成可扫描的选项。

它们让内容的呈现方式服务于当前任务，不再只是给文字配图。

这次发布中的界面由原生组件库和编译器支撑，可以随着回答逐步出现。模型负责根据问题组织文字、图形和交互，选择合适的组件组合；这并不等于每次回答都从零生成任意程序。

不过，这里需要把三件相近但不同的事分清。

第一种是视觉回答：模型用图片、图表或排版让信息更容易理解。

第二种是对话里的交互组件：用户可以点选、调整，界面根据输入更新。

第三种是第三方 App：开发者提供自己的界面和业务逻辑，还可能连接账号、数据和后端服务。

它们可以在一个对话里衔接起来，但对应不同的产品能力。一次发布也没有把所有软件都变成可随意生成的程序。

截图里的滑杆和旅行卡片，能说明这组素材展示了什么；它们不能证明任意问题都能生成复杂且正确的工具。

入口、界面和服务，可能逐渐分开

我倾向于把未来的变化拆成三层来看：用户从哪里进入，眼前看到什么界面，以及背后由谁真正完成任务。

入口可能越来越像一句意图。比如用户说：“想找个周末能感受节日气氛的地方。”助手先追问时间、预算或同行人，再决定要不要展开一张比较表。

界面则可以跟着任务变化。需要看差异时出现比较卡片；想了解某个选项时打开详情；条件明确后再出现筛选表单。它不必要求用户先在固定菜单里猜到正确位置。

这里可以设想一个未来的旅行产品流程：用户先说想看热闹，补充自己怕冷、预算有限后，比较表就把室内活动、交通成本和天气适应度等条件放到更显眼的位置；用户收藏几个候选，再继续细化行程。

这是一个假想的产品设计，用来说明任务界面可以怎样适应条件变化。它不代表截图中已有实时数据、收藏同步或预订能力。

截图上的天气、票价、节庆信息，也不能因出现在卡片里就自动成为经过核验的事实。

真正履约的服务还在第三层。查库存、读取账户、创建订单、收款或发送通知，都需要连接真实业务系统。

OpenAI 的 Apps SDK讲的是另一条路径：开发者可以定义 ChatGPT 应用的界面和聊天逻辑，并连接自己的后端。

助手界面可以成为服务入口，背后仍要有明确的服务提供者和执行逻辑。

我推测，入口、界面和服务会逐渐从同一个固定容器里拆开。有些 App 会围绕一次目标变成任务工作台。

同一服务也可能从原生 App、网页或助手进入。稳定高频功能仍会留在 App 里。

商业上，用户先把需求交给助手后，应用争夺的可能不只是首页停留和图标点击，还有某项关键任务会不会被选中。

数据是否可靠、服务能否履约、推荐依据是否透明，都会影响这个选择。助手按什么标准挑选服务，也会成为新的产品与商业问题。以上是我的推测，不是 OpenAI 已公布的商业规则。

地图、剪辑、记账、即时通讯等功能，可能仍需要熟悉的原生操作；但用户未必每次都要先打开应用，再从首页开始找。需要一眼看懂、连续探索或跨服务组合时，对话界面可能承担更多工作。

产品经理要重新想清楚“做到哪一步”

界面能随任务变化，产品工作就不只是安排页面和按钮。更重要的是把任务边界和状态说清楚。

助手此时是在提供建议，还是准备替用户操作？

如果需要读取个人资料或调用第三方服务，用户是否知道会分享什么？一个任务现在是草稿、等确认、处理中，还是已经完成？

如果失败，能不能重试、取消或改条件？屏幕上的“成功”提示怎样对应后台真实发生的结果？

例如用户把目的地改成另一座城市，系统应该明确哪些比较条件仍有效，哪些需要重新查询。界面跟着变化时，用户也要知道自己的选择有没有丢失。

这些问题过去也存在，只是现在更容易藏在流畅的对话后面。按钮做得越顺手，用户越可能把“点了”理解成“办成了”。

一个控件的出现只证明用户有了操作入口。它是否触发后端逻辑、是否收到成功回执，需要产品把这条链路交代明白。

我的产品判断是，界面越灵活，状态越要稳定。旅行比较表可以快速重排，但收藏是否跨设备保留？价格过期后，系统如何提示？用户点了预订后，订单状态从哪里确认？

如果模型误解了条件，用户能否直接改掉其中一项，而不用从头开始？如果服务暂时不可用，原有信息能否留下来？这些问题都属于交互设计的一部分。

这些细节决定它是一个聪明的演示，还是可以托付真实任务的产品。

产品经理的工作会从“把用户带到正确页面”，扩展到“让系统知道自己能做什么，以及做到哪里必须停下来”。

对理解和比较，界面可以轻一些；涉及钱、账号、个人资料或不可逆结果时，权限和确认就应该清楚可见。

风险不能只靠多一个确认按钮解决。真正可靠的体验还需要准确的数据、可追溯的操作记录，以及出错后的恢复路径。

模型可以帮忙组织过程，产品仍要对用户看到的状态和实际服务之间的对应关系负责。

灵活界面也需要克制

每个问题都配一张动态图表，不会自动让产品更好。官方说明也强调，简单文字有时更合适；用户可以表达呈现偏好，但具体布局仍会变化。

动态界面还会带来新的体验要求：内容是否易读，控件是否可访问，状态刷新后是否保留，等待是否能被理解，第三方数据是否及时。

截至 OpenAI 当前的帮助文档，Intelligent UI 适用于 ChatGPT 的 Chat 页面，不适用于 Voice 和 Work tab。

某些组件可以在刷新对话后保留状态，但不会跨对话保留。

产品能力还会变化，这些限制应按当下说明理解。

我会把它看作软件交互方式的一次扩展：系统不再只回答内容，也开始决定答案应该以什么形态出现；但界面越接近真实操作，用户就越需要知道数据来自哪里、操作会发生什么、完成与失败如何判断。

未来的 App 会怎样组合？

用户可能从对话里开始任务，在临时工作台里比较和调整，再由稳定的原生 App 或后端服务完成需要账户、权限和持续状态的部分。界面可以按需变化，服务作出的承诺和最终结果仍要清楚可见。

这会改变我们设计产品的起点。过去先问用户要进入哪个页面；现在可以先问他想完成什么。页面仍然重要，只是它不必永远是用户开始工作的第一步。

那么，你愿意让 AI 参与到哪一步？帮你解释、替你筛选，还是让它执行涉及账号或钱的操作？欢迎留言说说你的边界。