移动端AI助手不止客服应借AI将小程序服务变为可调用能力

先说几个核心判断。很多APP在推出AI助手时，最容易陷入一个传统模式：在首页添加一个对话入口，接入大模型，然后把历史帮助中心、FAQ、客服知识库全部喂进去。上线初期用户会尝试询问几句，但过一段时间后，这个入口就变成了“智能客服”的换壳版本。

问题不在于模型无法回答，而在于它只能给出文字回复。用户说“帮我开发票”“查一下本月账单”“预约明天上午的网点”“把这笔订单申请售后”，如果AI只能提供一段说明，再让用户自己去寻找对应入口，体验很快就会回到原有的菜单体系。

综合型APP和金融类APP尤其明显。服务种类繁多，入口层级很深，用户需求往往带有明确的操作动作。AI助手要想真正产生价值，不能只停留在问答层面，而必须能够把APP内已有的服务直接调起。小程序服务、Skill元数据以及小程序运行时，恰好可以构成一条比较清晰的工程路径。

举个例子，基于小程序容器架构，可以帮助APP升级为真正具备AI能力的超级APP。主APP保留账号、权限、支付、消息、安全和设备能力，业务服务以小程序形态沉淀；AI侧通过Skill元数据理解服务能力，再由路由层调用对应的小程序页面、卡片或表单。这样一来，用户表达需求后，服务可以在APP内直接呈现，而不是给出一段文字然后让用户自己去翻找。

一、客服式AI为什么容易失效

过去市场上不少团队把这个方向做窄了：客服式AI的目标通常是“回答问题”。它适合处理规则解释、流程说明、材料清单、活动介绍，但不太适合承接高频业务操作。

在一个金融APP里，用户问“本月信用卡账单是多少”，需要的是账单结果和还款入口；问“帮我开一张电子发票”，需要选择订单、填写抬头、提交开票；问“附近有没有可用的权益券”，需要定位、筛选、展示券包并支持领取。把这些需求都回答成文字，用户还得回到页面里继续操作，体验断层非常明显。

综合APP也是如此。外卖、出行、缴费、会员、售后、客服工单、活动报名都不是纯粹的知识问答。用户说出需求后，系统要能识别意图、补齐参数、判断权限、打开服务，并把结果返回到对话中。这才是理想的交互形态。

客服式AI跑不起来，常见原因有三类。

第一，服务不可调用。APP里虽然有大量页面和功能，但AI不知道哪个页面能完成什么任务，也不知道需要哪些参数。

第二，权限不可判断。不同用户、组织、账户、设备和版本能使用的服务不一样，如果AI直接给出入口，容易出现无权限、无数据或打开失败的情况。

第三，结果不可交互。模型生成一段话，页面操作仍然要用户自己完成。对账单、发票、预约、支付、售后这类场景来说，结果必须是卡片、表单、列表、按钮或页面流程。

要解决这些问题，需要把“页面入口”整理成“可调用服务”。

二、小程序服务为什么适合做AI调用承接

其实APP里很多业务已经适合小程序化：账单、发票、客服、权益、缴费、预约、订单、售后、投教、活动、生活服务。它们有独立页面，有相对清晰的业务边界，也经常需要独立发布。

通过小程序容器，宿主APP可以获得运行小程序的能力。业务模块放在小程序里，宿主APP提供登录态、权限、支付、消息、风控、设备能力和安全策略。这样AI助手调服务时，不必直接侵入主工程，只需要通过运行时打开对应的小程序服务。

这类架构有几个好处。

服务边界清楚。一个小程序对应一个或一组业务场景，页面路径、输入参数、返回结果都可以被描述出来。

发布节奏独立。服务要改页面、加字段、调整流程，可以通过小程序管理平台上传、审核、灰度、热更新和回滚，减少主APP发版压力。

安全边界可控。小程序调用宿主能力时经过权限网关，敏感操作可以要求二次确认，执行记录进入审计日志。

多端承接方便。移动端、鸿蒙端、信创PC端或其他终端是否支持某个服务，可以放到Skill元数据和平台策略里统一判断。

AI助手在这套架构里不直接做业务系统，它更像服务调度入口。业务执行仍然由小程序和宿主能力完成。

三、Skill元数据要描述清楚服务能力

AI能调用服务，前提是它能读懂服务。一个小程序页面只写着路径，AI并不知道它适合处理哪些用户表达，也不知道缺哪些参数、需要什么权限、返回什么结果。

Skill元数据就是把小程序服务描述给AI和路由层看的说明书。它不需要很复杂，但要足够明确。

下面是项目侧示例

{
    "skillId": "invoice.apply",
    "name": "电子发票",
    "intents": ["开发票", "补开发票", "下载发票", "查询发票状态"],
    "params": [
        {
            "name": "orderId",
            "required": false,
            "source": ["conversation", "recent_orders"]
        },
        {
            "name": "titleType",
            "required": true,
            "values": ["personal", "company"]
        }
    ],
    "miniProgram": {
        "appId": "finance-invoice",
        "path": "/pages/invoice/apply"
    },
    "permission": {
        "loginRequired": true,
        "riskLevel": "medium"
    },
    "result": {
        "type": "card",
        "fields": ["invoiceStatus", "downloadUrl", "nextAction"]
    }
}

这类元数据至少要覆盖五件事。

意图标签。用户可能说“开发票”“补一张票”“发票在哪下载”，这些表达都要能映射到同一个服务。

参数规则。哪些参数必须由用户提供，哪些可以从上下文、最近订单、账户信息或页面状态里补齐，哪些需要再次确认。

页面路径。匹配到服务后，运行时要知道打开哪个小程序、哪个页面、带哪些参数。

权限要求。是否必须登录，是否需要实名，是否涉及支付、账户、隐私或风控，是否需要二次确认。

返回形态。执行后返回卡片、表单、列表、状态页还是完整页面流程。没有返回规则，对话无法继续承接下一步。

四、服务路由层要控制匹配和执行

有了Skill元数据，还需要一个服务路由层。它负责把用户表达转换成可执行动作：识别意图、补齐参数、判断权限、选择Skill、打开小程序服务，并接收执行结果。

下面是项目侧伪代码，表达路由流程，不代表任何官方SDK方法签名。

type UserRequest = {
    text: string;
    userId: string;
    sessionId: string;
    appVersion: string;
};

async function dispatchService(req: UserRequest) {
    const intent = await intentEngine.parse(req.text);
    const skill = await skillRegistry.match(intent);

    if (!skill) {
        return assistant.reply("暂时没有找到可办理的服务，可以换一种说法。");
    }

    const permission = await permissionGateway.check({
        userId: req.userId,
        skillId: skill.skillId,
        appVersion: req.appVersion
    });

    if (!permission.allow) {
        return assistant.reply(permission.message || "当前账号暂不支持办理该服务。");
    }

    const params = await parameterResolver.fill(skill, intent, req.sessionId);
    if (params.missing.length > 0) {
        return assistant.ask(params.missing[0].prompt);
    }

    return miniProgramRuntime.open({
        appId: skill.miniProgram.appId,
        path: skill.miniProgram.path,
        query: params.values
    });
}

这段逻辑里有几个细节容易被低估。

匹配不到服务时，不要硬编答案。可以引导用户换一种表达，也可以转人工客服，但不要让AI生成一个看似合理、实际不能办理的流程。

参数缺失时，要在对话里补齐。比如开票缺订单、预约缺时间、缴费缺账户类型，AI可以继续追问。补齐后再调小程序。

权限失败要给明确原因。金融APP尤其要注意，账户状态、实名状态、风险等级、设备环境都会影响服务是否可用。

打开失败要有fallback。小程序版本不匹配、客户端版本太低、网络异常、运行时异常，都需要回到原生页面、H5兜底页或明确提示。

五、从高频、低风险、路径清晰的服务开始

AI助手调用小程序服务，不适合一开始就覆盖全部业务。试点阶段可以挑路径短、参数清楚、结果明确的服务。

综合APP可以从订单查询、售后进度、会员权益、生活缴费、活动报名、客服工单开始。金融APP可以从账单查询、电子发票、权益领取、网点预约、投教内容、理财产品资料查询开始。

这类服务有几个共同点：用户表达稳定，业务边界清楚，不需要复杂风控决策，执行结果可以做成卡片或页面。跑通一批服务后，再逐步接入支付、交易、授信、投资等敏感链路。

敏感链路不要让AI直接完成关键动作。比如转账、还款、申购、赎回、授信申请，AI可以帮助用户找到服务、补齐非敏感参数、解释流程，但提交前需要宿主APP完成身份校验、风控校验和用户确认。

六、小程序管理平台要能管理Skill资产

小程序服务进入AI调用链路后，管理平台要多管一层Skill资产。

过去管理平台关注小程序包：版本、审核、灰度、热更新、回滚、下架。接入AI后，还要关注Skill描述、意图标签、参数规则、权限级别、页面路径、返回形态和可用范围。

一个小程序可以有多个Skill。比如账单小程序里可能包含“查账单”“查明细”“申请分期”“下载对账单”；权益小程序里可能包含“查可用权益”“领取优惠券”“查看使用规则”。这些Skill可以独立灰度，也可以按用户群、客户端版本和风险等级控制可见范围。

平台侧还要记录调用数据：用户表达、匹配Skill、参数补齐次数、打开成功率、服务完成率、失败原因、回滚记录。没有这些数据，产品团队无法判断AI助手到底解决了哪些问题。

七、技术落地时的边界

AI助手调小程序服务，需要把几条边界提前讲清楚。

模型负责理解和生成，不直接绕过业务系统。账户、支付、风控、权限、审计仍然由宿主APP和服务端系统负责。

Skill元数据负责描述服务，不替代业务逻辑。它告诉AI和路由层“这个服务能做什么、需要什么参数、怎么打开”，具体执行还在小程序和业务接口里。

小程序运行时负责承接页面和交互。用户确认、表单填写、卡片点击、结果展示都在APP内完成，避免把用户跳到外部不可控环境。

管理平台负责治理。服务上线、灰度、回滚、下架、权限调整和数据统计都要有记录，不能把AI调用链路做成一组散落在代码里的规则。

最后总结一下：通过小程序容器承接服务页面，用管理平台治理小程序和Skill资产，用运行时把AI匹配到的服务在APP内打开。对产品经理和AI负责人来说，重点应放在服务资产整理上，让已有小程序能力变得可理解、可调用、可交互、可治理。

从一个高频服务试点会更稳妥。先把Skill元数据、权限网关、运行时打开、结果返回、灰度发布和回滚跑通，再复制到更多场景。AI助手如果只能回答问题，很难改变APP使用习惯；当它能把小程序服务调出来，用户才会把对话当成新的服务入口。