#AI

Susan STEM
11小时前
App卖不动了,然后呢?我推演了一种AI泡泡 这个问题我是真的很想搞清楚,也是我这几周集中准备研究的重点。跟进这条线也是我现在安排的主线任务之一:推演,押宝,收集这条线上所有的资源。 App 卖不动,本质上并不是因为大家突然不喜欢用软件了,而是因为分发逻辑、用户习惯以及价值交付模式都发生了根本变化,让过去那条“装一个 App → 形成留存 → 再变现”的路径逐渐失效。如今 iOS 和 Android 的入口层被平台牢牢掌控,App Store 与 Google Play 的曝光越来越集中在头部应用,新应用几乎很难自然获得流量。同时,入口被超级 App 吞并——微信、抖音、支付宝等已经演变成“操作系统之上的操作系统”,用户的许多需求可以直接通过小程序、内嵌网页解决,不再需要额外下载独立 App。再加上AI 与 Web 化降低了‘必须下载’的门槛,生成式 AI 可以直接通过网页或多平台插件调用功能,PWA(Progressive Web App)更是让网页具备了接近 App 的体验,从而绕过下载环节。 这些现象几乎成了行业共识。但我是真的经历过那个“万物 App”的年代,当时人人都在学 Kotlin 开发移动应用。如今的变化在商业层面表现得更为明显:获客成本飙升,广告投放、应用商店排名、网红推广成本高得吓人,小型开发者很难回本;生命周期缩短,用户可能只用几次就卸载,因为功能容易被替代,除非形成完整生态,否则靠单一功能长期留住用户几乎不可能;商业模式趋同,过去依赖订阅、内购、广告三种模式就能赚钱,如今同质化竞争严重,用户的付费心理门槛也在不断提高。 别说用户,就拿我自己来说,如今也很少再去下载新的 App 了。从“下载占有”到“即用即走”。首先是安装疲劳——手机里已经有几十个常用 App,对新增安装天然抵触,“能用现有 App 搞定就不装”;功能期望提高——用户不再愿意为一个孤立功能单独安装 App,他们希望这些功能能够嵌入到自己已有的生态体系里,比如微信、飞书、Teams、浏览器插件等。 但是AI界面总不能承载所有功能吧? 如果 App 外壳化 / 接口化 已经成为不可逆的趋势,而 AI 窗口(Copilot、对话框、Agent Hub) 又无法承担所有职能,那么下一个真正的入口/窗口必然会是更贴近具体场景与数据流的形态。我的推演方向是,在现有 App 宿主之上,构建一种能够填补 AI 窗口“非万能”空白的应用生态——即 场景原生入口(Context-Native Entry)。 这种入口不再是独立应用,而是直接嵌入到场景的触发点里。例如,在会议中,日历界面会原生弹出“行动建议”;在设计工具中,用户选中元素时会自动出现 AI 协作气泡;在车机屏幕中,驾驶到达目的地时会直接显示路线与任务执行按钮。它有三个显著特征:第一,零跳转,用户无需离开当前场景即可完成任务;第二,数据即时可用,上下文数据已经在场景内,无需额外授权;第三,执行闭环内建,任务完成后可自动将结果回写到对应的数据源(如 CRM、ERP、日志、交易记录)。 我画了两个示意图:主界面就是宿主(host environment),可以是日历、项目管理软件等;旁边的“泡泡”则是上下文触发的操作入口,而这个泡泡正是未来全球应用开发者共同参与的生态。它看起来像插件,但用户无需安装,由宿主内的 AI 自主决定何时调用。 Calendar: 宿主host environment Action items: 泡泡 (AI自由调用,其他开发者开发) 这种生态的核心特征包括: 能力模块化——功能以插件、微应用或结构卡形式存在,每个模块可以独立更新与授权;用户既可固定常用模块,也可临时调用一次性模块。 上下文可迁移——身份、任务、数据、历史操作等上下文信息在不同模块间无缝传递,避免重复输入。 AI 编排驱动——用户既可直接点击模块,也可用自然语言输入目标,由系统自动选择和组合模块执行。 多入口混合——既支持传统图标,也支持场景气泡、任务栏、语音指令等多种入口,根据任务性质动态显形或隐藏。 半自主闭环——简单任务可自动执行,复杂任务在关键节点需用户确认,执行完成后结果自动回写到对应数据源。 这意味着,未来的应用形态不再以“下载一个 App”作为起点,而是以场景驱动的即时入口作为载体,AI 在背后完成能力调度与组合,用户在前端获得零跳转、上下文贯通、结果可闭环的体验。 如何成为宿主以及泡泡的触发机制 要理解如何让一个应用从“功能提供者”升级为宿主,并能在合适的时机触发上下文气泡,需要先明确宿主的定义和运行机制。 宿主环境 = 上下文源 + 触发点 + 执行容器 + 用户界面 它承担的是一个舞台的角色,为能力模块(Capability)提供完整的执行与交互环境,包括: 触发契机——明确什么时候启动能力(事件触发、条件满足、用户操作等); 上下文数据——运行前必须知道“是谁、在做什么、涉及哪些资源”; 执行通道——调用外部能力所需的网络、权限与运行时容器; 显形界面——用户可见、可操作的 UI(气泡、侧栏、提示条等); 回写目标——执行结果要存回的权威数据源(如 CRM、ERP、文档、日志等)。 如何让任意应用成为宿主 为了具备承载外部能力和触发气泡的能力,一个应用至少需要以下四个开放接口与结构: 触发点 API:允许外部能力监听特定事件,如用户操作、状态变化、定时器触发、数据更新等。 例:会议开始前 2 分钟、文档被选中一段文字、车辆进入充电站。 上下文 API:提供标准化接口,让外部能力读取必要的上下文信息,如当前用户、选中对象、会话内容、位置等。 必须保证数据最小化原则,并在用户授权范围内暴露。 执行 API:提供安全可控的调用方式,让外部能力可以在沙盒环境中运行,并具备函数调用、网络访问、跨模块通信等能力。 支持权限校验和费控机制,防止能力滥用资源。 UI 插入点:为外部能力提供可嵌入的位置,用于显形气泡、侧边栏、弹窗、HUD 等不同形态的 UI。 插入点应与上下文事件绑定,保证用户交互自然、即时。 “泡泡”触发的全流程 当宿主具备上述条件后,一个上下文气泡的触发与执行过程通常如下: 事件监听:宿主通过触发点 API 监测到某个场景事件(如会议即将开始)。 上下文构建:宿主调用上下文 API,生成包含当前用户、任务、数据等信息的标准化上下文对象。 AI 决策:宿主内的 AI 调度器基于上下文,筛选最匹配的能力模块(可从能力目录中动态检索)。 显形触发:在 UI 插入点上显示气泡,提示用户可以执行的操作(或直接开始执行低风险任务)。 能力执行:调用执行 API,沙盒运行外部能力,并实时更新执行状态。 回写闭环:任务完成后,通过宿主的回写通道,将结果存回权威数据源,并刷新宿主界面。 只要协议畅通,全球开发者有能力的开发宿主,能力弱的开发泡泡,组合是天文数字量级的 只要协议畅通,这个由全球开发者共同构建的“巨型开发、应用与工具网络”就能进入几乎自我扩张的状态——它会像互联网早期的 TCP/IP 一样,把原本彼此孤立的能力和数据源接入同一张网络,让调用、组合与分发成为默认能力而非额外集成。能力强的开发者可以构建宿主,承载和调度多种外部功能;能力弱的开发者也能专注于制作单一“泡泡”模块,被宿主按需调用。 一旦协议统一了能力卡、上下文、权限和回写机制,任何能力都能被任意宿主直接使用,不同开发者产出的功能无需点对点适配即可自动兼容,AI 调度器也能跨厂商、跨领域、跨设备自由编排执行链。分发将彻底自动化——不必依赖人工搜索、下载或安装,能力会在符合上下文的场景中自动显形,高质量的能力会被宿主和 AI 持续选用,新能力一旦注册就能零延迟进入全球可调用范围。 这种模式会触发生态自增强效应:接入的能力越多,可组合的可能性越多,衍生出更多新场景;每次闭环执行的结果都会回写到数据源和特征库,使下一轮决策更精准,吸引更多调用,形成“数据—体验—调用”的正反馈飞轮;协议的统一也意味着一次改进可在全网生效。与此同时,生态的边界会不断开放——宿主可通过协议变成流量与上下文的枢纽,小型开发者可以靠单一能力卡或场景编排持续获利,平台还能围绕调用和数据确权发展出分润、信誉、质保、治理等全新商业模式。 换句话说,只要协议打通,组合空间就是天文数字级的,调用、分发和优化会自动发生,整个生态会以互联网式的速度与规模爆发。 这个“协议畅通 + 宿主/泡泡”模式,其实针对的是现有 App 开发和使用模式中的几条核心瓶颈,而且它的结构设计正好能逐一化解。 1. 分发和获客瓶颈 现状 App 必须依赖应用商店、广告投放、内容引流才能被用户发现。 新应用进入成本高,获客成本(CAC)居高不下,小团队往往无法回本。 分发渠道高度集中,头部应用占据曝光,大多数 App 没有生存空间。 突破方式 在协议畅通的模式下,能力(泡泡)不需要用户搜索、下载、注册,而是由宿主在符合上下文时自动分发显形。 分发入口变成多点分布(各种宿主和 AI 调度器),降低依赖单一渠道的风险。 新能力一旦注册,就零延迟进入全网可调用范围,被动获客。 2. 集成和适配成本瓶颈 现状 不同 App、系统、行业的数据和功能接口差异巨大,需要大量定制化集成。 跨系统协作需要重复开发“胶水层”,浪费时间和人力。 突破方式 统一上下文协议、能力描述协议、回写协议,让不同宿主和能力模块之间天然互操作。 开发者一次接入协议,就可以在所有遵循该协议的宿主中运行,不必逐个适配。 AI 调度器在运行时动态组合能力,无需提前硬编码集成关系。 3. 功能封闭与长尾需求瓶颈 现状 App 功能由开发团队预先定义,长尾需求(小众场景)很难覆盖。 用户经常需要跨多个 App 来完成一个任务,效率低下。 突破方式 协议化能力可以被 AI 自由组合,一次性生成专属于某个用户、某个上下文的任务链,哪怕这个链只执行一次也值得。 小众能力也可以生存:哪怕调用量很低,只要在某个链中被用到,就能产生价值并获得分润。 4. 更新和迭代瓶颈 现状 App 更新周期长,功能迭代慢,用户必须整体升级 App 才能获得新功能。 功能和数据常常被锁死在 App 内,迁移和重用困难。 突破方式 能力模块化后,每个能力卡或泡泡可以单独更新、单独授权。 改进一次能力,就能立刻在全网生效(所有宿主和链路同步受益)。 数据闭环让优化路径自动收集反馈,形成持续迭代的飞轮。 5. 用户交互路径瓶颈 现状 用户必须主动切换 App 才能完成任务,跨场景跳转造成体验中断。 每个 App 的 UI 逻辑不同,学习成本高。 突破方式 场景原生入口(泡泡)直接嵌入用户所在的任务上下文,无需跳转。 宿主负责 UI 容器统一化,外部能力复用相同的交互模式,降低学习成本。 一句话总结 这个模式克服了分发集中、集成昂贵、长尾难覆盖、更新迟缓、体验割裂五大瓶颈,让开发者专注能力本身,让用户在场景中即时获得可组合、可闭环的服务。 (1/n)