大概半年前我把自己搭的一个智能体发给朋友试用。功能上确实没毛病能查天气、能算报销、帮人排日程模型的理解和推理都挺稳。但朋友玩了两分钟回了我一句“这不就是个高级点儿的AI聊天框吗”这句话我琢磨了好几天。后来终于想明白问题不是出在智能体的“脑力”上而是出在它“递东西”的方式上。一个只会往对话框里吐大段文字的Bot在用户眼里天生就是个聊天机器人离“产品”两个字差了十万八千里。直到我给它换上卡片界面这个项目才真正像是做出来的一款产品了。这篇文章就聊聊这段折腾的过程为什么纯聊天界面撑不起一个智能体、卡片界面到底解决了什么问题、以及我在coze、dify这类平台和自己写代码渲染两种路线下把卡片能力落地时踩过哪些坑。1. 先想清楚为什么纯聊天的智能体“不像个产品”1.1 用户眼里的“产品”到底是什么我自己做过几年工具类产品后来转做AI应用最大的感受是用户对一个东西像不像产品判断标准特别朴素。他们不看你的架构图也不关心你用的是哪个大模型就看三件事——打开以后能不能一眼看懂、能不能直接上手操作、操作之后有没有明确的反馈。聊天框恰恰在“一眼看懂”和“直接上手”上都很弱。用户打开一个纯聊天的智能体看到的是一块空白输入框连这个Bot能干什么都得靠打字去问。而一个产品形态的界面打开就能看到入口左边能选功能中间有卡片底部有按钮用户不需要思考就知道接下来可以点什么。这就是最核心的差异。聊天是“对话驱动”的产品是“界面驱动”的。智能体要想真正产品化就必须把一部分能力从“语言”里抽出来变成“界面元素”。1.2 聊天界面天生的三个短板我在几轮迭代中发现纯聊天输出有三个绕不过去的问题这也是促使我下决心做卡片界面的直接原因。第一个是信息密度低。智能体返回一段话描述天气“明天北京晴转多云最高气温18度最低气温7度空气质量良建议穿夹克。”这段信息用户得逐字读、自己提取。换成卡片温度数字、空气质量等级、穿搭建议分栏摆开一秒就能读完全部关键信息。人眼对结构化信息的处理速度远快于对线性文本的解析速度这不是玄学是设计里的基本常识。第二个是操作路径长。纯聊天场景下用户想完成一个“预订”类任务往往要在对话里反复打字确认。智能体问一句“你是要双人桌还是四人桌”用户就得回一句。一来一回五六轮才把信息收齐体验极其割裂。卡片可以一次性把“人数选择时间选择确认按钮”全部呈现在一个界面里把多轮对话压缩成一次点击。第三个是反馈感弱。你让智能体帮你订了个会议它在聊天框里回你一句“已帮您预订会议室”用户其实没有“事情办成了”的实感。但如果界面上弹出一张预订成功的卡片上面有会议室名称、时间、参会人列表底部还有“加入会议”的按钮这种确定性和仪式感是纯文字永远给不了的。一句话总结聊天框适合的是“开放式的对话”而不是“确定性的任务交付”。智能体一旦要承担具体任务就必须有任务化、结构化的呈现方式——这就是卡片的价值。2. 卡片界面到底解决了什么信息结构、确定性交互与产品心智2.1 卡片是一种“结构化表达”我一直觉得卡片本质上是“给智能体的输出加了一层Schema约束”。模型再聪明生成的内容也是自由文本而产品需要的是稳定格式。卡片让你把“模型输出的不确定性”挡在界面之外用固定的结构去承载内容。打个比方纯聊天输出就像同事口头跟你汇报工作说得再清楚也容易遗漏你要自己做笔记卡片界面则像一份排版好的报表主次分明该加粗的加粗、该标红的标红。同一份数据换了承载形式人的接收效率完全不一样。所以我做卡片界面的第一步不是写前端而是先给自己的智能体定义了一整套“输出协议”——什么场景输出什么卡片、卡片上有哪些字段、这些字段的顺序和优先级是什么。协议一旦定下来后面所有智能体的行为都会变得可控。2.2 三种最常用的卡片类型拆解见得多了以后我发现智能体场景下的卡片翻来覆去其实就三种类型其他的都是变体。第一种是信息展示卡。用于查询类任务比如查天气、查股票、查订单状态。卡面上把数字、状态、关键结论放最显眼的位置辅助信息收在下面。查快递的卡片物流状态“已签收”要有颜色标识签收时间写清楚后面再跟着运单号和物流轨迹。用户一眼扫过就拿到了最想要的信息。第二种是流程推进卡。用于多步骤任务比如预订、审批、下单。卡片里不仅包含信息还带了操作按钮用户点一次就往前走一步。我做得最多的是审批流卡片“张三提交的报销单(金额¥1280)”下面两个按钮“通过”和“驳回”点了以后卡片刷新状态。整个流程不需要用户输入任何文字全靠点击完成效率极高。第三种是决策辅助卡。用于需要用户在多个选项中做选择的任务。比如“帮你找到3家合适的餐厅”把三家店的关键差异——人均、评分、距离——并排展示用户点选一家再带出后续的操作。这种卡片在本质上就是把推荐系统里的对比表格搬进了对话里。2.3 卡片设计的三层模型信息层、动作层、状态层我后来总结出一套自己的设计模型把每张卡片都拆成三层写方案时不会乱。信息层是底子解决“这张卡要告诉用户什么”。我的约束是核心信息不超过三到四个字段超过就要做折叠或跳转。动作层解决“用户拿到这张卡能干什么”按钮最多放两个一个主行动一个次要行动三个以上按钮用户就会纠结。状态层解决“这张卡处于流程的哪个阶段”通过颜色、标识、禁用态来表达。举个例子一个“订单确认”卡。信息层展示商品、价格、地址动作层是“确认支付”和“取消”状态层则体现在卡片的底色和角落的小标签上——待支付是橙色已支付是绿色已过期是灰色。这三层想清楚后卡片的逻辑就非常清晰后续无论加什么类型的卡片都能套进这个框架里。3. 实操过程从零给智能体换上卡片界面3.1 第一步盘点智能体的高频输出场景动手前最重要的一步是先梳理你的智能体到底有哪些高频输出场景。我当时的智能体有八九个能力但经过埋点统计后发现用户最常用的是查天气、算报销、订会议室这三个。我没必要给所有能力都做卡片只需先把这三个场景的卡片做透就能覆盖80%的使用量。怎么梳理很简单把每次用户和智能体的对话记录翻出来找出用户问得最多的任务类型再为每个任务画出它的“信息清单”和“操作清单”。比如“查报销进度”信息就是金额、事由、当前审批到哪一层操作就是“催办”和“查看明细”。这两个清单就是后面定义卡片的原料。这一步很多开发者会跳过直接开始画UI。我建议别省因为卡片设计本质上是信息架构设计没有清晰的信息架构UI画得再漂亮也是空中楼阁。3.2 第二步选型——平台组件还是自研渲染卡片界面的实现路线我两条路都走过先说结论如果你用的是coze、dify这类现成的智能体平台优先用平台自带的卡片能力如果你是纯代码开发比如基于LangChain或自建服务那就走“结构化输出前端自渲染”的路线。以coze为例它提供了比较完整的卡片消息组件可以在编排节点里拼接字段无需写前端。dify在最新版本里也有类似的能力通过Markdown和结构化输出做呈现。平台的优点显而易见不用管渲染细节消息格式平台帮你兜底。缺点是样式和交互受限于平台提供的能力深度定制空间小而且要跟着平台版本走。我自己项目后期用的是自研方案大概长这样后端智能体不直接生成自然语言而是先输出一个结构化的JSON对象这个JSON交给前端渲染器渲染器根据卡片类型选择模板画成可视卡片用户点击卡片上的按钮时前端把动作回传给后端触发下一轮节点的执行。整体链路是智能体产出结构化结果 → 前端渲染 → 用户交互 → 结果回传。两种方案我都做过对比各有优劣。维度平台方案coze/dify等自研方案代码上手速度快拖拽配置即可慢需要前后端一起开发卡片自由度受平台组件限制完全自定义像素级控制交互闭环平台内置回调机制需要自己实现会话与回调管理部署形态一般托管在平台可完全私有化部署适合阶段快速验证MVP深度做产品、做品牌3.3 第三步定义卡片的消息协议JSON Schema自研方案的灵魂是消息协议也就是“智能体输出什么结构、前端怎么读”。我在这里踩过最大的坑是一开始协议定义得太随意字段命名不统一后面加卡片类型时改得欲仙欲死。所以建议把字段名、类型、约束条件一次性定死做成一个JSON Schema。我用一个订餐场景来做演示。用户说“帮我订明天中午2人位的川菜馆”智能体经过意图识别和数据库查询后输出的卡片消息大概是这个样子{ card: { type: booking_confirm, title: 预订确认, fields: [ { label: 餐厅, value: 蜀香居望京店, type: text }, { label: 时间, value: 2026-03-12 12:30, type: datetime }, { label: 人数, value: 2位, type: text }, { label: 预计人均, value: ¥120, type: text } ], actions: [ { id: confirm, label: 确认下单, style: primary }, { id: change, label: 换一家, style: default } ], state: awaiting_confirmation } }前端拿到这个JSON后根据type字段找到对应的卡片模板渲染标题、字段区域和按钮区。state字段控制卡片整体状态——待确认时高亮提醒确认后按钮置灰、状态标签变绿。这样设计的好处是智能体永远只负责“输出数据”界面永远只负责“呈现数据”双方解耦任何一端改动都不会牵动另一端。3.4 第四步前端渲染与服务端回调有了协议渲染层其实就不复杂了。最直接的做法是用React或Vue写一个轻量卡片渲染器内部维护一个type - Component的映射表。新增卡片类型时只需要新增一个组件并注册不用改核心逻辑。交互回调上我强烈建议引入“请求追踪ID”。用户点击按钮时前端把card_id、action_id、session_id一起post到后端。后端根据这三个参数定位到这个卡片是哪个会话中的哪条消息然后执行对应的动作。这里有个细节值得注意用户点击按钮后卡片应该立刻进入“处理中”状态按钮置灰、转圈后端拿到新结果后再刷新卡片。不做这一步用户手快了连点三次就会触发三次重复下单这是我在真实场景里踩过的坑。4. 卡片交互的细节打磨让用户真的去点4.1 默认值策略让用户少打字卡片界面虽好但如果每个按钮点下去都要求用户重新输入一遍信息体验还是会崩。我的经验是给卡片配一套“默认值策略”。还是拿订餐来说。用户点了“确认下单”后端执行预订后返回的新卡片应该直接把人数、时间、餐厅这些信息带出来用户不需要再输入。如果预订失败卡片上也不要只写一句“失败”而是直接把失败原因“该时段已满可选剩余时间如下”以列表形式呈现同时在每个可选项旁配上按钮。让用户在所有状态下都能“只点不敲”这是卡片交互的终极目标。4.2 兜底解析用户非要打字也不崩做了卡片不代表用户就会乖乖点按钮总有人习惯直接在输入框里打字。比如卡片下方明明有“换一家”按钮他非要自己敲“换个辣一点的”。这时候系统必须能兜住。我的做法是双轨并行一方面所有进入聊天的内容仍然走一遍模型解析识别用户的意图在高频意图命中时覆盖卡片上按钮对应的动作另一方面在卡片内部也放一个“自由输入”的入口用户点击后唤起输入框并自动带上上下文。两条路最终都汇入同一套动作处理逻辑。这样做保障了体验的底线——即便用户完全不点卡片智能体的核心能力也不会打折扣。4.3 移动端适配与无障碍卡片界面很容易忽略的一个问题是移动端。桌面端一行能放十个字段的卡片到了手机上可能挤成一团。我后期专门给移动端做了一套缩略态核心信息保留次要信息折叠成“展开详情”。适应下来发现移动端的卡片尺寸控制在“单手可点、一屏可读”的范围所有按钮高度不低于44像素点击区域足够大误触率明显下降。5. 常见问题与排查技巧实录5.1 卡片渲染不出来或白屏卡片白屏是我最初被坑得最惨的一块。排查了两天最后发现是后端返回的字段类型和前端Schema里的定义不一致——后端返回的price是个数字前端却按字符串解析直接抛异常。这类问题最好的预防手段是前端加个schema校验工具数据不合法时渲染一个带有错误信息的fallback卡片而不是让整个界面白屏。现象可能原因排查方法解决手段卡片白屏Schema类型不匹配打开控制台看报错增加数据校验和fallback卡片卡片没有按钮actions字段缺失查看后端返回JSON协议里把actions设为必填状态不刷新回调后没有requestAnimationFrame更新检查前端状态管理用轮询或长连接接管消息推送所有卡片长得一样type字段固定死了确认渲染映射表注册检查type传递链路5.2 按钮回调超时或重复触发回调超时的根子在于后端处理时间太长。比如某个智能体节点要调第三方接口动辄三五秒用户等得着急就再点一次于是重复下单。解决方法是“幂等键乐观UI”用户第一次点击后就给按钮加锁并显示加载态后端用card_id做幂等键同一个卡片的同一个动作方言简说——只处理一次其他直接返回“处理中”。5.3 卡片做了用户就是不买账这事其实是最扎心的。我有一个阶段花了不少精力把卡片做得极漂亮结果数据一看点击率不到10%用户大部分还是直接打字。后来复盘发现问题出在接入引导上用户根本不知道这个框里可以点。从那以后我吸取教训在对话开场白里就引导用户“你可以直接输入需求也可以点击下方卡片快速开始。”如果用户连续两轮打字智能体会主动推出一张“常用功能”卡片把入口摆到用户手边。几次之后点击率明显上来了。做功能很容易陷入“做了就行”的假象该做的引导和埋点一样都不能少。6. 从卡片到产品智能体产品化的剩余几块拼图6.1 会话状态与持久化卡片本质上只是交互层下面还有状态层。智能体要做到“像个产品”至少要保证用户刷新页面之后之前对话和卡片状态还在。我把会话状态持久化到数据库卡片状态也一起存下来。用户重进对话翻到历史消息时每一张卡片还能原样展现按钮状态也能还原。这一步的坑在于模型每次回复的消息都是动态生成的历史会话的卡片如果只存渲染后的HTML状态变更时不好更新。后来我改成双写——既存渲染结果也存底层的JSON结构。要更新时找到对应JSON重新渲染逻辑就干净很多。6.2 多智能体协同时的卡片编排项目后期上了多智能体结构不同节点由不同子智能体负责。这带来一个协调问题如果每个子智能体都各自输出一段自然语言用户的界面就会变成一场群聊大杂烩毫无产品感。我的解法是设立一个“卡片编排层”。子智能体之间不直接输出给用户只输出卡片JSON由编排层统一决定什么时候把哪张卡片展示给用户。比如数据查询智能体把结果整理成图表卡流程智能体把审批卡推到最前编排层可以做到“同一屏上多张卡片按优先级排列”。这其实就是把多智能体的协作从对话流抽象成了卡片流界面自然就稳定了。6.3 行为审计为什么卡片交互更利于追踪顺着上一小节说卡片交互还有一个容易被忽略的优势行为审计。纯文本聊天场景下想复盘“用户到底对这个答案满意吗”非常难你只能靠用户后续的一条转人工消息去猜。有了卡片之后用户的每一次点击都成为一条结构化日志。我们可以记录用户点击了哪个按钮、停留了多久、有没有二次修改参数。对于企业内的审批智能体与客服智能体这些日志本身就具备审计与合规价值。比如审批卡谁在什么时间点了“通过”一查日志就能定位。市面上热门的“智能体行为审计”说的其实也是这件事——你没法审计一段自由文本但你可以审计一组结构化的交互记录。最后再分享一点我自己私底下的习惯每次改完卡片协议我都会拿真实对话数据跑一轮回归把所有高频任务对应的卡片截图存档。这样改动一版我就能立刻发现“这张卡片比上一版丑了”“按钮位置变了”之类的回归问题。做AI交互产品千万不能只盯模型效果忘了界面稳定这两者本来就是同一件事的两面。