★ FEATURED ARTICLE 最近在做的一个跨端对话助手项目终于跑通了鸿蒙真机整个过程中最有意思的部分是用Flutter做壳通过groq的LPU推理服务做端云混合调用把生成式AI的“重计算”尽可能下沉到云端端上只保留轻量的交互与渲染逻辑。标题里的“极简栈”不是夸张整套工程的第三方依赖控制在个位数这在涉及AI调用的客户端项目里确实不太常见。这篇文章把整个项目的设计拆解、鸿蒙适配的关键节点、并发与流式渲染的边界控制以及实操中踩过的坑都整理出来给同样在探索“Flutter 鸿蒙 生成式AI”这条路的开发者做个参考。1. 项目到底在做什么一个“极简栈”跨端对话助手的诞生1.1 拆解标题里的每个关键词先把标题拆开看其实核心就三件事跨端框架选型、云端推理服务接入、鸿蒙系统适配。Flutter跨端UI框架一套代码同时覆盖Android、iOS以及鸿蒙。这里的核心诉求不是“跨端”本身而是希望后续多端迭代时不必维护多套原生代码。groq提供高吞吐、低延迟的推理API服务。它的底层硬件是LPULanguage Processing Unit在大模型推理场景下首token延迟和生成速度都明显优于传统GPU集群方案这也是为什么它适合做实时对话类产品。鸿蒙HarmonyOS/ohos目标平台是鸿蒙生态工程通过OpenHarmony SDK与Flutter侧对接产物可以直接在鸿蒙真机或模拟器上运行。端云混合调用不是所有逻辑都丢给云端。端上做意图识别、输入校验、轻量上下文管理云端负责任重活——大模型推理。既降低对网络的强依赖也让每一个请求花的钱更有价值。极简栈控制依赖数量不用重型状态管理框架、不用大型网络库直接用dart:io或轻量http库、不用繁琐的本地数据库。所有能在100行内自己写的逻辑都不引第三方包。这几样东西拼在一起最后落地的是一个“智慧级跨端对话助手”。所谓智慧级在工程上主要体现在三个方面能流式输出、能动态拼接上下文、能跨端保持一致的对话体验。1.2 为什么选择“Flutter groq 鸿蒙”这个组合先讲讲Flutter。鸿蒙在2024年之后对Flutter的支持力度明显增强OpenHarmony SDK发布了对应的flutter_flutter与ohos适配层让原本只面向Android/iOS的Flutter工程可以低成本迁移到鸿蒙。这个项目从一开始就以鸿蒙为首要适配目标所以Flutter是当下成本最低的路。再看groq。选择它有几个非常实际的原因首token延迟极低。groq的LPU推理服务在开源对话模型上能做到几十毫秒级首token响应这让端上表现为“消息发出去几乎立刻看到文字滚动”体验非常接近本地模型。API兼容性强。它提供OpenAI兼容的ChatCompletion接口客户端代码几乎不需要写二次封装直接用标准参数就能跑。并发边界清晰。groq有明确的rate limit策略适合做客户端侧的并发控制测试——这正好是项目里“并发边界毫秒级渲染”要解决的工程问题。端云混合则是从产品层面倒推出来的技术选择。纯云端方案在弱网下几乎不可用纯端侧方案又受限于设备算力和模型体积。最后的设计是输入预处理、历史消息压缩、UI流式渲染都在端上真正的文本生成走云端推理。端上把“不需要大模型也能完成的事情”全部做掉云端只处理核心生成任务。1.3 项目的核心交付物与适用场景整个项目最终交付的东西包括一个Flutter工程已适配鸿蒙ohos平台可直接编译为HAP包安装运行一个基于groq API的流式对话服务封装支持SSE流式解析、超时重试、并发边界控制一个极简的端云调度模块负责判断哪些操作留本地、哪些请求发云端一套针对流式文本的渲染优化策略实现了毫秒级的增量UI更新。适合参考这个方案的人主要有三类正在把Flutter应用往鸿蒙迁移的开发者想在移动端快速接生成式AI能力的产品工程师以及做端云混合AI应用架构选型的技术负责人。注意一点groq提供的API是标准云端服务并不涉及本地模型部署端上也不做任何模型推理。整个项目的“重计算下沉”指的是把生成式AI的推理放到云端而不是让端侧设备承担大模型计算。2. 端云混合调用的整体架构重计算下沉的设计思路2.1 哪些计算该下沉云端谈端云混合之前先明确一个边界问题到底什么样的计算适合下沉到云端什么样的计算留在端上更划算。这个项目里云端负责任务只有一个根据输入的对话上下文生成下一段自然语言文本。这个过程需要大模型推理能力端侧设备根本扛不住或者即便能靠简化模型跑起来质量也会大打折扣。所以这类算力需求一定要下沉。但对话助手不能只有一个生成模型。它还要做这些事判断用户输入是否合理、决定要不要触发生成、把历史记录压缩成简洁的上下文、把云端返回的增量文本渲染到UI上。这些事情如果都丢给云端每次对话都要捎带大量重复数据网络开销巨大而且响应延迟会被无线放大。所以架构上就有了清晰的拆分处理环节执行端原因输入预处理去空格、纠错、长度校验端侧毫秒级完成无需模型能力意图判断是否闲聊、是否生成类请求端侧规则引擎足够避免无效API调用历史消息压缩与摘要端侧轻量算法处理减少云端输入token消耗上下文组装端侧根据业务规则动态拼接云端无感知文本生成云端groq LPU推理需要大模型能力必须下沉增量文本解析与UI渲染端侧流式数据按帧渲染保障交互流畅端云混合的“混合”本质上是把任务的依赖关系理顺凡是能被规则、算法、缓存解决的全部就地处理只有真正需要大模型涌现能力的部分才消耗token调用云端API。这个设计直接决定了整个系统的成本和响应速度。2.2 端侧调度模块什么场景走云、什么场景走端调度模块的职责是“判断一个请求需不需要走云端”。我用一个极简的决策链实现全部逻辑放在一个Dart类里大概100行代码搞定。判断链路是这样的输入是否为空或纯符号直接返回本地提示不走云输入与前一次会话是否完全重复如果重复且上一次已经生成过结果直接返回本地缓存输入是否符合预设的本地规则比如计算器、汇率转换、单位换算走本地规则引擎不走云输入长度超过阈值先做本地截断或摘要再走云以上都未命中进入云端调用。这套规则看起来简单但它避免了一个很常见的问题——把一切输入都丢给大模型既浪费token又让产品行为不可预测。在实际使用中大概有30%左右的请求被本地规则直接拦截API调用量明显降低。调度模块还负责一个关键任务网络状态感知。在弱网或断网环境下直接禁用云调用UI切换成本地模式只提供基于规则的交互。这样可以避免用户在信号不好的场景下等一个永远不来的超时。2.3 极简栈是怎么“极简”的所谓极简并不是“代码写得少”而是“依赖选得少、引入的复杂度可控”。这个项目里第三方依赖只有两个一个是Flutter官方扩展包提供异步流式处理能力另一个是通用的HTTP客户端库实际上我用的是系统自带的HttpClient能力彻底去掉了第三方网络库。状态管理直接使用Flutter内置的ValueNotifier与ChangeNotifier没有引入重量级框架。这样做的直接收益是工程可维护性大幅提升。依赖少意味着升级冲突少、编译时间短、鸿蒙适配时没有大量原生插件需要重新编译。尤其是鸿蒙目前对第三方插件生态还处于兼容阶段减少非必要依赖是降低适配风险最有效的手段。“极简栈”在代码层面还有一个体现没有本地数据库。对话历史的持久化直接用文件系统写JSON。对于一个轻量对话工具来说几百KB的数据量完全不需要引入数据库引擎文件读写就够了。这一刀切下去少了两三个依赖包和一堆初始化的烦恼。3. LPU推理响应机制与并发边界控制3.1 LPU推理模式的特性为什么响应可以毫秒级groq的底层硬件是LPU它的设计目标和GPU不同。GPU追求通用计算什么都能跑但大模型推理特别是自回归生成时每一步生成的瓶颈都在“内存带宽”而不是“算力峰值”。LPU把内存和计算单元的距离设计得更近减少了数据搬运的瓶颈让token生成速度非常可观。对于客户端开发来说LPU带来的最直观体验是请求发出去首包数据返回的间隔非常短。传统云端模型可能要在1到3秒后才开始吐字groq常常在几百毫秒内就返回第一批增量文本。这个差异直接决定了UI流式渲染能不能做出“打字机”效果。实际项目中我测试过groq上不同模型的首token延迟基本都能稳定在155ms到400ms之间生成吞吐量远超普通的移动端交互需求。这就带来一个有意思的转折既然生成速度远快于用户阅读速度那么系统的瓶颈反而不在模型端而在端上的流式渲染速度和并发任务调度能力。3.2 并发边界系统能同时处理多少对话流项目标题里的“并发边界”这个词在客户端语境下有一个更实际的含义当用户快速连发消息时系统应该如何处理是排队是取消前一个任务还是并发生成多个结果在生成式AI类应用中并发边界主要体现在三个层面groq API的rate limit每个token窗口内的请求次数和生成token数都有限制。端上渲染能力多个流式输出同时更新UI会造成频繁的setState影响帧率。用户认知负荷同时显示多个回复会让交互变得混乱绝大多数对话助手产品只需要“单流聚合”。我最终采用的策略是“并发请求、串行呈现”。具体来说用户的多个快速请求会并行发出充分利用groq的并发处理能力但UI层维护一个消息队列同一时刻只渲染一条消息流新的消息生成任务完成后排队等待前面消息渲染结束再插入对话列表超时或错误的任务单独标记不影响其他任务继续执行。这个策略看似简单但它解决了一个很核心的体验问题生成结果的速度很可能比UI渲染更快如果每条流都同时更新界面界面会跳动得非常厉害用户根本来不及阅读。串行呈现则保证了“每一条消息都有稳定的展示时长”与用户阅读节奏保持一致。代码实现上我用了一个统一的StreamController作为消息总线所有云端返回的增量文本都走同一个管道UI侧监听这个管道后做渲染调度。这样并发和串行之间的切换就很优雅底层并发获取数据上层管道按序消费。3.3 渲染链路中的“毫秒级”调优从流式文本到动态模型文本链条流式文本渲染最核心的痛点是如何让大模型的增量输出以最小的UI开销呈现出来。最初版本里我简单地把每个增量文本片段追加到全量字符串上然后setState重新渲染整个对话气泡。这在文本短时没问题文本一长就会发现明显的键盘卡顿和滚动跳动。原因是Flutter在每次setState后都会对整棵widget子树做diff文本越多diff成本越高。调优的方向是把“全量刷新”改成“增量刷新”。具体做法是UI层维护一个固定尺寸的文本显示区域只刷新增量区域的RichText每个对话消息拆成独立的StatefulWidget内部维护自己的文本状态新token到来时只更新当前消息组件内部的TextPainter数据不触发父级组件重建使用RepaintBoundary隔离消息组件让滚动区域内的其他组件不参与本次重绘。这套优化做下来在鸿蒙模拟器和真机上流式输出的增量帧率稳定在60fps以上即使连续生成几百个token也不会出现明显的UI掉帧。所谓“毫秒级渲染”这里指的不是渲染耗时恰好是几毫秒而是每一次增量更新都被控制在一帧渲染时间16ms左右以内。另一个加分项是“动态模型文本链条”。简单说就是让对话上下文不再是一个固定长度的字符串而是一个可以动态追加、裁剪、重新排序的链条结构。每次云端请求前端侧会从链条中抽取最近N轮对话拼接成标准提示词格式。整个链条的组装是纯计算逻辑不涉及模型调用所以可以在毫秒级完成。4. 鸿蒙HarmonyOS适配实战环境搭建、工程改造与关键配置4.1 从Flutter空工程到鸿蒙可运行工程鸿蒙适配的第一步是准备环境。目前主流的做法是通过OpenHarmony的Flutter支持仓库拉取适配好的Flutter SDK分支然后用这个SDK来构建鸿蒙应用。具体步骤安装DevEco Studio配置OpenHarmony SDK拉取适配鸿蒙的Flutter SDK分支切换到对应版本配置flutter config启用ohos平台支持在Flutter工程下执行flutter create --platforms ohos生成鸿蒙平台目录用DevEco Studio打开生成的ohos目录编译验证。这里最容易踩的坑是版本对齐。Flutter SDK分支、OpenHarmony SDK版本、以及groq API需要使用的Dart版本必须匹配否则编译时会冒出各种诡异的兼容性错误。建议每一步都先构建官方示例工程验证环境再动主工程代码。另外需要注意鸿蒙的工程目录结构与Android有差异。Flutter代码本身不用改动但ohos目录下的Module配置、权限声明、签名配置都必须走DevEco Studio的工程体系不能用Android的配置逻辑直接套用。4.2 鸿蒙侧的网络权限与明文通信配置鸿蒙应用默认的网络权限是受限的。如果直接发HTTP请求很可能会在运行时被拦截。所以在适配过程中需要明确在module.json5中声明网络权限。以我的项目为例配置了{ module: { requestPermissions: [ { name: ohos.permission.INTERNET }, { name: ohos.permission.GET_NETWORK_INFO } ] } }如果API地址是http非https还要在网络安全配置中放行对应域名。这里有个细节groq API默认是https所以只要权限声明正确通常不会遇到明文流量拦截问题。但如果本地调试时需要访问局域网服务就得额外配置网络策略。网络权限没声明时最常见的表现是请求抛出的异常提示“Connection failed”或“SocketException”容易让人误以为是代码问题。排查时优先检查module.json5里的权限声明再查代码。4.3 Flutter侧代码的鸿蒙兼容处理大多数Flutter插件在鸿蒙上都有对应实现但如果插件生态不完整就可能会出现MethodChannel调用失败。为了避免这个问题项目里所有需要原生能力的部分全部用Flutter标准能力实现不走自定义插件。具体来说网络请求使用dart:io自带的HttpClient不依赖第三方网络库本地存储用path_provider获取目录后直接用File读写不引入数据库插件异步调度用Dart的Isolate做耗时任务不依赖原生线程插件。这种做法的好处非常明显当平台从Android切换到鸿蒙时Flutter层代码完全不用改动只有工程配置需要调整。如果你在任何Flutter项目里遇到了鸿蒙适配困难优先检查一下是不是引入了不兼容的第三方原生插件。去掉这些插件移植复杂度会立刻下降一个数量级。项目里的groq服务调用、流式解析、UI渲染全部是纯Dart实现所以在鸿蒙上运行和Android上运行没有行为差异。验证下来真机上首帧渲染速度、流式更新帧率都符合预期。5. 流式文本处理坑点SSE解析、UTF-8边界与增量渲染的准确性5.1 SSE流式数据解析的边界问题groq的流式接口遵循SSEServer-Sent Events协议。服务端会把增量返回的文本包在data:字段里以空行分隔。客户端需要逐行解析以data:前缀开头的内容才是有效数据。但在实际解析中有一个棘手问题TCP流不保证一个数据包正好是一行SSE消息。数据可能被截断也可能多个数据块粘在一起。如果按行读取后直接解析会出现JSON解析失败或消息丢失。我的处理方式是使用一个“行缓冲器”。具体逻辑final buffer StringBuffer(); final completer CompleterString(); // 收到字节流时按UTF-8解码追加到buffer // 然后按换行符切分逐行处理解析过程中还要处理多个data:字段粘包的情况需要用双重拆分先按空行拆消息块再按data:前缀提取内容。这套解析逻辑是整个流式渲染正确性的基础在这里出错后面所有优化都白搭。5.2 UTF-8截断问题中英文混合消息的隐形杀手这是一个在流式场景中特别隐蔽的坑。HTTP流式响应的数据块可能是任意字节长度如果某个数据块的末尾正好落在一个中文字符的UTF-8编码中间那么解码时会得到乱码字符或者解码异常。比如一个汉字占3个字节某次网络包头尾只收到这个字的2个字节如果直接对这段字节做UTF-8解码就会出现这样的替代符。解决思路不难但很关键维护一个“残余字节”缓冲区每次收到网络数据后先检查末尾是否有不完整的UTF-8序列如果有则把不完整部分保留到下一次数据到达时再拼接解码。具体判断方式if (bytes.isNotEmpty) { // 检查最后一个字节是否属于完整UTF-8序列 // 如果是多字节字符首字节或后续字节不完整则缓存尾部 }这个问题的可怕之处在于它只在特定网络环境下随机出现纯靠肉眼测试很难复现。如果对话内容偶尔出现乱码优先排查这里而不是去怀疑模型输出问题。5.3 增量文本拼接的准确性流式场景下文本到了之后要无缝追加到已有内容中。这就要求端侧必须保证增量文本的序号正确、重复追加时不产生重复内容、追加顺序与服务端生成顺序一致。项目里用了简单的递增序号来处理每个SSE消息块解析后带上递增的indexUI渲染层根据index判断是否插入正确位置。当网络抖动导致消息乱序时渲染层会先缓存乱序块等待序号补全后再插入。这种处理方式在对话流式输出里已经足够。但如果你的应用场景是实时会议纪要、字幕等对顺序极度敏感的文本可能需要引入更复杂的序列对齐算法不过对于对话助手递增序号方案又轻又稳定。6. 毫秒级渲染的工程细节当文本刷新速度超过帧率时怎么办6.1 渲染瓶颈出现在哪里很多人会以为流式文本渲染卡顿是设备性能问题但实测下来哪怕是中端机型一帧里也只是绘制一小段新增文字根本不会造成绘制压力。真正的瓶颈在于Flutter的widget重建和布局计算。假设每帧到达一个新token如果直接调用setState更新消息组件那么每次都会触发父级列表重新布局因为消息文本高度可能变化进而触发列表项重新排列。消息越多重排成本越高。当消息变长到上百个字时每次token到达都会带来一次完整的布局周期这样累积下来UI响应速度自然会下降。所以核心优化方向不是“少画字”而是“减少布局触发的范围”。6.2 把重绘范围控制到最小我在项目中做了三个层面的隔离第一层列表层。整个对话列表使用ListView.builder并且为每个消息组件包上RepaintBoundary。这样某条消息内部的文本变化不会扩散到整个列表的重绘区域。第二层消息组件层。每条消息内部文本区域使用独立的EditableText或者Text.rich并把自己的状态保存在State中只有当前消息收到新token时才更新当前State触发局部build。第三层渲染层。在build方法中增量文本的RichText直接构造新的TextSpan树避免使用Markdown解析或HTML渲染这类重型处理。因为生成式AI的输出格式基本可控对话场景下文本加粗、换行、代码块的需求用TextSpan的样式组合就能覆盖不需要引入markdown包。这套方案最终的效果是每个token到达时Flutter实际需要处理的工作只有“当前消息内部的文本树更新”其他所有组件完全不动。在鸿蒙真机上连续生成500个token的场景下fps稳定保持在55帧以上也没有出现滚动手感变差的情况。6.3 消息滚动策略自动滚动与用户阅读权重的平衡流式输出时有一个体验难题到底要不要自动滚到底部如果每次都强制滚动到底部用户在回看历史消息时会被强行拉走体验极其糟糕。如果不滚生成的内容很快超出当前视口用户还要手动滑动才能看到新内容。最终的策略是“智能跟随滚动”如果用户当前正处于列表底部则新token到达时继续滚动到底部如果用户已经向上回看历史消息则取消自动滚动只在列表底部显示一个“新消息”浮标用户点击浮标后才回到最底部。这个交互模式在很多聊天软件里都有但在生成式AI流式输出场景里实现细节略有不同生成过程是持续的可能每200ms就有一个新token不能每300ms就滚一次。所以项目中做了滚动节流滚动的触发间隔不低于500ms避免滚动动画与高频token更新互相争抢主线程。7. 常见问题与排查技巧实录从崩溃到卡顿逐个击破7.1 API请求偶发失败超时重试的正确姿势groq API在实际使用中偶尔会返回429请求过多或503服务不可用。处理方式需要区分场景429说明并发超限正确做法是退避重试503说明服务暂时不可用可以马上重试但重试次数要有限制。项目中实现了一个简单但有效的重试策略初次请求失败延迟300ms重试一次再次失败延迟800ms重试第三次失败直接放弃抛给UI层一个带错误码的提示。关键点是要记录“重试期间已接收到的部分token”。如果流式会话在输出中途断掉重试时不能直接把整个会话作废而应该携带已有内容让模型继续生成或者至少把已生成内容展示给用户避免内容突然消失。7.2 鸿蒙真机上出现网络错误但代码看起来没问题典型表现是模拟器能跑通一到鸿蒙真机就报SocketException。这类问题大多是权限声明缺失导致的。开发阶段最容易遗漏的是INTERNET权限因为Android工程里会默认配置但鸿蒙的module.json5默认不带网络权限必须手动添加。排查路径是检查module.json5中是否声明INTERNET权限确认API地址是https还是httphttp需要额外配置网络安全策略确认系统代理设置鸿蒙的WiFi代理默认情况下不影响应用内突发流量但如果配了代理且代理失效也会导致连接失败。换到真机之前先用鸿蒙模拟器做一次全链路请求验证能排除掉大部分环境干扰。7.3 千行长文本渲染掉帧流式内容生成到一定长度后即使做了消息级隔离仍可能出现掉帧。原因通常是Text组件内部对超长文本的布局耗时显著增加。解决方案是把长文本按自然段落拆成多个Text组件放到一个Column里。这样每次增量更新时只有最后一个Text组件需要重新布局前面的Text组件完全复用。实测下来单条消息达到2000个汉字时增量更新的帧耗时依然控制在10ms左右不会掉帧。这个方案的局限是段落间不能有复杂的Markdown内联样式但对话场景下这个限制完全可以接受。8. 打磨智慧级对话体验动态模型文本链条与上下文管理8.1 上下文链条的数据结构设计对话助手的智能感很大程度上来自上下文管理。粗糙的做法是把全部历史消息直接传给模型模型根据全部token生成回复。这种做法有两个问题长对话token消耗巨大成本不可控距离当前时间久远的信息会分散模型注意力反而降低回复质量。项目里采用的“动态模型文本链条”是一个链式结构每一环代表一轮完整的对话回合用户输入助手回复。链条有长度上限默认保留最近20轮超出部分自动截断。但简单截断也有问题某些早期信息虽然文本上“旧”但对当前问题非常重要。所以链条设计里增加了一个“关键信息锚点”机制当用户消息中命中关键词如“我的手机型号是xxx”时该信息会被提取出来单独存放在链条头部不随轮次滚动淘汰。这样即使中间夹了很多无关内容关键上下文依然能传递到每次的模型提示词中。8.2 上下文环境变量如何传参才能既少token又保住信息传参逻辑上每次请求前端侧会生成一个提示词模板包含三个部分系统提示词固定内容用于限定助手人设与响应风格关键信息锚点动态内容包含长期不变的用户信息最近N轮对话摘要按时间顺序排列。对话摘要不是直接拷贝原文而是经过本地压缩每轮助手回复只保留核心结论过长的代码块或表格内容用占位符简化。比如一个回答如果包含完整代码摘要里只写“[代码块]”模型看到占位符后结合用户最新提问决定是否需要展开代码细节。这套机制的最终效果是对话轮数增加到100轮时单次请求的token数没有成比例增长反而稳定在固定值附近。生成的上下文质量也远高于直接截断全部历史的做法。8.3 跨端一致性为什么同样代码在鸿蒙和Android上体验一致项目增补了鸿蒙支持后有一个很实际的验证结论纯Dart逻辑的跨端一致性远超预期。groq API的请求、SSE流式解析、上下文链条组装、本地文件存储这些核心逻辑在鸿蒙和Android上跑出的结果完全一致。差异只出现在系统级能力上比如文件目录路径不同、界面安全区域高度不同、系统返回手势的事件拦截方式不同。这些差异通过Flutter的PlatformChannel做了轻量适配没有影响业务逻辑。如果你在做类似的项目建议把所有业务逻辑全部收敛到纯Dart层不要依赖任何平台专属能力。这不仅是为了鸿蒙适配也能让项目在未来的新平台比如PC、Web上一键复用。9. 性能调优与极限场景验证并发、弱网与超长对话9.1 并发压力测试60s窗口内的请求边界为了验证“并发边界”设计是否正确我在鸿蒙真机上做了一组测试模拟用户每2秒发出一条消息持续60秒观察系统行为。测试结果有几个有意思的点groq的API在单会话场景下表现稳定所有请求均成功端上同时发起8个流式请求时StreamController管道能正常承载没有数据丢失界面串行呈现策略起作用后即使底层并发很高用户感知到的始终是“一条一条地出”没有混乱感超出API限流阈值后请求返回429端上自动进入退避重试用户无感知。极限场景下最危险的是内存占用。每个流式响应都会在内存中积累完整的生成结果如果大量并发任务同时进行内存增长很快。后续优化可以增加磁盘临时缓存把已完成的消息落盘释放内存压力。9.2 弱网场景掉线、半包与重连弱网测试中遇到最多的问题是流式中断。一半消息没生成完Socket就断掉了。处理方式分两层网络层检测到Socket异常后尝试重连重连成功后用“续聊”模式继续请求让模型基于已有已生成内容继续补全。UI层中断点的消息立刻显示“已中断”标记并提供“重新生成”按钮。用户点击后端上组装“已生成部分原输入”作为新请求发送模型会从断点附近继续而不是从头开始。这个方案被验证比直接重新生成整条回复的等待时间更短用户体验也更贴近“自然对话被打断后接着聊”的直觉。9.3 超长对话的降级策略对话长度超过100轮后即使有摘要机制生成质量也会下降。这是模型本身的上下文窗口限制决定的。项目里加入了降级策略当对话超过50轮时提示用户“继续对话可能影响回复质量”超过80轮时自动结束当前对话会话创建一个新会话并把旧的会话摘要带过去提供一键归档把完整历史导出为本地文件用户可以随时重新导入。这个策略不是为了省token而是为了保住“助手在认真听你说话”的体验。相比让模型在一个膨胀的上下文里胡言乱语结束并开启新会话反而更能维护用户对产品的信任。10. 写在最后这套方案的延展空间这个项目做完我个人最大的体会有两点。一是“极简栈”在适配新平台时真的香。鸿蒙适配过程中我几乎没有因为第三方依赖去额外踩坑所有精力都集中在业务逻辑和平台差异上。如果你的项目未来也要考虑多平台发布控制依赖数量是一个值得从第一天就坚持的原则。二是端云混合的边界划分决定了产品的成本结构和体验天花板。不是所有功能都要走大模型API也不是所有计算都该留在本地。把能规则化的逻辑下沉到端上把真正需要智能的部分交给云端这套思路不止适用于对话助手也适用于翻译、图片生成、内容摘要等各类生成式AI应用。后续如果要继续迭代几个方向是我特别想做的接入多模态输入输出、增加本地小模型作为断网兜底、把上下文链条的摘要算法升级为端侧embedding检索。这套基于“Flutter groq 鸿蒙”的底座已经足够稳定上面的每一层能力都还有广阔的发挥空间。一个再接地气一点的小技巧如果你也在鸿蒙上调试类似的AI应用每次改完代码后别急着编译HAP包先用DevEco Studio的Previewer把Flutter页面单独预览同时用模拟器验证API请求链路。两个工具配合能比直接上真机节省至少一倍调试时间。真机只留到最终验证阶段这样效率会高很多。
阅读完成 · 觉得有帮助？
