Vue+UniApp全端AI问答助手实践：Markdown渲染与流式输出

最近在把AI问答助手从纯Web端迁移到全端（H5 + 微信小程序 + App）的时候，我把Vue、UniApp、Markdown渲染、公式展示、多模态交互这些东西挨个重新撸了一遍。越到后面越觉得，"AI + 跨端"这个组合的难点根本不在AI模型本身，而在工程侧的细节治理：流式输出在三个端上的行为完全不一样，Markdown渲染各自有坑，键盘弹起时消息列表的表现也让人头大。这篇就把我完完整整做下来的过程，包括选型、架构、渲染方案、多模态交互、打包上架和踩过的坑，全部写出来。如果你正准备用Vue + UniApp做一款支持Markdown和公式的AI问答助手，或者已经在做但卡在某一步，这篇文章应该能给你省不少时间。

1. 为什么用Vue + UniApp做全端AI助手：选型背后的真实算账

1.1 一套代码三端覆盖：成本核算与取舍

选UniApp之前，我其实认真评估过Flutter、React Native和纯原生三套方案。我们团队背景是Vue，手上已经有成熟的Web端AI对话产品，目标很明确：要小程序和App，且必须尽量复用Web端的业务逻辑与UI思维。这个时候UniApp的优势就很直接了——Vue语法天然熟悉，组件模型和响应式机制跟Web端几乎一致，团队成员基本不需要学习成本就能上手。Flutter的Dart语法和自绘引擎很强，但对我们这种"AI对话功能为主、原生能力辅助"的工具型应用来说，属于过度投入。

另外一个很实际的原因是微信小程序生态。国内做AI助手绕不开微信小程序这个分发渠道，UniApp对微信小程序的适配做得比较深，包括分包、分享、隐私弹窗等机制都有对应的API封装。对比下来，我在选型文档里写得很直白：Flutter适合重交互重绘制的应用，但AI对话本身就是列表 + 输入框 + 流式文本，UniApp完全顶得住；React Native在JS桥接成本上又比UniApp多一层工具链维护。最终我们选择Vue 3 + UniApp + Vite这套组合，核心考量有三点：开发速度、团队迁移成本、微信生态覆盖度。

从后来实际开发看，这个决策是对的。三端共享了大概90%的代码，只有录音、流式请求、隐私合规这些部分做了条件编译拆分。如果你也面临类似选型，我建议你把"团队的既有技术栈"放在第一位，而不是单纯比框架性能。工具链本身的差距，远没有团队学习成本带来的差距明显。

1.2 整体的数据流设计

整个AI问答助手的数据流，我拆成了四层：UI层（对话页面）、状态层（Pinia）、请求层（普通请求 + SSE流式请求）、业务层（会话管理、内容解析）。UI层只负责渲染消息数组，状态层保存当前会话的消息列表和loading状态，请求层负责与后端AI网关交互，业务层负责Markdown解析、多模态消息组装、会话持久化。

单个消息的结构我设计成了统一的对象：

interface ChatMessage { id: string role: 'user' | 'assistant' | 'system' type: 'text' | 'image' | 'audio' | 'multi' content: string images?: string[] // 多模态图片URL reasoning?: string // 思维链内容，可选择渲染 createdAt: number status: 'streaming' | 'done' | 'error' }

这样设计的用意很明确：AI回答的内容在流式返回时，content字段是不断追加的Markdown字符串；多模态场景下，用户发送的消息里可以同时携带文本和图片，type标记为multi，images字段保存压缩后的图片地址。所有消息对象都放在Pinia的currentSession里，每追加一次内容就触发一次响应式更新，配合自定义滚动逻辑，就能实现打字机效果。

这里有一个特别容易被忽略的点：AI回答的Markdown内容是逐渐完整的。流式输出过程中，代码块可能只出来了半个，表格可能只渲染了表头。所以在UI层，我要么等每个chunk推完再整体解析渲染，要么对半截Markdown做容错处理。我后面会在流式输出章节专门讲这个问题的处理思路，这里先记住一个结论：不要在流式过程中反复调用完整Markdown解析，性能会很难看。

2. 工程初始化与多端请求层封装：跨端问题的源头治理

2.1 脚手架搭建（Vue 3 + Vite）与目录约定

UniApp项目有两种创建方式：HBuilderX图形化创建，或者命令行CLI创建。我建议有一定工程习惯的团队直接用CLI，因为可以纳入Git管理、配合CI/CD，依赖也更好控制。用下面的命令初始化：

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

初始化后，目录我会做一层约定，避免后续多端逻辑乱掉：

src/ api/ // 接口请求层，纯业务无关的HTTP封装 components/ // 通用组件 pages/ // 页面 store/ // Pinia状态 utils/ // 工具函数 static/ // 静态资源

其中utils里我会专门放一个platform.ts，统一导出当前端类型的判断，配合UniApp的条件编译注释使用。条件编译是UniApp最核心的能力之一，它允许你在同一份代码里写不同端的逻辑，编译器会自动剔除不属于当前端的部分：

// #ifdef MP-WEIXIN import { wechatStreamRequest } from './request-wechat' // #endif // #ifdef H5 import { h5StreamRequest } from './request-h5' // #endif // #ifdef APP-PLUS import { appStreamRequest } from './request-app' // #endif

这套机制帮我避免了很多"这个API微信小程序有、H5没有"的兼容问题。关于路由参数获取，UniApp的页面在onLoad生命周期里能拿到options对象，比如?sessionId=123就能在进入对话页时恢复历史会话。但有个小坑：H5端刷新页面后onLoad还会再触发一次，如果此时在回调里写了重新拉列表的逻辑，会导致会话被重复初始化，我做了个safeLoad标记来避免。

2.2 请求层封装：普通请求与SSE流式请求的并存方案

AI问答助手的大部分请求还是普通POST，但最核心的对话接口必须是流式的，否则用户会盯着空白页面等好几秒。我先封装了一个最基础的普通请求函数：

// src/api/request.ts const BASE_URL = import.meta.env.VITE_API_BASE_URL export function request<T>(options: { url: string method?: 'GET' | 'POST' data?: Record<string, unknown> header?: Record<string, string> }): Promise<T> { return new Promise((resolve, reject) => { uni.request({ url: BASE_URL + options.url, method: options.method || 'POST', data: options.data, header: { 'Content-Type': 'application/json', Authorization: getToken(), ...options.header }, success: (res) => { if (res.statusCode >= 200 && res.statusCode < 300) { resolve(res.data as T) } else { reject(new Error(`HTTP ${res.statusCode}`)) } }, fail: (err) => reject(err) }) }) }

流式请求的封装则麻烦得多。三端对SSE的支持差异很大：H5好办，直接fetch配合ReadableStream就能读；微信小程序需要wx.request开启enableChunked；App端则需要用plus.net的原生能力。我为了让上层代码统一，回调固定暴露onChunk和onDone：

// src/api/stream.ts export interface StreamOptions { url: string data: Record<string, unknown> onChunk: (text: string) => void onDone: (fullText: string) => void onError: (err: Error) => void } export function streamRequest(options: StreamOptions) { // #ifdef H5 h5Stream(options) // #endif // #ifdef MP-WEIXIN wechatStream(options) // #endif // #ifdef APP-PLUS appStream(options) // #endif }

微信小程序的enableChunked有个反直觉的点：success回调在流结束时才触发，流数据是通过onChunkReceived每次返回一段ArrayBuffer。你需要自己维护一个TextDecoder来拼接字符串，并按SSE协议（以\n\n分隔事件，data:开头的行才是有效payload）解析：

function wechatStream(options: StreamOptions) { const decoder = new TextDecoder('utf-8') let buffer = '' // 这里是简化写法，实际会放到 requestTask 上 const task = wx.request({ url: BASE_URL + options.url, method: 'POST', data: options.data, enableChunked: true, header: { 'Content-Type': 'application/json' }, success: () => { options.onDone(buffer) }, fail: (err) => options.onError(new Error(err.errMsg)) }) task.onChunkReceived((res) => { const text = decoder.decode(res.data, { stream: true }) buffer += text // 逐行解析 SSE 事件 const lines = buffer.split('\n\n') buffer = lines.pop() || '' lines.forEach((block) => { const dataLine = block .split('\n') .find((line) => line.startsWith('data:')) if (dataLine) { const payload = dataLine.slice(5).trim() if (payload === '[DONE]') return options.onChunk(payload) } }) }) }

2.3 环境变量与多端条件编译

开发过程中一定要从一开始就规划好环境变量，我建了.env.development、.env.test、.env.production三个文件，分别配置后端地址、OCR服务地址、文件上传地址。注意UniApp + Vite的环境变量必须以VITE_开头才能在代码里通过import.meta.env读到。小程序端没有process.env的概念，所以条件编译和公共配置要绕开Node API。

这里有一个实际教训：微信小程序的request合法域名是HTTPS且ICP备案的，但本地开发时你可以勾选开发者工具里的"不校验合法域名"，真机和预览时就必须配置线上域名。我把这个配置写到了条件编译里，开发环境自动走本地代理，生产环境走正式域名，避免上线前一晚到处挖域名。

3. Markdown与数学公式渲染：AI回答的"门面工程"

3.1 为什么AI回答必须在端上渲染Markdown

如果你用过任何一个成熟的AI问答产品，就会发现回答几乎都是排版好的：代码有高亮、列表有缩进、表格有边框、数学公式是真正排版出来的，而不是一行裸文本。原因很简单，大模型输出的是结构化文本，天然包含Markdown标记，如果不解析渲染，用户看到的就是一堆#、**、```符号，体验会非常糟糕。尤其当回答里包含代码块和公式时候，纯文本完全没法看。

所以在AI问答助手的工程里，Markdown渲染不是"锦上添花"，而是"基本盘"。我统计过我们线上的对话内容，超过70%的AI回答包含至少一个代码块或公式片段。这就意味着渲染层必须稳定支持：标题、列表、引用、表格、行内代码、代码块、图片、数学公式，并且在不同端的表现要尽量一致。

3.2 小程序端用towxml渲染Markdown的完整接入

H5端渲染Markdown很简单，markdown-it或marked解析HTML之后v-html就行。但微信小程序没有DOM，没法直接操作HTML字符串，这时候一个成熟的第三方库towxml就派上用场了。towxml底层也是把Markdown解析成JSON树或HTML字符串，然后通过自带的组件递归渲染到小程序上，支持代码高亮、表格、公式、流程图，甚至echarts图表。

我在项目中接入towxml的方式如下：

1. 把towxml完整目录放到src/components/towxml下。
2. 在pages.json里注册组件，或直接在页面模板里引用。
3. 拿到AI返回的Markdown字符串后，调用towxml(markdown, 'markdown')生成渲染数据。
4. 将渲染好的HTML字符串传给<towxml nodes="..."></towxml>组件。

<template> <towxml :nodes="htmlContent" :theme="isDark ? 'dark' : 'light'" /> </template> <script setup lang="ts"> import Towxml from '@/components/towxml/towxml.vue' import { computed } from 'vue' const props = defineProps<{ markdown: string }>() // 这里用towxml自带方法解析 const htmlContent = computed(() => { if (!props.markdown) return '' // 补充：把markdown解析为towxml需要的数据结构 return parseMarkdown(props.markdown) }) </script>

这里有个必须强调的点：towxml的解析方法在微信小程序端运行时有环境依赖，不能在App的Service层直接调用，一般放在页面内执行；另外它默认的样式表在深色模式下容易看起来突兀，需要覆盖主题变量做适配。我后来没有追求用towxml的完整功能，而是只保留了markdown解析和代码高亮，公式部分单独接了自己更可控的KaTeX方案（下面会讲），换来的是包体积减少了约三分之一。

3.3 公式渲染：KaTeX方案与MathJax取舍

AI问答里经常出现数学公式，比如"请解释一下泰勒公式""求导的链式法则"，这时候回答里通常是LaTeX格式的公式。我对比了KaTeX和MathJax：KaTeX是"快、轻、输出高质量"，MathJax是"全功能、慢、适合复杂公式"。在移动端场景，性能是第一位的，所以我选了KaTeX，并把KaTeX的CSS和JS都打包进H5端，小程序端则用towxml自带的公式解析能力。

具体的处理逻辑是：在后端生成回答时，约定公式使用$...$表示行内公式，$$...$$表示块级公式；前端拿到文本后，在渲染Markdown之前先对公式片段做保护性处理，避免Markdown解析器把公式里的*、_当成强调语法。我在utils里写了一个预处理函数：

// src/utils/formula.ts export function protectFormula(text: string): string { // 先保护块级公式，再保护行内公式 const blocks: string[] = [] const protectedText = text .replace(/\$\$([\s\S]+?)\$\$/g, (match) => { blocks.push(match) return `@@FORMULA_BLOCK_${blocks.length - 1}@@` }) .replace(/\$([^$\n]+?)\$/g, (match) => { blocks.push(match) return `@@FORMULA_INLINE_${blocks.length - 1}@@` }) // 渲染完成后替换回来 return protectedText }

在H5端，块级公式最终会渲染成一个div.katex-display，需要保证行内公式和文字对齐。移动端小屏最容易出的问题是长公式溢出，我加了一行CSS：

.katex-display { overflow-x: auto; overflow-y: hidden; padding: 4px 0; }

这样长公式可以横向滑动，不会撑破卡片。

3.4 代码高亮与表格样式：那些被忽略的深坑

代码高亮是Markdown渲染里最容易得到"看起来不错"但一深究就露馅的部分。towxml自带highlight.js，但默认主题在深色模式下对比度很差。我换成github-dark主题的CSS变量，但highlight.js在微信小程序里不能直接用<link>引CSS，需要把主题样式转成内联或复制进组件的<style>里。这是一个很费时间的体力活，我把它整理成了一个独立样式文件code-theme.scss，方便全局切换。

另一个深坑是表格。AI回答里常常输出Markdown表格，但表格在微信小程序里默认不会自动换行，一旦某一列很长，整个表格会把屏幕撑爆。我加的兜底样式是这样的：

table { display: block; width: 100%; overflow-x: auto; white-space: nowrap; border-collapse: collapse; }

同时给图片加上懒加载和点击预览。图片可以来自AI回答里的远程URL，我用uni.previewImage绑定点击事件，并且给<image>组件设置lazy-load。在App端还要注意图片域的合法域名与缓存策略，不然会出现"真机能看到图，小程序上看不到"的灵异现象。

4. 多模态交互实战：图片理解、语音输入与流式体验

4.1 图片上传与多模态理解：从chooseImage到识别结果

多模态交互是现在AI助手的标配。所谓多模态，直观来说就是用户不仅能打字，还能发图片、发语音，AI也能看图理解、识别语音。我在这个项目里实现的方式是：用户输入区提供"相册/拍照"按钮，选择图片后先压缩，再上传到对象存储，拿到URL后随文本内容一起提交到后端大模型接口。

uni.chooseImage封装得比较直观，但它返回的是本地临时路径，需要再配合uni.uploadFile把文件传到自己的OSS或服务端。我提一下压缩这一步：微信小程序里uni.compressImage可以指定压缩质量，我常用quality: 70，既能减小体积又不会太影响OCR或视觉理解效果。

AI接口的多模态请求体一般是这样的结构：

{ "model": "qwen-vl-max", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "这张图里有什么异常？" }, { "type": "image_url", "image_url": { "url": "https://xxx/1.jpg" } } ] } ] }

如果你不想引入原生多模态模型，也可以走"OCR + 文本理解"的组合：先用OCR接口把图片里的文字识别出来，拼接进提问文本再送给普通大模型。这个方案对"拍题、票据识别"这类场景基本够用，但遇到需要理解图片空间关系的问题就抓瞎了，所以我还是接了真正的多模态模型。

4.2 语音输入：微信小程序与App的双轨实现

语音输入是"沉浸式体验"的一个加分项，但跨端实现完全不同。微信小程序里可以用wx.getRecorderManager()，App端则是uni.getRecorderManager()。我封装了一个startVoiceInput函数，统一暴露录音结束后的音频临时路径，再由上传接口转成文本，最终回填到输入框。

需要注意两点：一是录音权限需要弹窗申请，微信小程序会在调用RecorderManager.start()时自动弹，但App端需要在manifest.json里声明android.permission.RECORD_AUDIO，iOS需要加NSMicrophoneUsageDescription描述；二是长录音的静音检测，如果用户停顿太久，应该自动结束录音，否则用户会困惑"怎么还在录"。我设置的静音判断是2秒无音量变化就自动停止，这个阈值可以根据场景调。

语音识别这块我接的是云厂商的短语音识别接口。录音文件格式在小程序端是mp3或aac，App端可能是amr，提交前要根据接口支持的格式做转换。如果格式不匹配，很常见的报错是"识别失败，音频格式错误"。

4.3 流式输出的两种方案：真实SSE与模拟打字机

流式输出是AI问答助手体验的灵魂。一个95分的AI助手和60分的AI助手，最大区别往往就是"字是蹦出来的还是憋出来的"。我们线上方案分两层：网络层优先走真实SSE流，后端不支持或端上兼容性有问题时，降级为"完整返回 + 打字机模拟"。

真实SSE的技术细节我在2.2节已经讲了请求层的封装。这里重点说业务层如何处理"逐渐完整的Markdown"。我的做法是：每个SSE chunk到达后，不直接整体重新解析Markdown，而是把文本追加到message.content，然后用一个定时器做"渲染节流"——保证最多每150毫秒调用一次markdown渲染。这样既能看到流畅打字效果，又不会让解析线程被频繁调用拖垮。

降级方案是完整JSON返回后，前端用setInterval每隔30毫秒往content里追加2-4个字符，模拟打字机。为了看起来自然，我会优先在标点符号处多切一点，避免"一个字一个字蹦"的机械感。实测下来，用户对这个模拟方案的满意度也不低，毕竟大家关心的是"回答有没有用"，而不是底层走不走SSE。

5. 沉浸式对话体验的细节打磨：滚动、键盘、会话持久化

5.1 软键盘顶起与输入框联动：scroll-view的正确姿势

"沉浸式"很大一部分来自输入和输出的无缝衔接。微信小程序里最容易翻车的就是软键盘：键盘弹起后，输入框被顶上去，但消息列表没有跟着滚动，或者底部最新的消息被键盘遮住。我在page.json里设置"disableScroll": true，同时不依赖页面的原生滚动，而是用一个scroll-view承载消息列表，再配合scroll-into-view实现滚动定位。

关键代码如下：

<scroll-view class="message-list" scroll-y :scroll-into-view="scrollIntoId" :scroll-with-animation="true" @scrolltoupper="loadMoreHistory" > <view v-for="msg in messages" :id="`msg-${msg.id}`" class="message-item" > <!-- 消息内容 --> </view> </scroll-view>

每次新消息或流式内容变化时，把scrollIntoId更新为最后一条消息的id。这里有个性能问题：如果每条流式chunk都触发一次scroll-into-view，列表会频繁抖动。我在代码里用了一个requestAnimationFrame+ 节流：

function scrollToBottom() { if (scrollTicking) return scrollTicking = true requestAnimationFrame(() => { scrollIntoId.value = `msg-${messages.value[messages.value.length - 1]?.id}` scrollTicking = false }) }

5.2 消息存储与会话恢复：本地缓存的幂等设计

AI问答助手不能每次打开都从空白开始，否则用户没法查历史记录。我用uni.setStorageSync把每轮会话按sessionId维度存储。考虑到小程序本地存储有10MB限制，我不会存完整消息列表，而是存精简的{ id, role, content }，并且每条消息限制长度，内容超长会被截断为"点击加载完整内容"。

会话恢复的幂等设计容易被忽略。我遇到过的问题是：用户从会话列表点进详情页，onLoad里拉取本地历史，同时异步从云端拉取最新消息列表，两个请求竞态，导致UI出现同一批消息渲染两遍。解决方法是给每条消息增加tempId，渲染时按tempId去重；另一个方案是本地历史只用于秒开占位，等云端数据返回后整体替换，并加一个loading标识。我最后采用的是"本地秒开 + 云端刷新后替换"，效果最稳。

切换会话时，我会把上一个会话全文保存到本地，避免用户划走一会儿回来数据没了。如果应用在后台被系统杀死，重新打开后也要能通过getStorageSync恢复最近一次的会话ID，直接定位到上一次浏览位置。这个体验对高频用户很重要。

5.3 深色模式与动效优化：从能用变成好用

深色模式不是简单的背景翻转，AI对话页面里消息气泡、代码块、公式卡片、输入区的颜色都要重新设计。我定义了CSS变量：

page, view { --bg-primary: #ffffff; --bg-secondary: #f5f6f7; --text-primary: #1a1a1a; --text-secondary: #8a8f99; --code-bg: #f6f8fa; } .dark { --bg-primary: #111418; --bg-secondary: #1d2128; --text-primary: #e4e6eb; --text-secondary: #9ca3af; --code-bg: #1d2128; }

在App.vue里根据uni.getSystemInfoSync().theme或用户手动选择来添加dark类。这里有个经验：代码块的深色模式最不能省，因为AI回答里代码占比很高，如果代码块在深色模式下变成白底黑字，整个沉浸感瞬间崩塌。我在towxml组件的容器上同步绑定theme属性，让它内部代码高亮主题跟着变。

动效方面我做了三个轻量级动画：消息进入时的淡入上移、loading时三个点的呼吸闪烁、图片卡片点击时的放大预览。这些用CSS transition就够了，不需要引入动画库。一个反直觉的坑是：小程序端transition在scroll-view内部偶尔会失效，原因是列表里的元素数量多时，新插入元素没有触发layout，解决办法是给消息项加transform: translateZ(0)强制开启合成层。

6. 打包上架阶段：官方文档没讲的那些坑

6.1 微信小程序：合法域名与隐私弹窗

微信小程序上架前的配置流程里，最容易卡住的是request合法域名。AI对话业务往往依赖多个域名：主接口域名、OSS文件域名、OCR域名、WebSocket域名，全部要加到小程序后台的"开发管理 > 服务器域名"里。域名必须是HTTPS，且ICP备案，否则真机预览会一直报url not in domain list。

另外从2023年起，微信小程序新增了"用户隐私保护指引"要求。如果你的App会调用麦克风、摄像头、相册、位置等隐私接口，必须在后台声明对应隐私项，并且在小程序代码里通过wx.requirePrivacyAuthorize()主动发起隐私授权。这里有一个设计细节：当你做隐私弹窗时，用户如果拒绝，不应该直接卡死在首屏。按照"不同意就退出"的思路，在微信小程序里我不建议强制退出，因为小程序被退出后会回到会话列表，体验很怪。更好的做法是只展示关键功能不可用，并提供"重新授权"按钮。

6.2 Android/iOS上架：权限声明、签名与软著

App端上架是另一套流程。先说Android，主流的安卓应用市场（华为、小米、OPPO、vivo）都要求提供软件著作权证书，在开发期就要提前申请软著，不然等产品好了再去申请，周期可能要1-2个月。此外，manifest.json里的权限声明要克制，只声明实际用到的权限。我用到的权限包括：网络、存储、录音、相机。如果声明了不必要的权限，应用市场上架审核时会被打回，要求说明用途。

iOS端上架则注意两点：一是隐私清单，苹果要求说明收集的数据类型和使用目的；二是签名证书与Bundle ID的匹配，很多团队在Android调试时用的是测试证书，上架时忘了切换生产证书，导致无法提审。我踩过最尴尬的坑是用测试描述文件打包，结果TestFlight一直报"缺少隐私清单"，查了半天才发现是证书配置不对。

这里补一个很多人在热搜里找的代码场景：iOS端当用户不同意隐私政策及用户协议时退出App。在App端，iOS没有直接的"退出应用"API，但可以通过plus.runtime.quit()实现退出。前提是你必须判断当前端是App，否则在H5或小程序上调用会报错：

function handlePrivacyReject() { uni.showModal({ title: '提示', content: '您未同意用户协议和隐私政策，将无法使用本应用', confirmText: '退出', cancelText: '暂不退出', success: (res) => { if (res.confirm) { // #ifdef APP-PLUS plus.runtime.quit() // #endif } } }) }

6.3 常见编译错误与解决速查表

最后整理一份我在这个项目里遇到的高频问题的排查速查表，不一定覆盖所有场景，但命中率很高：

这张表基本概括了我在整个开发周期里大部分卡壳的地方。每个问题单独拿出来都能写一整篇排查文章，这里先留给读者一个排查思路。当你遇到"三端表现不一致"的情况时，记住一句方法论：先定位是端能力差异，还是自己的代码没做条件编译；再检查是外层容器问题，还是内层组件样式问题。按这个顺序排查，大部分坑都能在20分钟内填平。

做完整套项目，我个人最大的体会是：跨端开发的核心不是"写一套代码跑三端"这个口号，而是把端的差异控制在极小的边界内。UniApp能帮你解决70%的兼容，剩下的30%必须靠条件编译、请求层统一、组件选型克制来治理。AI问答助手这个品类特别适合用它来做，因为核心交互是"文本流 + 消息列表"，对原生能力依赖有限，但对渲染层的要求又足够高，刚好把UniApp的优势发挥出来，也把它的小程序生态补齐了。如果你正要起步，建议先把H5端跑通、把Markdown和流式体验调好，再逐步扩展到小程序和App。按这个顺序，你会少走很多弯路。