移动端的AI助手不应该只是客服窗口：更应该借助AI能力如何把小程序服务变成可调用能力-拓冰建站

很多APP做AI助手时，最容易落到一个旧模式里：在首页加一个对话入口，接上大模型，再把历史帮助中心、FAQ、客服知识库喂进去。上线初期用户会试几句，过一段时间后，入口就变成了“智能客服”的新皮肤。

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

综合APP和金融APP尤其明显。服务很多，入口很深，用户需求又常常带着明确动作。AI助手要有价值，不能只停在问答层，要能把APP内已有服务调起来。小程序服务、Skill元数据和小程序运行时，正好可以组成一条比较清晰的工程路径。

例如FinClip的小程序容器，可以实现帮助APP升级为真正具有AI能力的超级APP，主APP保留账号、权限、支付、消息、安全和设备能力，业务服务以小程序形态沉淀；AI侧通过Skill元数据理解服务能力，再由路由层调用对应小程序页面、卡片或表单。这样用户表达需求后，服务可以在APP内直接出现。

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

客服式AI的目标通常是“回答问题”。它适合处理规则解释、流程说明、材料清单、活动介绍，但不适合承接高频业务动作。

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

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

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

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

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

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

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

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

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

通过FinClip小程序容器，宿主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方法签名。

typeUserRequest={text:string;userId:string;sessionId:string;appVersion:string;};asyncfunctiondispatchService(req:UserRequest){constintent=awaitintentEngine.parse(req.text);constskill=awaitskillRegistry.match(intent);if(!skill){returnassistant.reply("暂时没有找到可办理的服务，可以换一种说法。");}constpermission=awaitpermissionGateway.check({userId:req.userId,skillId:skill.skillId,appVersion:req.appVersion});if(!permission.allow){returnassistant.reply(permission.message||"当前账号暂不支持办理该服务。");}constparams=awaitparameterResolver.fill(skill,intent,req.sessionId);if(params.missing.length>0){returnassistant.ask(params.missing[0].prompt);}returnminiProgramRuntime.open({appId:skill.miniProgram.appId,path:skill.miniProgram.path,query:params.values});}