企业官网建设流程全解析

最近围绕微信小微AI的讨论里，有一个变化很值得APP团队关注：AI入口开始从“回答问题”走向“调起服务”。

微信小微还处在灰度和内测阶段，不必急着判断最终产品形态。对APP开发团队来说，更值得先拆的是它指向的交互变化：用户说一句需求，AI理解语义、补齐参数，再调用合适的小程序完成任务。点一杯附近可自取的咖啡，或者下一个外卖订单，原本需要用户自己找入口的流程，开始被放到对话里处理。

从场景看，京东、美团、携程、滴滴这类高频服务对应的都是明确可执行任务：购物、外卖、出行、旅行。最终开放情况仍以微信侧实际入口和开发者平台信息为准，但这个方向已经足够提醒普通APP团队：如果微信可以用AI调度小程序服务，企业自己的APP是否也可以把已有小程序能力整理成AI可调用服务？

只加一个聊天框解决不了服务调用问题。更关键的是，APP里的服务能不能被AI识别、路由、调用和治理。

一、入口问题，很多APP已经遇到了

APP做久以后，入口会越来越多。会员权益、订单查询、发票、客服、活动报名、内容专区、预约服务，每个业务都需要露出，每个团队都希望用户能看到。

早期可以靠首页运营位、频道页、搜索框和消息推送解决一部分问题。业务继续增长后，用户很容易陷入“知道有这个服务，但找不到入口”的状态。APP团队也会不断维护路由、页面、权限、发版和回滚。

AI助手带来的变化，是把用户的第一步从点击入口改成表达需求。用户说“帮我开一张上个月订单的发票”，系统如果只回答“请前往发票中心”，体验变化并不大。更有价值的处理方式，是识别开票服务，判断是否登录，补齐订单范围，再打开对应的小程序页面或表单。

这里的工程目标很具体：把APP里已有的小程序能力整理成服务资产，让AI能够按需调用。

二、先把小程序能力整理成Skill

AI要调用服务，不能只面对一堆页面路径。一个APP里可能有多个页面都和订单、发票、客服相关，AI需要知道每个服务能做什么、需要哪些参数、由哪个小程序页面承接、执行后返回什么结果。

项目里可以把这层描述叫做Skill。它面向AI调用链路，描述服务能力、调用参数、页面路径、权限边界和返回结果。

以开票服务为例：

{"skill":"invoice.apply","name":"电子发票申请","intent":["开发票","开电子发票","补开发票"],"appId":"invoice-service","page":"/pages/invoice/apply","params":[{"name":"orderId","type":"string","required":false,"description":"订单编号，不填则进入订单选择页"},{"name":"invoiceTitle","type":"string","required":false,"description":"发票抬头"}],"permission":["login","invoice:write"],"result":["status","invoiceId","downloadUrl"],"fallbackUrl":"app://native/invoice"}

这段JSON是项目侧Skill元数据示例，不对应某个固定SDK接口。实际项目里可以根据自己的AI网关、权限系统和小程序管理平台调整字段。

这份描述至少要解决五个问题：

有了这层描述，AI就不需要猜“开发票”应该打开哪个页面。Skill Router可以根据用户意图匹配服务，再把参数和路由交给小程序运行时。

三、调用链路可以先做成五步

第一版不需要做成复杂Agent平台。对多数APP团队来说，先把一个稳定链路跑通更重要。

用户说需求 AI识别意图和参数 Skill Router匹配服务 权限网关校验 小程序运行时承接服务

这个链路里，AI负责理解用户表达，Skill Router负责匹配服务，宿主APP负责权限和安全，小程序负责具体业务流程。

比如用户说“帮我开一张上周打车订单的发票”。AI识别出开票意图，提取“上周”“打车订单”这两个条件。Skill Router匹配invoice.apply。权限网关确认用户已登录，并具备开票权限。小程序运行时打开开票小程序页面，带入筛选条件，让用户选择订单并确认提交。

关键点在于，AI只负责把需求转成受控调用。订单选择、发票提交、支付确认、签约等动作仍然由小程序页面和宿主业务系统完成。

四、代码示例：一个轻量Skill调用器

这段TypeScript代码只表示项目侧封装思路。FinClipRuntime.open是对小程序打开能力的一层包装，真实项目要按SDK版本、初始化方式和鉴权方式适配。

typeSkillParamValue=string|number|boolean;interfaceSkillDefinition{skill:string;appId:string;page:string;permission?:string[];fallbackUrl?:string;}interfaceSkillCall{skill:string;params:Record<string,SkillParamValue|null|undefined>;}functionnormalizeQuery(params:Record<string,SkillParamValue|null|undefined>):Record<string,string>{constquery:Record<string,string>={};for(const[key,value]ofObject.entries(params)){if(value===null||value===undefined)continue;query[key]=String(value);}returnquery;}asyncfunctioncallMiniProgramSkill(call:SkillCall){constskill=(awaitSkillRegistry.find(call.skill))asSkillDefinition|null;if(!skill?.appId||!skill.page){returnChatUI.reply("这个服务暂时不可用，可以换个说法再试一次。");}constuser=awaitAuthSession.current();if(!user){returnChatUI.reply("请先登录后再使用这个服务。");}constallowed=awaitPermissionGateway.allow(user.id,skill.permission??[]);if(!allowed){returnChatUI.reply("当前账号暂无该服务权限。");}try{returnawaitFinClipRuntime.open({appId:skill.appId,path:skill.page,query:normalizeQuery(call.params)});}catch(error){Logger.warn("open mini program skill failed",{skill:call.skill,error});if(skill.fallbackUrl){returnNativeFallback.open(skill.fallbackUrl);}returnChatUI.reply("服务打开失败，请稍后再试。");}}

这段代码里有几个点需要保留：

• 调用前先查Skill注册表，不让AI直接拼页面路径。
• 调用前校验登录态和权限。
• 参数只保留可序列化的简单类型。
• 小程序打开失败时走原生fallback或会话提示。
• 日志里保留Skill名称，方便后续排查。

如果参数很复杂，比如订单筛选条件、地理位置范围、商品推荐结果，建议先写入服务端缓存，再把短ID传给小程序页面。不要把大对象直接塞进页面query。

五、FinClip在这条链路里负责什么

微信有自己的小程序生态。企业自己的APP要做类似体验，先要让APP具备运行小程序的能力。

FinClip小程序容器可以放在这个位置：宿主APP集成容器后，已有小程序可以在APP内运行，客服、发票、订单、权益、预约、活动等业务模块可以逐步小程序化。AI识别用户需求后，不需要跳到外部APP，也不需要只返回文字说明，可以通过小程序运行时打开对应页面、卡片或表单。

这条链路里，FinClip更像运行和治理底座：

对APP团队来说，这样做的价值在于让已有业务模块变成可调用、可发布、可治理的服务资产。宿主APP继续掌握账号、权限、安全和原生体验，小程序负责可独立迭代的业务流程。

六、不要让AI绕过安全边界

AI入口会缩短用户路径，也会放大权限风险。用户一句话就能触发服务，宿主APP更要明确哪些动作可以自动打开，哪些动作必须用户确认，哪些动作只能跳转到受控页面。

比较稳的做法是把能力分级：

AI可以理解“我要买”“帮我支付”“替我提交”这类表达，但执行动作不能绕过原有业务规则。尤其是金融、政务、医疗、车企这类APP，AI只适合做受控调度，最终确认仍然要留在原有业务链路里。

这也是小程序容器和宿主APP分工的价值。AI负责把用户带到正确服务，小程序承接业务页面，宿主APP掌握敏感能力。

七、从一个高频服务开始

第一次做AI调用小程序，不建议一上来覆盖全部业务。可以先选一个高频、低风险、路径清晰的服务，比如电子发票、订单查询、客服工单或预约服务。

以电子发票为例，第一阶段只需要跑通几个动作：

1. 把开票功能做成小程序模块。
2. 在Skill注册表中配置invoice.apply。
3. AI入口识别“开发票”相关表达。
4. Skill Router匹配开票服务。
5. 权限网关校验登录和开票权限。
6. FinClip运行时打开开票小程序页面。
7. 小程序页面完成订单选择、抬头填写和提交。

这个闭环跑通以后，再扩展到账单查询、权益领取、活动报名、预约服务等场景。每新增一个Skill，都复用同一套运行时、权限网关、发布管理和监控体系。

微信小微AI把一个趋势摆到了APP团队面前：用户不一定愿意再从复杂入口里找服务。很多需求本来就可以用一句话表达，系统要做的是把这句话转成一次受控服务调用。

对企业APP来说，比较现实的路径是：把已有小程序能力整理成Skill，通过AI助手识别意图和参数，再由Skill Router调用FinClip小程序运行时承接服务。宿主APP继续负责账号、权限、安全和风控，小程序负责业务流程，小程序管理平台负责发布和治理。

当APP从“找入口”走向“说需求”，改造范围会从界面上的聊天框，延伸到服务描述、服务调用、回滚治理和运行监控。