短短48小时，全球网络安全接连告急！

欧洲多国政府网站紧急下线，拉美400多个金融目标遭AI自动化攻击，华尔街顶级银行开始拦截第三方智能体。政府关网站，银行拦AI。

当AI开始替人操作电脑，谁来管住它的手？

事实上，凡泰极客长期关注AI安全，并持续探索智能体安全防护技术。随着AI从云端走向个人电脑，凡泰极客正式推出智能体安全卫士，让普通用户也能获得专业的智能体安全防护，个人版免费开放体验。

为什么智能体安全越来越值得警惕？这两天发生的全球互联网被AI攻陷事件，已经敲响了警钟。

1、黑色48小时！全球AI安全风暴来袭

近日，欧洲多个国家的政府服务网站突然关闭。

德国、法国、芬兰等国部分政府网站暂停访问。荷兰政府服务门户Overheid.nl、个人政务平台MijnOverheid.nl等服务也紧急下线。

罪魁祸首是两个软件漏洞，这些漏洞出现在广泛应用于互联网的PHP软件中，一旦被利用，黑客无需正常登录，就能远程控制存在漏洞的服务器。

为了避免系统被攻破，多国政府干脆选择暂时关站。

2026年10月21日，法国政府网站 http://info.gouv.fr 显示暂不可用

更可怕的是，AI已经开始被用于组织大规模网络攻击。

安全公司Straiker披露，黑客组织CyberCartel利用Claude、Grok等模型，组建了一套多智能体自动化攻击系统。

有的AI分析目标，有的搜集情报，有的协调行动。

以前需要一群黑客干的活，现在直接交给一群AI。

调查涉及拉美400多个银行及支付机构等金融目标，研究人员发现了4493条被收集的记录，其中包括账户信息、密码和密钥。

华尔街也开始限制AI

10月22日，据Axios、路透社报道，摩根士丹利、摩根大通、美国银行等金融机构，开始限制第三方AI智能体访问客户账户。

有些用户把账号密码交给AI，让它帮忙查询资产、处理财务。

可银行发现，部分智能体尝试执行的操作，超出了用户原本的指令。登录账户的，究竟是人还是AI？

AI做出的操作，到底有没有得到授权？

为了安全起见，银行干脆先把第三方AI挡在门外。

2、比黑客更难防的，是我们日常使用的AI

现在，各类AI智能体已能直接操作电脑，可谁来管住它的手？

让AI整理文件，它可能误删重要合同。

让它修复电脑问题，它可能改坏系统设置。

更可怕的是个人隐私信息的泄露防不胜防，有可能是你的账单、银行卡信息、身份证号还有家庭住址。

不需要黑客，个人电脑已经对AI打开了大门。

如何最大程度上保护这些隐私信息？

过去，人登录系统、操作软件、使用杀毒工具来守卫安全。

现在，智能体开始替人登录、替人操作、替人处理数据。

软件的使用者变了，安全防护自然也要变。

3、普通人的智能体安全卫士重磅上线！

智能体安全沙箱技术并不新鲜，只是市场上的沙箱主要向企业端，或者服务开发者、技术人员。

因为沙箱需要部署容器、配置环境、调整参数，存在一定的技术门槛。

对普通人来说用个AI助手，还得先学会部署容器，不太现实也没必要。

一家企业有几千名员工，总不能要求每个人都懂安全技术。

针对这一需求，凡泰极客重磅推出智能体安全卫士——一款面向普通人的智能体安全卫士。从个人电脑的系统与隐私保护出发，将智能体安全沙箱带到普通Windows电脑上，让个人用户也能轻松获得AI安全防护。

一是机器安全，别让AI把电脑弄坏：

限制AI随意修改系统配置、重要权限和系统服务，降低误操作导致电脑异常的风险。

二是数据安全，别让隐私随便跑出去：

文件、隐私资料的访问，都能提前设置好防护，比如身份证号、账单中的个人信息。

举个例子：开启智能体安全防护后，你让AI整理电脑资料，工作文件夹可以正常读写，参考资料只能查看，私人文件禁止访问。

如果AI准备把包含身份证号的内容发送给外部模型，FinSAFE还可以按照预设规则，在发送前拦下来相关模型请求，并进行安全告警，也能按设置保留记录，方便查看。

4、哪些人需要智能体安全卫士？

• AI重度使用者

每天让WorkBuddy、豆包、千问等智能体处理工作、操作电脑，要防止它误删文件、乱改设置、越权操作。

• 技术小白

让AI帮忙查看电脑，结果系统设置被改乱；让它自动执行任务，被AI抢夺了电脑控制权不知道怎么修复。

• 对隐私很敏感的用户

身份证、银行账单、水电缴费单，很多人存在自己电脑里，不小心智能体就读取到了。智能体安全卫士可对已接入、可检查的请求检测敏感信息，在发送前按规则提醒或拦截，减少无意泄露隐私的风险。

• 开发者

智能体读取网页、文档或代码时，可能遭遇提示词注入攻击，被诱导执行原本不该做的事。与其完全依赖AI自己判断，不如提前限制它的文件访问和高危操作权限，降低被诱导越界执行的风险。

5、哪些组织需要智能体安全卫士？

• 金融机构｜符合强合规强安全要求

银行、保险、证券、基金等机构，每天处理大量客户资料和交易数据。智能体一旦越权访问或外发敏感信息，就可能带来安全与合规风险。

• 政府及公共服务机构｜保护敏感信息与业务

政务办公涉及居民身份信息、行政文件和内部业务数据。哪些资料能访问、哪些操作不能执行，必须有明确边界。

• 央国企及大型集团｜管住成千上万台办公电脑

员工分布广、终端数量多、AI工具各不相同。企业需要统一掌握智能体的运行情况、操作权限和安全风险。

• 高端制造业及科技企业｜保护核心业务与研发资料

从生产报表到研发文件，智能体可以提高效率，但不能随意修改。

针对企业级需求，凡泰极客还提供桌面智能体安全管控解决方案：个人版保护一台电脑，企业解决方案面向成千上万台办公终端的统一管控：统一安全策略、运行监测、行为审计与集中治理。

凡泰极客希望让每个普通用户都能安心使用AI，也让企业真正掌握桌面智能体的安全控制权。

摘要：企业App生态的业务价值，短期是降本增效和留存，中期是交叉销售和多元变现，长期是流量与生态效益，生态型App助力企业从一次性收入转向持续性生态经营。不少企业都有自己的App，但真正运营起来后，常常遇到一个问题：App能提供的服务太少，用户只有在办理特定业务时才会打开。为了增加使用场景，业务部门希望加入短剧、短视频、会员活动、外卖、出行、小游戏等服务。可每增加一项业务，都要重新开发页面、对接接口、测试版本，再跟随整个App提交应用商店审核。

如果服务来自第三方，不同合作伙伴使用不同的技术方案，企业需要逐一对接；某项活动只运行一个月，也可能要经历一次完整的App发版。久而久之，App虽然增加了很多功能，开发和管理成本也越来越高。

打造企业超级App

无需将所有功能装进一个安装包

微信能够承载大量服务，并不是因为所有功能都由微信团队开发，而是因为它提供了一套小程序运行环境。不同的开发者可以按照统一标准建设小程序，再把服务放入微信运行。用户不需要安装新的App，就能使用购物、出行、缴费、游戏等服务。企业App也可以采用类似思路：原生App继续负责登录、会员、账户、支付、安全和核心业务；短剧、商城、活动、生活服务等变化较快的场景，则通过小程序独立建设和运营。这样一来，App不再只是几个固定功能的集合，而是一个可以不断引入新服务的业务入口。

给现有App装上一套“小程序运行环境”

要让企业自己的App运行小程序，需要先集成小程序容器。简单理解，就是在App里增加一套负责加载、解释和展示小程序的运行环境。基于FinClip，企业可以在已有App中集成小程序容器SDK，使App具备运行和管理企业小程序的能力。

企业不需要推倒重做原有App，也不必把每一项新服务都开发成原生功能。FinClip对主流小程序语法提供兼容支持。合作伙伴已有的小程序，如果使用的是兼容组件和接口，通常可以保留较多现有代码；涉及微信登录、订阅消息、平台支付、特定插件等专属能力时，则需要根据企业App的账号体系和业务环境进行适配。尽可能复用已有的小程序资产，减少重复开发。

一套业务，也可以覆盖多个终端

对企业而言，多端适配也是一笔不小的成本。同一项服务要进入iOS、Android、鸿蒙和PC客户端，如果分别开发和维护，很容易出现功能不一致、版本不同步的问题。FinClip提供面向不同终端的SDK支持。

小程序完成一次开发后，可以在兼容范围内复用到手机、平板和电脑等终端。企业仍需根据屏幕尺寸、设备能力和使用场景做好适配，但不必为每个系统重新建设一套完整业务。例如，同一个会员权益小程序，可以进入手机App供客户领取权益，也可以进入PC客户端供员工查询和处理；同一个活动服务，也可以根据企业的运营安排进入不同的App入口。这种跨端复用的价值，不只是节省几次开发，而是让一项业务能力真正变成可以重复使用的数字资产。

服务接得进来，更要管得住

建设超级App，难点不只是“接入多少服务”，还包括这些服务由谁开发、谁审核、何时上线、出现问题怎么处理。如果没有统一管理，第三方服务越多，版本、权限和责任越容易混乱。FinClip提供统一的小程序管理平台，支持围绕小程序进行版本管理、审核、上下架、灰度发布和热更新。业务团队可以独立迭代自己的服务，企业IT则可以掌握服务的发布范围、运行版本和管理责任。新增一项活动或更新一个页面时，不必频繁修改整个App。核心App保持稳定，外围业务可以更加灵活地上线和调整。

FinClip已经在哪些行业落地？

这套模式并不只停留在方案层面。围绕“核心App保持稳定、外围服务灵活接入”，FinClip已经在金融、政务、传媒和运营商等行业形成了不同实践。

• 某大型银行没有把所有业务都塞进一个App，而是通过统一的小程序底座，连接金融服务、信贷服务和生活服务等多个入口。账户、交易等核心能力继续由原生系统承载，餐饮、出行、会员权益等外部服务则以小程序形式接入，并统一管理版本、权限和发布范围。
• 某区域政务平台将教育、医疗、停车、场馆预约等服务汇集到一个App。不同部门仍然维护各自的业务系统和服务流程，但面向用户时可以形成统一入口。局部规则或页面发生变化时，相关小程序可以独立更新，不必等待整个App重新发版。
• 在传媒行业，某省级融媒App把直播互动、短剧、学习和场馆预约等场景做成独立小程序。大型活动期间，可以快速上线多机位、评论、集卡等互动服务；活动结束后，临时模块可以下线，日常服务则继续保留。一次活动形成的技术和运营能力，也可以在后续项目中复用。
• 还有运营商旗下的云盘类App，通过引入视频、短剧、小游戏和在线工具等第三方小程序，逐步从单一存储工具扩展为数字生活与办公服务入口。企业无需自己开发所有内容，而是通过统一标准连接合作伙伴，并在自有App内完成服务管理。

这些案例虽然来自不同领域，背后的思路却很接近：核心业务保持稳定，把变化快、适合合作伙伴参与的服务做成独立小程序，再通过统一平台管理审核、版本、发布和下线。超级App的价值，不是功能越堆越多，而是让企业拥有一套能够持续引入服务、连接合作伙伴并管理业务生态的机制。作为FinAIOS的一部分，FinClip承担移动端App的AI服务承载与业务交互能力。企业在现有App中集成FinClip小程序容器后，就能承接智能体调用的业务服务，满足用户从提出需求到完成业务的过程。

如果你的企业正在评估小程序容器、第三方服务接入或超级App建设，可以联系凡泰极客，基于现有App、终端范围和合作伙伴情况，进一步梳理小程序兼容性、接入边界及运营管理方案。

如果原生APP已经有了成熟的账号体系、导航和业务接口，前端团队又交付了一套 React 或 Vue 页面。现在希望把这些页面接进APP，并让后续页面改动独立发布，今天分享一下Ionic Portals 和 FinClip的技术差异对比～

迁移时，可以沿着一个页面的执行过程往下看：Web 产物放在哪里，原生端怎样打开它，JavaScript 怎样调用宿主，下载新资源后又在什么时候切换。今天基于安卓端的系统，来分享一下这些接口分别落在哪一层。

保留现有 Web 页面，可以直接比较两种 H5 接入路径

Portals 基于 Capacitor，为原生 APP 提供增强 WebView。一个 Portal 对应一组 Web 资源和运行配置，页面仍由 Web 框架渲染，也不要求界面必须使用 Ionic Framework。

FinClip 除了运行小程序，也支持将现有 Web 项目打包成 H5 应用。这种方式可以保留 HTML、CSS 和 JavaScript，再适配运行环境。如果决定迁入小程序页面，才需要进一步处理页面模板、样式和小程序 API。把这两条路径分开，迁移工作量就更容易判断。

PortalView 直接进入原生布局，宿主决定页面怎么展示

假设前端构建目录为 dist，把产物复制到 Android 的 src/main/assets/business/，让其中的 index.html 成为入口。原生端注册 Portal 时指定这个目录，再在 Activity 中创建视图：

// Application.onCreate：注册一次；授权值由项目构建配置注入。

PortalManager.register(BuildConfig.PORTALS_KEY)

PortalManager.newPortal("business")

    .setStartDir("business")

    .addPlugin(HostContextPlugin::class.java)

    .create()



// AppCompatActivity.onCreate：也可以把这个视图加入现有布局。

val businessView = PortalView(this, "business")

setContentView(businessView)

这里的 HostContextPlugin 是项目自行实现的 Capacitor 插件，用来返回宿主上下文。PortalView 随 Activity 的视图生命周期创建和释放，避免把它长期保存在全局对象中。需要 Fragment 或 Compose 布局时，也可以选用对应的挂载方式。

宿主保留原生导航和页面布局，Web 应用负责自己的表单、列表和内部路由。启动时传少量参数可以用 Initial Context，页面间交换消息可以用 Portals 的发布订阅能力；需要调用登录、相机等原生操作时，再接入 Capacitor 插件。

FinClip 按应用包启动，已有 Web 产物可以进入管理流程

在 FinClip 管理端创建 H5 应用，将 Web 构建产物纳入项目，再用 FinClip Studio 打包上传。假设项目根目录下已有 dist，可以配置入口：

{

  "miniprogramRoot": "dist",

  "entryFile": "index.html"

}

Android 宿主完成 SDK 初始化、配置好应用关联后，通过服务器地址和应用标识打开它。下面是 Activity 中的接入片段，onFallback 由项目传入，用来返回已有原生入口或展示重试页面；BuildConfig 中的配置项也由项目定义。

fun Activity.openBusinessApp(appId: String, onFallback: () -> Unit) {

    if (appId.isBlank()) {

        onFallback()

        return

    }

    FinAppClient.appletApiManager.startApplet(

        this,

        IFinAppletRequest.fromAppId(BuildConfig.FINCLIP_API_SERVER, appId),

        object : FinSimpleCallback<String?>() {

            override fun onError(code: Int, error: String?) {

                runOnUiThread { onFallback() }

            }

        }

    )

}

startApplet 也支持 H5 应用类型，但这个调用与“把一个 View 塞进布局”有不同的接入职责：宿主启动由运行环境管理的业务界面。如果需求是在原生页面中放一个固定高度的业务区域，需要单独评估 FinClip 小组件形态及其支持范围。

Web 项目打包后，还要检查资源引用与请求地址。FinClip H5 应用文档给出的规则是：相对路径会按包内文件处理，访问外部服务需要完整地址。原来依赖网站反向代理的 /api/orders，迁移时就要调整 API base URL；静态文件则应进入包内，并检查构建工具生成的资源路径。

桥接调用加一层适配，业务函数可以继续复用

如果页面到处直接调用 Capacitor 插件，换运行环境时就得逐处修改。可以让业务只依赖项目定义的 getHostContext()，约定返回 bridgeVersion、route 等字段，再分别实现运行层适配。

Portals 侧，通过 Capacitor 注册同名插件并调用方法：

// adapters/portals.js

import { registerPlugin } from '@capacitor/core';



const HostContext = registerPlugin('HostContext');



export function getHostContext() {

  return HostContext.getContext();

}

原生 HostContextPlugin 的注册名称需要与 HostContext 一致，并实现 getContext 方法。插件内部可以继续调用宿主已有的账号服务，只需把结果转换为约定的数据结构。权限不足或宿主能力缺失时，通过插件的失败结果返回给前端。

FinClip H5 应用侧，通过基础库提供的 ft.loadExtApi 声明自定义 API，再将回调调用包装成 Promise：

// adapters/finclip-h5.js：在 H5 应用基础库就绪后调用。

export async function getHostContext() {

  const ft = globalThis.ft;

  if (typeof ft?.loadExtApi !== 'function') {

    throw new Error('宿主桥接尚未就绪');

  }

  ft.loadExtApi([{ name: 'hostGetContext', sync: false, params: {} }]);



  return new Promise((resolve, reject) => {

    const timer = setTimeout(() => reject(new Error('宿主调用超时')), 5000);

    const fail = error => {

      clearTimeout(timer);

      reject(new Error(error?.errMsg || '宿主调用失败'));

    };

    try {

      ft.hostGetContext({

        success: result => { clearTimeout(timer); resolve(result); },

        fail

      });

    } catch (error) {

      fail({ errMsg: error.message });

    }

  });

}

hostGetContext 是项目自定义接口，Android 端需要实现 BaseApi，并通过 FinAppClient.extensionApiManager.registerApi(...) 注册，成功结果按双方约定返回字段。loadExtApi 负责声明调用接口，不会自动生成原生实现。H5 应用采用这种配置方式；如果改用小程序内的 web-view，接入的是另一组 Web API 注册和 JSSDK 调用，不能混用。

两端适配好后，业务层只调用 getHostContext()。原来的登录服务、文件处理或导航服务可以保留在原生端，Capacitor 插件包装层需要改为 FinClip 自定义 API 包装层。这样一来，页面上的业务调用点可以保持稳定。

页面路由与宿主返回分开处理，避免迁移后跳错页面

Web 应用内部的 /form，原生 APP 的 Activity，以及小程序的 /pages/form/index，分别属于不同的路由体系。Portals 可以通过启动上下文把业务路由交给 Web 应用；FinClip H5 应用也可以由项目桥接接口返回路由信息，让 Web 路由器完成跳转。小程序启动参数中的 path 则对应小程序页面路径。

业务层可以共用下面这段启动处理。router 是项目已有的 Web 路由器，两个运行环境分别注入上面的适配函数；未知路径回到表单首页，桥接失败则交给页面展示重试入口。

export async function enterBusiness(getHostContext, router, showRetry) {

  try {

    const context = await getHostContext();

    const bridgeVersion = Number(context?.bridgeVersion);

    if (!Number.isFinite(bridgeVersion) || bridgeVersion < 1) {

      throw new Error('宿主桥接版本不支持');

    }

    const routes = new Set(['/form', '/history']);

    const path = routes.has(context.route) ? context.route : '/form';

    await router.replace(path);

  } catch (error) {

    showRetry(error.message);

  }

}

FinClip H5 应用文档提示运行环境对路由事件有限制，因此依赖浏览器历史事件的路由实现需要适配。可以选用 Web 路由器的内存模式，在页面内维护路由，再由宿主返回事件驱动回退。Portals 也要处理原生返回与 Web 页面栈的关系：页面还能回退时留在业务内部，回到业务首页后再退出原生入口。

原生导航跳转应由宿主校验目标和参数，再执行已有导航服务；页面传入的业务路径只在约定范围内解析。宿主升级桥接协议时保留旧字段，让旧资源包也能继续调用。

业务资源独立更新，下载完成后仍要安排切换时机

Portals 的本地 assets 随 APP 安装包发布。接入 Live Updates 后，Web 资源可以单独下载：Appflow 通过应用标识和 channel 配置；当前官方文档还提供 Live Update Provider 接口，可以对接支持该协议的其他更新服务或自建服务。

使用 Provider 时，配置入口为 setLiveUpdateProviderManager(...)，同步调用为 syncProvider() 或 syncProviderAsync()。Portals 不会自行调用 Provider 的同步接口，不能只配好 manager 就等待更新自动发生。Appflow 的构建期资源同步，也要与客户端运行时下载区分开。

FinClip 的 H5 应用基础库会打进应用包。业务要使用新的基础库能力，需要用对应 Studio 重新打包；基础库中已有的接口，仍要有宿主 SDK 或自定义原生实现支持。两种方案都应把 Web 资源版本和宿主桥接版本记录在一起，发布范围按宿主能力筛选。

当用户正在填写表单时，后台可以下载资源，页面切换安排在业务完成后或下一次进入。升级前先分组发布，保留上一版可用资源及发布记录；回退资源也要确认它与当前桥接协议兼容。采用自建更新源时，还要在分发链路落实包签名或完整性校验，记录实际加载版本。

复用清单明确后，运行层迁移更容易估算

已有页面围绕 DOM 和 Web 组件库开发时，Portals 的视图挂载方式方便继续组织原生布局；FinClip H5 应用则让 Web 产物进入应用包的接入与版本管理流程。后续如果需要迁入小程序体系，业务计算和接口层还能继续复用，页面与运行时调用需要进一步调整。迁移成本可以按这份清单逐项估算：保留业务代码，替换桥接适配，重新接好入口和更新链路。

企业开始建设一款新App时，最先被讨论的往往是上线时间：需求什么时候确认，开发需要多久，首版能否按计划进入应用市场。某企业客户在梳理App建设方案时，也有明确的交付要求，希望尽快完成首版开发和上架。但随着需求逐步展开，企业发现，项目不能只解决“现在有没有App”的问题。

• 首版上线后，新的业务服务还会持续增加；
• 同一套能力未来可能需要进入手机、平板或电脑等不同终端；
• 不同业务团队和供应商，也可能按照各自节奏参与建设。

如果第一版采用的技术路线只能完成眼前交付，后续每增加一项服务，都可能重新进入开发和发版流程。因此，客户真正需要选择的不是一个App页面方案，而是一条能够兼顾当前交付和长期扩展的建设路径。

全量定开能交付当前需求

也可能固化后续建设方式

按照传统定制开发方式，可以根据首期需求完成一套原生App。品牌界面、登录体系、业务页面和设备能力都写入主工程，项目边界清楚，也便于按照当前需求组织验收。这种方式并没有问题，对于功能稳定、后续变化较少、只需要覆盖单一终端的应用，全量定制仍然是一种适合的选择。但企业的需求往往并不止于此。如果所有业务都紧密写入原生主工程，后续每增加一个功能，都可能牵动需求评审、客户端开发、集成测试和整包发布。不同终端还可能分别维护相应代码和版本。随着业务部门、外部服务和运营活动增加，最初的一次性交付容易逐渐变成长期的重复开发。

不是放弃原生开发

而是重新划分建设边界

经过方案比较，该企业最终选择了“底层原生App定制开发＋FinClip”的整体方案。

原生App继续承担适合长期稳定的部分，包括品牌视觉、主导航、登录与身份衔接、核心页面以及必要的系统和设备能力。这样可以保证App的整体体验仍然掌握在企业手中，也能根据实际业务完成有针对性的定制。与此同时，企业在App中集成FinClip SDK，使App具备运行和管理企业小程序的能力。需要持续更新的业务服务，可以作为相对独立的模块进入App，并通过平台完成开发协作、审核、发布、版本和上下架管理。FinClip并不是替代原生App开发，而是把“稳定的App框架”和“持续变化的业务服务”分开。需要原生体验的部分继续定制，变化频繁、需要独立发布或多团队协作的服务，则由成熟的平台能力承载。

成熟产品，有效降低首期交付不确定性

梳理以上需求，该企业没有选择从零搭建整套小程序运行和管理体系，一个重要考虑是FinClip已经形成相对完整的端侧运行与云侧管理能力。项目团队不需要重新开发小程序容器、代码运行、版本管理和发布管理等通用能力，而是可以把精力集中在原生App框架、业务页面、系统连接和首期场景上。这种分工也让项目边界更加清楚。原生团队建设App底座，小程序团队围绕业务模块推进开发，双方按照约定完成集成和联调。首版需要上线的功能可以有序收敛，后续服务也不必全部挤进第一次交付范围。对一个有明确上线目标的项目来说，成熟产品的价值不只是“少写一些代码”，更重要的是减少从零建设基础能力带来的技术和项目不确定性，让交付风险更加可控。

为未来留下统一运行和多端复用的空间

首版交付只是App生命周期的开始。上线之后，业务会调整，运营活动会变化，新的合作方和服务也可能持续进入。FinClip端侧提供小程序运行能力，云侧平台管理多个小程序、多个App和不同开发组织。业务模块可以相对独立地开发、发布和更新，减少每次变化都依赖主App整包发版的情况。对于需要覆盖多个终端的业务，采用统一的小程序标准，也有助于复用服务模块和开发成果。具体终端仍需结合系统能力进行适配，但企业不必为每个端都重新组织一套完全独立的业务工程。这意味着客户建设的不再只是某个版本的App，而是一套可以持续增加服务、统一管理版本并向更多终端延伸的应用基础。

真正要比较的，是一次性交付与长期运营

如果只比较首期功能清单和项目报价，标准平台可能只是方案中的一项新增投入。但把观察周期拉长，企业还需要考虑后续发版、多端适配、重复开发、供应商协作和业务扩展。

原生App保障品牌、核心体验与基础能力，FinClip承接需要持续变化、独立迭代和多端复用的业务服务。正在规划新App或进行移动端重构的企业，如未来的服务会持续变化，未来或业务需要跨终端复用。凡泰极客可结合原生App建设需求与FinClip平台能力，协助企业打造AI+超级App，包括模块化边界和后续扩展路径，让App尽快上线之后，仍然具备持续生长的空间，欢迎咨询方案与案例。

今天分享一下保险APP接入小程序的一种做法。APP已经用了Flutter，保单列表、客户登录和个人中心也都已经有了，现在准备增加一项保单服务预约。客户可以从某张保单进入，选择服务网点和时间，填写想咨询的问题，提交后还能在APP里查看预约记录。

如果继续按原来的方式开发，这项服务可以直接写进Flutter工程。不过，预约页面后续还会增加咨询类型、补充表单字段，调整办理提示。每次改页面，客户端团队都要跟着开发、测试和发版，这些业务调整就会一直占用主工程的排期。

其实，Flutter工程也可以接入FinClip小程序。沿用现有APP，让小程序来承接新增预约服务，再接好登录和导航，就可以利用已有的客户端能力增加服务入口。这样一来，Flutter继续负责APP主界面，FinClip负责小程序运行，预约团队维护自己的业务页面，三者可以在同一个APP里配合工作。

沿用Flutter主工程，新增服务按小程序交付

当客户打开保险APP，看到的首页、保单卡片和底部导航仍然由Flutter实现。点击“保单服务预约”后，APP可以通过FinClip的Flutter SDK打开小程序，再通过启动参数，把当前保单标识、服务类型和来源页面一起带过去。

在iOS和Android上，FinClip的Flutter插件衔接对应的原生SDK，小程序页面和逻辑由FinClip运行环境承载。预约团队使用小程序的页面、组件和API开发业务，客户端团队继续维护Dart代码与已有工程。预约表单有了自己的交付单元，APP主工程则增加运行环境、入口和宿主接口。

比如，客户从一张保单的详情页进入预约，小程序拿到保单标识后，可以直接展示对应的服务类型，让客户少选一次保单。网点和可用时段由业务后台返回，提交结果也保存在保险公司的预约系统中。页面入口换成小程序后，保单数据和网点管理仍然沿用公司的业务系统。

客户端接入时，将Flutter插件与两端原生依赖纳入工程配置。预约团队开发表单和接口，Flutter团队联调入口和公共能力。双方对着同一条客户流程推进，各自的交付内容也更清楚。

共用APP登录，让客户直接进入保单预约

如果客户在保险APP里已经登录，进入预约服务时，就可以继续使用当前账号。预约小程序通过FinClip的自定义API调用宿主登录能力，Flutter端接上已有账号模块，再把结果返回给小程序。

在接入时，可以让宿主取得预约服务所需的短期登录凭证，小程序用它与预约后台建立业务会话。保单标识用来确定客户要办理哪张保单的服务，后台根据登录身份确认可办理的内容。这样一来，客户可以直接进入对应保单的预约流程，少输一次账号。

如果客户进入服务时还没登录，或者登录状态已经过期，宿主可以打开现有登录页面。登录完成后，把结果交回小程序，继续查询网点和时间。客户取消登录时，预约页面可以保留当前选择，等客户再次操作时继续处理。

把这项接口接好后，新增其他客户服务也可以沿用同一套登录约定。FinClip提供小程序与宿主之间的调用通道，保险团队把登录凭证和账号关联接入现有认证体系，让后续服务少做一遍账号对接。

接续导航与预约结果，客户办完仍在原业务里

当客户在预约小程序里选好网点和时间，提交咨询内容后，后台会生成预约编号，页面展示服务地点、预约时间和办理提示。这时客户可能想回到保单，也可能点“查看我的预约”，两个动作都需要接到Flutter主界面的路由上。

预约页面可以调用约定的宿主导航接口，把目标页面和预约编号交给Flutter。宿主接到请求后，先收起小程序界面，再打开对应页面：客户想回保单，就恢复原详情页；想看预约记录，就打开预约列表或详情页。具体怎么跳转由Flutter团队维护，小程序按接口约定告诉宿主要去哪里。

预约提交成功后，小程序还可以通过自定义API通知宿主，把预约编号和处理状态交给Flutter。宿主标记相关页面需要刷新，再从业务后台查询最新记录。小程序中的成功提示、保单页中的预约状态和“我的预约”里的记录，便能对应到同一笔业务。

如果客户提交后直接退出APP，下次打开时，也可以用同一个账号查到预约记录。预约结果已经保存在后台，小程序给宿主发的通知，用来刷新页面和安排跳转。这样，客户从哪个入口回来，都可以继续查看这次预约。

两端联调时，团队可以直接走一遍“保单详情—预约—结果—返回”的过程，检查系统返回键、页面返回按钮和“查看预约”是否到达约定页面。两端导航遵循同一业务约定，客户换设备后也能按熟悉的顺序完成操作。

业务页面独立更新，减少主工程重复改动

如果网点临时调整营业时间，可以直接在预约后台修改可用时段；页面要增加咨询类型或补充办理提示，就更新预约小程序。Flutter主界面的入口与公共接口可以继续沿用，让客户端团队把更多精力放在保单展示、消息和整体体验上。

FinClip小程序管理平台承接业务版本的上传、审核与发布。预约小程序按自己的节奏维护，Flutter主工程增加新的宿主能力或升级SDK时，再安排APP版本。首次接入运行环境需要随客户端发版，后续在已接入能力范围内的业务页面更新，可以走小程序发布流程。

对于保险团队，已有Flutter工程沉淀下来的账号和导航可以继续复用，新的预约服务则拥有自己的页面、逻辑和版本。后续增加新的保单服务入口，团队沿用已经接好的运行环境与接口，就能把更多客户服务接进现有APP。

感兴趣的话，可以关注了解更多技术细节～

资产盘点，明确小程序复用边界不少企业已经在微信里建设了查询、预约、会员或内部办公小程序。自有App需要承接更多服务后，IT部门自然会问：这些存量小程序能否复用？这个问题很容易被简化成“兼不兼容微信语法”。但代码能运行只是第一步,登录、支付和消息由谁提供？用户身份如何对应？小程序更新后由谁审核和发布？这些问题共同决定真实工作量。

先补上App内的小程序运行环境

微信小程序能够在微信中运行，是因为微信提供了完整的运行环境。企业自有App如果要承载小程序，也需要先集成相应的小程序容器或运行时，并处理它与App导航、生命周期、用户状态和原生能力之间的连接。

这一步通常不要求推翻原有App，FinClip负责提供运行环境和管理能力，企业项目团队主要完成三类衔接：让小程序能够从App入口正常打开和返回，沿用企业已有的登录身份，以及按业务需要接入扫码、文件、设备读取等能力。哪些工作可以直接配置，哪些需要接口适配，要根据现有App和小程序的实际依赖逐项确认；账户、订单、审批等最终结果仍由原业务系统提供。四个方向，界定小程序改造范围

代码与接口：先区分可兼容部分和微信专属部分。

对FinClip已支持的组件和API，通常以兼容性验证为主；微信登录、订阅消息、开放数据、特定插件等平台专属能力，则需要逐项确认替代方式。

比如，信息列表、预约表单和自有后台接口通常有较大的复用空间；如果预约结果原来依靠微信消息触达，进入企业App后就要改用企业现有消息渠道，或另行接入新的通知方式。账号与权限：沿用原有账号体系，补上身份衔接。

FinClip不替代企业的会员、员工或客户账号体系。小程序进入App后，需要由企业App把已登录用户的必要身份信息传递给小程序，再由原业务系统判断其可查询的积分、订单和权益。金融、政务及内部办公场景，还要继续执行既有的授权范围、敏感数据展示和操作留痕要求。

设备与App能力：标准能力先验证，企业专用能力按需开放。拍照、定位、文件、扫码等能力，应先确认FinClip SDK的支持情况以及App现有的授权方式；

设备读取、内部扫码、业务支付等企业专用能力，可以由App通过自定义API提供，并只授权给指定小程序使用。以设备巡检为例，如果蓝牙读取采用企业自有协议，项目团队只需围绕这项业务接口进行连接和授权，不必为所有小程序重建一套设备能力。版本与发布：平台提供机制，企业明确管理责任。

FinClip管理平台已提供体验版、审核版和线上版管理，以及审核、上架、灰度发布、下架和版本回退等能力。

企业不必从零建设一套发布后台，但要明确谁能上传版本、谁负责审核、什么情况下可以上架或回退。平台解决“怎么管”，企业制度决定“由谁管、按什么规则管”。

分级评估，匹配小程序改造深度

如果小程序主要由标准页面和独立业务接口组成，对微信专属能力依赖较少，通常以兼容性验证和少量接口适配为主。常见的信息查询、政策展示和简单预约就比较接近这一类。如果小程序与微信登录、支付、消息、地图或文件能力结合较深，就需要同步调整身份链路、接口映射和交互提示。如会员商城、活动报名和售后服务等，让原有业务在新的运行环境中保持连续。如果小程序大量依赖平台插件、特定云能力或复杂的风控流程，则需要单独评估。相较于“整体迁移”，更稳妥的方式是选择一项边界清楚的服务做验证，再决定其余模块是适配、保留还是重构。

持续治理，控制小程序运维成本

一次迁移是否成功，还需考虑后续新增小程序由谁接入，不同部门和供应商如何协作，版本出现问题怎样停用，多个App能否共享同一套服务资产。

FinClip提供企业级小程序容器和管理平台，企业在自有App中集成FinClip SDK后，可以承载企业小程序，并对小程序、App和开发组织进行统一管理。

核心价值在于把运行环境和管理底座建立起来，让可复用的业务资产进入App，并在企业自己的边界内持续发布和运营。

如果企业正在评估存量微信小程序上架自有App，凡泰极客可基于FinClip，协助企业开展存量小程序兼容性与接入边界评估，形成可供IT、业务和供应商共同确认的改造清单，欢迎咨询落地方案。

某省级政务服务APP准备增加鸿蒙客户端，面临最大的问题不是如何从零开发一个鸿蒙APP，而是如何复用已有的资源，类似于社保、医保、税务、企业服务、办事预约、材料提交、预约这些业务在iOS和安卓端已经运行，页面和业务接口也经历过多轮调整，如果全部重新开发，技术层面是一方面，更麻烦的是还需要重新对接一边，需要花费大量的时间调试成本。

例如办事预约来说，用户无论是iOS、安卓还是鸿蒙APP，都是要选择事项、查看可预约时间、填写信息，再拿到预约结果。事项规则和办理流程没有跟着操作系统改变。如果能够把已有业务继续用起来，那鸿蒙开发团队的精力都可以放在新客户端打磨体验上。

今天分享一个新的技术路径：借助FinClip复用已有的小程序、H5页面：鸿蒙APP接入小程序运行能力，业务团队沿用已有页面与逻辑，再把登录、导航等客户端能力接好，无需二次开发就能快速完成APP的上架工作。

复用已有页面与接口，减少鸿蒙端重复开发

预约页面上的事项名称、办理地点、日期选择和表单校验，已经承载了不少业务积累。比如某个大厅周末不开放、某类事项需要补充联系人，这些规则散落在页面逻辑和后台配置里。重新做一套鸿蒙原生页面，后续每次调整都要考虑多份实现之间的同步。

那借助小程序容器，已有小程序可以沿用页面结构、业务逻辑和接口调用，在鸿蒙客户端集成FinClip SDK后接入运行。业务团队继续维护预约小程序，鸿蒙团队负责把它接进APP的事项入口。

如果预约服务原本采用H5，也可以保留现有页面，通过小程序内的web-view加载。页面中原来调用iOS或安卓宿主的登录、返回等接口，则接到鸿蒙端对应的公共能力。页面与接口复用的同时，把与操作系统有关的工作集中到客户端适配上。

原有原生插件和宿主桥接由鸿蒙团队补充对应实现，小程序涉及的组件、API也按鸿蒙运行环境完成适配。

团队梳理存量服务时，可以按事项整理页面入口、业务接口和宿主调用。这样就能看清一项预约中哪些代码继续维护，哪些调用由鸿蒙客户端补齐，开发排期也能对应到具体工作。

预约后台继续服务新客户端，号源由同一个系统管理，预约提交和取消沿用原有接口。鸿蒙端接入原预约系统后，业务部门照常维护事项，办理地点和可预约时间仍由原有后台配置。

统一登录与导航接口，减少重复对接工作

用户从鸿蒙APP首页进入预约页面时，通常已经完成了政务账号登录。预约服务可以通过宿主提供的公共接口取得业务所需的身份上下文，再由预约后台按统一用户标识处理查询与提交。市民进入新的事项页面，沿用的是APP里已经完成的登录过程。

FinClip支持通过自定义API，让小程序调用宿主APP提供的能力。对政务APP来说，可以把登录、返回事项列表、打开消息中心等能力整理成公共接口。小程序按约定发起调用，各端客户端完成对应的原生实现。

例如，预约页面提交成功后，需要回到“我的预约”。业务代码只负责发起这项操作，鸿蒙宿主负责打开正确的客户端页面。iOS和安卓端也遵循同一套调用约定，预约页面就能保持相同的业务处理方式。

登录、返回和消息跳转的参数及结果格式在三端保持一致后，材料申报、进度查询也能沿用这些接口。遇到登录过期，业务页面发起重新登录，由宿主衔接现有认证流程。把这层衔接做好，比为每个事项单独处理一次登录和导航更省事。

预约表单到了鸿蒙端，输入框被键盘挡住、返回按钮回到错误层级，都会影响用户完成操作。客户端团队处理好导航和窗口交互，业务团队检查日期选择、表单填写和提交结果，双方围绕同一条预约流程完成联调。

共用身份与预约后台，换端也能查询已有预约

在一个省级政务服务APP里，同一个预约入口可能服务不同地区和大厅。鸿蒙首页点击某个事项后，客户端根据事项配置打开对应的小程序页面，带入事项和地区等启动参数。预约页面继续使用原有接口查询办理地点与可用时间。

用户选好日期并提交信息，后台生成预约记录，页面展示预约编号和办理提示。回到“我的预约”时，客户端仍按同一用户身份查询业务后台。整个过程里，鸿蒙负责提供新的使用入口，已有预约服务继续完成业务处理。

两个客户端共用身份体系和预约后台后，市民在iOS或安卓端提交的预约，也可以在鸿蒙端查询。记录归属于同一个业务账号，换设备后仍能查看办理时间和取消状态。对用户来说，政务服务的连续性比页面是否重新开发更有感知。

项目验收也可以沿着这条流程展开：从事项入口进入，完成登录衔接，选时间、填信息、提交，再回到记录列表查看结果。双方对照完整的预约结果，就能检查新客户端是否已经接好现有服务。

一套业务代码集中维护，减少三端重复修改

鸿蒙端上线以后，业务部门还会增加办理地点、调整预约提示，或者给表单补充字段。采用共用业务代码的方式，这些变化可以在预约小程序中集中维护，再在各端检查相应的展示和交互。

FinClip的小程序管理平台可以承接版本上传、审核和发布。预约页面的业务更新走小程序版本，客户端新增原生能力或升级SDK则安排APP版本。业务团队和客户端团队按各自的工作对象推进，预约提示改几个字，也能有自己的更新节奏。

对于多个部门共同建设的省级政务APP，这种分工还有一项实际收益：原来负责事项的团队可以继续维护自己的业务。鸿蒙团队把运行环境和公共接口接好后，各部门沿用同一套接入方式交付服务，减少逐项重新解释流程、重新开发页面的工作。

下一次部门增加预约事项，业务团队提交的仍是一套页面和业务逻辑。FinClip将这项服务接入不同客户端，鸿蒙团队沿用已经接好的公共能力，市民在新手机上继续完成熟悉的办事流程。已有事项积累下来的代码和经验，也能随着新客户端继续发挥作用。

感兴趣的话，可以关注了解更多技术细节～

资产盘点，明确小程序复用边界

不少企业已经在微信里建设了查询、预约、会员或内部办公小程序。自有App需要承接更多服务后，IT部门自然会问：这些存量小程序能否复用？这个问题很容易被简化成“兼不兼容微信语法”。但代码能运行只是第一步,登录、支付和消息由谁提供？用户身份如何对应？小程序更新后由谁审核和发布？这些问题共同决定真实工作量。先补上App内的小程序运行环境微信小程序能够在微信中运行，是因为微信提供了完整的运行环境。企业自有App如果要承载小程序，也需要先集成相应的小程序容器或运行时，并处理它与App导航、生命周期、用户状态和原生能力之间的连接。

这一步通常不要求推翻原有App，FinClip负责提供运行环境和管理能力，企业项目团队主要完成三类衔接：让小程序能够从App入口正常打开和返回，沿用企业已有的登录身份，以及按业务需要接入扫码、文件、设备读取等能力。哪些工作可以直接配置，哪些需要接口适配，要根据现有App和小程序的实际依赖逐项确认；账户、订单、审批等最终结果仍由原业务系统提供。

四个方向，界定小程序改造范围

代码与接口：先区分可兼容部分和微信专属部分。

对FinClip已支持的组件和API，通常以兼容性验证为主；微信登录、订阅消息、开放数据、特定插件等平台专属能力，则需要逐项确认替代方式。比如，信息列表、预约表单和自有后台接口通常有较大的复用空间；如果预约结果原来依靠微信消息触达，进入企业App后就要改用企业现有消息渠道，或另行接入新的通知方式。

账号与权限：沿用原有账号体系，补上身份衔接。

FinClip不替代企业的会员、员工或客户账号体系。小程序进入App后，需要由企业App把已登录用户的必要身份信息传递给小程序，再由原业务系统判断其可查询的积分、订单和权益。金融、政务及内部办公场景，还要继续执行既有的授权范围、敏感数据展示和操作留痕要求。

设备与App能力：标准能力先验证，企业专用能力按需开放。

拍照、定位、文件、扫码等能力，应先确认FinClip SDK的支持情况以及App现有的授权方式；设备读取、内部扫码、业务支付等企业专用能力，可以由App通过自定义API提供，并只授权给指定小程序使用。以设备巡检为例，如果蓝牙读取采用企业自有协议，项目团队只需围绕这项业务接口进行连接和授权，不必为所有小程序重建一套设备能力。

版本与发布：平台提供机制，企业明确管理责任。

FinClip管理平台已提供体验版、审核版和线上版管理，以及审核、上架、灰度发布、下架和版本回退等能力。企业不必从零建设一套发布后台，但要明确谁能上传版本、谁负责审核、什么情况下可以上架或回退。平台解决“怎么管”，企业制度决定“由谁管、按什么规则管”。分级评估，匹配小程序改造深度

如果小程序主要由标准页面和独立业务接口组成，对微信专属能力依赖较少，通常以兼容性验证和少量接口适配为主。常见的信息查询、政策展示和简单预约就比较接近这一类。如果小程序与微信登录、支付、消息、地图或文件能力结合较深，就需要同步调整身份链路、接口映射和交互提示。如会员商城、活动报名和售后服务等，让原有业务在新的运行环境中保持连续。

如果小程序大量依赖平台插件、特定云能力或复杂的风控流程，则需要单独评估。

相较于“整体迁移”，更稳妥的方式是选择一项边界清楚的服务做验证，再决定其余模块是适配、保留还是重构。

持续治理，控制小程序运维成本

一次迁移是否成功，还需考虑后续新增小程序由谁接入，不同部门和供应商如何协作，版本出现问题怎样停用，多个App能否共享同一套服务资产。

FinClip提供企业级小程序容器和管理平台，企业在自有App中集成FinClip SDK后，可以承载企业小程序，并对小程序、App和开发组织进行统一管理。

核心价值在于把运行环境和管理底座建立起来，让可复用的业务资产进入App，并在企业自己的边界内持续发布和运营。

如果企业正在评估存量微信小程序上架自有App，凡泰极客可基于FinClip，协助企业开展存量小程序兼容性与接入边界评估，形成可供IT、业务和供应商共同确认的改造清单，欢迎咨询落地方案。

在不少团队里，一个功能从开发完成到用户用上，要经历客户端联调、整包构建、回归测试、签名和应用市场审核等环节。功能本身可能只是改个活动页、增加一张表单，发布链路却要和登录、支付、导航这些主工程能力一起走完。

当业务模块和客户端版本绑在一起，团队花在“等版本”的时间会越来越多。iOS、Android、鸿蒙各有构建和验证流程，同一项业务的页面调整要跟着多端重复走一遍。单纯压缩构建时间能解决一部分问题，更影响上线节奏的，常常是业务改动必须经过宿主 APP 的整条发布链路。

要改变这条链路，先要分清哪些变化必须进入客户端，哪些业务可以独立交付。小程序容器提供了一种拆分方式：宿主 APP 提供稳定的运行环境和公共能力，变化较频繁的业务以小程序模块运行，再由管理平台控制版本和发布。页面和业务逻辑可以脱离主工程独立更新，宿主能力变化仍按客户端版本发布。

发版时间通常花在依赖关系上

客户端版本慢，原因往往不在编译器。一个看似独立的活动页面，如果直接写进 APP 主工程，就会与宿主的页面路由、公共组件、登录态、埋点和构建流程形成依赖。页面更新时，客户端团队要确认兼容范围；涉及公共模块时，相关链路也要重新回归。发版工作量取决于功能影响范围和依赖关系，不只看功能大小。

多端建设会把这个问题放大。同一个功能在 iOS、Android 和鸿蒙客户端中共享产品流程，却分别依赖不同的导航实现、系统权限、文件选择和生命周期。三端同时变更时，产品逻辑要保持一致，端侧实现也要分别验证。业务页面、交互逻辑和系统能力如果没有明确边界，哪怕只改一个表单，回归范围也会难以判断。

优化上线速度，除了打包效率，也要看业务页面是否必须和宿主代码一起发布。账号、安全、原生导航、消息、支付确认等基础能力由客户端掌握；活动、查询、预约、内容服务等边界清楚的模块，可以独立运行和更新。

把稳定能力留在宿主，把业务模块拆开

在小程序容器架构里，宿主 APP 仍然是用户入口，负责账号体系、全局导航、系统权限和经过授权的原生能力。容器 SDK 集成在各端客户端中，为小程序提供运行时、页面渲染、生命周期和宿主能力调用通道。具体业务以小程序包交付，管理平台维护应用、版本、审核和发布状态。

用户打开某项业务时，宿主根据服务入口调用容器，容器加载对应小程序并创建运行环境。小程序通过受控接口访问登录信息、扫码、定位等宿主能力，业务数据仍由原有服务端处理。这样，客户端团队主要维护运行底座和公共接口，业务团队维护自己的页面与流程，双方通过明确的接口契约协作。

模块拆分的收益，取决于它能否独立测试、发布和止损。账户、交易等关键流程若频繁依赖宿主接口，就应连同接口边界一起设计；活动运营、轻量查询、服务预约、专区页面这类变化频率高、边界清晰的模块，独立发布通常更有优势。

业务更新走平台，宿主更新仍走客户端

小程序从开发包到线上版本，会经过上传、测试、审核和发布。管理平台可以记录版本、配置可见范围，并根据项目流程支持灰度、回滚或下架。新版本只涉及页面、组件和业务逻辑时，用户获取对应小程序的新版本，APP 无需随之重新构建。

小程序独立更新覆盖页面、组件和业务逻辑。新增系统权限、修改宿主 SDK、增加原生 API、调整公共导航或变更客户端基础能力，仍需修改宿主并发布 APP。业务包调用的接口必须存在于用户当前安装的客户端版本中。管理平台维护最低宿主版本或能力版本，发布前检查目标客户端；版本不满足时提示升级、关闭入口或提供兼容页面。

小程序管理平台把开发者、业务审核、技术审核和运营发布的职责分开，记录版本内容、审批结果和目标范围。新版本先对内部人员或有限用户开放，观察加载失败、接口错误和关键流程完成情况，再逐步扩大范围。发现异常时，可以回退小程序版本或暂时关闭入口，影响范围通常小于回滚整个 APP。

多端复用业务资产，保留端侧适配

APP 同时覆盖 iOS、Android 和鸿蒙时，容器分别集成对应客户端的 SDK。业务小程序可以共用页面结构和主要业务逻辑，再由各端运行时承载。对业务团队来说，统一的代码和发布对象减少了重复实现；对客户端团队来说，主要工作转向运行环境、宿主能力和系统差异的适配。

多端运行仍有系统差异。文件选择、权限弹窗、键盘、安全区域、窗口切换和后台恢复，会受系统版本及设备行为影响。小程序运行时提供相对一致的接口，各端容器 SDK、宿主 API 和操作系统负责各自实现。项目建立公共业务回归集，并为各平台维护差异用例：登录、路由、接口失败、上传、版本更新和返回行为跨端共测；系统权限、文件访问和生命周期按端验证。

发布前校验三端的能力契约。例如某项小程序能力只在较新的客户端版本中提供，平台应识别旧客户端，并在能力缺失时阻断发布或关闭入口。新增宿主能力时，先让客户端版本完成覆盖，再发布依赖该能力的小程序版本，避免线上接口不兼容。

上线效率要从发布链路里衡量

引入小程序容器以后，建议把业务发布和客户端发布分别记录。客户端侧关注 SDK 集成、启动稳定性、权限实现和公共能力变更；业务侧关注小程序包提交到发布的耗时、审核等待、灰度范围、加载成功率和回滚情况。这样才能看出时间究竟省在构建、审核，还是团队之间的等待上。

服务目录与版本管理关联，每个业务模块记录维护部门、技术负责人、当前线上版本、最低宿主版本、所需权限和下线联系人。出现问题时，运营人员先关闭入口或回到稳定版本，技术团队按小程序标识和版本日志定位。模块独立迭代，责任人同步明确。

通过 FinClip 小程序容器与管理平台，APP 团队可以把一部分业务页面从主工程中拆出，按小程序维度上传、审核、发布和运营；同一业务资产可在已接入对应 SDK 的客户端中复用，减少多端重复实现。宿主仍然控制账号、系统能力和公共体验，业务模块获得自己的更新节奏。发版压力因此从“每次业务变化都动主包”，转向“只有宿主能力变化才走客户端版本”，业务上线效率也就有了更实际的提升空间。

虽然很多城市已经暂停了APP开发的项目，当对于已有的资源开始无法得到充分的利用，每个部门前期开发了一批小程序、H5页面，包括社保、公积金、医保、停车、文旅、教育等服务都有，当有的来自微信小程序，有的是部门早年建设的 H5 页面，还有一些业务已经做成原生页面，却没有被纳入统一的服务目录。

今天分享一下如何将这些已有的资源服务，整合为一个政务APP，通过一个入口就能够实现访问所有的服务。不同部门的服务由不同团队维护，后台系统和发布节奏也各不相同。如果只是把链接堆到首页，用户依旧会反复登录、来回跳转；如果把所有页面重新写进 APP 主工程，后续每次政策调整和页面修改都要等待客户端发版，原本分散的问题会变成一套更大的协作问题。

统一移动政务门户需要解决的，是服务资源如何共存、用户身份如何贯通、不同技术形态如何保持一致，以及上线以后由谁管理这些服务。小程序容器可以承担其中的运行层，但它要和宿主 APP、H5 接入层、小程序管理平台以及原有业务系统一起设计，单独集成一个 SDK 并不能自动解决门户建设的问题。

统一门户先统一入口和身份

门户 APP 的职责不应该是重新实现所有部门业务。它更适合承载稳定的公共能力：统一登录、实名状态、服务目录、消息中心、搜索、通知、原生导航，以及定位、扫码、文件选择等经过授权的设备能力。

用户从服务目录进入某项业务时，门户需要知道这项服务的承载类型、目标页面和所需上下文。例如，社保查询可能是一个小程序，政策公告可能是 H5 页面，某个高频缴费流程可能仍然保留原生页面。门户根据服务配置选择打开方式，并把当前用户的登录状态、地区、语言和必要的业务参数传给对应承载层。

身份贯通要比页面统一更早确定。门户完成实名认证后，小程序和 H5 不应各自再做一套登录流程，也不能把完整的用户凭证直接暴露给前端页面。项目通常会通过统一身份服务换取短时、限定范围的访问上下文，由业务网关完成接口授权和身份映射。服务结束或上下文过期后，容器和 WebView 都应能回到门户的统一登录处理，而不是各自弹出一套无法解释的登录页。

小程序、H5和原生页面可以共存

三种承载方式各有边界，统一门户不需要强行把它们变成同一种技术。

原生页面适合高频、强设备依赖和对启动性能要求高的流程，例如统一身份、消息、扫码、支付确认等公共能力。它们变化相对稳定，放在宿主 APP 中便于集中控制。

H5 适合已有投入较多、以内容展示或查询办理为主的服务。它的优势是服务端更新灵活，原有页面和后台可以继续使用。但 H5 依赖 WebView、网络和域名配置，和宿主之间的返回行为、文件上传、摄像头调用、消息推送也需要明确约定。把一个 URL 放进 APP 并不等于完成接入，页面加载失败、登录失效、版本提示和异常退出都要有统一处理。

小程序适合由部门或合作单位独立维护、需要持续迭代，又希望具备比 H5 更稳定运行边界的业务。小程序代码包由运行时加载，业务页面与宿主 APP 的主工程分开，宿主通过能力桥接向小程序提供经过授权的接口。以 FinClip 这类小程序容器为例，宿主集成 SDK 后负责提供运行环境，小程序运行时负责代码加载、生命周期、页面渲染和能力调用，业务小程序则处理具体的事项页面和流程。

这样的分工并不意味着所有旧 H5 都要迁成小程序。对内容型、变化不频繁、已经稳定运行的页面，继续使用 H5 反而更省事；对需要独立版本、灰度发布、离线包或多端复用的服务，再评估小程序化。技术选型的依据应当是业务更新频率、设备能力、运行稳定性和责任边界，而不是追求门户里只剩一种页面。

统一路由要管住服务入口

多种页面共存之后，路由不能由每个部门自己定义。门户需要建立一套服务标识，将服务名称、部门归属、承载类型、打开地址、默认页面、用户范围和状态纳入统一配置。

用户点击“公积金查询”时，门户读取的是一个服务配置，而不是直接写死某个 URL 或小程序页面路径。配置层判断当前服务应该打开原生页面、H5 还是小程序，并把必要参数交给对应的打开器。服务从 H5 迁移为小程序时，服务目录的入口不必改变，门户只需要切换承载配置并完成新版本验证。

路由层还要处理几个容易被忽视的动作。小程序内部返回时，应该回到小程序自己的页面栈；用户关闭服务时，回到门户原来的位置；H5 页面遇到登录失效时，不能把用户带到一个空白 WebView；服务下架后，旧入口要显示明确的维护或下线提示，而不是让用户一直看到加载失败。

统一路由也方便埋点。一次服务打开可以记录宿主入口、服务标识、承载类型、版本和结果状态。出现“某服务打不开”时，运营和技术人员可以判断是入口配置、容器加载、H5 网络、接口权限还是业务后台的问题，不用在多个团队之间凭感觉排查。

小程序容器承接独立运行的业务服务

当一个部门的小程序进入政务门户，容器承担的工作不只是把页面显示出来。它需要完成小程序代码包的获取、校验、缓存和加载，维护页面生命周期，隔离不同小程序的运行数据，并通过统一能力接口与宿主 APP 交互。

从运行机制看，小程序通常将业务逻辑和页面渲染分开处理。逻辑层执行脚本，视图层负责页面呈现，容器在中间协调路由、事件和宿主能力。这样，业务小程序不需要直接操作宿主的文件系统、账号数据或系统权限，调用摄像头、定位、扫码等能力时要经过宿主提供的授权接口。

政务场景里的权限边界尤其重要。停车服务可能需要定位和支付，政策查询页面可能只需要网络访问，材料上传服务还会涉及文件选择。权限不宜按宿主 APP 的总权限一次性放开，而应按小程序、接口和业务场景分别登记。用户撤销授权、接口超时或设备不支持时，容器应把错误转成业务能够理解的提示，并保证不会影响门户其他服务。

小程序容器还给多部门协作留出了独立更新的空间。部门页面调整时，可以更新对应小程序版本，不必因为一个表单字段变化就重新提交整个政务 APP。宿主侧的容器升级、系统权限变化和公共导航调整，仍然走 APP 自己的版本流程。两条发布通道分开，才能真正减少主工程排队。

H5 接入不能停留在“套一层 WebView”

已有 H5 资源要进入统一门户，接入重点不在页面能否打开，而在它能否遵守门户的公共规则。

登录方面，H5 不应长期保存门户的完整登录凭证。可以由宿主向统一身份服务申请一次性或短时访问上下文，再由业务服务换取自己的会话。不同部门的 H5 继续使用自己的接口和页面结构，但身份入口、会话过期和退出登录由门户统一处理。

导航方面，需要规定 H5 页面内的返回按钮、系统返回手势和关闭入口如何配合。文件上传、相机、定位和下载能力也要通过宿主桥接或明确的系统授权处理，不能默认 WebView 在所有手机系统上都表现一致。网络异常时，门户应能显示统一错误页，同时保留重试和返回服务目录的入口。

安全方面，要限制可访问的域名、跳转范围和外部页面打开方式，避免一个 H5 页面把用户带出政务 APP 后失去统一身份与审计能力。H5 服务的维护方、域名、接口、数据类型和下线条件也应该登记到服务目录中，否则服务虽然进入了统一入口，治理仍然留在原来的分散状态。

管理平台把资源变成可运营服务

当服务数量只有几个时，运营人员还能靠表格记录。部门和供应商一多，平台必须知道每项服务是谁维护、当前是什么状态、哪一版正在运行、哪些用户可以看到，以及出了问题由谁处理。

小程序管理平台承担的是云端控制面。以 FinClip 管理平台为例，可以围绕小程序资产、宿主 APP 关联、成员与角色、版本提交、审核、发布、灰度、回滚、下架和操作日志建立持续运营流程。小程序从开发版本进入体验验证，再进入审核版本和线上版本，发布过程有记录，运营人员能够看到服务处于什么状态。

H5 和原生服务虽然不经过同样的代码包发布流程，也应该进入同一套服务目录和运营台账。平台至少需要记录服务名称、主管部门、技术负责人、承载类型、入口地址、版本或发布日期、用户范围、所需权限、接口依赖、运行状态和下线条件。这样，服务目录展示的不是一张静态菜单，而是一份有责任主体、有生命周期的业务资产清单。

灰度与回退也要按服务处理。小程序可以按用户范围、版本、地区或设备条件逐步放量；H5 可以通过服务端版本、路由开关或后端配置控制新旧页面；原生页面则遵循 APP 发布流程。无论是哪一种承载方式，都需要有暂停入口、恢复旧版本或切换兜底页面的手段。服务出现异常时，平台先止损，业务团队再排查，不要让一个部门的故障拖住整个门户。

统一门户的价值在长期运营

一个政务 APP 能不能持续使用，不只取决于上线时接入了多少服务，还要看新部门能不能按规则加入，旧服务能不能及时下线，出问题后能不能找到责任人，业务变化能不能避开主 APP 的发版排队。

小程序、H5 和原生页面并存并不可怕，真正需要统一的是服务目录、身份上下文、路由规则、公共能力、发布责任和运行数据。小程序容器提供独立运行和跨端承载能力，H5 保留已有页面的交付效率，原生页面继续承担稳定的公共能力；管理平台把这些资源放进同一套审核、发布和运营规则中。

对建设方来说，这种架构减少的是重复重写和多方对齐的成本；对部门和供应商来说，保留了自己的业务迭代节奏；对运营团队来说，服务有入口、有状态、有版本和退路。移动政务门户不再只是把几十个链接摆在一起，而是形成一套能够持续接入、持续更新、持续治理的服务承载体系。

2026年企业AI正在从“局部试用”走向“全面落地”。
大模型进入办公平台，智能体开始调用知识库和业务接口，PC端、Web端也能借助MCP等标准化连接方式接入更多企业能力。
下一步的问题随之出现：这些AI服务怎样进入员工和客户每天使用的手机App，并与电脑桌面端等其他入口保持一致？

企业办公中，常常会遇到如下场景：
会议室里的AI已经能查知识、调系统，到了员工和客户每天使用的手机App，却常常只剩一个聊天窗口。
企业要贯通PC、Web与移动端，难点不只是接入模型，而是让存量小程序、智能体和业务系统在原有权限与流程内协同运行。

凡泰极客推出Fin AIos，正是为补全企业多端AI服务链路而生。

对金融机构、央国企和大型企业来说，App里已经沉淀了账户、审批、工单、预约、营销等大量服务，其中不少由小程序承载。
那么企业既不能为了AI推倒成熟系统，也不能让AI绕过身份、权限和业务规则直接执行。

企业会思考一个问题：移动端落地的难点，是让新的AI入口接得上存量业务，还能继续沿用原有的发布、风控和运营体系？

为什么企业AI到了手机端更难落地？

一个很大的因素是，PC和Web环境适合展示复杂信息，也便于连接企业内部系统。
手机App则同时面对屏幕空间、原生能力、登录状态、交互连续性和应用生命周期等约束。

许多企业已经建设了数量可观的小程序、H5页面和业务接口。如果每增加一个智能体，就重新开发一套移动页面、权限逻辑和流程衔接，成本会随着场景快速上升；如果只把PC端页面嵌入App，又容易出现交互割裂、原生能力调用受限等问题。

因此，企业需要解决的并非“手机端能不能接AI”，而是三件更具体的事：
已有小程序如何变成AI可识别、可调用的服务；
智能体调用之后，复杂交互由什么承接；
同一项服务如何在不同终端共享能力，又保留各端合适的体验。

小程序AI化，不重建一套移动业务

小程序AI化的价值，在于复用企业已经形成的App架构、业务接口、页面组件、身份体系和发布机制，为存量服务补充AI能够理解的描述与调用边界。
一项“账单查询”服务，不只是一个接口地址。它还要说明适用意图、必要参数、用户权限、返回形式、异常处理，以及何时需要进入小程序页面。

大模型负责理解需求，智能体负责任务组织，Skill把查询、校验、提交等能力转成可调用服务，小程序则承接卡片、表单、材料上传和多步骤页面。最终交易、审批和数据处理仍回到原业务系统。
这种方式保留了移动业务最重要的连续性。用户可以从一句自然语言开始，在需要补充信息或确认时进入熟悉的页面；业务团队无需为AI另建平行流程；IT也可以根据场景复杂度决定改造深度，而不是一次性重做全部App。

Fin AIos把分散能力组织成一套多端服务体系

当模型、智能体、Skill和AI化小程序逐渐增多，企业管理的已不是某个AI助手，而是一组需要持续接入、运行和治理的服务。
基于以上服务需求，凡泰极客推出Fin AIos，把这些能力组织进企业自有入口。
Fin AIos助力企业多端建设从“每个入口重复做一套”，转向“服务能力统一管理、交互按终端适配”。

业务部门可以持续增加服务，IT团队能够查看服务归属、调用范围和版本变化，安全与运营团队也拥有更一致的治理视野。

在这套协同关系中，FinClaw侧重智能体与Skill的连接、运行、治理和受控调用；FinClip侧重AI化小程序在App内的运行，以及卡片、页面与原流程的衔接。两者共同支撑AI服务从PC、Web延伸到手机App及更多终端，但不替代企业已有的身份体系、后台系统和责任边界。

“App一步变身AI+ Super App”

企业App不需要一键完成全部改造，而是可以先统一接入路径。接口、权限、确认、异常回退和日志审计仍需按业务逐项梳理。涉及金融交易、重要信息变更或不可逆操作时，还应保留适当性要求、风险提示、用户确认和人工处理。
企业AI全面落地，不能只停在会议室和电脑屏幕上。
让手机App中的存量服务被AI理解、调用和持续治理，才可能把分散建设的模型、智能体与业务系统连成一套可持续运行的多端服务体系。
如果企业正在规划统一AI入口或多端智能体平台，可以先盘点现有App、小程序和业务接口，识别哪些能力能够直接复用，哪些环节需要补充权限、页面和确认机制。凡泰极客可基于Fin AIos、FinClaw与FinClip，协助评估首批移动端场景的接入方式与治理边界。

员工用 AI 起草了一份采购申请，材料整理得更快了，接下来却仍要打开采购系统填表，到预算系统查额度，再把附件发给负责人确认。如果字段不一致、材料不齐，还得在群里来回补充。个人处理文档的时间缩短了，一项工作从发起到办完，依然可能卡在系统切换和部门交接上。

企业推进 AI 应用时，很容易先从写作、检索、总结等个人工具入手。这些能力有直接的使用价值，但一项工作通常需要多个人、多个系统共同完成。员工各自拥有 AI 助手以后，谁把整理好的信息送进业务系统，谁接收下一步任务，处理结果又回到哪里，仍然需要协同办公平台承接。

企业需要升级的，是能够让 AI 参与业务办理的协同能力。已有办公 APP 可以继续使用，OA、ERP、财务和人力系统也可以保留，在原有入口中增加 AI 交互、业务调用和结果反馈。判断是否需要建设新的工具，应该看现有平台能否接住这些能力，以及能否让各部门持续提供可复用的服务。

从个人效率延伸到业务流程效率

个人使用 AI 时，任务范围通常比较明确：整理一份资料、分析一张表、拟一封邮件，结果交给本人使用。进入组织协作后，同一份结果还需要符合业务字段、部门规则和审批要求，才能进入后续环节。生成一段采购理由，与完成一笔采购申请，中间还有预算、品类、供应商、附件和审批路径等具体工作。

如果 AI 只存在于独立聊天窗口里，员工就要承担信息搬运：把系统里的内容复制出来，再把 AI 的结果粘贴回去。每个人都在使用新工具，部门之间的信息传递方式却没有变化。要减少这种重复劳动，需要把 AI 与企业的查询接口、表单和流程连接起来，让整理好的信息能够继续被业务系统使用。

评估 AI 对一项业务的帮助时，可以看申请材料是否更完整、重复录入是否减少、退回补充的次数有没有变化，以及跨部门交接是否更清楚。这些变化比员工发起了多少次 AI 对话更接近实际效果。人工审批和专业判断继续保留，AI 优先承担查询、整理、填充和状态汇总等反复发生的工作。

围绕任务组织协同办公入口

传统办公平台按部门和系统组织入口，人力、行政、财务各有自己的菜单。员工提出的需求则经常跨越这些分类，例如“帮新同事办理入职准备”，涉及人员信息、办公位、设备领用和账号申请。员工关心的是事情有没有准备好，不愿意逐一研究每个后台的操作路径。

以新员工入职准备为例，在接入人事、行政和 IT 服务接口后，经办人可以在办公 APP 中提出办理需求，由 AI 根据入职信息和岗位要求整理待办，补充询问尚未确定的内容，再呈现设备、办公位和账号申请卡片。经办人核对后，申请分别进入已有流程，由对应部门处理。

后续进度通过业务接口查询或事件回传进入门户，经办人能够看到设备是否已分配、账号是否已开通，以及还有哪些事项需要补充。AI 可以帮助汇总当前状态、定位未完成项，跨部门任务的负责人和完成状态由企业流程系统保存。换一个人接手时，也有共同的业务记录可以查，不必从零翻阅前任的聊天内容。

员工使用的入口由此可以围绕任务组织：表达需求、补充信息、确认操作、查看结果。复杂的选择和填写仍然通过表单完成，简短的查询和进度追踪则留在会话里。聊天、页面与待办能够配合使用，员工也可以直接打开熟悉的业务页面办理。

存量系统的业务能力接入

把 AI 引入协同办公，并不要求企业重新建设所有业务后台。多年积累的账号、组织架构、审批规则和业务数据可以继续使用，新增的工作集中在如何把服务接出来，以及如何让员工通过统一入口操作。

每项业务需要提供明确的用途、输入参数、执行接口和返回结果。例如“查询设备库存”和“提交设备领用”是两个不同的动作，前者返回可用设备，后者需要申请人、用途和领用信息。项目可以用 Skill 描述或工具接口组织这些能力，让 AI 根据员工需求匹配调用，同时让业务系统按原有规则处理请求。

人力维护岗位信息和入职要求，行政维护资源与领用规则，IT 维护账号与服务流程，各部门将自己负责的业务知识和接口接入平台。规则变化以后，更新相应的知识、接口或表单，供进入同一流程的员工共同使用。经过确认的业务处理方式由此能沉淀为组织共享的服务，减少每个人重复整理资料、编写提示词和询问办理路径的工作。

跨部门的先后关系也可以沿用企业已有流程。例如必须完成入职信息确认才能开通账号，就由流程系统保留这个条件。AI 帮助员工准备和发起任务，各项工作的状态与依赖有统一记录，后续查询才能得到一致的结果。

FinClip AI+ 与办公应用的结合

在应用层，FinClip AI+ 可以为企业办公 APP 增加会话交互、上下文感知和交互式界面，结合企业模型、知识服务与业务 API，把员工的需求连接到具体服务。查询结果可以直接呈现在会话中，需要补充或核对信息时，则通过卡片、表单和业务页面继续操作。

对于已经开发好的办公模块，可以借助 FinClip 小程序容器接入统一 APP。小程序容器是嵌入宿主 APP 的运行环境，负责加载小程序代码、运行页面和业务逻辑。设备领用、会议预约、报销申请等业务可以分别作为小程序维护，员工从工作台点击进入，AI 助理也可以按配置调起同一项服务。

设备领用小程序中已有的设备列表、附件上传和确认页面，可以继续承接 AI 整理好的申请信息，员工在原有业务界面核对和办理。企业不用为了增加会话入口，再长期维护一套功能相同的办理页面。原有小程序在完成适配后可以复用，H5 和原生模块也能保留在门户中，按统一的账号与导航约定接入。

应用架构可以分工为：AI 理解需求并组织调用，业务接口负责查询和执行，小程序承接需要员工参与的交互，办公 APP 提供统一入口，原有流程系统保存处理状态。FinClip 连接应用运行与交互，企业已有系统继续承担业务处理，协同能力便能建立在存量投入之上。

面向岗位的 AI 助理与统一管理

销售、财务、行政和管理人员需要的服务不同，可以在统一办公入口中，按岗位组织 AI 助理的知识与可调用能力。行政人员常用会议、用车和物资服务，财务人员需要费用制度、预算和报销进度，管理人员更关注待办及业务汇总。员工无需从一长串工具中自行选择，门户结合企业身份和岗位提供相应服务。

岗位助理之间可以共用同一批业务接口和小程序。例如设备领用既可以由员工发起，也可以由行政人员协助准备，但执行时使用相应人员的授权范围。提交申请、变更数据等操作按企业要求保留确认，办理结果进入原有审批流程，个人的会话内容不作为全组织共享的数据源。

FinClip 支持私有化部署，小程序平台可以部署在企业指定环境中，AI 方案对接企业模型与知识服务。小程序在端侧沙箱中运行，业务访问衔接企业身份与权限体系。结合平台操作记录和业务系统日志，企业可以关联应用版本、调用记录与实际办理结果，让 AI 办公进入现有管理体系。

可持续扩展的组织服务平台

组织里的业务一直在变，协同工具也需要能持续增加服务。人力上线新的员工服务，行政调整资源申请，分支机构增加专属业务，都可以按统一规范交付小程序。FinClip 管理平台提供版本管理、审核、灰度发布、上下架和回退，企业统一管理发布过程，各团队继续维护自己负责的模块。

在宿主已提供所需能力的情况下，小程序业务更新可以独立发布，减少对主 APP 整体升级的依赖。AI 侧的工具描述、接口约定和知识内容则随业务变更同步维护，让员工从菜单进入或通过对话办理时，使用的是一致的服务。FinClip 的多端运行能力也能帮助受支持客户端复用同一套小程序资源，降低办公入口扩展时的重复建设。

平台运营可以进一步结合业务数据判断改进方向：入职准备为什么迟迟没有完成，是缺少资料、资源不足，还是任务交接不清楚；员工反复询问同一个问题，是服务入口难找，还是流程状态没有及时反馈。把这些问题持续修正，AI 的价值才能落实到具体办理过程。

企业是否需要新的协同办公工具，取决于现有平台能否支持这种服务方式。能够继续承接的入口可以升级，分散的业务则通过统一门户重新组织。借助 FinClip AI+、小程序容器和管理平台，企业可以把已有系统变成员工可直接使用、AI 可按授权调用、部门可持续维护的办公服务，让个人使用 AI 的便利延伸到跨部门协作之中。

公司已经做好的会员服务小程序，能不能同时放进 iOS、安卓和鸿蒙 APP？对业务团队来说，页面、接口和办理流程已经有了，新增一个客户端，当然希望继续使用原来的成果。按三个平台分别重写页面，后续每次修改活动规则、增加表单字段，还要再跟着维护三遍。

借助小程序容器，可以把业务页面和逻辑保留在同一套小程序代码中，由三个 APP 分别嵌入对应的小程序 SDK，提供加载和运行环境。客户端团队完成宿主接入，业务团队继续开发小程序，管理平台负责版本上传和发布。同一项业务就能进入不同系统的 APP，后续更新也有了统一的管理入口。

以 FinClip 为例，可以让三个 APP 打开同一个测试小程序，再逐步接入登录、支付等业务能力。接入示例使用官方 SDK 接口，并补充项目侧状态判断和错误处理；尖括号中的版本、凭据和服务地址需要替换成项目配置。代码放入已有宿主工程，省略工程结构及部分导入声明。

小程序与三个客户端的运行关系

小程序代码包含页面结构、样式、业务脚本和资源文件。容器在 APP 内加载代码包，提供页面渲染、脚本执行、路由、生命周期以及设备能力调用等运行支持。用户在 APP 首页点击某项服务，打开的就是运行在宿主内部的小程序页面。

iOS APP 使用 iOS 版 SDK，安卓 APP 使用 Android 版 SDK，鸿蒙 APP 使用 HarmonyOS 版 SDK。各端运行时对接自己的系统环境，向小程序提供相应的组件和接口，业务开发者可以复用页面布局、表单校验、查询逻辑和后端请求。三端共用业务代码，各自保留原有客户端工程和原生导航。

例如，会员积分小程序里有积分明细、兑换列表和订单详情。业务团队维护一套页面，三个客户端都从各自的入口打开它。积分怎么计算、订单怎么生成仍由原有业务后台处理，小程序容器负责让页面在不同 APP 中运行。

平台配置与小程序准备

开始集成前，需要在 FinClip 管理平台创建小程序，取得平台分配的小程序 AppID，再配置宿主应用及各端应用标识，获取相应的 SDK Key 和 SDK Secret。小程序还要与允许承载它的宿主应用建立关联，客户端才能按平台配置打开服务。

接入时可以把信息分成两组：SDK 初始化使用宿主凭据和平台服务地址；打开具体业务时使用小程序 AppID、目标页面与业务参数。宿主凭据标识的是哪个 APP 在接入平台，小程序 AppID 标识的是要运行哪一项业务，两者在工程配置中分别维护。

已有微信小程序可以导入 FinClip 开发者工具，检查组件和 API 兼容情况，复用受支持的页面与逻辑。登录、支付、消息以及微信云开发等平台相关能力，需要对接自有 APP 和后端服务。为了验证 SDK 接入，先准备一个只显示入口参数的小程序页面，避免把容器接入与业务接口问题混在一起。

共用测试小程序

在小程序项目中注册 pages/index/index。项目侧测试示例的 app.json 如下；已有工程只需合并页面配置。

{

  "pages": ["pages/index/index"],

  "window": {

    "navigationBarTitleText": "多端运行测试"

  }

}

pages/index/index.js 读取启动参数，pages/index/index.wxml 将参数显示出来：

Page({

  data: { source: '未传入' },

  onLoad(options) {

    this.setData({ source: options.source || '未传入' });

  }

});

<view>

  <text>小程序已打开，入口参数：{{source}}</text>

</view>

用开发者工具编译并上传代码包，完成审核、上架和宿主关联。三端示例统一使用同一个 <MINIAPP_ID>，通过 source=ios、source=android、source=harmony 区分入口。source 只是客户端传入的测试标记，不代表系统检测结果。示例按 AppID 打开正式版；体验版和开发版应使用对应的二维码打开接口，并配置体验成员。

iOS：依赖引入、初始化与打开页面

在现有 Podfile 的 APP target 中加入官方依赖，将 <IOS_SDK_VERSION> 替换为选定版本，执行 pod install，再通过生成的 .xcworkspace 打开工程。

pod 'FinApplet', '<IOS_SDK_VERSION>'

在 AppDelegate 的应用启动方法中加入初始化片段。示例使用 Objective-C；Swift 工程可以按官方集成方式导入同一 SDK，再按 Swift 调用形式接入。

#import <FinApplet/FinApplet.h>



// 放在应用启动方法内，初始化一次。

FATStoreConfig *store = [[FATStoreConfig alloc] init];

store.sdkKey = @"<IOS_SDK_KEY>";

store.sdkSecret = @"<IOS_SDK_SECRET>";

store.apiServer = @"<FINCLIP_API_SERVER>";



FATConfig *config = [FATConfig configWithStoreConfigs:@[store]];

NSError *initError = nil;

BOOL ready = [[FATClient sharedClient] initWithConfig:config

                                               error:&initError];

if (!ready) {

    NSLog(@"小程序 SDK 初始化失败：%@", initError);

}

宿主保存初始化结果，成功后启用业务入口。在当前可见的 UIViewController 中响应按钮点击，使用 FATAppletRequest 指定小程序和目标页面。代码中的 self 是当前页面控制器，打开操作在主线程执行。

FATAppletRequest *request = [[FATAppletRequest alloc] init];

request.appletId = @"<MINIAPP_ID>";

request.apiServer = @"<FINCLIP_API_SERVER>";

request.startParams = @{

    @"path": @"/pages/index/index",

    @"query": @"source=ios"

};



[[FATClient sharedClient] startAppletWithRequest:request

    InParentViewController:self

    completion:^(BOOL result, FATError *error) {

        if (!result) {

            NSLog(@"小程序打开失败：%@", error);

        }

    }

    closeCompletion:^{

        NSLog(@"已返回宿主页面");

    }];

测试页显示 ios，即可确认代码包加载、页面跳转和参数传递已经连通。接入相机、定位等业务时，再补充相应权限描述和扩展模块。

安卓：初始化状态与业务入口

按官方集成指引配置 FinClip Maven 仓库后，在 APP 模块的 build.gradle 中加入 SDK 依赖。仓库地址与访问配置由工程维护，<ANDROID_SDK_VERSION> 替换为项目使用的固定版本。

dependencies {

    implementation 'com.finogeeks.lib:finapplet:<ANDROID_SDK_VERSION>'

}

同时按该版本接入文档配置原生库打包与混淆规则，在使用代码压缩的工程中加入：

-keep class com.finogeeks.** {*;}

初始化放入宿主现有 Application。Kotlin 示例使用 FinStoreConfig、FinAppConfig、FinAppClient 和 FinCallback 的官方接口；类名 HostApplication、状态字段及提示语是项目侧示例，导入声明由 IDE 从已安装 SDK 补齐。若项目已有 Application，将字段和初始化逻辑合入原类，并确认 Manifest 指向该类。

class HostApplication : android.app.Application() {

    @Volatile var finclipReady = false

        private set



    override fun onCreate() {

        super.onCreate()

        if (FinAppClient.isFinAppProcess(this)) return



        val store = FinStoreConfig(

            "<ANDROID_SDK_KEY>",

            "<ANDROID_SDK_SECRET>",

            "<FINCLIP_API_SERVER>",

            "<FINCLIP_APM_SERVER>",

            "/api/v1/mop/",

            "",

            "MD5",

            false,

            true

        )

        val config = FinAppConfig.Builder()

            .setFinStoreConfigs(listOf(store))

            .build()



        FinAppClient.init(this, config, object : FinCallback<Any?> {

            override fun onSuccess(result: Any?) {

                finclipReady = true

            }

            override fun onError(code: Int, error: String?) {

                finclipReady = false

                android.util.Log.e("FinClip", "初始化失败：$code $error")

            }

            override fun onProgress(status: Int, info: String?) {}

        })

    }

}

MD5 是示例中的 SDK 通信配置值，需要与平台配置一致；末尾两个布尔值分别关闭返回数据加密、开启基础库预加载。APM 地址填写平台的数据上报地址。进程判断也应覆盖其他宿主级初始化，避免小程序进程重复启动整套业务组件。

Activity 的按钮点击处理使用真实的 startApplet 接口。只有初始化成功才继续打开，失败结果交回当前页面处理。

val app = application as HostApplication

if (!app.finclipReady) {

    android.widget.Toast.makeText(

        this, "小程序服务尚未就绪", android.widget.Toast.LENGTH_SHORT

    ).show()

} else {

    val request = IFinAppletRequest.fromAppId(

        "<FINCLIP_API_SERVER>", "<MINIAPP_ID>"

    ).setStartParams(mapOf(

        "path" to "/pages/index/index",

        "query" to "source=android"

    ))

    FinAppClient.appletApiManager.startApplet(

        this, request, object : FinCallback<String?> {

            override fun onSuccess(result: String?) {}

            override fun onProgress(status: Int, info: String?) {}

            override fun onError(code: Int, error: String?) {

                android.util.Log.e("FinClip", "打开失败：$code $error")

            }

        }

    )

}

打开接口接收当前 Activity，测试页应显示 android。初始化成功却打不开时，优先核对小程序发布状态、关联关系和请求的服务地址。

鸿蒙：HAR 依赖与 Navigation 接入

鸿蒙可以采用线上依赖或本地 HAR 包。以本地包为例，将同一交付版本的 FinClipSDK.har 和 FinClipSDKCore.har 放进工程根目录的 har 文件夹，在 entry/oh-package.json5 中合并：

{

  "dependencies": {

    "@finclip/sdk": "file:../har/FinClipSDK.har"

  }

}

在工程根目录的 oh-package.json5 中合并底层依赖覆盖配置，随后执行 ohpm install：

{

  "overrides": {

    "@finclip/sdk-core": "file:./har/FinClipSDKCore.har"

  }

}

依照接入指引，在根目录 build-profile.json5 的目标 app.products 元素内合并配置；JSON 片段均保留工程已有字段：

{

  "buildOption": {

    "strictMode": {

      "useNormalizedOHMUrl": true

    }

  }

}

entry/src/main/module.json5 的 module.requestPermissions 中至少配置网络权限：

{

  "name": "ohos.permission.INTERNET"

}

启动方式采用官方 Navigation 方案，该方式文档标注最低支持 SDK 1.1.0。小程序使用宿主已挂载的 NavPathStack 打开，因此无需额外注册承载小程序的 Ability。将示例加入工程已登记的入口页面，已有 Navigation 工程则复用自己的页面栈。

import common from '@ohos.app.ability.common';

import {

  EAppletStartMode, FinAppClient,

  IFinAppConfig, IFinAppStartMode

} from '@finclip/sdk';



@Entry

@Component

struct Index {

  @State pageInfos: NavPathStack = new NavPathStack();

  @State status: string = '等待打开';

  client?: FinAppClient;



  async openMiniProgram() {

    try {

      if (!this.client) {

        const config: IFinAppConfig.IFinAppConfig = {

          finStoreConfigs: [{

            apiServer: '<FINCLIP_API_SERVER>',

            sdkKey: '<HARMONY_SDK_KEY>',

            sdkSecret: '<HARMONY_SDK_SECRET>',

            cryptType: 'md5'

          }]

        };

        const mode: IFinAppStartMode = {

          startMode: EAppletStartMode.Navigation,

          routerState: this.pageInfos,

          uiContext: this.getUIContext()

        };

        this.client = FinAppClient.init(

          config,

          getContext(this) as common.UIAbilityContext,

          '',

          mode

        );

      }



      this.status = '正在打开';

      await this.client.startApplet({

        appId: '<MINIAPP_ID>',

        apiServer: '<FINCLIP_API_SERVER>',

        startParams: {

          path: '/pages/index/index',

          query: 'source=harmony'

        }

      });

      this.status = '打开调用已返回，请检查小程序页面';

    } catch {

      this.status = '调用异常，请查看 SDK 日志后重试';

    }

  }



  @Builder

  PageMap(name: string) {

    // 在已有工程中保留宿主原有的页面路由映射。

  }



  build() {

    Navigation(this.pageInfos) {

      Column({ space: 16 }) {

        Text(this.status)

        Button('打开测试小程序')

          .onClick(() => { this.openMiniProgram(); })

      }

    }

    .mode(NavigationMode.Stack)

    .id('root')

    .title('小程序接入测试')

    .navDestination(this.PageMap)

  }

}

openMiniProgram 是页面自定义方法，内部调用的是 SDK 的 FinAppClient.init 和 startApplet。初始化在用户点击后执行，此时页面已经创建，能够提供 UI 上下文；routerState 与页面上的 Navigation 使用同一个实例。示例将通信方式显式设为 md5，实际值按平台配置填写。已有工程统一保存客户端实例，不随页面重建重复初始化 SDK。

点击按钮后，小程序应显示 harmony。startApplet 的调用返回并不单独作为页面成功展示的证据，实际验收以测试页出现、参数正确和 SDK 日志为准。

宿主登录与设备能力对接

小程序页面能够打开后，接下来要让它接上 APP 已有的业务环境。比如用户已经登录 APP，进入会员小程序时，应该能够继续查询自己的积分和订单，无需再走一遍注册流程。

项目可以通过容器提供的扩展机制，把获取业务登录态、发起支付、打开原生页面等操作封装为统一的宿主能力。小程序调用约定接口，各端宿主分别完成原生实现，再按一致的数据结构返回结果。登录过程由企业账号服务衔接，业务后台继续校验用户身份和访问权限。

对于扫码、拍照、定位等能力，三个客户端需要分别配置系统权限、接入相关 SDK 模块。业务侧保持统一的调用约定，平台差异由运行时和宿主适配处理。后续再增加新的小程序时，已经接好的登录、支付和设备能力就能继续复用。

返回行为也要与 APP 原有体验接上：小程序内部返回上一页，退出小程序则回到宿主入口；业务完成后需要刷新原生列表的，由宿主接收办理结果并更新页面。用户感受到的是同一个 APP 内连续的服务流程。

三端联调与发布检查

三台设备使用同一个小程序 AppID，分别从宿主按钮打开测试页。先看页面能否显示，再核对参数和返回行为，比直接接入完整业务更容易定位接入问题。

测试页通过后，将相同的打开方式接到首页宫格、活动位或消息入口，再把目标路径换成真实业务页面。例如订单消息可以携带订单标识，直接进入详情页。随后在三个宿主中完成登录、查询、提交、返回的全流程，检查设备授权、网络中断和前后台切换。错误日志同时记录宿主版本、SDK 版本及小程序版本，方便区分客户端接入问题和业务更新问题。

统一发布与业务独立更新

三端接入完成后，小程序代码包进入同一个管理平台，经过体验验证、审核和发布，再由各端 SDK 获取适用版本。团队可以统一管理小程序资产，也可以通过灰度策略控制新版本的发布范围，结合各端测试结果逐步上线。

日常调整会员页面、增加活动专区、修改表单等业务更新，只要使用的能力已由当前宿主和运行时提供，就可以走小程序发布流程，无需等待三个主 APP 同步发版。容器 SDK 升级、新增原生能力等宿主工程变更，继续走各客户端的构建和发布流程。

业务更新与客户端更新分开后，团队的协作方式也会随之变化：业务开发人员维护共用的小程序，客户端人员维护各端运行环境和公共能力，运营人员在平台查看版本、审核和上线状态。新增业务可以继续接入现有容器，已有微信小程序资源也能在完成适配后加入自有 APP。

FinClip 将三端运行 SDK、开发者工具和管理平台连接起来，让同一套小程序拥有跨客户端运行和持续发布的能力。企业保留各端 APP 已有的原生体验，同时把频繁变化的业务交给共用小程序承载，减少重复开发，让功能上线与日常维护围绕同一份业务成果推进。

9月17日，由凡泰极客联合聚呗科技举办的“智驭金融·AI赋能新增长——金融机构AI落地案例与监管新规下增长分享”主题沙龙在深圳举行。活动面向券商、基金、银行等金融机构，围绕金融产品网络营销新规、证券行业智能投顾、AI获客增长以及金融AI创新与合规等议题展开交流。

随着人工智能加快进入金融业务，机构的关注点正从模型能力转向具体场景：AI如何接入现有业务系统，如何遵循授权与适当性要求，如何兼顾服务效率、数据安全和过程审计。本次沙龙通过专题分享和圆桌交流，为金融机构推进AI应用提供更多可参考的思路。业务落地，证券智能投顾实践凡泰极客战略与业务增长副总裁彭肖镝以“证券行业智能投顾落地实战分享”为题，围绕智能投顾从方案设计到业务应用的关键环节展开交流。

金融机构推进智能投顾，需要处理场景选择、系统接入、业务权限和人工复核等一系列实际问题。智能服务既要识别客户身份和授权范围，遵循适当性管理要求，也要与机构已有的客户经营、产品服务、审核和留痕流程衔接。对于关键建议和业务办理环节，仍需设置明确的人工确认机制。

在技术建设层面，金融机构通常希望复用现有App、业务系统和服务能力，减少重复建设，同时对AI调用的数据、接口和执行范围实施管理。分享将讨论重点落在真实业务链路，也体现了凡泰极客对金融AI落地的长期关注：技术价值需要通过业务流程承接，并在安全、权限和合规边界内持续运行。

关注获客变化，探讨AI时代增长路径

随后，广州聚呗科技有限公司CEO陈国辉以“FDE × GEO：获客增长的AI双引擎”为题进行分享，围绕AI时代用户获取信息和选择服务方式的变化，探讨企业获客的新思路。

对于金融机构而言，新增触点最终仍要回到机构可识别、可管理的服务链路。无论入口来自搜索、内容平台还是合作渠道，都需要清楚展示服务主体，保证信息准确，并由具备相应资质的流程承接后续咨询与业务办理。

凝聚行业共识，推动AI进入真实场景

在“金融AI场景创新与合规思辨”圆桌对话中，与会嘉宾围绕AI应用的适用场景、风险边界和落地节奏进行交流。讨论认为，金融AI项目应从具体业务需求出发，明确服务对象、数据来源、AI可执行动作和人工确认节点，再选择相应的模型、智能体及前端入口。

本次沙龙以金融业务实践和增长议题为切入点，为金融机构交流AI落地路径提供了专业平台。未来，凡泰极客将继续围绕金融机构移动服务、智能体接入与安全治理，加强与行业客户及生态伙伴的交流，推动AI能力进入更多可管理、可验证的真实业务场景。