基于现有接口构建原生移动报销应用，保留 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 是否像设计稿。报销状态、审批节点、助手结果和附件绑定必须与后端一致。