AI 原生 APP 和传统 APP 最大差异：传统 APP 以确定性 CRUD 业务 为主；AI APP 需要同时承载确定性业务逻辑 + 不确定性大模型推理能力。
架构第一原则：确定性业务与 AI 推理逻辑严格解耦。不要把模型调用、Prompt、RAG 检索散落在客户端页面代码里，所有 AI 能力收敛到独立 AI 服务层。第二原则：端云混合推理优先。绝大多数场景不要一刀切纯云端或者纯端侧；云端负责强推理、长上下文、复杂 Agent 任务；端侧轻量化模型处理离线、隐私敏感、低延迟轻量任务。
一、移动端客户端技术栈选型（多方案横向对比）
评估维度：包体积、性能、跨平台一致性、原生能力调用、AI 端侧推理集成、迭代效率、上架合规。
| 方案 | 包体积 | 原生性能 | 跨平台 | 端侧 AI 集成 | 迭代效率 | 适用场景 |
|---|---|---|---|---|---|---|
| 原生 Android (Kotlin)+iOS (Swift) | 最小 | 最优 | ❌双端维护 | 完美支持 NPU/NNAPI、CoreML | 低，两套代码 | 重度 AI、视频 / 图像推理、百万级用户，追求极致性能，预算充足团队 |
| Flutter | 中等 | 良好 | ✅一套代码双端 | 支持 TFLite、ONNX Runtime 移动端，NPU 适配需要额外开发 | 高 | AI 工具类、AI 对话、多模态轻量 APP，当前 AI 跨平台首选 |
| React Native | 偏大 | 一般，JS 桥损耗 | ✅一套代码 | ONNX 集成成本偏高，大量推理会卡顿 | 高 | 业务重、AI 能力仅作为附加功能的存量 APP 改造 |
| UniApp | 小 | 一般 | ✅多端（APP / 小程序 / H5） | 端侧大模型集成难度高 | 极高 | AI 轻应用，需要同时覆盖小程序和 APP，AI 仅简单 API 调用，不做本地推理 |
选型决策结论
- AI 是产品核心卖点、大量图像 / 语音 / 本地 LLM 推理：优先原生。
- 需要快速交付，同时发布安卓 iOS，AI 包含对话、轻量多模态：Flutter + ONNX Runtime Mobile，综合性价比最高。
- 原有 React 业务，仅增加简单 AI 问答功能：React Native；
- 多端矩阵，AI 只是锦上添花，无本地推理需求：UniApp。
重点提醒：端侧模型会显著增加 APP 包体积，量化后的 GGUF/ONNX 模型动辄几百 MB，上架应用商店会遇到包大小限制，需要做模型按需下载、分包策略。
二、后端服务技术栈选型（AI 服务层是核心）
后端拆分为两层：业务服务层 （用户、订单、权限、产品）、AI 编排服务层（模型路由、RAG、Agent、Prompt 管理、输入输出校验）。两层必须隔离。
业务服务层选型
- Java/SpringBoot：稳定、生态完善，适合企业级商业化 APP，权限、风控、订单体系成熟；缺点是启动资源开销大。
- Go：高并发、内存占用低，适合 API 网关、模型请求转发、限流熔断；AI 流量波动大，Go 非常适合做 AI 请求接入层。
- Python (FastAPI)：AI 原型开发最快，对接各类 LLM SDK、向量库、RAG 框架极其方便；短板：高并发场景需要做好进程管理，不适合承载核心交易业务。
- Node.js：适合 IO 密集型流式输出（SSE，大模型打字机效果），适合轻量 AI 应用。
推荐组合：Go 做网关 + 流量控制；FastAPI 承载 AI 编排；SpringBoot 承载交易、用户核心业务。
小团队轻量化版本：全部 FastAPI，初期业务量低足够使用。
AI 编排层框架选型
- LangChain / LangGraph：生态最全，RAG、Agent 工具调用开箱即用，适合快速搭建原型；缺点抽象较重，生产环境要自行处理限流、重试、缓存、异常降级。
- Spring AI：Java 技术栈首选，和 Spring 体系无缝集成，企业级安全、权限管控友好。
- 自研轻量编排：当 AI 能力简单，仅单轮问答，不需要复杂 Agent，推荐自研。减少重型框架带来的依赖臃肿、版本升级风险。
存储选型
- 关系库 MySQL：用户、订单、会话元数据；
- Redis：会话缓存、限流、模型请求锁、热点 Prompt 缓存；
- 向量库：RAG 场景必选。轻量业务：Chroma、SQLite-Vector；生产高并发：Milvus、Qdrant。向量库不要和业务库共用实例。
三、AI 模型选型（云端模型 + 端侧轻量化模型）
3.1 云端大模型选型
云端模型负责复杂推理、长文档总结、复杂 Agent 规划、多模态图文生成。评估维度：推理质量、token 成本、响应速度、函数调用稳定性、上下文长度、国内合规资质。
- 通用强推理：DeepSeek、通义千问、文心一言；国内有合规资质，适合面向 C 端上线，支持 Function Calling，RAG 场景稳定。
- 长文本场景：优先选择支持 128K 上下文窗口模型。
- 多模态（图片理解）：选择原生支持图片输入模型，减少自行 OCR 带来的链路损耗。
云端模型架构策略：多模型路由。不要硬编码单一模型。根据用户请求类型自动分发：简单问答调用低成本小模型；复杂推理路由到大模型。增加降级策略，某模型服务商故障自动切换备用模型。
3.2 端侧模型选型（本地推理，离线可用，隐私优先）
端侧模型核心约束：手机 RAM、NPU 算力、包体积。主流量化格式 GGUF / ONNX。
- 高端机（8G + 内存）：Qwen3-4B、Phi-4 Mini Q4 量化，可实现本地对话、简单工具调用；
- 中端手机（6G 内存）：Qwen3-1.7B、SmolLM2，适合文本摘要、分类；
- 低端机型：不跑本地 LLM，直接回退云端 API。
端侧模型适用场景：离线使用、用户敏感数据不允许上传服务器、超低延迟简单文本处理。不建议端侧模型承担复杂 Agent 任务，移动端算力有限，幻觉、推理速度问题很难解决。
3.3 模型部署模式对比
| 模式 | 延迟 | 隐私 | 成本 | 离线 | 适用场景 |
|---|---|---|---|---|---|
| 调用公有大模型 API | 中等 | 数据会提交第三方 | 按量计费 | ❌ | 绝大多数 C 端 AI APP 首选，开发成本最低 |
| 私有化部署大模型 | 较高 | 数据内网 | GPU 服务器成本高 | ✅ | 企业内部 APP，数据强隐私要求 |
| 端侧本地小模型 | 极低 | 数据不上传 | 一次性打包成本 | ✅ | 离线、隐私类轻量 AI 任务 |
| 端云混合 | 可控 | 敏感数据本地处理 | 平衡 | 部分离线 | 主流 AI APP 最终方案 |
四、AI APP 顶层架构设计（端云混合）
APP客户端
├─ UI层（对话界面、多模态输入）
├─ 本地AI模块：端侧小模型、本地向量检索、本地缓存
└─ 网络层：SSE流式请求、鉴权、模型状态上报
↓ HTTPS
API网关（Go）：鉴权、限流、熔断、模型路由、日志
↓
AI编排服务：Prompt管理、输入校验、RAG、Agent工具调用、输出过滤
↓
模型服务集群：公有API / 私有部署模型
↓
存储：MySQL、Redis、向量库核心流程：
- 用户提交提问，客户端先做本地预处理，敏感内容本地拦截；
- 判断设备状态：无网络 / 隐私模式，交给端侧模型处理；有网络走云端；
- 请求进入网关，校验 token、QPS 限流，防止恶意刷 token；
- AI 编排层：清洗用户输入，拼接 Prompt，执行 RAG 检索，调用工具；
- 调用大模型，流式 SSE 把 token 逐片返回前端；
- 输出内容做安全过滤，违规内容拦截；
- 会话记录落库，缓存常用问答结果，降低 token 开销。
五、核心能力模块落地要点
5.1 RAG 知识库模块
RAG 用来降低幻觉，接入私有业务资料。 标准链路：文档解析 → 文本分块 → 向量化 → 向量入库；用户 Query → Query 改写 → 向量检索 → 重排 → 上下文拼接送入大模型。 坑点：不要只靠向量相似度检索，必须加 Rerank 重排；分块大小根据业务调整；知识库更新要做增量更新，避免全量重建向量库。
5.2 Agent 智能体模块
适合 APP 需要自动调用外部工具：查订单、生成文件、联网搜索。 核心：Function Calling。架构上必须增加输入输出校验层，防止模型幻觉乱调用接口。工具调用逻辑写在后端，不要放到客户端。
建议：初期版本尽量弱化 Agent 复杂度。Agent 不确定性高，调试成本高。优先做完 RAG 稳定上线，后续迭代再加入复杂工具调用。
5.3 流式输出 SSE
对话类 APP 必备，提升用户体感。后端采用 SSE 流式返回 token；客户端做好断连重试、文本渲染。注意移动端弱网环境，增加断点续传机制。
六、安全、风控、合规（AI APP 上线重中之重）
- 输入输出内容安全：前后双层审核，客户端基础过滤，后端必须接入内容安全接口，拦截违规提问与模型输出；大模型本身安全能力不可信任。
- 用户隐私：涉及端侧 AI，明确告知用户本地模型处理数据范围；用户隐私数据不要直接传入大模型 Prompt；个人信息采集符合个人信息保护法，APP 上架隐私协议必须完善。
- Prompt 注入防护：用户输入会篡改系统提示词，必须做输入转义、分隔符隔离，防止 Prompt 注入攻击。
- 计费与限流：大模型 token 是主要成本。必须做用户级别限流、token 消耗统计、额度控制；防止爬虫恶意刷 API 造成巨额账单。
- 幻觉兜底：AI 输出不可保证 100% 准确，涉及金融、医疗类内容，必须增加免责提示，关键业务结果禁止直接依赖模型输出。
七、性能、成本优化策略
- Prompt 缓存：高频固定问题，缓存模型返回结果，直接返回，减少 token 消耗；
- 上下文裁剪：会话历史不要无限累加，超出阈值自动摘要压缩上下文；
- 模型分级路由：简单任务低成本小模型，复杂任务大模型；
- 量化压缩：端侧模型使用 Q4_K_M 量化，平衡推理质量、体积、速度；
- 异步任务：文档解析、长文本总结这类耗时任务放入消息队列异步处理，不阻塞主请求。
八、分阶段迭代落地路线（避免一次性堆砌所有能力）
阶段 1 MVP 验证（最小可用） 客户端基础 UI；后端接入公有大模型 API；单轮对话；基础内容安全；无本地模型，无复杂 Agent/RAG。目标：验证产品需求，快速上线。
阶段 2 能力增强 增加会话历史、SSE 流式输出；上线基础 RAG 知识库；完善限流、计费、日志监控。
阶段 3 端云融合 按需集成端侧轻量化模型，实现离线问答；增加 Agent 工具调用；多模型自动切换；全链路监控告警。
阶段 4 规模化优化 向量库、AI 服务集群扩容；模型微调做业务场景适配；全链路压测，优化延迟与成本。
九、常见踩坑总结
- 把 AI 逻辑全部写在客户端：严重安全风险，Prompt 泄露、用户可以篡改请求参数；所有模型调用密钥禁止放在 APP 客户端代码。
- 高估端侧模型能力：低端手机跑本地 LLM 极易闪退、内存溢出，一定要做设备能力检测，自动降级云端。
- 忽视 token 成本：上线后流量暴涨，大模型账单失控，缺少额度管控。
- 过度追求复杂 Agent：Agent 幻觉问题会带来大量用户投诉，优先保证基础问答稳定。
- 缺少降级策略：大模型服务商接口故障，APP 直接瘫痪，必须设计备用模型、关闭 AI 能力的降级开关。
十、最终选型决策总览
- 初创小团队快速验证产品：Flutter + FastAPI + Redis + Milvus 向量库 + 公有云端大模型 API；暂不上端侧模型。
- 中重度 AI 产品，隐私 + 离线需求：原生 Android/iOS + Go 网关 + FastAPI AI 编排；端云混合推理。
- 存量 APP 改造，仅增加 AI 问答：复用原有技术栈，新增独立 AI 后端服务，不要侵入原有业务代码。