这两年我接触了不少ToB系统的改造项目印象最深的是某物流调度系统的使用场景调度员每天要在十几个表单字段里来回切换填完车次填司机填完司机填路线一单下来少说五分钟。后来在HarmonyOS设备上接入了AI助手调度员只需要说一句“明天上午安排三辆车走华东线”系统自己就把车辆、司机、时间窗、路线约束全部匹配好调度员只需要确认结果。这个变化让我意识到一件事当ToB系统开始具备“思考”能力界面设计的逻辑根基就变了。过去我们设计界面本质是设计“人操作机器的路径”现在要设计的是“人理解机器的意图、机器理解人的意图”的双向通道。HarmonyOS的分布式能力和AI框架给了这种交互落地的土壤但真正难的不是技术接入而是界面设计观念的切换。这篇文章我不打算讲某个具体API怎么调用而是想聊清楚一个更底层的问题AI介入后ToB系统的界面到底该怎么设计我把它拆成五个部分从交互范式、信息架构、组件落地、状态设计到信任边界每一部分都有HarmonyOS上的实操要点和踩坑记录。1. 交互范式从“填表”变成“对话”ToB界面为什么再也回不去了先看一个基本事实传统ToB系统的界面绝大多数是围绕“表单”和“流程”展开的。建单、审批、查询、导出每一步都有固定字段、固定按钮、固定路径。这种设计的好处是确定性极高——用户不会迷路系统不会误判坏处也极其明显——用户的大量精力消耗在“把人类语言翻译成系统字段”这件事上。AI一旦介入最先被重写的就是这一层翻译工作。1.1 “填表”的本质是让用户迁就系统“对话”的本质是让系统迁就用户我在HarmonyOS上做过一个实验同一个库存盘点任务用传统表单需要用户依次选择仓库编码、货架编号、SKU、数量、备注而用AI对话只需要输入“A库第三排货架的临期牛奶还剩多少”。前者是在操作数据结构后者是在表达业务意图。前者界面再漂亮学习成本也压不低后者界面哪怕只有一个输入框用户上手也几乎是零成本。这里有个容易被忽视的细节AI对话并不是要取代所有表单而是把表单从“前台”挪到了“后台”。用户的自然语言输入进来系统解析成查询参数后台跑完逻辑再把结果以结构化卡片的形式反馈。用户看到的界面变简单了但系统要做的“界面”反而更多了——至少包括意图解析结果、参数确认、结果呈现、异常兜底四层。1.2 ToB场景里有一个ToC没有的约束业务正确性不能完全交给AI自由发挥消费者聊天场景里AI答错了顶多被笑话ToB场景里AI做错了可能直接导致一笔错误订单、一次错误调度、一条错误生产指令。所以我在设计这类界面时一直强调一句话AI负责理解但确认权必须留在人手里。这个原则落到界面设计上就体现在一个“确认”环节的取舍上。以HarmonyOS的对话框组件的实现为例AI解析完用户意图后不要直接把结果提交给后端而是先在对话流里生成一张“意图确认卡”把系统理解到的关键参数数量、时间、对象、动作逐项展示出来用户点一下确认才真正进入业务流转。if (this.aiIntent.confidence 0.8) { // 高置信度意图展示确认卡用户一键确认 this.showConfirmCard(this.aiIntent); } else { // 低置信度意图进入澄清追问流程 this.startClarifyFlow(this.aiIntent.missingParams); }这段ArkTS代码看起来简单却是我踩过坑之后的沉淀。最初我设计的是“高置信度直接执行”测试阶段就出了事——AI把“下周”理解成了“下周一到周五”置信度高达0.93结果直接生成了五天的调度计划。从那以后ToB场景我坚决不碰“自动执行”所有涉及业务状态变更的操作界面必须给出明确的人机确认节点。1.3 为什么HarmonyOS适合做AI交互的ToB界面关于技术选型我明确说自己的判断HarmonyOS分布式流转能力天然适合ToB的AI交互改造。传统ToB业务很多是“PC上录入、手机上审批”的双端模式AI介入后对话发起端、意图理解端、业务执行端经常落在不同类型的设备上比如用户在手机上用语音发起请求AI在平板上展示分析结果最终的审批动作在PC端完成。HarmonyOS的分布式数据管理能力可以做到对话上下文跨端无缝流转用户在手机上没说完的话到平板上还能接着补全。这种体验在传统开发里要自己维护一套会话同步逻辑而在HarmonyOS上底层能力是现成的重点反而是界面层怎么把“跨端”这个状态自然地表达给用户。2. 设计师先要过一关把“确定性操作”和“不确定性输出”分开设计很多团队做AI界面失败问题不是AI能力不行而是设计思路还停留在“让AI去适配传统UI”。结果AI的结果要么被塞进一个过小的卡片里要么被强行套进表格流程里用户的体感是“这个系统一会儿聪明一会儿智障”。我的经验是在设计之初就把界面分成两块——确定性操作区和智能交互区两者互不污染。2.1 确定性操作区保留传统组件不要为了AI化而AI化ToB系统里大量操作其实是确定的查询条件、状态切换、批量操作、数据导出。这些操作已经有成熟的组件方案输入框、下拉框、单选多选、按钮组。在HarmonyOS的ArkUI里这些组件很成熟性能也稳定完全没有必要让用户通过自然语言去做一个下拉框就能完成的事。我见过一个反面案例某项目把所有查询都改成了AI对话入口用户输入“查一下上个月华东区的销售数据”AI偶尔能答对偶尔把“华东区”理解成“华东华南”结果用户还得再检查一遍下拉框的任务反而更慢了。这个例子提醒我AI应该用在“用户不知道怎么做”或“步骤特别多”的地方而不是替代一个简单选择器。2.2 智能交互区用卡片承载AI的不确定性输出AI输出的内容天然带有不确定性——置信度、可解释性、多候选结果。这些信息不适合塞进传统表格里更适合用“卡片”承载。HarmonyOS的ArkTS里卡片组件已经很成熟我在AI交互区常用的结构是四层卡片嵌套顶层是AI回答摘要卡用自然语言概括结论第二层是参数依据卡列出AI做判断时参考的关键字段第三层是操作建议卡给出可执行的动作按钮第四层是追问入口卡给用户提供“换一种方案”“补充条件”等引导。四层结构的好处是用户可以只读第一层快速获得结论也可以逐步下钻到第三层、第四层完成完整业务动作。每一层都是降级路径AI再拉胯用户也不至于卡死在这一步。Entry Component struct AiResultCard { Prop summary: string Prop evidence: EvidenceItem[] Prop actions: ActionItem[] build() { Column({ space: 12 }) { // 层1摘要 Text(this.summary) .fontSize(18) .fontWeight(FontWeight.Medium) // 层2依据 ForEach(this.evidence, (item: EvidenceItem) { Row() { Text(item.label).fontSize(14).fontColor(#666) Text(item.value).fontSize(14).fontWeight(FontWeight.Regular) } }) // 层3可执行动作 Row({ space: 8 }) { ForEach(this.actions, (action: ActionItem) { Button(action.text) .onClick(() this.onAction(action)) }) } } .padding(16) .backgroundColor(Color.White) .borderRadius(12) } }这个组件的代码量不大关键却在它的交互逻辑每一层卡片只回答一个用户最关心的问题——“结论是什么”“凭什么这么判断”“接下来能干什么”。在设计评审时我常用一句话说服项目组不要让用户的眼睛在对话流里到处找按钮。2.3 识别AI能力的边界界面才能做出正确的功能分区在HarmonyOS的AI能力接入实践里我总结出一个大致的边界表格规划界面功能时会直接参照它任务类型AI介入方式界面呈现建议数据查询解析自然语言生成查询参数参数确认卡 结果表格统计分析生成分析结论与可视化建议结论摘要卡 图表组件异常诊断定位根因并给出修复建议根因链路图 建议动作卡流程审批摘要审批要点并给出建议要点摘要 审批按钮区批量操作自动化生成操作序列操作预览列表 二次确认弹窗这张表不是让团队死记硬背而是想说明一件事AI能力落在哪个环节界面里的“AI特征”就应该出现在哪个环节。该用表格的地方用表格该用对话的地方用对话该用确认弹窗的地方用确认弹窗各得其所。我在实际项目中还会给每个功能卡片加一个置信度角标低于某个阈值的回答卡片底部会显示“低置信度请人工复核”的提示条并把依据卡置顶暴露。这个细节虽然只占了几行代码却在提升用户对系统的信任度上起到了关键作用。3. 对话式卡片式HarmonyOS上AI界面的两套核心骨架说到落地HarmonyOS上目前最实用的两套AI界面骨架一套是对话流Conversational Flow一套是意图卡片流Intent Card Flow。两者不是二选一而是根据场景配合使用。3.1 对话流适合开放式意图但要设计好“对话的终点”对话流的典型实现是把用户发言和AI回复按时间顺序排列在会话面板里类似聊天软件的界面。HarmonyOS的List组件天然适合这种场景配合Scroll可以做到性能不错的无限滚动。我踩过的坑在于“对话终点”的设计。很多初版会做成无限对话——用户问完一个问题AI只能继续用文字回复用户再提问再回复如此循环。这在ToB场景是灾难因为ToB用户往往只想知道结果、记下结果、然后回到业务系统里去操作。解决方案是在对话流里嵌入“业务落地块”当AI回答完成后对话流末尾出现一行功能按钮——“跳转到明细”“加入待处理列表”“生成工单”。点击按钮对话面板收起系统切换到对应的业务模块。这样对话是“有出口的”而不是一个永无终点的聊天窗。3.2 意图卡片流适合多参数业务把每一步拆成可视卡片另一种常见场景是用户用一句话提交了一个多参数任务例如“把下周一上午上海到杭州的订单全部安排给华东车队”。这个意图涉及时间维度、地域维度、对象维度、动作维度四个参数任何一个解析错了后续都会出错。这时候我倾向于不用纯对话流而是用一个“意图卡片流”系统先把用户的话显示在顶部然后按照参数维度生成四张确认卡片时间卡、地域卡、对象卡、动作卡每张卡片都显示解析结果用户可单独修改卡片内容全部确认后统一提交。在HarmonyOS的实现上我推荐用WaterFlow组件或简单的Column嵌套来实现这种流式卡片。关键点在于每张卡片要支持独立的编辑能力和独立的确认状态——用户可能改完时间卡就直接点“下一步”并不需要再回看整个对话。State intentCards: IntentCard[] [] State overallConfirmed: boolean false build() { Column() { // 用户原始意图 Text(this.originalQuery).fontSize(16).fontColor(#222) // 参数解析卡片 ForEach(this.intentCards, (card: IntentCard) { CardEditor({ card: card, onChange: (newCard: IntentCard) this.updateCard(newCard) }) }) // 全量确认按钮 Button(全部确认并执行) .enabled(this.overallConfirmed) .onClick(() this.submitAll()) } }这个流程最核心的体验改进是“一次说清分段确认”用户不需要为了改一个参数反复打断AI每张卡片的独立性把容错成本降到了最低。3.3 键盘与语音输入方式决定界面的入口形态HarmonyOS设备形态多样有的带物理键盘有的依赖触屏有的支持语音。我在设计界面入口时通常遵循一个优先级原则输入成本越低的通道越优先展示。对于关键业务动作我会同时提供三种入口语音输入胶囊悬浮在页面底部文字输入框常驻在对话区快捷指令预设展示在首页。语音输入在HarmonyOS上接入比较简单但要注意设置明确的“结束说话”反馈——因为ToB用户往往在嘈杂环境里使用误触发的概率远比想象中高。我实测下来一个比较稳妥的做法是语音输入触发后界面停留在等待状态顶部显示波形动画系统自动做端点检测直到检测到用户停顿超过1.2秒才结束录音再进入意图解析。这个1.2秒的阈值比ToC软件常用的0.8秒更保守因为ToB用户表述业务意图时往往更长、更含术语过早断句会导致大量的语音文字转写错误。4. 流式输出与多轮追问AI界面的状态设计暗坑到了真正跑AI推理的时候界面设计会撞上另一个大问题AI不是瞬间返回的。传统界面的状态设计只有加载中、成功、失败三种而AI界面至少要多出“流式输出中”“部分参数已确认”“等待用户补充信息”“推理降级”四种状态。这些状态处理不好用户会频繁觉得系统“卡死了”。4.1 流式渲染别让用户在等待里干瞪眼大模型输出的Token是逐个生成的如果界面非要等全文生成完再渲染一次用户等待时间会长达数秒甚至十几秒。我在HarmonyOS上处理流式输出用的是ArkTS的异步流每收到一个增量片段就追加到当前回答区域用State驱动UI刷新。需要注意一个细节流式输出过程中用户很可能会忍不住点击回答区域里的按钮但这些按钮的“可点击状态”要等整段回答稳定后才开放。我在实现里维护了isStreaming状态流式期间禁用操作按钮同时显示一个细小的“生成中”指示动画。这比让用户点击后发现没有反应体验要好得多。async streamAnswer(prompt: string) { this.isStreaming true try { for await (const chunk of this.aiProvider.chatStream(prompt)) { this.answerText chunk } } finally { this.isStreaming false this.enableActions true } }4.2 多轮追问与上下文会话面板里的记忆边界ToB对话的另一个特点是多轮追问频繁。用户会问“华东区的库存呢”紧接着问“那华南呢”再问“两个加起来呢”每一轮都依赖上一轮的上下文。这里的界面设计关键是“上下文可视化”——让用户清楚地看到当前对话的上下文边界在哪。我在会话面板顶部固定了一个“当前关注范围”条里面以标签形式展示当前锁定的筛选条件时间范围、地区范围、对象范围用户可以随时点击标签删除或修改某个条件。这样设计后AI的“记忆”被显性化了用户不会在第四五轮追问时突然发现AI早已忘了第一轮的条件。4.3 打断、纠错与重试用户绝不会按剧本走我之前天真地认为用户会等AI说完再操作。实际测试时发现用户一看AI回答开头不对马上就会点“停止生成”然后重新输入问题甚至直接修改已经生成的卡片参数。如果界面没有给这些动作设计响应路径系统就会处于一种“旧答案还在生成新意图已经进来”的并发状态。我的处理方案是在每次新的用户输入进入时主动取消当前生成任务丢弃尚未完成的增量帧并清空上一轮的回答缓存然后加载新问题的初始状态。这看起来是基础逻辑但我在三个项目里都发现初版代码普遍没做好“取消”这件事导致用户看到上一轮的半个答案混在新一轮回答里非常掉价。重试按钮更是必不可少。AI偶尔会因为网络抖动或上下文超长而回答异常此时在错误提示旁边放一个“重新生成”按钮让用户不用重新组织语言。这个按钮的文案我建议用“重新生成”而不是“重试”因为ToB用户对“重试”的感知是“系统又出错了”而“重新生成”的感知是“换一种方式再算一次”。5. ToB场景里的边界感权限、审计与信任设计最后这部分可能是ToB界面和ToC界面差异最大的一块。消费者接受AI偶尔一本正经地胡说八道但ToB用户坐在工位前对着一套业务系统他需要对结果的来源负责。界面设计的终极目标是让用户“敢点确认”。5.1 数据权限可视化AI不该替用户越权ToB系统的数据权限通常很严格不同角色只允许查看不同维度的数据。AI介入后权限校验不能只发生在后端界面层也需要把权限边界传递给用户。我在HarmonyOS上的做法是AI生成的回答卡片里凡是引用了受权限控制的数据域卡片右上角会显示一个小锁图标并在折叠区说明“当前视图受权限限制以下字段已脱敏”。这样用户不会因为AI提到了某个字段但看不到明细而困惑也不会误以为系统出了故障。5.2 审计痕迹设计AI做的每一步都要有迹可循ToB系统上线后所有操作都可能被审计。AI生成的建议、自动执行的参数修改必须留下足够清晰的痕迹记录。这个需求直接影响了界面设计会话面板的技术上要把每一轮AI回答固化成不可编辑的会话记录并关联操作人、时间戳、意图解析版本、模型版本。我在界面上预留了一个“导出会话”按钮点击后生成结构化的操作记录文件。这个看似很小众的功能在实际推行中反而是客户验收时最看重的点。合规审查人员可以据此复盘AI当时为什么这么建议用户当时为什么这么确认。5.3 降级路径AI不在时系统不能瘫痪这是我最想强调的一条。ToB系统接入AI能力之后团队最兴奋的是上线后的智能化体验但必须给AI不可用的情况准备完备的降级界面。我的经验是AI入口旁边永远放着一个传统入口。对话输入框上方供一个“切换到表单模式”的链接一旦AI服务出现异常超时、模型不可用、解析失败系统要自动检测并提示“智能助手暂不可用您仍可通过表单方式完成任务”随后一键切换到传统界面。降级路径的意义不在于多一套界面而在于向客户和管理层传递一个信息AI是一个增强能力的模块而不是业务系统的心脏。那些一上线就出问题的所谓AI化改造绝大多数都是把AI当成了心脏而忘了它是来辅助人的。我在HarmonyOS里实现时给AI服务封装了一个健康检查器每次调用前做一次轻量探活连续两次失败就自动冻结AI交互区展示降级提示。这个策略在线上运行了几个月确实在几次模型服务波动时避免了业务停摆。写到这里我想起一个做实施的朋友说过的话ToB系统的AI改造说到底不是技术升级而是信任设计。让一个业务负责人相信AI给出的调度方案比让AI真的算出最优方案要难得多。而信任的建立恰恰藏在那些界面细节里——确认卡的参数拆得够不够清楚依据列得够不够直观降级路径够不够从容权限边界表达得够不够明确。我个人实际测试中体会最深的一点是把设计方案扔给用户前一定要先用真实业务数据做一遍完整的对话模拟。你会发现用户的问题远比Demo里要含糊“把这个弄一下”这种人类独有的省略表达AI大概率解不出来。这时候界面能做的是把缺失参数变成一张张待补充的小卡片一步步把人的表达补成机器的理解。这套“补全设计”做到位了AI界面才真正算得上开始落地。以后如果还有机会我打算再写一篇关于HarmonyOS上AI结构化输出组件封装的实战记录把这套卡片的参数协议和跨端流转方案展开聊聊。那又是一个新的坑但值得踩。