从点击流到会话流，AI+ 如何塑造超级APP的使用体验～

Geek_Vision
0 阅读8分钟

超级APP服务做多以后，入口问题迟早会出现。

用户想开发票，要先找订单；想查账单，要知道入口在“资产”“我的”还是“服务”；想预约办理，还要在城市、网点、日期、材料几个页面之间来回切。点击流能记录这些路径，也能告诉团队用户在哪里流失，但它解决不了一个更底层的问题：用户本来就不想理解APP的菜单结构。

超级APP过去解决的是“把服务装进来”，下一步要解决的是“让服务被更快调用”。AI进入APP以后，体验变化不只是多一个聊天框，而是服务入口开始从“点击页面”转向“表达需求”。用户说一句话，系统理解意图、补齐参数、匹配服务，再把对应小程序页面、卡片或表单推出来。这就是从点击流到会话流的变化。

点击流优化路径，会话流承接意图

传统超级APP优化的是路径：入口放哪里、搜索怎么召回、菜单怎么分层、跳转链路能不能少一步。路径越短，转化通常越好。 在这里插入图片描述

但当服务越来越多，路径优化会遇到上限。首页不能无限堆入口，搜索也要求用户知道业务名称。很多时候，用户不是不知道自己要什么，而是不知道在超级APP里该怎么找到。

比如“帮我把上周那笔订单开票”，页面路径可能是：

订单列表
→ 筛选订单
→ 订单详情
→ 发票入口
→ 填写抬头
→ 提交开票
→ 查看状态

会话流要做的，是把这条路径前面的“找入口”压缩掉。用户表达需求，超级APP直接定位到可执行服务。

一条比较清晰的工程链路是：

用户表达需求
→ FinClip Chatkit会话入口
→ 意图识别和参数补全
→ Skill Router匹配服务
→ FinClip Runtime打开小程序
→ 小程序页面、卡片或表单承接
→ 结果回到会话

这里的Chatkit承担会话入口和上下文承接；Skill Router负责服务匹配、权限判断和页面路由；小程序 Runtime负责运行小程序；小程序继续承接具体业务流程。

对超级APP来说，这条链路的意义在于：服务越多，入口不一定越复杂。大量小程序服务可以继续沉淀在APP内部，但用户触达它们的方式，从点击目录变成会话调度。

Chatkit不是客服浮窗

很多超级APP第一次做AI入口，容易把它做成客服问答。用户问一句，AI答一句，看起来有智能，但对核心业务帮助有限。

更有价值的会话入口，至少要处理三件事：

  • 拿到当前场景：用户从订单详情页进入会话，问“这个能不能开票”，系统应该知道“这个”是哪笔订单。
  • 知道可调用服务：账单、发票、客服、预约、权益等能力要被整理成Skill。
  • 返回可交互结果：不要只回复“请前往发票页面”，而是直接打开小程序页面或推送服务卡片。

接入层可以这样设计。下面是项目封装示意，具体字段和方法需要按实际SDK版本、初始化方式和鉴权方案调整：

import { ChatKit as FinClipChatkit } from '@finclip/chatkit';

type OpenChatEntryOptions = {
  currentUser: {
    id: string;
    level?: string;
  };
  currentPage: string;
  scene: string;
};

export async function openAiServiceEntry(options: OpenChatEntryOptions) {
  const { currentUser, currentPage, scene } = options;

  return FinClipChatkit.open({
    mode: 'floating',
    entryPoint: 'home',
    userContext: {
      userId: currentUser.id,
      memberLevel: currentUser.level ?? 'default',
      currentPage,
      scene
    },
    hitlConfig: {
      enabledOperations: ['submit_invoice', 'payment', 'modify_profile'],
      confirmTimeout: 30
    },
    skillRegistry: '/api/ai/skills'
  });
}

这段代码重点不是open方法本身，而是把页面上下文、用户身份和关键操作确认传给会话层。没有上下文，AI只能泛泛回答；有上下文，才可能把“这个订单”“本月账单”“附近网点”落到具体服务。

Skill是会话流的业务地图

AI不能直接猜页面，也不应该直接绕过业务系统调用接口。超级APP里的每个可调用服务，都需要一份Skill描述，说明它能处理什么意图、需要什么参数、打开哪个小程序、返回什么结果。

以电子发票为例：

{
  "skillId": "invoice-skill",
  "name": "电子发票",
  "intents": ["开发票", "补开发票", "申请电子发票"],
  "params": [
    {
      "name": "orderId",
      "required": true,
      "source": "context_or_select"
    },
    {
      "name": "invoiceTitle",
      "required": true,
      "source": "user_confirm"
    }
  ],
  "miniApp": {
    "appId": "invoice-miniapp",
    "path": "/pages/apply/index"
  },
  "permissions": ["readOrder", "getUserInfo"],
  "result": {
    "type": "card",
    "fields": ["invoiceStatus", "downloadUrl"]
  },
  "fallback": "native://invoice/help"
}

这份配置要解决三个问题：AI能不能识别这个服务，参数缺失时怎么补，服务异常时怎么兜底。Skill写得越泛，后面越难治理；早期更建议按可执行动作拆，比如“账单查询”“电子发票”“预约记录”，不要直接做一个笼统的“订单服务”。

小程序承接，比纯聊天更稳

把所有操作都塞进聊天窗口，落地时会很麻烦。表单校验、支付确认、敏感字段修改、失败回退，这些本来就是APP和业务系统已有能力，没必要在对话框里重写一遍。

更稳的方式是：会话负责找到服务，小程序负责完成服务。

项目里可以把Skill调用封装为统一入口：

type SkillInvokeParams = {
  skillId: string;
  appId?: string;
  path?: string;
  query?: Record<string, string>;
  fallback?: string;
};

export async function invokeMiniProgramSkill(params: SkillInvokeParams) {
  const skill = await SkillRegistry.find(params.skillId);
  const query = params.query ?? {};

  if (!skill || skill.status !== 'online') {
    return ChatResult.fail('service_unavailable');
  }

  const fallback = params.fallback ?? skill.fallback;

  if (!HostVersion.supports(skill.minHostVersion)) {
    if (fallback) NativeRouter.open(fallback, query);
    return ChatResult.fail('host_version_unsupported');
  }

  if (!PermissionGate.check(skill.permissions, query)) {
    return ChatResult.fail('permission_denied');
  }

  try {
    const result = await FinClipRuntime.open({
      appId: params.appId ?? skill.miniApp.appId,
      path: params.path ?? skill.miniApp.path,
      query
    });

    return ChatResult.card(result);
  } catch {
    Monitor.report('mini_program_skill_failed', {
      skillId: params.skillId,
      appId: params.appId ?? skill.miniApp.appId
    });

    if (fallback) NativeRouter.open(fallback, query);
    return ChatResult.fail('fallback_opened');
  }
}

这里的FinClipRuntime.open是项目里对小程序打开能力的一层封装，不是固定SDK版本的原始接口。真实项目还要结合端类型、离线包策略、登录态同步和启动参数做适配。

这段调用链有几个点不能省：Skill状态检查、宿主版本检查、权限校验、失败上报和原生fallback。AI入口一旦给到用户，最怕的不是“不够聪明”，而是把用户带到不可用流程里。

会话流更需要发布治理

点击路径时代，用户自己点入口，问题通常停留在某个页面。会话流里，用户一句话就可能触发Skill匹配和小程序打开。超级APP服务数量更多，治理范围也会更大。

建议一开始就把这些能力放进小程序管理平台：

治理点作用
权限控制限制Skill可调用的宿主能力
HITL确认提交、支付、修改资料前二次确认
灰度发布只对部分用户开放新Skill或新版本
热更新小程序服务调整后快速生效
回滚下架异常时立即停用并回退
审计日志追踪会话、参数、结果和版本

小程序管理平台原本就能管理小程序上传、审核、灰度、热更新、回滚和上下架。在AI+超级APP场景里，可以进一步把Skill元数据和小程序版本绑定起来。业务方上线小程序时，同步维护它是否允许被AI调用。否则Skill数量一多，很容易从“服务直达”变成“入口失控”。

先从一个高频场景开始

超级APP从点击流转向会话流，不需要一上来重做全站。更现实的做法，是先选一个高频、低风险、路径明确的服务。

金融APP可以从查账单、开发票、客服进度开始；政企APP可以从办事预约、材料查询、进度查询开始；生活服务APP可以从订单查询、会员权益、预约服务开始。第一批尽量避开强交易，支付、购买、转账这类能力要放到后面，并且必须接宿主强确认和风控。

落地步骤可以收敛成五步：

  1. 选一个已有小程序服务。
  2. 补Skill元数据，包括意图、参数、页面、权限和fallback。
  3. 在宿主APP接入Chatkit，并注入页面上下文。
  4. 通过Skill Router匹配服务，再由小程序 Runtime打开小程序。
  5. 把灰度、热更新、回滚、下架和日志纳入管理平台。

跑通一个场景以后，再扩展第二批Skill。否则问题会同时出现在意图识别、参数补全、页面承接、权限配置和运营治理上，排查成本会被拉得很高。

请添加图片描述

点击流不会消失，超级APP仍然需要页面、菜单、搜索和埋点。但当用户可以直接说“帮我开票”“查一下本月账单”“预约明天下午的服务”，体验重心就会从入口设计转向意图承接。

小程序 AI+的价值也在这里：小程序 Chatkit提供会话入口和上下文承接，小程序Skill把已有服务变成AI可调用能力，小程序 Runtime负责运行小程序，小程序管理平台负责发布治理。它不是替代原有超级APP，而是在现有服务生态之上补一条新的触达链路。

从点击流到会话流，表面变化发生在交互层，真正考验的还是工程底座。能把意图、服务、权限、页面和发布治理串起来，超级APP才会从“功能很多”走向“服务刚好出现”。

avatar
文章
阅读
粉丝