最近手头在做一款AI对话App项目核心工作就是围绕“接入AI”展开。从立项到第一版可用的过程里我把大模型API对接、后端网关搭建、客户端流式渲染、多轮会话管理这些环节完整走了一遍踩了不少坑也沉淀了一些比较实用的方案。这篇文章就把整个开发过程中的关键决策和实操细节复盘一下适合正在准备做类似AI对话产品的开发者参考也适合那些已经接入了API但总觉得体验不够流畅的团队对照检查。1. 先把这个项目拆明白1.1 项目核心需求解析很多团队一上来就想着做“大而全”的AI助手角色扮演、知识库问答、多模态识图、语音克隆什么都要往上加。实际动手后才发现需求越杂链路越长问题越多。我们这款AI对话App在MVP阶段只做了三件事让用户发消息、让模型回消息、把历史会话存下来。听起来简单但光是“让模型回消息”这四个字就牵扯出接口鉴权、流式传输、超时重试、上下文管理、内容安全过滤一长串问题。需求拆解时我把对话链路画了一条主线用户输入、请求后端网关、网关调用大模型API、模型流式返回、客户端逐字渲染、完成后持久化。所有额外功能都排在主线跑通之后。这么做的好处是团队始终有一个“可用的版本”兜底不会被边缘需求拖住主线进度。1.2 项目里程碑路线规划整个开发周期我拆了五个里程碑。第一个里程碑是验证API连通性用脚本直接调用大模型接口确认模型能正常返回内容。第二个里程碑是搭建后端网关把鉴权、限流、日志都收在服务端。第三个里程碑是客户端基础UI先做出聊天气泡、输入框、消息列表这些静态界面。第四个里程碑是流式接入让回复一个字一个字蹦出来这是体验质的飞跃。第五个里程碑是稳定性打磨包括历史会话存储、断网恢复、错误提示优化。每个里程碑都有明确的验收标准。比如流式接入的验收标准是“首字响应时间不超过1秒字符间隔稳定可感知”。用可量化的标准卡进度比“差不多能用了”这种模糊目标靠谱得多。1.3 技术选型的底层逻辑做技术选型时我重点考虑三个因素团队技术栈的熟悉度、迭代速度、以及长期维护成本。后端没有选Java那套重量级框架而是用了Python的FastAPI。原因很直接大模型生态里Python的SDK最成熟FastAPI原生支持异步配合SSE做流式转发非常顺手。换Java的话生态也有但很多工具链要自己拼在项目早期不划算。客户端这边选了原生Android Kotlin界面用Jetpack Compose。选原生不是因为它“高级”而是因为AI对话App对网络层和UI交互的控制要求比较高原生方案在流式刷新、键盘处理、列表滚动这些细节上最容易做到精细。如果团队要做跨平台Flutter也能干但要做好性能调优的心理准备。大模型服务商的选择上国内和海外都有可用方案。判断标准我整理成了一张表评估维度推荐权重说明文档完备度高快速跑通是关键文档差会浪费大量时间流式接口质量高是否标准SSE断线后是否有续传机制免费额度与价格中早期开发调试的Token消耗量其实不小内容安全机制高必须有可配置的敏感内容拦截能力周边生态中SDK种类、社区案例、第三方工具链2. 大模型接入把API吃透是关键2.1 大模型服务商选型与申请我选服务商跑了三个备选分别申请了测试额度逐个写脚本调用对比三个核心指标文档是否清晰、接口稳定性、返回内容质量。筛选过程持续了大概两天。有些服务商接口都通了但模型回复经常漏字排查半天发现是他们的流式协议实现不标准只能换。还有一家免费额度给得很大方但每次请求要传一堆签名参数签名算法文档还写错了也放弃了。申请通过后第一件事就是把API Key管理起来。密钥绝不能放到客户端代码里否则反编译一下就能被别人拿走盗刷。我的做法是后端单独建了一个配置服务密钥只存在于环境变量中前端请求自己的后端接口由后端持有密钥去调用大模型。客户端永远不感知密钥的存在。权限管理上再分一层后端内部把“调用大模型”和“读取历史记录”拆成不同的权限位防止被越权使用。2.2 首次对话请求的完整搭建第一步先用Python脚本验证连通性不碰任何框架。核心请求结构长这样import requests api_key sk-xxxxxxxx url https://api.example.com/v1/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: chat-model-name, messages: [ {role: system, content: 你是一个乐于助人的AI助手。}, {role: user, content: 你好请用一句话介绍你自己} ], temperature: 0.7, max_tokens: 800, stream: False } response requests.post(url, headersheaders, jsonpayload) print(response.json())这段代码里几个参数值得细说。messages是整个对话的核心结构它是一个数组每个元素有role和content两个字段。role有系统、用户、助手三种。系统消息用来设定模型的角色和行为风格用户消息是用户的输入助手消息是模型之前的回复。多轮对话的本质操作就是往这个数组里不断追加消息。temperature控制随机性数值越大回复越发散。做对话类产品一般设在0.6到0.8之间太低回复会很机械太高容易胡说。max_tokens限制回复的最大长度这里按1个汉字约等于1.5到2个token估算800个token大约能覆盖400字左右的中文回复。stream先设为False等确认连通后再改成True验证流式。跑通脚本后立刻做了异常测试。把model换成不存在的模型名观察返回什么样的错误码把api_key改错看鉴权失败的响应长什么样把max_tokens设成1看截断效果。这些异常样本留存下来后面做客户端错误提示时直接复用。2.3 流式输出打字机效果怎么做出来非流式请求要等模型生成完所有内容才一次性返回用户等待时间动辄好几秒体验很差。流式请求在模型生成第一个字时就推给客户端首字响应能压到几百毫秒配合逐字渲染用户感知到的就是“AI正在思考并回答”等待焦虑大幅降低。大模型流式接口普遍基于SSE协议也就是服务端以text/event-stream的形式持续推送数据块。每个数据块以data:开头直到收到data: [DONE]表示结束。我后端用FastAPI做了一层网关转发既隔离密钥又可以在中间做限流和日志记录。核心代码from fastapi import FastAPI, Request from fastapi.responses import StreamingResponse import httpx app FastAPI() API_KEY sk-xxx MODEL_URL https://api.example.com/v1/chat/completions app.post(/v1/chat) async def chat(request: Request): body await request.json() headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: body.get(model, chat-model-name), messages: body.get(messages), temperature: body.get(temperature, 0.7), max_tokens: body.get(max_tokens, 800), stream: True } async with httpx.AsyncClient(timeout60) as client: async with client.stream(POST, MODEL_URL, headersheaders, jsonpayload) as resp: async def generate(): async for line in resp.aiter_lines(): if line.startswith(data: ): yield line[6:] \n return StreamingResponse(generate(), media_typetext/event-stream)转发层有几个容易踩的细节。一是超时时间不能设太短大模型在复杂问题下耗时可能超过30秒我设了60秒并支持动态延长。二是转发的数据要保持原始结构不要试图在这层解析或重组数据避免引入JSON解析的额外延迟和出错点。三是网关层要做好连接断开的清理逻辑客户端断开时立即终止上游请求否则会白白消耗Token。客户端解析SSE流时用OkHttp的逐行读取来处理。核心逻辑是不断读取响应体中的行凡是data:开头的行就截取后面的内容尝试解析成JSON块把其中的增量文本追加到当前回复气泡中。遇到[DONE]标记就结束本次接收。实测下来这种逐行解析方式在弱网环境下比一次性读入更稳因为不需要等全部数据到达才开始渲染。2.4 多轮对话与上下文管理多轮对话的核心不复杂每次请求都把历史对话拼进messages数组。但有一个绕不开的问题上下文窗口是有限的。模型一次能处理的Token数有上限比如常见的32K上下文听起来很大但每轮对话都带着全部历史几轮下来就会触顶。我做了三级策略。第一级是“裁剪”维护一个最大消息条数比如20条超过就丢掉最早的。这个策略简单但粗暴模型可能会忘记早期对话的关键信息。第二级是“摘要压缩”当超过16轮对话时把更早的历史消息交给模型生成一段摘要用摘要替代原始内容放进上下文。摘要策略的效果明显更好。第三级是“关键记忆定向保留”把用户明确提到的关键信息抽出来单独放进系统消息里摘要覆盖不了的重要信息靠这个兜底。实现Token计算时我用官方开源的tokenizer工具做了封装在组装请求前先估算当前消息数组的总Token数超过了阈值就触发压缩。这个封装虽然增加了一点计算开销但能避免大量因为上下文超限导致的请求报错。上线后看到的数据是通过压缩策略长对话的Token消耗下降了30%左右同时用户对对话连续性的投诉没有增加。3. 客户端开发与接入AI的完整实操3.1 前端基础设施与配置客户端这边的网络层单独封装了一个模块核心职责只有两个统一请求头拼接和统一超时管理。客户端所有的请求都指向自己的后端域名不直接触碰任何大模型供应商的地址。这样做的好处是如果模型服务商换了客户端代码一行都不用改只改后端网关的配置即可。超时设置我在客户端做了两个层级。连接超时设为10秒弱网环境下如果10秒还建立不了连接直接提示网络异常。读取超时设为60秒因为流式响应是一点点到达的读取超时要给足。不要在客户端把超时设得太短否则问答进行到一半就会被切断用户看到的就是“AI回复到一半突然停了”体验非常糟糕。绑定baseURL时还有一个细节不同环境要用不同域名。开发环境、测试环境、生产环境的域名分开配置通过构建参数切换避免上线后连到测试服务器的尴尬。我在项目里吃过这个亏上线当天用户反馈“对话记录经常丢”查了一下午才发现测试环境的数据库被生产包连着写了一整天。3.2 消息列表与打字机效果的实现UI这块消息列表我用了Jetpack Compose的LazyColumn。流式回复的核心难点在于模型每返回一小段文本列表就要刷新一次如果每次都重新绑定全部数据用户会明显感到列表卡顿甚至闪烁。我的做法是维护一个“当前正在生成的消息”的单独状态。这个状态在流式接收期间由底层网络层持续追加字符串UI层只在文本长度发生变化时做增量更新不触发整个列表的notifyDataSetChanged。这个方法听起来很基础但很多初学者就是在这里把性能做崩的。滚动还有一个小技巧当用户在读取历史消息时不能强制把列表滚到底部这会打断阅读节奏。我的方案是判断用户当前滚动位置是否接近底部如果距离底部较近就自动跟随滚动否则只更新数据不移动滚动位置等用户滑到底部时再展示最新内容。键盘处理上输入框用了imePadding开启输入法避让。还有一个容易忽略的细节发送消息后要主动收起键盘给用户一种“已提交”的反馈感。快速连点发送按钮的问题也得处理我加了一个发送锁消息还没发完时禁止再次提交同时把按钮置灰这个交互虽然简单但非常影响对话节奏的流畅度。3.3 输入框与键盘的交互细节我把这个单独拎出来说是因为体验差别真的很大。AI对话App里输入框就是用户和AI之间唯一的物理交互入口键盘的每一次弹起和收起都直接影响操作心情。首先要确保输入框不在键盘弹出时被遮挡。Android上最稳妥的方式是给Activity设置adjustResize再配合边缘到边缘的布局模式。其次输入框获取焦点时消息列表要自动滚动到最新位置否则用户刚打几个字消息又被顶到上面去了会很烦躁。声音和震动反馈也建议加但震动要轻太强会让人觉得廉价。还有一个小细节是“多行输入”的处理。AI对话场景下用户经常输入长文本输入框不能只有单行。回车键可以保留换行功能发送通过按钮完成。如果想让发送更高效把回车键改成发送键也不是不行但要在设置里让用户自己选默认保持换行更稳妥。3.4 错误处理与状态恢复客户端错误处理我分了三类网络层错误、服务端错误、模型层错误。每类都有独立的提示文案。网络层错误是最常见的Wi-Fi切换、移动网络信号差都会导致请求中断。断网时我不仅弹提示还把当前未发出去的消息保存在本地草稿箱下次联网后让用户选择是否重新发送。服务端错误主要是限流和鉴权。限流时后端会返回429状态码我在客户端做了指数退避重试第一次重试等待2秒第二次4秒第三次8秒最多重试三次。鉴权失败说明后端配置出了问题这种错误要提示得明显不能轻描淡写否则用户反复重试只会把日志刷得更乱。模型层错误比较特殊。大模型的API有时会返回内容安全警告这种提示要柔和处理不能直接展示错误码。我单独设计了一种“系统提示气泡”用不同的背景色和文案呈现在对话流里告诉用户这条回复被安全策略拦截了。这个气泡本身也可以作为消息类型存储重新进入历史会话时能正确渲染。4. 成本控制、性能优化与风控合规4.1 模型调用成本与Token优化策略Token费用可以类比成手机流量日常聊天还好但高并发或者长对话一上来消耗量非常惊人。我上线后第一周看账单才发现单日Token消耗量远超预期。后来做了三件事才把成本压下来。第一是给所有回复设置了合理的max_tokens上限。很多模型默认会给很长的回复但用户并不需要AI每句话都写作文。把默认上限控制在500到800个token既能覆盖大多数回答场景又不会因为模型“话痨”产生额外费用。第二是做了语义缓存用户问过的问题如果在短时间内再次出现直接返回缓存结果不再调用模型。对重复性咨询类场景这类缓存能把成本降到原来的五分之一。第三是模型分级简单问题用轻量模型只有复杂推理才调用旗舰模型。我写了一个简单的意图分类器拦截“翻译”“解释成语”“时间查询”这类明确指令直接路由到廉价模型。运营数据也证实了成本优化的价值优化后单次对话的平均成本下降了约40%而用户满意度没有明显波动。4.2 响应性能与并发设计后端网关层加了两道保险。第一道是请求超时控制我用的是分级策略普通对话请求最多等模型的响应60秒超过就通知客户端“本次回答超时请稍后重试”。第二道是并发限流单个用户的并发对话数限制为1超出后直接排队让用户知道“上一条还在生成中”。不做限流的话用户连续点击发送会产生多个同时进行的大模型请求到时候栈都堆起来费用和体验都会失控。压测结果这边分享一组数据。网关层单机4核8G配置下并发50个对话请求时平均响应延迟增加了20%服务基本不抖。增长到100并发时延迟明显攀升主要是大模型服务商的接口本身成为了瓶颈。所以如果业务规模再往上走网关层只是做路由和鉴权真正的并发瓶颈在大模型服务商侧选服务商时质询一下他们的并发承载能力非常重要。4.3 数据安全与隐私合规底线AI对话App涉及用户隐私的高压线非常多。用户对话内容可能包含姓名、手机号、身份证号、病情描述等敏感信息这些都是隐私合规的重点对象。我的做法是双管齐下第一对话消息在数据库里加密存储密钥独立管理第二日志系统做了脱敏请求日志里不记录消息正文只记录请求体的大小、耗时、返回码。内容安全过滤不能只靠大模型服务商自带的那一层自己在网关层还要做一道关键词和分类模型检测。检测维度包括暴力恐吓、色情低俗、违法信息等。检测结果分为“直接拦截”和“人工审核”两级直接拦截的请求不调用模型人工审核的请求虽然调用模型但回复会被打上标记延迟展示。隐私政策里必须明确告知用户对话内容是否会被用于模型训练。如果选了“不用于训练”就要在请求头里带上相应的标识字段服务商看到这个标识就不会把数据纳入训练语料。这个字段很多人会忘记但它在合规审查中是重点检查项。5. 实战复盘遇到的那些坑与排查思路5.1 对话异常的N种现场开发半年我整理了一份“异常现场清单”每个场景都是真实踩过的坑。场景之一是“AI回答到一半突然停止”。排查方向先看网关日志确认是否触发了超时再看返回数据流确认服务商是否在中间断流。我遇到过的情况是模型在生成超过700个token的长回复时服务商那边的连接偶尔会无征兆断开最后在前端加了一个“继续生成”按钮把断掉的上下文再接上问题才算解决。场景之二是“用户连续发了两条消息AI只回了第一条”。这是典型的并发保护缺失。用户在第一条消息还没回完时又发了第二条两个请求都带着完整历史上下文到达服务端模型会基于重复的上下文生成两条回复展示时覆盖。加上单用户并发限制后这个问题不再出现。场景之三是“历史会话打开后之前的消息格式全乱了”。排查发现是Markdown渲染库的兼容性问题。有些模型回复里的代码块、表格在旧版本渲染库中不能正确解析导致消息错位。解决方案是升级渲染库并增加一个容错逻辑遇到解析失败时直接展示纯文本。异常现象优先排查方向根治建议回答中断超时、服务商流断开增加继续生成机制只回一条并发控制缺失网关层加单用户限流格式错乱渲染库兼容性升级渲染库并加容错内容为空模型返回空字符串增加请求重试与空响应兜底消息重复重试机制触发幂等处理记录请求序号5.2 那串“连接不上”的历史问题项目上线第二周用户反馈“AI时而能回时而不能回”但后端日志显示服务运行正常。排查过程一路从客户端网络层查到DNS解析最后发现是后端网关的连接池配置问题。网关转发时用的HTTP客户端连接池上限设得太小请求量一上来池子被占满新请求只能排队等待空闲连接表现就是用户侧随机超时。把连接池上限调大再配上连接空闲回收机制后问题彻底消失。这个坑提醒我转发层中间件的配置参数都要做过压测验证不能用默认值直接上生产。5.3 经验速查表与避坑技巧最后整理一份浓缩版避坑清单都是我亲手验证过的经验。密钥永远只放在服务端客户端只请求自己的网关这点怎么强调都不过分。流式输出是AI对话App的底线功能非流式方案上线即劝退。上下文管理必须做不做的话对话超过十轮必出问题。限流和幂等是一个组合缺一个都会产生故障账单。日志系统提前设计脱敏不要等合规审查来了再改。模型服务商的稳定性选型比价格更重要动不动就断流的服务商让你省下的钱全变成运维时间。前端要处理好“半截回复”流式中断时把已生成的内容保留不要让用户看到一个空气泡。上线前一定做并发压测网关参数不要用默认值。我最后再分享一个体感上的细节打字机效果不是锦上添花它直接影响用户对“AI是否在干活”的判断。第一版我偷懒用了加载转圈结果投诉率明显上升。后来换成逐字流式输出同样还是等待但用户感知完全不同。技术优化做到后面真正区分产品高下的往往就是这些看不见的小细节。
最近手头在做一款AI对话App项目核心工作就是围绕“接入AI”展开。从立项到第一版可用的过程里我把大模型API对接、后端网关搭建、客户端流式渲染、多轮会话管理这些环节完整走了一遍踩了不少坑也沉淀了一些比较实用的方案。这篇文章就把整个开发过程中的关键决策和实操细节复盘一下适合正在准备做类似AI对话产品的开发者参考也适合那些已经接入了API但总觉得体验不够流畅的团队对照检查。1. 先把这个项目拆明白1.1 项目核心需求解析很多团队一上来就想着做“大而全”的AI助手角色扮演、知识库问答、多模态识图、语音克隆什么都要往上加。实际动手后才发现需求越杂链路越长问题越多。我们这款AI对话App在MVP阶段只做了三件事让用户发消息、让模型回消息、把历史会话存下来。听起来简单但光是“让模型回消息”这四个字就牵扯出接口鉴权、流式传输、超时重试、上下文管理、内容安全过滤一长串问题。需求拆解时我把对话链路画了一条主线用户输入、请求后端网关、网关调用大模型API、模型流式返回、客户端逐字渲染、完成后持久化。所有额外功能都排在主线跑通之后。这么做的好处是团队始终有一个“可用的版本”兜底不会被边缘需求拖住主线进度。1.2 项目里程碑路线规划整个开发周期我拆了五个里程碑。第一个里程碑是验证API连通性用脚本直接调用大模型接口确认模型能正常返回内容。第二个里程碑是搭建后端网关把鉴权、限流、日志都收在服务端。第三个里程碑是客户端基础UI先做出聊天气泡、输入框、消息列表这些静态界面。第四个里程碑是流式接入让回复一个字一个字蹦出来这是体验质的飞跃。第五个里程碑是稳定性打磨包括历史会话存储、断网恢复、错误提示优化。每个里程碑都有明确的验收标准。比如流式接入的验收标准是“首字响应时间不超过1秒字符间隔稳定可感知”。用可量化的标准卡进度比“差不多能用了”这种模糊目标靠谱得多。1.3 技术选型的底层逻辑做技术选型时我重点考虑三个因素团队技术栈的熟悉度、迭代速度、以及长期维护成本。后端没有选Java那套重量级框架而是用了Python的FastAPI。原因很直接大模型生态里Python的SDK最成熟FastAPI原生支持异步配合SSE做流式转发非常顺手。换Java的话生态也有但很多工具链要自己拼在项目早期不划算。客户端这边选了原生Android Kotlin界面用Jetpack Compose。选原生不是因为它“高级”而是因为AI对话App对网络层和UI交互的控制要求比较高原生方案在流式刷新、键盘处理、列表滚动这些细节上最容易做到精细。如果团队要做跨平台Flutter也能干但要做好性能调优的心理准备。大模型服务商的选择上国内和海外都有可用方案。判断标准我整理成了一张表评估维度推荐权重说明文档完备度高快速跑通是关键文档差会浪费大量时间流式接口质量高是否标准SSE断线后是否有续传机制免费额度与价格中早期开发调试的Token消耗量其实不小内容安全机制高必须有可配置的敏感内容拦截能力周边生态中SDK种类、社区案例、第三方工具链2. 大模型接入把API吃透是关键2.1 大模型服务商选型与申请我选服务商跑了三个备选分别申请了测试额度逐个写脚本调用对比三个核心指标文档是否清晰、接口稳定性、返回内容质量。筛选过程持续了大概两天。有些服务商接口都通了但模型回复经常漏字排查半天发现是他们的流式协议实现不标准只能换。还有一家免费额度给得很大方但每次请求要传一堆签名参数签名算法文档还写错了也放弃了。申请通过后第一件事就是把API Key管理起来。密钥绝不能放到客户端代码里否则反编译一下就能被别人拿走盗刷。我的做法是后端单独建了一个配置服务密钥只存在于环境变量中前端请求自己的后端接口由后端持有密钥去调用大模型。客户端永远不感知密钥的存在。权限管理上再分一层后端内部把“调用大模型”和“读取历史记录”拆成不同的权限位防止被越权使用。2.2 首次对话请求的完整搭建第一步先用Python脚本验证连通性不碰任何框架。核心请求结构长这样import requests api_key sk-xxxxxxxx url https://api.example.com/v1/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: chat-model-name, messages: [ {role: system, content: 你是一个乐于助人的AI助手。}, {role: user, content: 你好请用一句话介绍你自己} ], temperature: 0.7, max_tokens: 800, stream: False } response requests.post(url, headersheaders, jsonpayload) print(response.json())这段代码里几个参数值得细说。messages是整个对话的核心结构它是一个数组每个元素有role和content两个字段。role有系统、用户、助手三种。系统消息用来设定模型的角色和行为风格用户消息是用户的输入助手消息是模型之前的回复。多轮对话的本质操作就是往这个数组里不断追加消息。temperature控制随机性数值越大回复越发散。做对话类产品一般设在0.6到0.8之间太低回复会很机械太高容易胡说。max_tokens限制回复的最大长度这里按1个汉字约等于1.5到2个token估算800个token大约能覆盖400字左右的中文回复。stream先设为False等确认连通后再改成True验证流式。跑通脚本后立刻做了异常测试。把model换成不存在的模型名观察返回什么样的错误码把api_key改错看鉴权失败的响应长什么样把max_tokens设成1看截断效果。这些异常样本留存下来后面做客户端错误提示时直接复用。2.3 流式输出打字机效果怎么做出来非流式请求要等模型生成完所有内容才一次性返回用户等待时间动辄好几秒体验很差。流式请求在模型生成第一个字时就推给客户端首字响应能压到几百毫秒配合逐字渲染用户感知到的就是“AI正在思考并回答”等待焦虑大幅降低。大模型流式接口普遍基于SSE协议也就是服务端以text/event-stream的形式持续推送数据块。每个数据块以data:开头直到收到data: [DONE]表示结束。我后端用FastAPI做了一层网关转发既隔离密钥又可以在中间做限流和日志记录。核心代码from fastapi import FastAPI, Request from fastapi.responses import StreamingResponse import httpx app FastAPI() API_KEY sk-xxx MODEL_URL https://api.example.com/v1/chat/completions app.post(/v1/chat) async def chat(request: Request): body await request.json() headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: body.get(model, chat-model-name), messages: body.get(messages), temperature: body.get(temperature, 0.7), max_tokens: body.get(max_tokens, 800), stream: True } async with httpx.AsyncClient(timeout60) as client: async with client.stream(POST, MODEL_URL, headersheaders, jsonpayload) as resp: async def generate(): async for line in resp.aiter_lines(): if line.startswith(data: ): yield line[6:] \n return StreamingResponse(generate(), media_typetext/event-stream)转发层有几个容易踩的细节。一是超时时间不能设太短大模型在复杂问题下耗时可能超过30秒我设了60秒并支持动态延长。二是转发的数据要保持原始结构不要试图在这层解析或重组数据避免引入JSON解析的额外延迟和出错点。三是网关层要做好连接断开的清理逻辑客户端断开时立即终止上游请求否则会白白消耗Token。客户端解析SSE流时用OkHttp的逐行读取来处理。核心逻辑是不断读取响应体中的行凡是data:开头的行就截取后面的内容尝试解析成JSON块把其中的增量文本追加到当前回复气泡中。遇到[DONE]标记就结束本次接收。实测下来这种逐行解析方式在弱网环境下比一次性读入更稳因为不需要等全部数据到达才开始渲染。2.4 多轮对话与上下文管理多轮对话的核心不复杂每次请求都把历史对话拼进messages数组。但有一个绕不开的问题上下文窗口是有限的。模型一次能处理的Token数有上限比如常见的32K上下文听起来很大但每轮对话都带着全部历史几轮下来就会触顶。我做了三级策略。第一级是“裁剪”维护一个最大消息条数比如20条超过就丢掉最早的。这个策略简单但粗暴模型可能会忘记早期对话的关键信息。第二级是“摘要压缩”当超过16轮对话时把更早的历史消息交给模型生成一段摘要用摘要替代原始内容放进上下文。摘要策略的效果明显更好。第三级是“关键记忆定向保留”把用户明确提到的关键信息抽出来单独放进系统消息里摘要覆盖不了的重要信息靠这个兜底。实现Token计算时我用官方开源的tokenizer工具做了封装在组装请求前先估算当前消息数组的总Token数超过了阈值就触发压缩。这个封装虽然增加了一点计算开销但能避免大量因为上下文超限导致的请求报错。上线后看到的数据是通过压缩策略长对话的Token消耗下降了30%左右同时用户对对话连续性的投诉没有增加。3. 客户端开发与接入AI的完整实操3.1 前端基础设施与配置客户端这边的网络层单独封装了一个模块核心职责只有两个统一请求头拼接和统一超时管理。客户端所有的请求都指向自己的后端域名不直接触碰任何大模型供应商的地址。这样做的好处是如果模型服务商换了客户端代码一行都不用改只改后端网关的配置即可。超时设置我在客户端做了两个层级。连接超时设为10秒弱网环境下如果10秒还建立不了连接直接提示网络异常。读取超时设为60秒因为流式响应是一点点到达的读取超时要给足。不要在客户端把超时设得太短否则问答进行到一半就会被切断用户看到的就是“AI回复到一半突然停了”体验非常糟糕。绑定baseURL时还有一个细节不同环境要用不同域名。开发环境、测试环境、生产环境的域名分开配置通过构建参数切换避免上线后连到测试服务器的尴尬。我在项目里吃过这个亏上线当天用户反馈“对话记录经常丢”查了一下午才发现测试环境的数据库被生产包连着写了一整天。3.2 消息列表与打字机效果的实现UI这块消息列表我用了Jetpack Compose的LazyColumn。流式回复的核心难点在于模型每返回一小段文本列表就要刷新一次如果每次都重新绑定全部数据用户会明显感到列表卡顿甚至闪烁。我的做法是维护一个“当前正在生成的消息”的单独状态。这个状态在流式接收期间由底层网络层持续追加字符串UI层只在文本长度发生变化时做增量更新不触发整个列表的notifyDataSetChanged。这个方法听起来很基础但很多初学者就是在这里把性能做崩的。滚动还有一个小技巧当用户在读取历史消息时不能强制把列表滚到底部这会打断阅读节奏。我的方案是判断用户当前滚动位置是否接近底部如果距离底部较近就自动跟随滚动否则只更新数据不移动滚动位置等用户滑到底部时再展示最新内容。键盘处理上输入框用了imePadding开启输入法避让。还有一个容易忽略的细节发送消息后要主动收起键盘给用户一种“已提交”的反馈感。快速连点发送按钮的问题也得处理我加了一个发送锁消息还没发完时禁止再次提交同时把按钮置灰这个交互虽然简单但非常影响对话节奏的流畅度。3.3 输入框与键盘的交互细节我把这个单独拎出来说是因为体验差别真的很大。AI对话App里输入框就是用户和AI之间唯一的物理交互入口键盘的每一次弹起和收起都直接影响操作心情。首先要确保输入框不在键盘弹出时被遮挡。Android上最稳妥的方式是给Activity设置adjustResize再配合边缘到边缘的布局模式。其次输入框获取焦点时消息列表要自动滚动到最新位置否则用户刚打几个字消息又被顶到上面去了会很烦躁。声音和震动反馈也建议加但震动要轻太强会让人觉得廉价。还有一个小细节是“多行输入”的处理。AI对话场景下用户经常输入长文本输入框不能只有单行。回车键可以保留换行功能发送通过按钮完成。如果想让发送更高效把回车键改成发送键也不是不行但要在设置里让用户自己选默认保持换行更稳妥。3.4 错误处理与状态恢复客户端错误处理我分了三类网络层错误、服务端错误、模型层错误。每类都有独立的提示文案。网络层错误是最常见的Wi-Fi切换、移动网络信号差都会导致请求中断。断网时我不仅弹提示还把当前未发出去的消息保存在本地草稿箱下次联网后让用户选择是否重新发送。服务端错误主要是限流和鉴权。限流时后端会返回429状态码我在客户端做了指数退避重试第一次重试等待2秒第二次4秒第三次8秒最多重试三次。鉴权失败说明后端配置出了问题这种错误要提示得明显不能轻描淡写否则用户反复重试只会把日志刷得更乱。模型层错误比较特殊。大模型的API有时会返回内容安全警告这种提示要柔和处理不能直接展示错误码。我单独设计了一种“系统提示气泡”用不同的背景色和文案呈现在对话流里告诉用户这条回复被安全策略拦截了。这个气泡本身也可以作为消息类型存储重新进入历史会话时能正确渲染。4. 成本控制、性能优化与风控合规4.1 模型调用成本与Token优化策略Token费用可以类比成手机流量日常聊天还好但高并发或者长对话一上来消耗量非常惊人。我上线后第一周看账单才发现单日Token消耗量远超预期。后来做了三件事才把成本压下来。第一是给所有回复设置了合理的max_tokens上限。很多模型默认会给很长的回复但用户并不需要AI每句话都写作文。把默认上限控制在500到800个token既能覆盖大多数回答场景又不会因为模型“话痨”产生额外费用。第二是做了语义缓存用户问过的问题如果在短时间内再次出现直接返回缓存结果不再调用模型。对重复性咨询类场景这类缓存能把成本降到原来的五分之一。第三是模型分级简单问题用轻量模型只有复杂推理才调用旗舰模型。我写了一个简单的意图分类器拦截“翻译”“解释成语”“时间查询”这类明确指令直接路由到廉价模型。运营数据也证实了成本优化的价值优化后单次对话的平均成本下降了约40%而用户满意度没有明显波动。4.2 响应性能与并发设计后端网关层加了两道保险。第一道是请求超时控制我用的是分级策略普通对话请求最多等模型的响应60秒超过就通知客户端“本次回答超时请稍后重试”。第二道是并发限流单个用户的并发对话数限制为1超出后直接排队让用户知道“上一条还在生成中”。不做限流的话用户连续点击发送会产生多个同时进行的大模型请求到时候栈都堆起来费用和体验都会失控。压测结果这边分享一组数据。网关层单机4核8G配置下并发50个对话请求时平均响应延迟增加了20%服务基本不抖。增长到100并发时延迟明显攀升主要是大模型服务商的接口本身成为了瓶颈。所以如果业务规模再往上走网关层只是做路由和鉴权真正的并发瓶颈在大模型服务商侧选服务商时质询一下他们的并发承载能力非常重要。4.3 数据安全与隐私合规底线AI对话App涉及用户隐私的高压线非常多。用户对话内容可能包含姓名、手机号、身份证号、病情描述等敏感信息这些都是隐私合规的重点对象。我的做法是双管齐下第一对话消息在数据库里加密存储密钥独立管理第二日志系统做了脱敏请求日志里不记录消息正文只记录请求体的大小、耗时、返回码。内容安全过滤不能只靠大模型服务商自带的那一层自己在网关层还要做一道关键词和分类模型检测。检测维度包括暴力恐吓、色情低俗、违法信息等。检测结果分为“直接拦截”和“人工审核”两级直接拦截的请求不调用模型人工审核的请求虽然调用模型但回复会被打上标记延迟展示。隐私政策里必须明确告知用户对话内容是否会被用于模型训练。如果选了“不用于训练”就要在请求头里带上相应的标识字段服务商看到这个标识就不会把数据纳入训练语料。这个字段很多人会忘记但它在合规审查中是重点检查项。5. 实战复盘遇到的那些坑与排查思路5.1 对话异常的N种现场开发半年我整理了一份“异常现场清单”每个场景都是真实踩过的坑。场景之一是“AI回答到一半突然停止”。排查方向先看网关日志确认是否触发了超时再看返回数据流确认服务商是否在中间断流。我遇到过的情况是模型在生成超过700个token的长回复时服务商那边的连接偶尔会无征兆断开最后在前端加了一个“继续生成”按钮把断掉的上下文再接上问题才算解决。场景之二是“用户连续发了两条消息AI只回了第一条”。这是典型的并发保护缺失。用户在第一条消息还没回完时又发了第二条两个请求都带着完整历史上下文到达服务端模型会基于重复的上下文生成两条回复展示时覆盖。加上单用户并发限制后这个问题不再出现。场景之三是“历史会话打开后之前的消息格式全乱了”。排查发现是Markdown渲染库的兼容性问题。有些模型回复里的代码块、表格在旧版本渲染库中不能正确解析导致消息错位。解决方案是升级渲染库并增加一个容错逻辑遇到解析失败时直接展示纯文本。异常现象优先排查方向根治建议回答中断超时、服务商流断开增加继续生成机制只回一条并发控制缺失网关层加单用户限流格式错乱渲染库兼容性升级渲染库并加容错内容为空模型返回空字符串增加请求重试与空响应兜底消息重复重试机制触发幂等处理记录请求序号5.2 那串“连接不上”的历史问题项目上线第二周用户反馈“AI时而能回时而不能回”但后端日志显示服务运行正常。排查过程一路从客户端网络层查到DNS解析最后发现是后端网关的连接池配置问题。网关转发时用的HTTP客户端连接池上限设得太小请求量一上来池子被占满新请求只能排队等待空闲连接表现就是用户侧随机超时。把连接池上限调大再配上连接空闲回收机制后问题彻底消失。这个坑提醒我转发层中间件的配置参数都要做过压测验证不能用默认值直接上生产。5.3 经验速查表与避坑技巧最后整理一份浓缩版避坑清单都是我亲手验证过的经验。密钥永远只放在服务端客户端只请求自己的网关这点怎么强调都不过分。流式输出是AI对话App的底线功能非流式方案上线即劝退。上下文管理必须做不做的话对话超过十轮必出问题。限流和幂等是一个组合缺一个都会产生故障账单。日志系统提前设计脱敏不要等合规审查来了再改。模型服务商的稳定性选型比价格更重要动不动就断流的服务商让你省下的钱全变成运维时间。前端要处理好“半截回复”流式中断时把已生成的内容保留不要让用户看到一个空气泡。上线前一定做并发压测网关参数不要用默认值。我最后再分享一个体感上的细节打字机效果不是锦上添花它直接影响用户对“AI是否在干活”的判断。第一版我偷懒用了加载转圈结果投诉率明显上升。后来换成逐字流式输出同样还是等待但用户感知完全不同。技术优化做到后面真正区分产品高下的往往就是这些看不见的小细节。
