用 ArkTS 构建 AI 内容创作应用：架构设计与踩坑实录

最近一个多月我把大部分业余时间都花在了一件听起来不算新、做起来才知道坑有多深的事上用 ArkTS 从零搭一款 AI 内容创作应用。起因其实挺朴素——我平时要同时维护几个公众号、短视频账号和项目文档写文案、列大纲、生成配图和短视频脚本这些事每天都得做但每次都要在通用 AI 聊天工具里反复复制粘贴、调 Prompt、再手动整理结果一来一回极其费时间。我想要的不是“一个能聊天的 AI”而是一个把内容创作流程固化下来的工作台打开应用就能写生成完能直接改、能存档、能导出发到各平台。这篇博文把整个项目的立项思考、架构设计、核心实现和踩坑过程完整记录下来给同样在做鸿蒙应用或 AI 工具型产品的朋友做个参考。1. 项目背景与需求拆解1.1 从“能聊”到“能干活”通用 AI 聊天工具和内容创作应用表面上都是输入文字、输出文字但实际体验差得远。聊天工具的逻辑是“你问一句我回一句”适合探索和答疑而创作场景要求的是“这一篇文案能直接用”需要模板、篇幅、风格、平台适配这些约束输出之后还得能改、能存、能反复迭代。所以这个项目的第一个决定就是不当“AI 聊天的替身”而是做“创作工作台”。具体来说应用至少要具备四件事一是模板把一个模糊需求快速套进适合自己的创作格式二是多步生成比如先出大纲再扩写而不是一次性吐两千字三是历史记录和素材收集生成的好内容可以收藏和复用四是导出生成完直接生成适合发布的文本文件或分享图。后面整个架构都是围绕这四个需求展开的。这里也有一个很重要的产品判断普通用户并不关心你接入了哪个大模型、用了什么推理框架他们只关心“输入一句话能不能拿到能用的成品”。所以在需求拆解阶段我就把重心放在“流程”而不是“模型”上。后续所有设计决策包括模板引擎、流水线、素材库本质上都是在回答同一个问题怎么让 AI 从玩具变成生产力工具。1.2 为什么选择 ArkTS立项时也犹豫过要不要走 H5 套壳路线毕竟 Web 生态成熟、招聘容易。但没有选择这套方案主要因为三个实际问题。第一聊天和流式生成这类界面核心体验在“即时反馈”。ArkUI 的声明式 UI 加状态管理处理增量文本刷新、消息列表滚动这类交互比 WebView 方案更稳尤其长会话下不容易出现输入卡顿、首屏白屏的问题。第二这个应用后续要覆盖手机、平板和折叠屏。ArkTS 的布局能力天然适配不同窗口形态一套代码能上多端比维护独立 Web 页面成本低。第三ArkTS 的类型约束对产品迭代是好事。AI 应用的协议、状态都很复杂没有类型系统的时候改一个字段要全局搜现在编译器能提前拦住一大批低级错误。团队协作、新人接手维护成本都会低一些。当然它也有明显短板三方组件很少很多 UI 效果得自己造轮子周边工具链不如 Web 生态成熟一些复杂的图形动画实现会比 Web 费劲。但这些短板都属于“多花时间能解决”而 WebView 方案在性能和体验上的短板是后期很难弥补的。权衡下来原生 ArkTS 路线更划算。1.3 功能边界与目标用户这代产品把目标用户锁定在内容运营、自媒体创作者、短视频制作人和需要经常写文档的产品研发人员身上。核心功能分成五个模块模块具体能力AI 对话创作支持多轮对话、流式输出、生成中断、追问改写场景模板小红书文案、短视频脚本、直播口播、AI 短剧分镜、周报等创作流水线大纲生成、分段扩写、风格调整、配图建议组成工作流历史与素材会话历史、收藏结果、常用素材库支持搜索导出分享导出为文本、图片卡片并支持复制到各平台需要明确的是这个应用从一开始就把合规边界划得很清楚不提供任何违反审核规则的生成能力不做未授权的资料抓取和抄袭所有用户内容默认只存本地尊重版权和数据隐私。产品红线定得越早后面越不会走弯路。尤其是内容创作这类天然面向公开传播的产品如果一开始就想走“擦边路线”后面在应用市场审核、企业采购、用户信任三个环节都会反复碰壁得不偿失。2. 整体架构与关键设计2.1 四层架构把 AI 能力封装成“内容生产线”整体架构可以分成四层。最上面是 UI 层负责对话界面、模板选择、结果预览和导出。UI 层下面是状态层用 ArkUI 的 AppStorage、LocalStorage 配合 State 管理会话数据、用户配置和 UI 状态。再往下是业务层包含 Prompt 模板引擎、创作流水线编排、文本后处理和存储逻辑。最底层是 AI 能力层通过统一的网关访问云端大模型服务包括文本生成、图像理解、语音合成等能力。这么分层的一个直接好处是换模型服务商的时候只需要改最底层的适配代码业务层和 UI 层完全不动。另一个好处是能力可复用比如配图建议在“短视频脚本”和“公众号文章”两个模板里都能用不用重复实现。实际上大部分 AI 应用失败不是因为模型不好而是生成结果没办法直接进入用户的工作流。架构上把“AI 能力”放到底层、把“创作流程”放到业务层就是为了让用户看到的是流程而不是一堆需要自己组织的大模型接口。2.2 创作 Agent 流水线从“回答问题”到“干完一件事”项目里最重要的一次设计决策是把单次生成改成多步工作流我内部把它叫“创作 Agent 流水线”。以短视频脚本为例用户只输入一个主题系统会依次执行五步需求理解用一小段 Prompt 把用户主题拆成目标、受众、平台、时长等结构化信息。大纲生成生成分镜或段落结构用户确认或修改。分段扩写按大纲逐段生成每段都可以单独改写和回滚。风格调整根据平台调性换语气比如小红书偏口语、公众号偏深度。配图与字幕建议给每组文案生成画面描述和字幕文本。每一步的输入输出都是结构化数据下一步从上游拿结果所以用户随时可以在中间插一步修改而不是生成完才发现问题。这种“多 AI 协作”的模式很实用文本、图像、语音分别调用最合适的模型而不是用一个模型硬扛所有任务。放到内容创作场景里文案生成用语言模型配图创意建议用多模态模型语音旁白生成则交给 TTS 服务各司其职。对比传统思路这种方式最大的优势是可控。单次生成的随机性很难压住但把生成拆成“大纲确认后再扩写”之后用户至少能在大纲阶段把方向纠正过来后面的扩写即使有偏差也不会跑太远。这也是很多所谓“AI 工作流”和裸模型调用之间的本质区别。2.3 ArkTS 状态管理流式生成不卡不丢的关键流式生成是这个应用体验的命脉。大模型返回是一段一段的UI 必须频繁更新这里状态管理设计直接影响流畅度。最核心的一条经验是不要让整个会话大文本绑在一个 State 变量里无限刷新。我的做法是消息列表用 State 持有每个消息对象内部再拆成“头部信息”和“正文内容”正文更新通过子组件接收。每次网络返回新片段时只替换正文内容不重建整条消息对象。配合 ArkUI 的 diff 更新能力界面刷新会收敛到真正变化的那部分文本上。会话持久化也要想清楚。AppStorage 适合存轻量配置会话列表这种重量级数据我用的是关系型数据库落盘启动时再恢复。这里有个细节恢复历史会话时不能一次性把所有消息都怼到状态里否则长会话直接卡死应该先恢复会话摘要进入会话详情后再按需加载消息。另外ArkTS 严格的类型约束在状态管理上带来了额外的好处。以前写动态语言时消息对象里字段名拼错了要等运行时才报错现在编译期就能发现。AI 消息结构里经常出现嵌套对象比如引用图片、素材、修改建议类型定义清楚之后代码可读性和协作效率都提升不少。3. 核心模块实操拆解3.1 对话式创作界面声明式 UI 快速落地对话式创作界面是这个应用的脸面。用 ArkTS 实现时核心结构很简洁一个 Scroll 承载消息列表一个输入区承载 Prompt 输入和发送按钮。消息气泡用 Builder 封装根据角色渲染成用户消息和 AI 消息两种样式。Component struct ChatView { State messageList: ChatMessage[] []; State inputText: string ; private listScroller: Scroller new Scroller(); Builder MessageItem(msg: ChatMessage) { Row() { if (msg.role user) { // 用户消息靠右展示 } else { // AI 消息靠左带角色头像 } Text(msg.content) .fontSize(16) .lineHeight(24) .copyOption(CopyOptions.LocalDevice) } .width(100%) .padding({ left: 16, right: 16, top: 8, bottom: 8 }) } build() { Column() { Scroll(this.listScroller) { Column() { ForEach(this.messageList, (msg: ChatMessage) { this.MessageItem(msg) }, (msg: ChatMessage) msg.id) } .width(100%) } .layoutWeight(1) .scrollBar(BarState.Off) Row() { TextInput({ placeholder: 输入创作需求..., text: this.inputText }) .layoutWeight(1) Button(发送) .onClick(() this.sendMessage()) } .padding(8) } } }注意两个细节。第一ForEach 的 key 必须用稳定的消息 id不能用索引否则流式更新时列表会被整体重建。第二每次新消息追加后要调用 listScroller.scrollEdge(Edge.Bottom)否则用户会一直停在旧位置体验很糟糕。实际项目里我在发送前、收到首段、生成结束这三个时机都做了滚动到底部的处理。3.2 大模型请求封装与流式解析网络层是这个应用与模型服务对接的枢纽。我封装了一个独立的请求模块统一处理三件事超时控制、错误重试、流式响应回调。ArkTS 里用的是 ohos.net.http 模块核心逻辑是发起 POST 请求、读取响应然后把增量数据通过回调抛给 UI 层。import http from ohos.net.http; class ChatService { private static readonly TIMEOUT_MS 30000; static requestChat(messages: ChatMessage[], onDelta: (text: string) void): Promisestring { const httpRequest http.createHttp(); return new Promisestring((resolve, reject) { httpRequest.request( https://your-ai-gateway.example.com/v1/chat/completions, { method: http.RequestMethod.POST, header: { Content-Type: application/json, Authorization: Bearer getAppApiKey() }, extraData: JSON.stringify({ model: your-model, messages: messages.map(m ({ role: m.role, content: m.content })), stream: true, temperature: 0.7 }), expectDataType: http.HttpDataType.STRING, timeout: ChatService.TIMEOUT_MS } ).then((response: http.HttpResponse) { // 服务端按 SSE 格式返回这里做增量解析 const result response.result as string; onDelta(result); resolve(result); }).catch((err: Error) { reject(err); }); }); } }上面的代码是做功能演示的省略版本。生产环境要注意三点一是 API Key 不要硬编码在客户端应该放在自己的服务端网关里客户端只带用户登录态二是服务端要做鉴权和限流防止密钥泄露后被刷三是流式解析要按 SSE 的数据帧来切分不能简单地把整包文本丢给 UI否则用户看到的是“一次性蹦出一大段”根本没有流式效果。SSE 解析的核心思路是把 buffer 按空行分割成帧逐个解析以 data: 开头的行然后把 JSON 里的增量字段提取出来通过回调函数推给界面。这里最坑的是编码问题如果模型返回内容里包含中文必须用 UTF-8 解码否则会出现乱码。最初我就因为漏了这一步调试了整整一个下午。3.3 生成结果的后处理与本地持久化模型生成的文本不能直接用。我总结了一个文本后处理的三步流程。第一步是清理噪音去掉重复的“好的明白了”这类前缀压缩多余空行。第二步是格式归一把 Markdown 标题符号统一转成应用内渲染格式。第三步是长度控制超出平台限制的内容自动截断并在末尾提示用户“内容过长已精简”。后处理做完再考虑存哪里。轻量配置用 Preferences会话历史和消息记录用关系型数据库大段生成结果和导出文件直接落文件系统。选择关系型数据库而不是 JSON 文件的关键原因是要支持会话搜索和分页加载数据库查询天然带索引比全量读文件再过滤靠谱得多。存储的另一个设计点是“本地优先”。默认所有生成内容只存在设备本地云端同步做成可选项而且必须明确告知用户保存范围和用途。这个决策一方面保护用户隐私另一方面也避免了很多合规上的麻烦。3.4 模板引擎与创作素材模板是这个应用的灵魂。没有模板的 AI 创作应用本质上就是个聊天工具有了模板才配叫创作工作台。我的模板不是简单的 Prompt 字符串而是一个包含变量槽位、默认参数、约束条件的结构化配置。{ id: live_script, name: 直播带货脚本, description: 生成一段带节奏的直播口播脚本, fields: [ { key: product, label: 产品名称, type: text }, { key: audience, label: 目标人群, type: text }, { key: scene, label: 使用场景, type: text } ], promptTemplate: 你是一位有经验的直播运营请围绕{product}面向{audience}在{scene}场景下生成直播脚本……, maxLength: 1500, platform: [直播, 短视频] }模板配置和渲染引擎分离意味着运营同学可以自己加模板不用改代码。目前模板库里已经内置了直播带货脚本、短视频口播、AI 短剧分镜大纲、公众号文章、周报、产品卖点提炼等十多个场景覆盖了主流内容形态。素材库则用来沉淀高频会用到的内容资产比如企业话术、常用专业术语、历史收藏的爆款开头。素材在 Prompt 组装时会自动拼接到上下文里让生成结果更贴合团队自己的语言习惯。4. 性能、隐私与兼容性避坑指南4.1 并发与内存管理别把脏活累活放在主线程ArkTS 提供 TaskPool 等并发能力但很多人容易忽略。一次生成结果可能几千字如果在主线程做文本清洗、关键词抽取、JSON 解析界面就会明显掉帧而掉帧在用户眼里就是“卡”。实际项目里我把三类任务放进了 TaskPool长文本清洗与去重、大 JSON 解析、语音合成结果的后处理。主线程只做 UI 更新和轻量的状态变更脏活累活都丢给并发任务。这里有一个性能优化经验流式生成过程中不要做重量级后处理先把增量文本原样填充到界面等整段生成结束再统一做清洗和格式化否则每来一段就清洗一次计算量翻好几倍界面也跟不上。内存方面最容易爆的是超长会话。模型上下文越长历史消息累积越快如果一直把全部消息保留在内存里几轮下来就是几十 MB 的占用。我加了一个会话窗口裁剪策略超过一定轮数后把早期的消息摘要化只保留摘要文本和最近 N 轮完整消息既能继续支撑上下文又不会拖垮内存。4.2 长文本渲染与列表性能生成结果长的时候列表性能问题立刻暴露。ArkUI 的 ForEach 适合几十条的渲染量但会话动辄几百条消息必须换成 LazyForEach。LazyForEach 要求实现一个数据源接口提供 totalCount、getData 等能力它会在列表滚动时才渲染可视区域附近的组件这是长列表不卡的标准解法。生成内容的渲染也要分层处理。一条超长 AI 消息如果按一个 Text 组件整体渲染段落更新时会触发整块文本重排。我把消息内容拆成多个段落子组件每个段落只负责渲染自己的文本。这样流式更新时只有最后一个正在生成的段落会频繁刷新前面已经定稿的段落完全不参与重排性能提升非常明显。图片类的生成结果还需要额外注意。生成配图描述时如果直接把多张图片数据塞进消息列表内存瞬间飙升。我的做法是列表里只放缩略图路径点击放大时才加载原图同时用 LRU 缓存维护最近浏览的图片降低重复加载的开销。4.3 隐私与内容合规机制AI 内容创作应用最容易被忽视、也最容易出问题的就是合规。这个项目从第一天就把合规当成功能来做。具体落了三件事。第一数据采集最小化不采集通讯录、位置等无关信息输入的内容默认只存本地云同步是显式开启的开关。第二内容安全审核所有生成的文本在展示前调用内容安全服务做一轮检查涉敏内容直接拦截不让它出现在用户界面里。第三用户反馈渠道提供举报和反馈入口任何内容问题都能追溯和处理。很多人觉得内容审核拖慢体验实测下来没必要过度担心。文本审核耗时可控制在几百毫秒到一两秒之间而且只对首段生成做全量检查后续流式输出可以并行异步审核不影响展示节奏。真正重要的是把审核逻辑放在业务层统一处理而不是散落在各个页面里否则后期加规则就是一场灾难。做内容和做产品一样一旦红线不清晰后面各种奇怪的 bug 和舆情都会找上来。早点把合规机制做成产品的一部分反而能在应用商店审核、企业采购、用户信任这些关键节点获得意想不到的加分。5. 踩坑实录与体验优化5.1 高频问题速查表开发过程中踩过不少坑最有代表性的几个整理成表格方便大家对照排查。问题现象根因解决方案生成到一半界面卡死大段 JSON 在主线程解析阻塞 UI把解析移到 TaskPool主线程只收结果流式输出中文乱码SSE 数据按单字节切割UTF-8 被截断按字节缓冲解码用 TextDecoder 处理增量历史会话恢复后列表崩溃一次性加载全部消息内存溢出恢复摘要进入会话再按需加载消息长对话后生成质量变差上下文被无关历史污染动态裁剪早期消息保留摘要和关键信息生成结果频繁重复词temperature 设置过高或 prompt 缺乏约束调低采样参数在 Prompt 中明确“不要重复”配图列表内存暴涨原图直接加载进列表列表用缩略图原图按需加载并 LRU 缓存系统字体变化后布局错乱自定义组件未适配字体缩放用自适应布局单位禁用部分固定高度这张表其实是整个项目最值钱的沉淀。很多问题报错信息只有一行不看上下文根本想不到根因我把每个坑的触发条件、复现路径和修复方案都记到团队 wiki 里后面新同事接手时少走很多弯路。5.2 几个提升体验的小细节功能做完之后体验优化才是拉开差距的地方。我挑四个投入产出比极高的小细节分享。第一生成过程中必须有“停止生成”按钮。长文本生成经常不是用户要的内容没有中断能力的应用会让人非常焦躁。中断的底层实现是取消底层 HTTP 请求同时给当前消息打上“已中断”标记下次重试时带着已有内容继续补全而不是重新生成。第二追问和局部改写比“再来一次”更常用。我的实现方式是在每条 AI 消息下提供三个快捷指令改短、改口语、换风格。用户点一下系统就把当前消息和指令一起发给模型不做多轮对话直接出修改版。这个功能把“生成完还得自己复制粘贴回输入框再改”的繁琐路径砍掉了。第三重试必须保留上下文。如果用户对结果不满意点了重试新的请求要基于当前会话的历史消息而不是只发一个问题否则模型理解不了“重试”到底针对什么。重试时还要自动把上一条生成结果标记为“已废弃”避免把两份结果混淆。第四历史记录要给足搜索能力。内容创作会积累大量灵感和文案如果只能翻列表三个月后基本就找不到了。我加了标题、关键词、日期三个维度的搜索并支持按模板类型筛选找一条半年前的脚本只需要几秒钟。最后说一点个人体会。整个项目做下来我最深的感受是AI 应用的核心竞争力从来不在“接入了多少模型”而在于有没有把模型能力变成用户能直接用的工作流。ArkTS 这套声明式开发框架配合云端大模型能力做内容创作类应用其实是挺合适的组合——界面动态刷新是它的强项类型安全又让复杂状态不容易失控。如果让我重新开始做一遍我会把更多时间留给模板引擎和素材库而不是花大把精力调对话界面因为用户真正能感知的价值是“进来之后能多快产出内容、产出的内容能不能用”而不是那个气泡动画多流畅。希望这篇记录能帮到正在做类似产品的朋友少走几个我已经帮你们踩过的坑。