改 3 处代码，让 AI 操作起你的 React 界面：Tambo AI 生成式 UI 上手笔记-北京尧图网络

改 3 处代码让 AI 操作起你的 React 界面Tambo AI 生成式 UI 上手笔记【免费下载链接】hydra-aiGenerative UI SDK for React项目地址: https://gitcode.com/GitHub_Trending/hy/hydra-aiTambo AI前身 hydra-ai是面向 React 的生成式 UI 工具包用 Zod schema 描述组件的 propsAI 就能替你选组件、填参数并渲染到页面里。我维护过几个接 LLM 的聊天应用最磨人的地方都一样AI 只动嘴不动手。用户说看看杭州仓的库存你得手写判断逻辑决定弹哪个图表、数据从哪来。Tambo 的思路是把这个决策权交给 AI——你声明我有哪些组件、各接受什么参数它自己挑、自己填、自己渲染。 AI 怎么知道你的组件长什么样每个组件的注册就是四样东西name、description、component外加一个用 Zod 写的 propsSchema。schema 相当于一页纸的组件说明书props 叫什么、什么类型、哪个必填全部写死。AI 拿到用户请求后先挑组件再生成一份符合说明书的 props 对象你的组件拿对象渲染。它看不到 JSX只看到这份说明书。const components [ { name: InventoryChart, // AI 可见的组件名 description: 柱状图展示各仓库剩余库存, component: InventoryChart, propsSchema: z.object({ // Zod schema 给 AI 的填参说明书 data: z.array(z.object({ warehouse: z.string(), stock: z.number() })), }), }, ]; TamboProvider apiKey{KEY} components{components}ChatPanel //TamboProvider根组件用 TamboProvider 包住API Key 和组件列表从这一处传进去整个应用就具备了生成式渲染能力。生成式和交互式组件边界在哪两类组件的生命周期不同。生成式组件是一次性的AI 生成 props、渲染、结束适合图表、报表卡这种纯展示内容。交互式组件要用 withInteractable 包一层它会在对话里一直活着AI 之后还能改它的状态。const InteractableBoard withInteractable(ScheduleBoard, { componentName: ScheduleBoard, // AI 引用它用的名字 description: 项目排期看板支持增删里程碑, propsSchema: z.object({ milestones: z.array(z.object({ title: z.string(), due: z.string(), done: z.boolean(), })), }), });上面这个动图展示的是交互式组件的典型用法用户在对话里说帮我润色这段邮件AI 直接改掉了已挂载组件里的文本而不是重新渲染一个新卡片。区别类似海报和白板海报印一次就挂墙上了白板能反复擦写。看板、表格、任何有持续状态的东西走 withInteractable纯展示走生成式。这张截图是一次典型的生成式渲染用户只说给我一个能做的食谱AI 查完可用食材后直接产出这张卡片包括份数调节这样的可交互细节。从零接入要改哪几个地方一共四步脚手架建应用、选部署方式、根组件挂 Provider、用 hooks 接输入和线程。建应用用 npm create tambo-app 一条命令出脚手架然后在项目里跑 npx tambo init 完成初始化。第三步就是上面那个 TamboProvider把组件以及后面的工具、MCP 配置都从根上注进去。第四步输入框和会话流交给 useTamboThreadInput 和 useTamboThread前者拿 value、setValue、submit、isPending 管输入区后者拿 thread 对象驱动渲染。这两个 hook 把和后端的通信、状态管理都吞掉了你只写 UI。Cloud 托管和自托管怎么选验证想法选 Cloud数据不能出内网才考虑自托管。Cloud 有免费档不维护服务器API Key 在控制台直接发自托管要自己拉起后端仓库里带 Dockerfile 和 docker-composeSELF-HOSTING.md 有逐步说明。判断标准很清晰Cloud 走验证自托管走生产且数据敏感的场景。怎么让 AI 拿到组件之外的数据和能力组件只解决渲染AI 要调接口、查数据库得再加三样东西MCP、本地工具、页面上下文。接 MCP 外部数据源MCP 是把外部数据源接进来的标准通道每条配置就三个字段。在 TamboProvider 的 mcpServers 里写 name、url 和 transportMCPTransport.HTTP 或 SSEAI 就能直接调用那个服务端暴露的工具。比如接一个 Supabase 的 MCP 服务用户在对话里问我有哪些项目AI 会去查库再把结果渲染成卡片——数据库的活全在服务端完成前端不写任何查询接口。这段录屏演示的就是上面的链路左侧是自然语言对话右侧的卡片数据来自 AI 通过 MCP 查到的数据库内容。本地工具函数与页面上下文轻计算直接注册本地工具比专门起一个 MCP 服务省事。每个工具带 name、description、实现函数和 input/output 两个 schemaAI 可以在浏览器端直接调用。注册一个查 SKU 实时库存的工具后用户问SKU-8821 还剩多少AI 自己调、自己答。容易被忽略的是 contextHelpers把当前页面、选中项这类状态注入 AI 的视野。知道用户选中了哪几行把这条的截止时间改到周五才有明确所指缺了这一步AI 只能靠猜。TamboProvider apiKey{KEY} components{components} contextHelpers{{ // 把当前页面和选中行作为上下文喂给 AI page: () ({ key: page, value: location.pathname }), selected: () ({ key: skus, value: rows.map((r) r.sku).join(, ) }), }} /组件不够写去哪拿现成的官方组件库 ui.tambo.co 有一批现成的生成式 UI 组件表格、图表、表单都有可以直接复用也可以读它们的实现当参考。仓库里对应的源码在 packages/ui-registry/一个组件一个目录propsSchema 怎么设计、description 怎么写看现成的比看文档快。起步阶段建议先改两三个库里的组件跑通再动手写自己的。这套方案适合什么场景、坑在哪结构化结果最吃香模糊交互最吃亏。仪表盘、排期看板、数据表格、表单这类能被 schema 描述的结果用它收益最大。三个边界要提前说清。第一交互逻辑越细、越依赖上下文判断AI 的把握越小别指望它决定所有布局细节关键路径还是留确定性的代码。第二description 写得含糊是 AI 选错组件的头号原因两个用途相近的组件描述里必须把区分点写明白。第三交互式组件的状态改起来走的是同一套 schema涉及写操作的高风险场景自己加一层校验再落库。今晚就能动手的一步挑你项目里一个列表组件用 withInteractable 包一层注册进 TamboProvider然后在对话里说一句加一条你会立刻看到原本要自己写的那段映射逻辑少掉了多少。延伸阅读官方文档示例项目组件注册表源码【免费下载链接】hydra-aiGenerative UI SDK for React项目地址: https://gitcode.com/GitHub_Trending/hy/hydra-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

改 3 处代码，让 AI 操作起你的 React 界面：Tambo AI 生成式 UI 上手笔记

相关推荐

LangChain4j 集成 Valkey：基于 HNSW 向量索引的 Java Embedding Store 实战

Zephyr 在 Armfly STM32H743XIH6 开发板上的移植支持与实战指南

STM32H7无阻塞驱动有方N58 4G模块：HAL库中断接收+环形缓冲+AT状态机

更多资讯

OpenSRE Telegram 网关部署实战：把聊天机器人变成你的 AI SRE

用Docker部署iVentoy搭建PXE网络批量装机平台全指南