我先说个真实感受。
第一次看到 Tambo 这个项目的时候，我没有那种“哇，好牛逼”的兴奋感。
相反，是一种很微妙的不舒服。
不是技术看不懂的那种不舒服，是那种——
“好像哪里不对劲，但又说不上来”的不舒服。
后来我想明白了：
它碰的，是前端最后一块“还牢牢握在手里的东西”。
一、UI，本来是我们最后的安全区
这两年 AI 干了很多事：
• 写代码
• 补单测
• 改 bug
• 甚至帮你写 PR 描述
但 UI 呢？
UI 一直是个“硬骨头”。
不是 AI 不会画，而是：
• UI 不只是展示
• 是状态
• 是交互
• 是时序
• 是用户下一步“还能不能点”
说白了， UI 是逻辑和感受纠缠在一起的地方 。
这也是为什么到今天，大多数 AI 还停留在：
“我给你一段 JSX，你自己接着改。”
而 Tambo 干了一件更激进的事。
它不“建议 UI”，
它 直接生成并驱动 UI 本身 。
注意这个动词：
不是写代码，是 操控界面 。
二、Tambo 到底在干嘛？别急着兴奋
如果只看一句话介绍，你可能会觉得它是：
“一个用自然语言生成 React UI 的 SDK”
听起来是不是有点像玩具？ 我一开始也是这么想的。
直到我认真翻了一下它的设计。
Tambo 的核心，不是生成 JSX。
而是三件事：
1. 你把组件注册给 AI
2. AI 决定什么时候用哪个组件
3. 组件不是一次性渲染，而是可持续存在、可被更新的
这第三点，很多人会忽略，但它非常关键。
三、真正让我警惕的，是 “Interactable Components”
在 Tambo 里，有一种组件叫 Interactable Components 。
什么意思？
不是：
AI → 生成 UI → 完事
而是：
AI → 生成一个“活着的组件”
→ 用户操作
→ AI 根据状态继续更新它
比如：
• 一个购物车
• 一个图表
• 一个任务列表
• 一个搜索结果面板
这些东西一旦生成，就 不是文本了 ，
而是你熟悉的那种：
• 有 props
• 有 state
• 有事件
• 有生命周期的 UI
区别只在于：
“谁在控制它？”
答案是： AI。
这时候我第一次意识到一件事：
这已经不是 Copilot 的升级版了。
四、这一步跨过去，意味着什么？
我们以前的开发链路是这样的：
需求 → 人脑 → 代码 → UI → 用户
现在 Tambo 提供的是另一条路：
意图 → AI → UI → 用户 （人只负责把“能力”提前注册好）
你有没有发现一个变化？
人，从“执行者”，变成了“能力提供者”。
你不再写“页面逻辑”， 你写的是：
• 这个系统“能展示什么”
• “允许被怎样展示”
• “哪些组件是安全的、可信的”
剩下的，由 AI 决定。
这一步一旦接受， 很多原本默认的前端工作，会开始动摇。
五、那前端是不是要完了？
先别急。我从来没说过前端已死
。
我不觉得这是“前端完蛋论”，我觉得是前端有了新的生机
且我非常确定一件事：
UI 不再是“人类专属操作区”了。
以后区分前端水平的，可能不再是：
• 你 CSS 多熟
• 你组件封装多优雅
而是：
• 你如何“定义系统的 UI 能力边界”
• 你是否能设计出 AI 不容易犯错的组件体系
• 你能不能预判：AI 在什么地方一定会乱来
换句话说：
你不是在写页面，你是在给 AI 设栏杆。
这活儿，比写页面难多了。
六、我反而开始理解一件事
很多人现在说：
“AI 还差得远，做不了复杂交互。”
这话没错。
但 Tambo 这种项目，让我意识到一个趋势：
AI 不需要一次性做到 100 分。
它只需要：
• 接管 30%
• 40%
• 最容易被标准化的 UI 决策
剩下的，人慢慢退。
历史上所有“角色变化”， 都不是一夜完成的。
七、最后一句，不是结论
我不打算在这里下结论。
我只是想说一句心里话：
如果你还觉得“UI 一定得人写”，那你可能低估了变化的速度。
Tambo 不是终点。 甚至未必是赢家。
但它很清楚地指向了一个方向：
AI，已经开始碰 UI 这条线了。
至于你是选择忽略，
还是提前适应——
那就是另一回事了。
