1. 客户端层（App / Web / 桌面端）#

• 桌面端常用 Tauri/Electron 包壳；移动端原生或跨端框架；Web 端主流是 React/Next.js。
• 聊天产品形态：消息流（像 IM）、Markdown/代码块渲染、LaTeX 公式渲染、流式打字光标、停止生成按钮、多轮会话切换、上下文编辑。
• 富文本渲染是这类前端的核心难点之一：AI 输出是混合 Markdown + 代码 + 公式的流式文本，要在”边收边渲染”的同时保证不闪烁、代码块高亮完整、表格不抖动。这块比传统网站”渲染服务端给定的 HTML”复杂得多。

2. 接入/网关层（API Gateway）#

• 鉴权（OAuth / API Key）、限流、配额管理（免费用户多少次/天、Plus 多少次/3小时）、计费埋点。
• 负载均衡、灰度发布、A/B 测试（不同用户路由到不同模型版本）。
• 这一层和传统 Web 网关几乎一样，差别只是多了”按 token 计费”和”按模型路由”。

3. 业务编排层（Application / Backend BFF）#

• 会话管理：维护多轮对话历史、上下文截断/压缩（超长上下文要做摘要、滑窗、检索增强）。
• 插件/工具调度（function calling / tool use）、联网搜索、代码解释器、文件解析。
• 安全与内容审核：输入/输出的敏感词过滤、越狱检测、PII 脱敏、安全护栏。
• 这层是传统网站里”业务逻辑层”的升级版——多了”对话状态机 + 工具编排 + 上下文工程”。

4. 推理服务层（Inference Serving）—— 这层是最大区别#

• 推理引擎：vLLM、SGLang、TensorRT-LLM、LMDeploy 等，做 PagedAttention / KV cache 复用 / continuous batching，把 GPU 吞吐拉满。
• 模型服务化：把模型包成 OpenAI 兼容的 HTTP API（/v1/chat/completions），支持流式。
• 这层是传统网站完全没有的。传统网站后端是”查数据库返回结果”，这里是”把 prompt 喂进 GPU，逐 token 吐出来”，延迟从几十毫秒变成几秒到几十秒。

5. 存储层#

• 对话历史：向量数据库（Milvus/Pinecone/pgvector）做语义检索（RAG），结构化库（PostgreSQL/MySQL）存会话元数据。
• 知识库：文档切片 → embedding → 向量库，支持上传文件问答。
• 缓存：对相同/相似 prompt 做语义缓存，省 token 钱。
• 传统网站主要存”业务数据”（订单、用户）；这里多了”向量 + 对话历史”这两类新存储。

6. 模型训练/微调层（不一定每家都做）#

• 预训练（极少公司做，烧钱）、SFT 监督微调、RLHF/DPO 对齐、领域微调。
• 这层是研究/算法团队的事，和”App 开发”关系不大，但决定了产品能力的上限。

相同点#

• 都是前后端分离 + API + 数据库的整体骨架；
• 都要鉴权、限流、CORS、HTTPS、日志监控、CI/CD；
• 前端都用 React/Vue 类框架，后端都用 Python/Go/Node；
• 都要过 nginx、CDN、负载均衡这套基础设施。

关键差异点（这才是重点）#

1. 流式响应是头等公民，而非可选 传统网站是”请求→等后端算完→返回完整响应”；AI App 几乎必须 SSE（Server-Sent Events）流式逐 token 返回，否则用户要干等十几秒。这改变了前后端契约：不能用普通 fetch().json()，要用 ReadableStream / EventSource，还要处理”中途取消""断线重连""渲染一半代码块”。WebSocket 反而用得少（SSE 单向更轻、HTTP 基础设施友好），多模态实时语音才用 WS。

2. 后端瓶颈从”I/O + DB”变成”GPU 推理算力” 传统网站调优是 SQL、索引、缓存；AI App 调优是 batch 调度、KV cache 命中率、GPU 显存、首 token 延迟。扩容方式也不一样——DB 是加从库，推理是加 GPU 卡。

3. 输出是非确定性的，测试范式变了 传统网站 assert “返回值 == 期望”；AI 输出每次可能不同，要用评测集 + 评分模型(LLM-as-judge) + 通过率指标，回归测试靠抽样打分而非精确比对。

4. 成本模型不同：按 token 计费/计成本 传统网站每请求成本近乎 0（CPU/带宽）；AI App 每次请求都有 GPU 算力成本，要做配额、限速、语义缓存、prompt 压缩。成本是产品设计的一部分（免费额度、Plus 订阅、按量付费）。

5. 上下文工程取代了”状态管理” 传统网站管”用户会话登录态”；AI App 要管多轮对话历史、上下文截断、记忆压缩、RAG 检索注入，还要处理超长上下文的 token 预算。

6. 新增一整条”模型/算法”流水线 传统网站没有”模型版本”；AI App 要管模型权重版本、灰度切换、回滚、A/B 不同模型、微调数据。这是纯新增的工程领域。

7. 安全重点不同 传统网站防 SQL 注入、XSS、CSRF；AI App 在此之上还要防越狱(jailbreak)、prompt 注入、敏感内容生成、数据投毒、PII 泄露到训练数据。输出侧的内容审核比传统网站重得多。

8. 多模态是增量复杂度 图像生成、语音对话、视频——每种模态都有独立的模型服务和流式协议（音频要低延迟双向流），传统网站不涉及。

1. 路线选择问题#

传统网站没有这个问题，AI App 移动端要先定调：

国内几大厂 App（豆包/通义/文心）几乎都是纯云端——模型太大、靠云 API 商业化、端侧成本不划算。端侧推理更多是系统级能力（Apple/Google）和第三方/社区在做。这条路线选择会直接决定后面整条工程链路。

2. 端侧推理（移动端独有重点）#

这是移动端相对 Web 最不一样的部分。主流端侧推理框架：

系统级原生能力（更值得关注，因为不依赖用户下载模型）：

• Apple Intelligence（iOS 18.2+）：系统内置约 3B 模型本地跑，重型任务走 Private Cloud Compute（Apple Silicon 服务器、端到端加密、不留存请求）。需要 A17 Pro / M1+ 起。
• Apple Foundation Models framework（WWDC 2025 / iOS 26）：第三方 App 可免费调那个端侧 ~3B 模型，纯本地、无需 API Key，支持工具调用和约束生成（guided decoding），A17 Pro 上约 30–40 tok/s。这是端侧从”系统自用”到”开发者可用”的关键转变。
• Gemini Nano（Android）：Google 端侧模型，跑在 Pixel 8 Pro+ 及部分三星机型，经 AICore 下发；开发者通过 ML Kit 的 Generative API 调用，按机型功耗分档。

端侧的核心约束（决定能跑多大模型）：

• 内存：iPhone 4–8GB、安卓 6–12GB，系统 + 你 App + 模型 + 对话历史全挤在一起。所以端侧模型基本是 1.8B–3B，4-bit 量化后约 1.5–2GB，7B 在中低端机就会 OOM。
• 量化：GGUF 的 Q4_K_M / int4 是主流，精度换内存和速度。
• 下发策略：模型几 GB，不能塞进 App 包（App Store 单包有上限），要首次启动按需下载、做断点续传、做机型适配（低端机不下发或不启用）。

3. 移动端工程难点（云端路线也躲不掉）#

流式渲染在原生 UI 里比 Web 难得多：

• iOS：URLSession 没有 SSE，要用 data task + dataTask(with:didReceiveData:) 委托手动按块拼、按 \n\n 切事件；或用 Starscream/EventSource 三方库。
• Android：OkHttp 对 SSE 支持较好，可配合 Retrofit。
• 真正难的是边收边渲染：Markdown/代码块/LaTeX 在原生 UI（UITextView/TextKit、Jetpack Compose 的 AnnotatedString）里渲染本就比 Web 的 react-markdown 麻烦，还要在 token 不断追加时不重排抖动、代码块高亮完整、表格不跳。很多 App 干脆用 WebView 内嵌一个富文本渲染页来绕过——这是个务实但被吐槽的方案。

后台与进程生命周期（移动端相对 Web 最致命的差异）：

• iOS 后台约 30s 到几分钟就被挂起/杀掉，长生成期间 App 一进后台，SSE 连接就断。
• 解法有限且都别扭：前台时 idleTimerDisabled 保屏常亮；用 BGTaskScheduler 做有限后台任务；或靠推送通知唤醒。没有”开个后台线程慢慢跑”这种 Web 式的自由。
• 网络切换（Wi-Fi↔蜂窝）也会掐断流式连接，要做断点续传 + 已生成内容的本地缓存与续写。

发热与降频：

• 长时间流式（尤其再叠加端侧推理）会让设备发烫 → CPU/GPU 降频 → token 变慢。iOS 有 thermal state API 可监测，热到一定程度要主动降级（如关掉端侧推理、降流式速率）。
• Web 不存在这个问题（算力在服务器）。

内存与闪退：

• 长对话历史 + 富文本渲染 + 可能的端侧模型同抢内存，低端机 OOM 闪退是高频 bug。要做：对话历史分页/懒加载、渲染层虚拟列表、文本节点复用、及时释放离屏内容。

弱网与移动网络特征：

• 蜂窝高延迟 + 抖动，SSE 比 Web 场景更易断流；要做指数退避重连 + 已生成内容对账（断在哪、续多少）。
• 首字延迟（TTFT）在弱网下被放大，要做打字占位符/骨架态安抚用户。

4. 客户端技术选型#

产品形态偏轻（纯云端对话）→ 跨端/壳性价比高；要做端侧推理或深度系统集成（Apple Intelligence 扩展、系统级快捷指令）→ 倾向原生。

5. 多模态与语音在移动端的特殊性#

• 语音对话：实时双向音频流要用 WebSocket（不是 SSE），要求低延迟，端侧跑 Whisper 类模型做 STT。移动端麦克风/扬声器权限、后台音频会话、蓝牙耳机切换都是坑。
• 拍照/相册问答：图片上传要压缩、EXIF 方向校正、分片续传；iOS/Android 相册权限流程不同。
• 实时屏幕理解 / 助手：需要屏幕录制权限（iOS ReplayKit、Android MediaProjection），合规和电量都是挑战。

6. 分发与合规（Web 没有的环节）#

• App Store / Google Play 审核：AI 生成内容类 App 是重点审查对象——要有内容过滤、举报通道、用户协议，否则被拒；UGC（用户自建 bot/提示词）还要按 UGC 策略审核。
• 按地区合规：端侧推理模型权重在某些地区有出口管制（例如美国 OFAC 模型清单），云端服务要按地区做模型路由。
• 隐私：端侧推理的卖点是”数据不出设备”，但 App 仍要声明是否会把对话上传；Apple ATT/Android 隐私沙箱对广告归因和跨 App 数据都有限制。

7. 与传统移动 App 开发的异同（聚焦差异）#

8. 最小可行移动端技术栈（云端起步）#

• 客户端：Flutter 或 React Native（纯云端对话够用）+ 一个流式 Markdown 渲染组件（Flutter 的 flutter_markdown + 自定义 SSE 客户端）
• 网络：Dio(http)/OkHttp 的 SSE 拦截器，带断线重连与已生成内容对账
• 后端：FastAPI + SSE 推流 + OpenAI 兼容协议（/v1/chat/completions）
• 要做端侧时：iOS 走 Apple Foundation Models（最省事、免下发权重）；跨端通用走 MLC-LLM 或 llama.cpp，配 4-bit 量化的 1.8B–3B 模型
• 监控：TTFT、流式中断率、内存峰值、机型分布、OOM 率

一句话总结移动端：相比 Web 版，移动端的本质新增项是——进程生命周期受限（后台被杀）+ 富文本流式在原生 UI 里更难 + 弱网断流处理 + 发热降频 + 端侧推理这条独立技术线（内存/量化/权重下发）+ App 分发与 AIGC 合规。其中端侧推理（尤其 Apple Foundation Models / Gemini Nano 这类系统级能力开放给开发者）是这两年变化最快的部分，也是移动端相对 Web 最独有的工程价值所在。