每次做 AI 应用，聊天界面都得重新写一遍：
消息气泡 推理展示 代码高亮 附件上传
这些组件单独拿出来都不复杂，但凑在一起就够你消耗一个迭代。更麻烦的是，大多数聊天 UI 库是黑盒，npm install 完毕就看不到源码了，想改个圆角都要翻文档找 props。
Vercel 显然也受够了这种循环。他们推出的 AI Elements，严格来说不是一个组件库，而是一个组件派发系统。它基于 shadcn/ui 的代码分发模式，CLI 直接把源码复制到你的项目目录里，你怎么改都行，Vercel 只管维护注册表中的上游版本。
更关键的是，这套组件是专门为 Vercel AI SDK 设计的：
-
对话容器 -
消息流 -
推理面板 -
工具调用可视化
18 个组件覆盖了 AI 聊天界面的绝大多数场景。而且每一个都能和 useChat hook 无缝对接，不需要自己写胶水代码。
说真的，AI Elements 解决的问题很具体：让你从零搭建 AI 聊天 UI 的痛苦中解脱出来，同时不绑架你的控制权。源码在你手里，样式由你决定，逻辑由 AI SDK 接管。这篇文章就把安装、用法、设计思路和适用边界捋一遍，帮你判断这东西值不值得用。
环境准备
前提条件不算复杂，但有几项绕不开：
| 前置条件 | 要求 |
|---|---|
| Node.js | 18 或更高版本 |
| 框架 | Next.js（App Router） |
| AI SDK | 已安装在项目中 |
| shadcn/ui | 已初始化（CLI 会自动处理缺失项） |
| 包管理器 | npm / pnpm / yarn / bun 任一 |
安装命令只有一行：
npx ai-elements@latest
这个命令会做四件事：检测你的包管理器，从注册表拉取组件索引，用 shadcn CLI 把组件源码写入你的项目目录，然后把必要的依赖项一起装上。整个过程很快，网络正常的话十几秒完事。
装完可以快速验证一下。打开 components 目录，应该能看到一个 ai-elements 子文件夹，里面有 conversation.tsx、message.tsx、prompt-input.tsx 等文件。这些都是标准 shadcn 风格的组件，用 cn() 做类名合并，forwardRef 做 ref 转发，Radix 做无障碍基础层。如果你之前用过 shadcn/ui，打开这些文件不会有任何陌生感。
容易踩坑的地方有两个。一个是 shadcn 配置必须用 CSS Variables 模式，如果用 Tailwind 原生色值会丢样式。另一个是路径别名，tsconfig.json 里得配好 @/* 映射，不然 import 会报模块找不到。这两个问题在 GitHub Issues 里出现频率不低，装完第一步最好先确认一下。
操作流程
AI Elements 的使用流程和 shadcn/ui 组件几乎一样：
-
安装 -
导入 -
组合 -
定制
区别在于，这些组件从一开始就是为 AI 对话场景设计的，内部结构和 props 都围绕 AI SDK 的数据模型做了适配。
先看一个最基础的消息列表。核心用法是三层嵌套：Conversation 做容器，Message 做每条消息，MessageContent 和 MessageResponse 分别负责内容区和回复体的渲染。AI SDK 的 useChat hook 返回的 messages 数组直接喂给 Message 组件：
import { useChat } from "@ai-sdk/react";
import {
Conversation,
ConversationContent,
} from "@/components/ai-elements/conversation";
import {
Message,
MessageContent,
MessageResponse,
} from "@/components/ai-elements/message";
const { messages } = useChat();
这看起来简单，但背后做了不少事。Message 组件根据 from 属性自动切换 is-user 和 is-assistant 的样式类，用户消息靠右、AI 消息靠左，不需要手动写条件判断。MessageResponse 负责渲染 AI 回复的 streaming 内容，增量的 token 会自动追加进来，不会有闪烁或跳变。
更复杂一点的场景是推理过程展示。Reasoning 组件专门处理 AI SDK 的 reasoning 类型 parts，默认折叠，点击展开后能看到模型的思考链。这个交互在 Claude 的回复中特别常见，AI Elements 把展开和折叠、loading 状态、内容溢出处理都封装好了。
Tool 组件类似，用来可视化 AI 调用了什么工具、传了什么参数、返回了什么结果。对调试和用户信任都很有价值。PromptInput 则是一个完整的输入系统，Textarea 做自适应高度，Submit 自动切换提交和停止按钮，ActionAddAttachments 提供文件上传入口，还有模型选择器和附件预览组件。一套下来，几乎覆盖了生产级 AI 输入框需要的所有交互。
关键设计
AI Elements 最值得说的不是某个组件长什么样，而是分发方式。和绝大多数 npm 组件库不同，CLI 直接把源码复制到你的项目里，而不是把编译后的代码藏在 node_modules。这个选择的影响比看起来大得多。
它解决了一个很实际的矛盾：AI 聊天 UI 是高度定制化的需求，但同时又有大量标准化模式。传统的方案是 npm 包加一堆 props 配置，组件越来越臃肿，props 文档越写越长。而 AI Elements 的方案是你直接改源码，想删按钮就删，想换样式就换。
| 维度 | 传统 npm 包 | AI Elements（shadcn 模式） |
|---|---|---|
| 源码可见性 | node_modules 黑盒 | 项目目录中可读可改 |
| 定制方式 | props 配置 | 直接改源码 |
| 版本升级 | npm update | 手动重新 add |
| 失控风险 | 低 | 高（改坏了得自己兜底） |
但这个模式也有代价。你改了组件之后，上游更新就没法无缝升级了。Vercel 清楚这一点，从文档的设计来看，他们的定位是给你一个起点，而不是让你依赖它。意味着你需要对自己的修改负责，不能指望一个 npm update 解决所有问题。
另一个有意思的设计是组件和 AI SDK 的耦合程度。AI Elements 没有把 AI SDK 作为硬依赖装进组件里，所有数据都通过 props 传入。Message 只关心 from 是什么角色，不关心这个消息是 useChat 给的还是你自己造的。你可以把 AI Elements 和任何 LLM 调用方案搭配使用，只要能把数据组织成它需要的格式。这种”松耦合但深度适配”的思路，在 AI 工具链里不算常见。
使用场景
AI Elements 最对口的场景是两类：从零开始的 AI 聊天产品 MVP，以及已有聊天界面但需要补全高级交互的项目。
第一类场景里，AI Elements 的价值是把你从 UI 层彻底解放。配合 AI SDK 的 useChat 和 streamText，一个带 reasoning、tool call 可视化、附件上传的聊天应用，后端加前端加起来可能不到 200 行代码。这对快速验证 AI 产品想法的团队来说，省下的不是一个 sprint，是一整轮的造轮子时间。
第二类场景更有意思。如果你的项目已经有一套自己的聊天 UI，但缺推理面板或工具调用可视化，AI Elements 可以单独安装某个组件来补位：
npx ai-elements@latest add reasoning
npx ai-elements@latest add tool
这种按需组装的能力，让它能渐进式接入现有项目，不需要整体替换。
不过 AI Elements 的边界也很明确。它的组件高度依赖 AI SDK 5 的 UIMessage 数据格式，也就是 parts 数组结构。如果你用的是其他 LLM SDK，或者还在用 AI SDK 4，需要额外写一层转换。另外它目前仅支持 Next.js App Router，Pages Router 和 Remix 等其他框架暂时不在兼容范围内。社区反馈中有不少人在问其他框架的支持，但从目前的 roadmap 来看，短期内这个限制不会放开。
洞察与反思
看完 AI Elements 的整体设计，有一个判断是比较确定的：它代表了组件分发的一种新共识。shadcn/ui 把”复制源码而非安装依赖”这个模式带火之后，AI Elements 是第一个把同样思路大规模应用到 AI 专用组件上的项目。18 个组件，每个都是直接进你仓库的可编辑文件，这种”拥有感”是 npm 包给不了的。
但从另一个角度看，这套方案也在制造新的碎片化风险。每个项目都有自己的组件副本，意味着生态里会分裂出无数个略有差异的 AI Elements 变体。Vercel 可能认为这是可接受的代价，毕竟他们更关心的是让开发者更快地接上 AI SDK，而不是维护一个统一的 UI 标准。问题是，如果用户各自改出了不兼容的版本，社区贡献和经验分享的流通性会打折扣。
还有一个信号不能忽视。AI Elements 替换了 Vercel 之前的 ChatSDK，而 ChatSDK 是一个更”开箱即用”的方案。从封装到解封的转向，说明 Vercel 认为 AI 聊天界面的需求已经分化到不适合再统一覆盖了。类似从 jQuery 到 React 的范式转移：界面复杂度到了一定程度，给你一个完整的房子，不如给你一箱建筑材料。
Tool 组件值得单独拿出来说。AI Agent 调用工具的可视化一直是个被低估的问题。用户看不到模型在后台做了什么，信任就很难建立。Tool 组件把调用链路可视化做得足够轻量，不需要额外的基础设施，这可能比组件本身更有行业价值。
资源地址
| 资源 | 地址 |
|---|---|
| 官网 | elements.ai-sdk.dev |
| GitHub | github.com/vercel/ai-elements |
| NPM | npmjs.com/package/ai-elements |
| Smithery | smithery.ai/skills/vercel/ai-elements |
总结
AI Elements 不是一个让你惊艳的东西。它不会生成内容，不会提升推理质量，不会让你的 AI 更聪明。它的全部价值在于消除一个反复出现的摩擦：每次做 AI 聊天都得重画一遍 UI。
如果你已经在用 AI SDK 和 shadcn/ui，这东西几乎没有上手成本。如果你在做 AI 产品的早期探索，它能帮你把省下的 UI 开发时间投入到更值得打磨的地方。它的局限性也很诚实：Next.js Only、AI SDK 5 依赖、改完源码后的升级路径不明确。但这些限制在使用场景里，多数情况下是可控的。
说到底，Vercel 做这件事的逻辑很清楚。AI SDK 是引擎，AI Elements 是车身。有了车身，更多人会选择这台引擎。作为开发者，你要不要上车，取决于你有多不想再手写一个聊天气泡。