央国企如何构建企业内部 AI+超级 APP

员工准备出差时，可能需要先到制度库确认差旅标准，再打开 OA 填写申请，等审批通过后进入另一个系统处理预订与报销。集团已经有门户，也汇集了各系统入口，但具体办事时，员工仍要判断该用哪个系统，把姓名、部门、项目和出行信息重复填进去。

在门户里加入 AI 助理，可以让员工直接描述要办的事。不过，从“帮我查一下差旅制度”到“帮我提交出差申请”，中间还隔着业务接口、身份权限、表单确认和审批流程。企业内部 AI+超级 APP 的建设，需要把这些操作接起来，同时保留员工熟悉的页面和原有业务系统的处理规则。

借助 FinClip，可以用小程序承载门户内的业务页面，让手机 APP、PC 桌面及适配的信创终端复用业务服务。AI 助理负责理解需求、组织查询与办理步骤，小程序提供表单、详情和操作界面，业务系统继续执行审批和数据处理。员工可以通过菜单打开服务，也可以从对话进入同一项业务。

统一门户与业务服务组织

集团门户通常需要同时容纳新闻通知、制度资料、培训内容和日常办公服务。内容平台已有的发布流程可以保留，门户负责按权限展示内容或提供访问入口；报销、会议预约、员工服务等业务，则可以通过独立小程序接入。页面调整与业务功能增加，不必都汇入门户主工程。

FinClip 小程序容器集成在宿主客户端内，负责小程序加载、运行及端内交互，管理平台承担小程序版本与发布管理。企业统一身份、消息、文件和设备能力，需要由宿主及已有公共服务提供，再通过约定的接口供业务使用。服务以小程序形式交付，也不能直接获得宿主的全部权限。

同一门户可以面向不同岗位组织不同的服务目录。财务人员、项目经理和普通员工看到的入口未必相同，AI 可调用的业务范围也应随授权变化。目录中记录的服务标识、责任单位和访问条件，可以作为页面入口与 AI 工具注册的关联依据，避免对话入口调用的是一套服务，应用中心打开的又是另一套。

AI 助理与存量系统连接

OA、ERP、CRM 和财务系统之间，接口形式、账号体系和数据口径可能并不一致。接入 AI 前，需要把允许使用的操作整理成明确的业务能力，例如查询申请、读取项目列表、保存草稿、提交申请。每项能力都要定义输入、输出、所需权限和异常结果，供 AI 编排服务选择调用。

业务能力可以通过工具接口或 Skill 组织，但仅有一段功能描述还不足以执行操作。后端适配服务需要处理系统鉴权、参数校验和结果转换，模型不应自行拼接任意接口地址，更不能持有一个能够访问所有系统的高权限账号。查询和写入也要分别授权，能够读取报销记录的员工，不一定有权修改或代他人提交。

制度问答与业务办理还需要采用不同的处理方式。AI 回答差旅标准时，应检索员工所属单位适用且有效的制度，并保留可查看的依据；提交申请时，业务系统按当前规则校验字段与资格。知识库里检索到一段制度文字，不能替代业务接口的实际校验，也不能直接成为授予权限的依据。

FinClip 在方案中承接业务页面的运行和管理。模型服务、知识检索以及面向存量系统的适配，需要结合企业已有环境建设。把职责分开后，可以在不重写整套办公系统的前提下逐项接入业务，也便于定位问题发生在哪个环节。

出差申请的交互与执行

以“帮我提交下周去上海的出差申请”为例，AI 可以识别出申请类型和目的地，但不能据此补齐所有字段。下周具体哪几天、出差事由、费用归属项目，都可能需要员工补充；姓名和部门等资料，也应在授权范围内从企业系统获取，不能根据历史对话猜测。

收集必要信息后，AI 查询适用制度及可选项目，准备申请草稿，再打开对应小程序表单或交互卡片。员工能够看到日期、事由、费用归属等待提交内容，并直接修改。表单仍沿用原业务的校验规则，AI 负责减少查找入口和重复录入，员工对实际提交内容保有确认机会。

确认动作需要绑定当时展示的草稿。员工改了日期或预算后，不能继续使用修改前的确认结果提交。后端收到请求时，应重新检查当前身份、字段和操作权限，再调用 OA 接口；AI 返回的“已提交”也要以接口的真实结果及申请单号为依据。提交成功只表示进入原有审批流程，不代表审批已经通过。

如果提交后网络超时，页面应先查询申请状态，再决定是否重试，避免生成重复单据。对支持的接口，可以用业务请求标识实现幂等控制。暂时无法确认结果时，向员工显示待确认状态并保留查询入口，比直接宣告失败或成功更可靠。审批进度继续从 OA 获取，通过门户消息或申请详情反馈。

员工不使用 AI 时，仍可以从应用中心打开同一张申请表。对话和页面共用业务流程，既方便人工接续处理，也减少两套提交逻辑长期并行的维护负担。

岗位权限与个人助理配置

为员工配置个人 AI 助理，可以基于统一身份，组合其岗位可用的知识范围、业务工具和服务入口，并不要求每个人单独部署一套模型。员工调岗或离职后，授权变化应同步到工具调用与知识访问，不能只更新门户菜单。

模型决定调用哪个工具后，执行服务仍要逐次鉴权。检索制度、客户信息或财务数据时，也应在获取内容的阶段执行访问限制，避免先把无权查看的数据交给模型，再期待模型自行隐藏。需要二次确认的写入操作，应由确定的服务端规则控制，不能依赖提示词要求模型“谨慎操作”。

为了排查一次办理过程，可以关联对话中的任务标识、工具调用、员工确认和业务单号。日志只保留必要信息，并按企业要求设置访问与留存范围。完整对话和附件可能包含敏感内容，不宜默认全部写入普通运行日志。

小程序生态与独立发布

集团各部门、下属单位及经过授权的服务商，可以按照共同的接入规范提供小程序。规范需要涵盖身份接入、页面导航、接口权限、异常提示和运行记录；负责开发的团队可以独立维护业务，但生产发布仍应经过企业约定的审核流程。

FinClip 管理平台提供小程序开发交付、审核与版本管理能力，企业可以据此组织内部应用商店。服务归哪个单位、由谁维护、关联哪些客户端，应与具体小程序记录对应。AI 工具与页面之间也要保留版本关系，业务接口字段变化后，需要同时检查工具定义和表单是否仍然兼容。

在容器已支持的能力范围内，业务小程序可以独立更新，减少页面变更对 APP 整体发版的依赖。新增系统权限、升级容器 SDK 或增加原生扩展，仍需客户端发布。出现异常时，可以停止问题版本继续分发并恢复已验证版本；涉及业务写入风险的，还应暂停相应工具操作。页面回退不会撤销已经提交的申请。

多端复用与私有化部署

FinClip 的多端运行能力，可以为 iOS、Android、鸿蒙及桌面客户端提供业务复用基础。各端完成 SDK 集成并验证组件与接口兼容后，同一套小程序业务代码可以复用。手机上的表单在 PC 上仍需考虑窗口布局、鼠标键盘和文件操作，不能只把页面放大就结束适配。

员工在手机发起申请、审批人在电脑处理，依赖的是同一业务系统保存申请状态，以及不同终端一致的身份和权限。小程序容器提供多端运行环境，并不自动同步尚未保存的草稿或对话上下文；需要跨端续办时，应将必要状态保存在企业服务端。

对于统信 UOS、麒麟等信创环境，需要按具体操作系统版本、处理器架构和 SDK 支持范围验证。客户端能运行，也不等于后台所有国产数据库、中间件组合都已适配。FinClip 支持私有化部署，模型与知识服务可以按项目要求接入企业部署的环境，但后台依赖、网络访问和运维方式仍需分别确认。

门户、小程序管理平台、模型服务和业务接口之间的数据流向也应纳入部署设计。采用私有化方案后，如果模型请求、日志或附件仍发往外部服务，数据处理范围并不会自动缩小到企业内网。

央国企建设 AI+超级 APP，可以让已有内容和业务系统通过统一门户持续提供服务，再用 AI 助理缩短员工从提出需求到实际办理的过程。小程序保留可操作、可确认的业务界面，FinClip 支撑多端运行与版本治理，企业原有系统继续管理权限、审批和业务结果。新增一项服务时，页面入口和 AI 调用可以围绕同一业务能力扩展，已有系统的投入也能继续使用。