基于现有接口构建原生移动报销应用,保留 AI 助手、相机拍票和语音输入能力。
+
+ 移动端作为 X-Financial 的新客户端,不重新发明业务系统。后端仍是唯一业务真相,
+ App 侧专注手机场景:快速拍票、语音询问、查看进度、补材料、处理审批。
+ 页面风格对齐 mobile/UI 设计稿,使用浅绿色企业金融风格、轻量卡片、
+ 底部导航和固定操作条。
+
端侧架构
++ App 按“页面功能、共享业务、平台能力”拆分。相机、语音、上传等能力不直接散落在页面里, + 页面只消费服务接口,后续替换原生模块或增加 iOS 适配时不会影响业务页面。 +
+mobile +├── app +│ ├── navigation +│ └── bootstrap +├── features +│ ├── home +│ ├── claims +│ ├── approvals +│ ├── assistant +│ └── profile +├── shared +│ ├── api +│ ├── auth +│ ├── domain +│ ├── design +│ └── components +└── platform + ├── camera + ├── voice + ├── upload + └── permissions+
相机与语音能力
++ 相机和语音是移动端的一等能力。相机服务票据生产流,语音服务助手输入流。 + 两者都先产生“用户可确认的中间结果”,不直接触发不可逆业务动作。 +
+相机拍票流程
+拍照或相册选择后,先进入临时附件和 OCR 识别流程,用户确认后再绑定真实报销单。
+语音输入流程
+语音只作为输入方式,转写结果回填输入框,由用户确认后再发送给 AI 助手。
+/api/v1/orchestrator/run,保持助手逻辑一致。页面设计与信息架构
++ 页面结构沿用移动稿的底部导航:首页、报销、审批、AI 助手、我的。 + 首页聚合待办与最近进度,报销和审批分别承载个人申请与处理他人申请。 +
+现有移动端设计稿参照
+
+
+
+
+
+
+ 视觉与组件规范
+
+ 从 mobile/UI 抽象设计 token,保证 mobile 和 web 能共享品牌语言。
+ 组件要偏企业应用密度,避免营销页式大装饰。
+
基础组件
+-
+
- Button:主按钮、次按钮、危险按钮、底部固定 CTA。 +
- Card:报销卡、待办卡、AI 结果卡、附件卡。 +
- StatusPill:草稿、审批中、待补充、已付款、已驳回。 +
业务组件
+-
+
- ReceiptPreview:票据缩略图、识别状态、删除。 +
- ClaimSummary:金额、单号、申请人、审批节点。 +
- RiskBrief:AI 风控提示、关注、需补充、正常。 +
交互规范
+-
+
- 所有触控区域 Android 不小于 48dp。 +
- 底部操作条必须预留安全区。 +
- 长表单使用分组和折叠,避免一屏过载。 +
接口与同步策略
++ 后端仍是唯一业务真相。移动端只做客户端适配,所有报销、审批、助手动作都走真实接口。 + 建议新增很薄的 mobile facade,用于首页聚合、临时附件和语音转写。 +
+复用现有接口
+建议新增移动端适配接口
+接口类型同步
+从 document/development/backend_api/openapi.json 生成 TypeScript 类型与 API client。
状态同步
+status、approval_stage、可编辑性、可上传性统一在 shared/domain 映射。
设计同步
+设计 token 同时输出给 Web CSS variables 和 Mobile theme,减少双端视觉漂移。
+交付计划
++ 先做 Android MVP,确保核心报销闭环可用;再补齐语音、通知、离线草稿等体验增强; + 最后进入 iOS 权限、打包和商店侧适配。 +
+验收标准
++ 验收要围绕真实业务结果,不只看 UI 是否像设计稿。报销状态、审批节点、助手结果和附件绑定必须与后端一致。 +
+