AI Chat产品设计中的思考③容器/Ctn
北京/产品设计师/146天前/3820浏览
版权
AI Chat产品设计中的思考③容器/Ctn
在这之前，聊一个关于UI的话题。之前我和几个大厂资深的UI设计师朋友聊天，讨论什么是最顶级的UI设计，或者说，UI设计的最高境界是什么。一开始大家都推荐自己欣赏的设计师或者APP，后来逐渐讨论到用户视角而非设计师视角，最后得到的答案是：无感，也就是“透明的设计”——最好的设计就像空气，你赖以生存却感觉不到它的存在。打个比方：你想购买一款适合自己的口红，你从进入app到付完款，所有操作一气呵成没有阻碍，等回忆起整个过程时，你没有留意到UI有多漂亮，动效有多炫酷，你只是觉得一切都自然而然，顺畅无比。传统的移动互联网产品设计逻辑是“构建路径”，也就是大家常说的用户地图，核心是流量和曝光。AI Agent App 的设计逻辑是“响应意图”，核心是效率和转化。而在 AI 时代，这种“无感”有了更深层的含义：无感，是让用户忘记“操作”，只关注“结果”。不仅是视觉上的干扰极小，更是决策成本的降维。你可以把Chatfeed 看做一个新的操作系统界面，而我们这一期要讲的容器，就是这个系统上运行的“微型应用”。AI 负责“思考”，而容器负责“行动”。没有容器，AI 的智能输出只能停留在文本层面，无法转化为高效率、高转化、高信任度的“无感”体验。
认识容器
1.1 什么是容器
在Chatfeed中，容器（Container，简写Ctn）是承载信息输出的标准化UI外壳。它不仅仅是个对话气泡，而是根据内容属性（文本、多媒体（图文/视频）、交互控件、商品SKU）自适应的交互单元。或者更直观的理解，容器是AI的“交付物”——即针对用户问题，交付给用户的内容物。
当前市面上的容器大概分为五大类：
文本容器、多媒体容器、基础交互容器、专业输出容器、商业交易容器。
1.1.1 文本容器：
Markdown格式的纯文本，用于承载和结构化文字信息的容器。它负责将 AI 输出的诊断报告、分析总结、长篇建议等信息进行
结构化、分层级
展示，以提高专业度和可读性。
1.1.2 多媒体容器：
用于承载图片、视频、音频等多媒体内容的容器。负责提供视觉证据、情感信息（如心理安抚语音）和教学演示（如推拿视频），增强感知和表现力。
1.1.3 基础交互容器：
用于在对话流中直接收集用户输入或引导用户行动的容器。追求
通用性
和
易用性
，目的是让用户快速输入信息。
1.1.4 专业输出容器：
用于在对话流中展示复杂计算和功能结果，如代码块、HTML 预览、3D 模型、数据分析图表，展示 AI 复杂工作的成果（秀肌肉）。
1.1.5 商业交易容器：
用于展示商品或服务的核心信息，以达成商业转化的容器。负责提供图片、价格、卖点和明确的 CTA（call to action），是实现对话内转化的关键载体。
容器的设计原则
2.2.1一致性：
建立统一的“骨架”，允许差异化的“皮肤”。
所有容器应遵循统一的圆角、间距、阴影（如有）和品牌色体系，但允许根据智能体人设进行微调（如：医疗类智能体偏理性、克制的蓝白体系，美妆专家偏高对比、时尚感更强的配色），但
交互逻辑和底层规范必须要统一
。
2.2.2高信噪比：降噪处理，让核心信息秒捕捉。
手机屏幕空间寸土寸金，且 AI 生成的内容往往容易冗长。设计的目标是让用户在 0.5 秒内捕捉到重点，为此，设计层面至少要做到两件事：
① 清晰的视觉分层：
- 分割线可以用，但必须克制、弱化；
- 优先通过字号、字重、留白建立层级；
- 让“重点自己跳出来”，而不是靠用户仔细找
② 强制内容结构化（而不是长文）
严禁出现大段密集的文本。以医疗场景为例，智能体的回复应被拆解为清晰的视觉区块，例如：
（通常需要 PE 工程层+ 前端渲染层双向协作），而不是一段数百字的长文。
这样就有几个好处：
①用户瞬间知道我在哪/下面是啥/接下来干啥，极大降低大脑的定位成本，直接把阅读体验提升好几个档次；
②把AI最容易犯的“过度解释”直接框死，让文本量大幅缩短，清晰度大幅提升。
③结构化的内容不容易被带智能体的人设带跑偏。
But，数字人场景需要反着来。
我们曾经遇到一个典型问题：
有个智能体版本过于追求智能体的回复效果像专家，模仿专家的说话语气与口头禅，忽略了内容必须为解决问题服务，导致体验特别差，看半天找不到重点。比如大段铺垫没有重点，口头禅被放大，输出的内容像是在cos专家而不是解决问题。在后续迭代中通过PE工程把内容在一定程度上结构化后，体验就拔高了好几个档次。
但是在数字人场景需要“反着来”，当然这不是说就得丢掉结构化，而是把结构化隐藏。因为在数字人场景，更需要的反而是“表演”。
数字人天生有两个东西：
如果直接把结构化文本原样呈现，很容易产生强烈的机械感和违和感，反而不利于信任建立。
例如，当用户说“我最近失眠”：数字人医生不应直接输出
“症状：睡眠不足；原因：压力过大；建议：冥想”
而应使用人类更自然的表达方式去覆盖结构：
“听起来你最近确实挺累的，尤其是睡眠这块有点吃不消。 很可能还是压力堆得有点多了。 不如我先给你几条能立刻缓一缓的小方法，我们一步一步来。”
2.2.3行动导向：
提升交互的可供性，让“内容”本身成为触发器。
容器的最终目的是让用户产生行动，尤其是在需要引流变现的商业化场景中。但行动不等于一定要一个 Button。
更合理的方法是采用全区域触发方式，比如整个商品卡片或多媒体封面，将整个容器或整行块状信息设定为点击热区，这样做也符合菲茨定律，即目标越大，点击越容易，体验越流畅。
一般在全交互流程的设计中，会采取
分级触发
策略：
- 比如导航或者查看类行为，就使用全区域触发，比如点击整个SKU卡片后进入详情页。
- 到了交易类或者承诺类行为，就要保留显性的button，例如涉及支付或不可撤销的删除，这种场景为了增加用户的确认感与掌控感，依然需要显性的button来增加摩擦力。
2.2.4流式体验：将等待转化为“正在发生”
由于大模型生成内容需要时间，容器不能像传统 App 那样瞬间加载，也不能让用户看着空白屏幕干等。打印机式的流式输出+骨架屏的方式，是主流前沿的AI软件常用的方式。
一般说起加载，大家都会想到传统的加载动效或骨架屏，但是在Chatfeed 中这种方式又显得有点呆不够智能。单纯的骨架屏需要确定性的页面，比如电商详情页，它需要预先知道内容的布局和尺寸。
但在 Chatfeed 中，AI 生成的内容（如文本长度、图片数量、卡片类型）在生成前是
不确定
的。因此，在 AI Chatfeed 中，我们的“流式体验”设计需要分层处理，并引入“基于模板的骨架”概念。
简单来说就是区分
内容类型
和
容器类型，
并依此采用两种不同的设计策略。
策略1：内容类型尚未确定（纯文本 / 思考中）
对于纯文本、或 AI 正在“思考”尚未确定容器类型时，我们不使用骨架屏，而是依赖于动态流畅的过渡
- 打字机效果：将用户的等待转化为阅读，让文本内容逐字出现，给用户一种正在实时生成而非卡顿的感知。文本气泡的高度尺寸应支持动态平滑高度，避免文本内容增加时，整个气泡边缘生硬地跳动。
- 动态高度的平滑过渡：当容器内容逐渐生成时，容器的高度和 Chatfeed 的滚动位置必须平滑过渡，防止用户感到画面抖动或者遮挡。
策略2：容器类型已知、生成时间较长
例如：文生图/视频/代码，容器是固定的，生成时间长，所以用骨架屏。
这类容器的
类型
是固定的，前端可以提前渲染其
布局骨架
。更重要的是，它们的
生成时间长
，骨架屏是
用户体验的必需品
，用来消除等待焦虑。
特例：商品 SKU 场景：追求极速，可以跳过骨架屏。
SKU 场景追求的是
对话内转化
。如果系统优化得当（需要技术团队非常给力），数据传输极快，跳过骨架屏能减少用户在 UI 元素上的等待时间，将用户注意力直接引向商品信息与购买入口，最大化转化效率。这一策略在部分即时推荐型 AI 应用中已有成熟实践。比如美团旗下小美app的AI推荐。
小结：
容器常见问题避坑指南
设计一个 Chat 界面似乎是最简单的工作——找一套成熟的 IM（即时通讯）UI 库，抄一下微信或飞书的气泡样式，任务似乎就完成了。
但当你真正把产品落地，你会发现体验一言难尽，比如：排版混乱、信息过载、交互断层。
核心原因在于：
AI Chat 不是人与人的对话，而是人与机器的协同。
我们不能简单照搬传统 IM 的设计范式，而是要理解 LLM的特性，这样才能更好的驾驭它。
3.1样式失控：当精美的设计系统遇上 AI 的“纯文本”
这是所有设计师在落地环节遇到的第一个痛点。我们在 Figma 里定义了完美的
H1、Body、Caption 字号
，精心调试了
字重
与
行高
。但在实际开发中，AI 输出的是一段没有任何 HTML 标签的纯文本。
结果就是：
该强调的重点没加粗，该分行的标题挤在一起，关键数据淹没在文字海洋中。
用户读起来非常累，甚至觉得产品很“粗糙”。这不仅仅是 UI 问题，而是
PE与前端工程的脱节
。AI不知道你的设计系统，它默认只会吐出文字。
要解决这个问题，设计师必须
跨界思考
：
- PE 侧（定义规则）： 在系统提示词中，强制要求 AI 使用 Markdown 语法。例如：关键结论必须用“**”加粗，标题必须用“#”标记。
- 前端侧（严格映射）：不要直接渲染 Markdown，而是编写解析器，将特定的 Markdown 标记“翻译”成设计系统里的样式组件。
用个简单的流程图来帮助大家理解：
然后是有规则和无规则的对比：
3.2视觉抖动：流式输出带来的焦虑感
为了缓解等待时间，AI 产品通常采用打字机效果逐字输出。这看起来很酷，但如果不做防抖设计，在处理复杂内容时是个灾难。
当 AI 正在生成表格、代码块或长列表时，由于高度无法预判，会造成聊天气泡会忽大忽小，页面滚动条疯狂跳动。用户的眼睛被迫跟着屏幕上下“震动”，产生极强的视觉疲劳。
- 高度预判：给容器设置一个合理的最小高度，避免初始跳动。
- 骨架屏：当识别到 AI 即将输出复杂组件（如图表、代码、表格）时，前端应先渲染一个灰色的骨架占位符，等内容缓冲一定量后再平滑替换。
3.3长篇大论病：不重要的统统折叠好的
AI为了确保逻辑完整性和准确性，会加入大量的
话痨属性
内容，比如步骤、注释、思考过程等，这在用户只想看最终答案时就变成了“噪音”或“信息墙”。还有就是在代码生成、长篇分析报告、需要引用原文和推理等场景。
一般这些信息对用户来说是无用的，但是因为各种原因（比如合规/可信），又必须展示，那就需要把容器进行
折叠化处理
。
上面的截图中，灵光的H5容器其实并不是一个非常好的案例。因为它最大化后，返回上一级是一个返回按钮，而不是最小化按钮，从视觉体感上给人感觉这不是一个窗口最大化，而是一个新页面。
这里要记住一个Chatfeed 核心的设计与体验要点：
所有容器的行动和信息展示，尽可能的在一个页面（或当前视图）完成，避免跳页。
因为
Chatfeed非常强调“流（Flow）”和“沉浸感”
，
跳页会破坏这种沉浸感，让用户感觉像是从对话中被“拉”了出来。
因此，我们需要尽可能的使用折叠、非模态弹窗与模态弹窗来解决内容延展的问题。
3.4被忽视的“编辑”：AI是工具，不是笔友
在微信里，你发出去的消息就是泼出去的水。但在 AI交互中，
“修改”是常态。
很多设计师或产品经理忽略了这一点，导致用户如果想微调提示词，必须复制上一条内容 → 粘贴 → 修改 → 再发送。这种体验非常笨重。
因此要允许用户直接点击自己已发送的气泡进行修改，并触发重新生成。
不过需要注意的是，有些产品是只允许用户对已经发送过的信息修改一次，比如灵光。而有的，则是没有做修改限制，比如豆包。这里面没有绝对的“更好”，只有更适合特定产品定位和目标用户的设计。
灵光可能更多倾向于
专业、效率和严谨性
，因此通过限制来引导用户“想清楚再问”或“另起一行”。豆包可能更注重
用户的自由、流畅度和高频交互
，通过无限制编辑来提升用户在不同 Prompts 间切换的效率。
结语
设计 AI Chat容器，本质上是在设计一种
新的“人机关系”
。
它不再是单纯的信息传输，而是信息的生成与协同。作为设计师，我们不能止步于画出好看的 UI，更需要深入理解大模型的技术特性（如 Token 限制、Markdown 输出、幻觉问题），才能设计出真正好用、可控的 AI 产品。
45
举报
声明
73
分享
相关推荐
评论你的想法~
表情
喜欢TA的作品吗？喜欢就快来夸夸TA吧！
推荐素材
你可能喜欢
相关收藏夹
登录注册
45登录即可同步推荐记录哦
73登录即可加入我的收藏
评论登录即可评论想法
分享分享