企业官网建设流程全解析

从标题看，这像是一个开发者终于把手里的免费AI聊天引擎搬上手机端的里程碑时刻。但真正让我感兴趣的，不是“王炸功能”这四个字，而是这类项目背后一套完整的移动端聊天架构：免费的模型服务、跨端的前端框架、流式输出的处理、再加上一堆手机端特有的兼容问题。如果你也想自己搭一个能在手机上随手打开的AI聊天应用，这篇就来拆解它到底由哪些部分组成，以及怎么从零跑通一条最小链路。

先说结论：手机端AI聊天项目的技术门槛，并不在模型本身，而在于三层问题。第一层是模型服务怎么选，免费方案通常有“本地部署开源模型”和“云端免费额度”两条路；第二层是手机端怎么和模型服务通信，聊天场景要求每生成一个字就刷新一次，这就离不开流式协议；第三层是做进手机壳之后的状态栏、跨域、版本一致性等工程细节。搞懂这三层，你也能复刻一个免费AI聊天引擎的手机端。

这篇文章不会去比较哪个模型“更聪明”，而是先给出一套可落地的参考架构：用Ollama跑开源模型，用FastAPI写一个SSE流式聊天接口，再用uni-app做一个跨iOS和Android的聊天页面。代码会分成后端、前端、运行验证三部分，最后还会把手机端开发里最容易踩的坑列出来。

1. 为什么手机端AI聊天值得自己搭

现在市场上并不缺AI聊天App，但我身边很多开发者最终都走向了自建。原因集中在三方面：订阅成本高、数据不在自己手里、功能不能按需改。官方App往往采用会员订阅制，每月费用不低，而且聊天记录和个性化配置大多绑定云端；一旦你想要一个自己的提示词模板、一个本地知识库入口，或者只是想改一下界面字号，官方产品基本不会给你开口。

“免费AI聊天引擎”真正吸引人的地方，不是白嫖一个模型，而是把“对话能力”变成自己项目里的一个模块。比如给现有业务加一个智能客服、给个人工具加一个语音助手，这些场景都需要一个能自由定制、能嵌入到手机端应用里的引擎。自己做出来的东西，模型可以随时换，接口可以随手改，数据也可以只留在本地服务器。

从成本角度看，免费通常分两种。一种是本地部署开源模型，只要电脑或服务器跑得动，就没有接口费用，也没有调用次数限制，但需要电费和硬件投入；另一种是使用云厂商的免费额度，接入简单、响应快，但通常有频率上限，而且要注意密钥不能暴露在客户端。这篇示例以Ollama本地模型为主，因为链路最简单，不依赖外部服务，也不需要申请各种密钥，特别适合先跑通流程。

适合读这篇文章的读者，大致有三类。第一类是已经用过ChatGPT或各类AI工具，想自己做一个简易聊天App的前端开发者；第二类是公司内部要做AI客服或AI助手，需要一个轻量MVP做验证的后端开发者；第三类是刚接触移动端开发，想同时了解SSE、跨端框架、本地模型服务这些概念的学生或爱好者。如果你只是想要一个能用的聊天软件，直接装现成App更省事；但如果你想要一个能改、能扩展、能私有部署的聊天引擎，这篇文章可以帮你把第一版跑起来。

2. 手机端AI聊天项目整体架构与选型

2.1 三层架构：手机端、网关服务、模型服务

手机端AI聊天项目虽然看起来是一个“App”，但按职责拆分后至少有三层。最上层是手机端，负责展示消息、收集输入、维护聊天界面；中间层是后端网关服务，负责接收手机端的请求、调用模型、把结果流式返回；最底层是模型服务，可以是一台运行Ollama的本地机器，也可以是一个远程API服务。

为什么中间一定要加一层后端网关，而不是让手机端直接连模型？这里有两个很现实的原因。第一是密钥安全，模型服务的API Key如果写在手机App里，客户端一旦被破解，密钥就泄露了；在后端统一调用模型，手机端只面对自己的业务接口。第二是协议统一，手机端只需要知道如何请求自己的后端，至于后端调的是Ollama还是云API，手机端完全不用关心，后续换模型服务不用重新发版。

2.2 技术选型对比与理由

前端框架方面，目前主流可选uni-app、Flutter、React Native。这里我建议用uni-app，理由很实际：它基于Vue语法，前端开发上手快，一套代码可以编译到iOS、Android和H5，微信小程序也能覆盖。对于“手机端AI聊天”这种以表单、列表、滚动文本为主的界面，uni-app的成熟组件完全可以胜任，而且国内社区资料多，遇到问题容易搜到。

后端方面选择Python FastAPI，看重的是它对异步流式支持非常好。聊天接口需要把模型逐步生成的内容持续推给前端，FastAPI的StreamingResponse配合异步生成器，写起来很直观。Node.js也能做，但FastAPI在数据建模和接口文档上更省事，启动项目后自带Swagger文档，方便调试。

模型服务选择Ollama，重点在于它把本地运行开源模型的复杂度降得非常低。一条命令拉模型，一条命令启动服务，还提供了OpenAI兼容接口，意味着上层代码可以按统一规范编写。换成其他模型平台时，只要接口兼容，改动量很小。

2.3 两条实现路线的取舍

如果只想做最小Demo，可以跳过后端，手机端直接请求云端兼容接口，但你需要自己处理跨域、密钥暴露和流量计费问题。这种方式适合个人临时测试，不适合作为工程化项目的基础。更稳的做法是本文采用的“手机端 + 后端网关 + 本地模型”模式，开发阶段链路稍长，但每一步都可控。

如果团队里有服务器，本地部署模型的体验更像“私有化AI引擎”。在算力允许的情况下，可以同时挂多个模型，按业务场景切换。如果服务器配置一般，则可以考虑云端免费额度，但要在后端做一层缓存和限流，避免免费额度被刷爆。不管选哪条路线，手机端代码都建议保持“只对接业务接口”的姿势，为以后替换模型服务留出余地。

3. 基础概念说明：SSE、OpenAI兼容接口与Token

3.1 什么是SSE流式输出

SSE全称Server-Sent Events，从名字可以看出来，这是服务器主动向客户端推送事件的协议。在AI聊天场景里，模型不是一次性把整段话生成完，而是逐个Token生成；如果不做流式，用户发出问题后可能要等十几秒才能看到结果，体验非常差。使用SSE后，后端每生成一小段内容，就立刻通过HTTP连接推给前端，屏幕上就会呈现“逐字输出”的效果。

SSE和WebSocket的区别，很多新手会搞混。WebSocket是双向通信，适合聊天室、实时协作这类前后端频繁互动的场景；SSE是单向的，由服务器向客户端持续推送，但它建立在普通HTTP之上，实现简单、自动重连也方便。AI对话本质上是用户发一次请求，服务器持续回一段话，正好落在SSE的优势区间。

3.2 OpenAI兼容接口为什么重要

OpenAI兼容接口指的是/v1/chat/completions这一类标准接口格式，请求和返回结构都有固定规范。只要模型服务实现了这个协议，上层业务代码就可以用同一套逻辑对接不同模型。Ollama目前也提供了这样的兼容接口，这让本地模型和云端模型在代码层面保持了一致。

兼容接口的流式返回，每一行以data:开头，最后以data: [DONE]结束。前端解析SSE流时，只需要不断按行读取，凡是以data:开头的内容都按JSON解析，取其中的增量文本字段；看到[DONE]就停止。这个数据格式是整个聊天链路的关键，后续示例代码就是围绕它展开的。

3.3 Token与上下文窗口

Token可以简单理解为模型处理文本的最小单位，中文场景下，一个字可能对应一到两个Token，不同模型的切分方式不一样。模型一次能接收的最大Token数叫上下文窗口，超出后要么报错，要么需要做截断。在聊天功能里，对话历史会越来越长，如果不做控制，很快会撑满上下文。

常见的做法是只保留最近几轮消息，比如保存最近10轮对话，旧消息在发往模型之前过滤掉。这样既能节省Token消耗，也能减少模型响应延迟。更好的方案是把早期对话摘要成一段总结，与最近消息一起发送，但这属于后续优化的方向。对于第一版，滑动窗口截断已经够用。

4. 环境准备与前置条件

4.1 模型服务环境：安装Ollama

本示例以Ollama作为模型服务，安装过程比较直接。Ollama支持Windows、macOS和Linux，官方安装包下载后即可运行。安装完成后，在终端启动服务，并拉取一个适合聊天对话的中文模型。下面给出常用命令：

# 启动Ollama服务 ollama serve # 单独打开一个终端，拉取qwen2.5系列模型 ollama pull qwen2.5:7b

执行ollama pull命令时，会从模型仓库下载模型文件，文件大小取决于模型规格。以7B规模模型为例，通常需要几个GB磁盘空间，下载耗时取决于网络。下载完成后，可以先用命令行快速验证模型能否正常对话：

ollama run qwen2.5:7b "介绍一下你自己"

如果模型能在终端里输出回答，说明Ollama服务正常，可以继续搭建后端。需要注意，qwen2.5:7b只是一个示例标签，实际可用的模型名称以Ollama官方模型库为准。

4.2 后端运行环境

后端代码使用Python编写，建议使用Python 3.10及以上版本，因为后面的示例代码用到了较新的类型注解写法。项目依赖使用pip管理，主要安装FastAPI、Uvicorn和HTTP客户端库。Uvicorn用来启动Web服务，httpx用来让后端异步调用Ollama接口。

安装依赖的命令如下：

pip install fastapi "uvicorn[standard]" httpx

安装完成后，可以执行python --version确认Python版本，再执行uvicorn --version确认服务工具可用。如果电脑上有多个Python环境，建议先创建虚拟环境，避免依赖冲突。这个后端项目本身不连数据库，第一版可以把聊天历史交给手机端本地存储。

4.3 前端运行环境

手机端项目选择uni-app，开发环节有两种方式。一种是使用HBuilderX可视化创建项目，优点是界面操作简单，适合不需要命令行构建的开发者；另一种是使用命令行创建Vue3 + Vite模板，适合习惯使用VS Code等编辑器的开发者。这里以命令行模板为例：

npx degit dcloudio/uni-preset-vue#vite my-ai-chat cd my-ai-chat npm install npm run dev:h5

如果本机还没有安装Node.js，需要先从Node.js官网下载LTS版本安装。npm install可能会花一点时间，因为要下载依赖包。npm run dev:h5的作用是在浏览器里启动H5版页面，方便开发调试；后续需要打包成App时，再用HBuilderX或官方命令行工具发布。

5. 构建聊天后端服务

5.1 后端项目结构

一个小型后端不需要复杂的目录，先让代码可运行比什么都重要。建议在后端目录下至少包含两个文件：requirements.txt用来记录依赖，main.py用来放FastAPI应用和接口逻辑。后续如果项目变大，再按模板、路由、服务层拆分。

项目结构如下：

chat-backend/ ├── requirements.txt └── main.py

这里的核心思路是只暴露两个能力：接收手机端发来的对话消息，把模型返回的增量内容以SSE流式推给手机端。main.py里会包含CORS配置、请求体定义、Ollama调用逻辑和流式返回逻辑。

5.2 写入依赖文件

创建requirements.txt，把运行时依赖写进去。这里不锁定具体版本，安装时取其当前可用版本即可。如果你需要锁定版本保证上线可重复，建议安装成功后用pip freeze重新生成依赖列表。

fastapi uvicorn[standard] httpx

保存在后端目录后，执行pip install -r requirements.txt完成依赖安装。如果在真实生产环境中，还会加入日志、配置中心、链路追踪等组件，但当前MVP阶段不需要。

5.3 实现SSE聊天接口

下面这段代码实现了一个完整的/api/chat接口。它接收到手机端传来的消息列表后，调用本机Ollama的/v1/chat/completions兼容接口，并把模型返回的增量内容逐个包装成SSE数据行返回给前端。

# -*- coding: utf-8 -*- # 文件路径：main.py from fastapi import FastAPI from fastapi.middleware.cors import CORSMiddleware from fastapi.responses import StreamingResponse from pydantic import BaseModel import json import httpx app = FastAPI() # 开发阶段放开跨域，生产环境建议改成具体域名 app.add_middleware( CORSMiddleware, allow_origins=["*"], allow_credentials=False, allow_methods=["*"], allow_headers=["*"], ) # 本地Ollama默认地址 OLLAMA_BASE_URL = "http://127.0.0.1:11434" MODEL_NAME = "qwen2.5:7b" class ChatMessage(BaseModel): role: str content: str class ChatRequest(BaseModel): messages: list[ChatMessage] temperature: float = 0.7 def parse_sse_line(line: str): if not line.startswith("data:"): return None data = line[len("data:"):].strip() if data == "[DONE]": return None return json.loads(data) async def generate_stream(messages: list[ChatMessage], temperature: float): payload = { "model": MODEL_NAME, "messages": [m.model_dump() for m in messages], "stream": True, "temperature": temperature, } async with httpx.AsyncClient(timeout=60) as client: async with client.stream( "POST", f"{OLLAMA_BASE_URL}/v1/chat/completions", json=payload, ) as resp: async for line in resp.aiter_lines(): parsed = parse_sse_line(line) if not parsed: continue choices = parsed.get("choices") or [] if not choices: continue delta = choices[0].get("delta") or {} content = delta.get("content") if content: yield f"data: {json.dumps({'content': content}, ensure_ascii=False)}\n\n" @app.post("/api/chat") async def chat(req: ChatRequest): return StreamingResponse( generate_stream(req.messages, req.temperature), media_type="text/event-stream", )

这段代码的核心在generate_stream函数。它用httpx.AsyncClient请求Ollama的流式接口，按行读取响应；每读到一条包含增量内容的JSON，就把它转换成统一格式的SSE消息。这样不管底层模型返回的结构有多少差异，手机端拿到的始终是{"content": "..."}这种统一格式。

需要特别提醒的是，这里为了演示方便，跨域配置写成了allow_origins=["*"]。这只能用于本机开发和局域网联调，如果部署到公网，必须改成受信任的来源列表，并考虑增加请求鉴权，否则任何网页都能向你的接口发起请求。

5.4 接口设计说明

聊天接口采用POST方式，请求体是一个标准JSON对象。messages数组里保存对话历史，每一项包含role和content两个字段；role可以取system、user或assistant，分别表示系统设定、用户消息和助手回复。temperature控制生成随机性，值越大回答越发散，一般在0到1之间。

返回时使用text/event-stream类型，前端浏览器或客户端只有识别到这种媒体类型，才会以流式方式处理响应。这个接口不返回完整JSON，如果需要兼容非流式客户端，可以再提供一个普通接口做兜底，但第一版建议先专注跑通流式。

6. 手机端核心流程拆解与代码实现

6.1 创建uni-app项目

假设你已经通过前面的命令创建好项目，并执行了npm run dev:h5。在这里，我们会新建一个聊天页面，页面结构包含三块：消息展示区、底部输入框、发送按钮。消息列表用scroll-view处理滚动，输入框用原生input组件，底部按钮用button。

创建好的项目里，页面目录通常是src/pages。为了保持结构清晰，可以在src/pages下新建一个chat目录，并在pages.json里注册页面路径。如果还不熟悉页面注册规则，可以参考uni-app官方文档中关于pages.json的说明。

6.2 聊天页面布局

下面的代码是一个最简可用的聊天页面模板，核心目标是把用户消息和助手消息以左右气泡形式展示出来。样式部分没有做过多的美化，重点在于业务逻辑能跑通。

<!-- 文件路径：src/pages/chat/chat.vue --> <template> <view class="chat-page"> <scroll-view class="message-list" scroll-y :scroll-top="scrollTop"> <view v-for="(msg, index) in messages" :key="index" class="message-row" :class="msg.role === 'user' ? 'user' : 'assistant'" > <view class="bubble">{{ msg.content }}</view> </view> </scroll-view> <view class="input-bar"> <input v-model="inputText" placeholder="说点什么..." confirm-type="send" @confirm="send" /> <button :disabled="loading" @click="send">发送</button> </view> </view> </template> <script setup> import { ref } from "vue"; import { fetchChat } from "@/api/chat"; const messages = ref([]); const inputText = ref(""); const loading = ref(false); const scrollTop = ref(0); async function send() { const text = inputText.value.trim(); if (!text || loading.value) return; messages.value.push({ role: "user", content: text }); const assistantMsg = { role: "assistant", content: "" }; messages.value.push(assistantMsg); inputText.value = ""; loading.value = true; // 发送消息历史时，去掉最后一条尚未生成完的assistant消息 const history = messages.value.slice(0, -1); try { await fetchChat(history, (chunk) => { assistantMsg.content += chunk; scrollTop.value = 99999; }); } catch (error) { assistantMsg.content = `请求出错：${error.message}`; } finally { loading.value = false; } } </script> <style scoped> .chat-page { display: flex; flex-direction: column; height: 100vh; } .message-list { flex: 1; padding: 20rpx; box-sizing: border-box; } .message-row { display: flex; margin-bottom: 20rpx; } .message-row.user { justify-content: flex-end; } .bubble { max-width: 80%; padding: 16rpx 24rpx; border-radius: 16rpx; background-color: #f2f3f5; word-break: break-word; } .message-row.user .bubble { background-color: #4a90d9; color: #ffffff; } .input-bar { display: flex; padding: 16rpx; border-top: 1px solid #eee; background-color: #ffffff; } .input-bar input { flex: 1; height: 72rpx; border: 1px solid #ddd; border-radius: 12rpx; padding: 0 20rpx; } .input-bar button { margin-left: 16rpx; } </style>

页面逻辑不算复杂。send方法先把用户输入推入messages数组，再创建一个内容为空的助手消息也推入数组；随后把除最后一条助手消息之外的历史记录发给后端。后端每返回一个文本片段，就往助手消息的content后面追加，因为Vue的响应式绑定，界面会实时更新。

这里有一个非常容易踩的坑：如果你把完整messages数组发给后端，最后一条消息可能是角色为assistant但内容为空的占位消息，模型会把它当成一条异常输入。所以发送前必须用slice(0, -1)去掉它。本文代码已经处理了这个问题，但你自己从零写的时候很容易漏掉。

6.3 请求封装与SSE解析

在src/api/chat.js中封装请求逻辑。这里使用浏览器fetch的ReadableStream能力，逐段读取后端返回的数据。本示例适配H5端，因为H5运行在浏览器中，具备完整fetch能力；如果你要跑在App端，建议之后将后端改造成WebSocket，再用uni.connectSocket接收消息。

// 文件路径：src/api/chat.js const BASE_URL = "http://localhost:8000"; export async function fetchChat(messages, onMessage) { const response = await fetch(`${BASE_URL}/api/chat`, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ messages, temperature: 0.7 }), }); if (!response.ok) { throw new Error(`请求失败：${response.status}`); } const reader = response.body.getReader(); const decoder = new TextDecoder("utf-8"); let buffer = ""; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); const lines = buffer.split("\n"); buffer = lines.pop(); for (const line of lines) { if (!line.startsWith("data:")) continue; const data = line.slice(5).trim(); if (!data || data === "[DONE]") continue; const json = JSON.parse(data); if (json.content) { onMessage(json.content); } } } }

解析SSE的关键在于“按行拆包”。后端在返回数据时，每条消息以空行分隔，但网络传输过程中一个完整数据块可能会被拆成多个片段。技巧是维护一个buffer，先按换行符拆分，把拆出来的完整行拿出来处理，最后一个不完整片段留在buffer里等下一次读取再合并。

真正开发时，还会遇到[DONE]标记，它表示整个流式响应结束。代码里遇到这个标记直接跳过，因为循环也会在reader.read()返回done后终止。如果后端在某次响应中同时返回多行数据，这段代码也能按顺序依次解析，不会丢数据。

6.4 状态栏与安全区适配

手机端页面布局还有一个常见问题：消息列表顶部会被状态栏遮挡。浏览器环境下一般没有这个问题，但打包成App后，状态栏会占掉一部分屏幕高度。处理思路有两种，一种是在pages.json里配置导航栏，让uni-app自己处理状态栏高度；另一种是自定义沉浸式状态栏，在页面根节点上加上padding-top，并用CSS变量env(safe-area-inset-top)预留安全区。

建议第一版先用默认导航栏，把状态栏问题交给框架处理，集中精力调通聊天逻辑。后续如果要做自定义导航栏，再统一处理安全区。状态栏适配是个典型的“看起来不重要、真机上很头疼”的问题，所以这里单独提出来。

7. 运行验证与联调

7.1 启动后端并验证接口

先把Ollama服务确保在运行，然后在后端目录启动FastAPI应用。命令如下：

uvicorn main:app --host 0.0.0.0 --port 8000

这里把--host设置成0.0.0.0，是为了让手机通过局域网IP也能访问到后端，而不是只能在本机访问。启动后，在浏览器打开http://127.0.0.1:8000/docs，可以看到FastAPI自动生成的接口文档，这能帮助你快速测试接口参数。

使用curl命令可以直接验证SSE流是否正常。终端里执行下面的命令，如果能看到多行data:输出，说明后端到模型服务的链路是通的。

curl -N -X POST http://127.0.0.1:8000/api/chat \ -H "Content-Type: application/json" \ -d '{"messages":[{"role":"user","content":"用一句话介绍你自己"}],"temperature":0.7}'

-N参数用于关闭curl的输出缓冲，让流式内容尽快显示。如果这里没有任何输出，第一步看Ollama服务是否运行，第二步看终端里有没有报错日志。后端接口是整条链路的中间层，先把这里跑通，再排查前端问题。

7.2 启动前端并模拟手机环境

在my-ai-chat项目目录下执行npm run dev:h5，浏览器会打开H5页面。为了模拟手机端效果，可以用浏览器开发者工具的移动设备模式。此时在输入框里输入一句话，点击发送，消息区域应该能看到助手内容逐字出现。

如果你手边有真机，想用手机访问H5页面，需要注意两点。第一，手机和电脑要处于同一个局域网；第二，前端BASE_URL不能写localhost，要改成电脑的局域网IP，比如http://192.168.1.100:8000。同时，后端启动时已经监听了0.0.0.0，手机才能通过局域网访问到接口。

7.3 判断功能是否成功

一个聊天功能是否成功，可以从三个维度判断。第一是“能聊起来”，用户发送消息后，模型返回正常中文回答，内容没有截断；第二是“能流式显示”，文字不是等全部生成完才出现，而是边生成边显示；第三是“能维持上下文”，连续问“我叫小明”再问“我叫什么”，模型能记住前文。

如果第一轮就失败，优先看浏览器控制台和终端日志。浏览器控制台会显示请求失败或CORS报错；终端日志会显示后端是否收到了请求、Ollama是否正常响应。不要一上来就改代码，先定位是哪一层出了问题，再对症处理。

8. 常见问题与排查思路

手机端AI项目跑起来之后，涉及的工程问题比单纯写后端要多。下面列出开发过程中最高频的一些问题，基本覆盖了从“网页能跑”到“手机能正常用”的差距。

这里特别要说一下“App端无法读取流式数据”的问题。本文示例代码用fetch实现SSE解析，在H5端可以正常运行，但打包成App后，uni-app的App端并不是完整的浏览器环境，fetch的流式读取能力在不同设备上表现不一致。更稳妥的做法是后端同时提供WebSocket接口，App端用uni.connectSocket建立长连接，收到多少数据就渲染多少数据。这是移动端聊天项目的常见选型，不要等到测试阶段才发现。

另一个容易被忽视的问题是“真机调试和模拟器行为不一致”。模拟器里页面正常，真机上状态栏遮挡、键盘弹起把输入框顶走、网络请求被移动网络拦截，这些情况都可能出现。建议从第一版开始就坚持真机联调，真机出现的问题才是用户真正会遇到的问题。

9. 最佳实践与工程建议

9.1 安全边界与密钥管理

一定要记住一个原则：模型服务的API Key、内部接口地址、管理后台信息，都不能出现在手机端代码里。即使是免费模型，一旦密钥泄露，别人可以拿你的Key去刷接口，轻则消耗免费额度，重则产生费用。正确方式是把所有外部依赖收敛到后端服务，手机端只拿到一个短期的业务Token。

如果你使用的是云端API，建议在后端增加请求频率限制，比如每个用户每分钟最多请求10次。免费额度不是无限额度，不做限流的话，一个异常客户端就可能耗尽整个项目的预算。Ollama本地部署虽然没有Key泄露风险，但也要做访问控制，避免局域网内其他设备直接调模型接口。

9.2 上下文长度控制

聊天项目上线后最明显的体验差异来自上下文管理。把所有历史对话都发给模型，一是浪费Token，二是超出模型窗口后直接报错。常见做法是只保留最近N轮消息，比如10轮，超过部分丢弃；如果想保留更多记忆，可以把更早的对话交给模型做摘要，把摘要作为系统提示词的一部分。

对于第一版，滑动窗口截断已经足够。后续如果要做知识库问答，可以把用户问题先召回相关片段，拼进提示词再发给模型，而不是把整本资料都塞进上下文。这个优化方向会让聊天质量有很大提升，属于“从能用到好用”的关键一步。

9.3 状态栏与安全区适配

移动端页面与普通网页最大的区别之一就是状态栏和底部手势条。如果页面使用全屏沉浸式布局，顶部状态栏会遮住内容，底部手势条也可能遮住输入框。建议在开发阶段就统一封装一个“安全区容器”组件，把env(safe-area-inset-top)和env(safe-area-inset-bottom)等系统变量集中管理。

很多人在做“手机端显示状态栏”时只处理了高度，忽略了聊天输入框被键盘顶起的问题。在scroll-view和输入框的布局上，尽量使用flex布局让输入框固定在底部；当键盘弹出时，uni-app在不同平台上的表现也不一样，需要根据平台做兼容。这些细节不会出现在后端接口设计里，但对用户体验影响很大。

9.4 日志与错误上报

后端接口能工作只是起点，线上出问题时如果没有任何日志，排查会非常痛苦。建议在聊天接口中记录三类日志：请求日志，包含消息长度和模型名称；错误日志，包含异常类型和堆栈；性能日志，包含首包时间和总响应时长。这些日志不需要一开始做得很重，靠Python的logging标准库就能满足。

手机端同样需要错误日志。当用户反馈“发送后没反应”“回答到一半没了”，如果前端没有任何上报，开发者很难判断是接口报错、模型超时还是网络断开。第一版可以先把错误信息写入console，同时弹窗提示；后续再接入可观测性平台，把关键日志统一收集起来。

9.5 版本管理与团队协作

手机端项目和纯后端项目有一个很大的不同：前端代码要经过编译才能运行在真实设备上，而编译工具链如果版本不一致，很容易出现“我这能跑、你那不能跑”的情况。解决思路是统一开发工具和依赖版本，项目里提交package-lock.json或pnpm-lock.yaml，让团队成员安装同一套依赖。

如果团队中有人用HBuilderX、有人用命令行CLI，建议约定项目使用其中一种作为主链路，避免混用导致构建结果不一致。H5端、App端、小程序端是同一套代码的多个编译目标，也要在CI流程里分别构建验证。这套规范并不复杂，但能省掉大量联调时间。

10. 总结与后续学习方向

这篇内容拆解的是一个免费AI聊天引擎手机端的完整链路。核心并不在于某个模型“效果多么好”，而在于四个技术点能否串起来：Ollama本地模型服务、FastAPI的SSE流式接口、uni-app的跨端聊天页面、以及手机端特有的状态栏与版本兼容问题。把这套链路跑通之后，你已经具备了自己搭建AI聊天应用的基础骨架。

下一步可以沿着几个方向继续深入。一是把前端通信方式从SSE换成WebSocket，让App端的流式输出更稳定；二是在后端加入用户体系，让每个用户的消息和历史记录互相隔离；三是引入向量数据库，给聊天引擎加一个知识库能力。每个方向都能让这个“免费AI聊天引擎”从一个Demo变成可上线的产品。

如果你正在计划自己的手机端AI项目，建议先用本文的代码跑通最小链路，再围绕实际业务去调整模型选择和交互方式。本地模型和云端API各有优势，没有绝对的好坏，只有适不适合当前场景。把基础链路吃透，后续换模型、加功能都会轻松很多。