最近有个趋势越来越明显：前端工程师看着 Copilot、Cursor 生成的 UI 代码，开始焦虑自己是不是要被替代了。

我觉得这个焦虑方向搞错了。真正值得关注的事情，不是 AI 写的代码比你好，而是 AI 可能根本不需要写代码了。

谷歌刚发布的 A2UI v0.9 就是这个方向上的一步。A2UI 全称 Agent-to-UI，是一套与框架无关的标准，让 AI 智能体声明 UI 意图，由 Web、移动端、桌面端原生渲染。关键词是"声明意图"——AI 不需要生成 HTML、CSS 或组件代码，它只需要说"我需要一个什么界面"，平台自己搞定渲染。

这件事值得认真聊聊。

AI 生成代码的真正问题，不是代码质量

现在 AI 写前端代码的方式，本质上是"生成一堆代码，人来兜底"。Copilot 也好，Cursor 也好，甚至那些号称能生成完整页面的工具，都在解决同一个问题：怎么让生成的代码能跑起来。

但跑起来只是最低标准。在生产环境里，一段前端代码要真正"能用"，得跟已有系统严丝合缝地集成：用团队的设计系统、符合品牌规范、支持无障碍访问、不超标性能预算、跟现有状态管理兼容、能扛住国际化。

AI 不知道这些约束。它生成的每一段代码都是"从零开始"的——没有设计系统的约束，没有组件库的上下文，没有历史包袱的考量。所以 AI 生成的代码看起来像模像样，集成起来全是坑。

这不是模型不够聪明，是问题本身不对。让 AI 生成能直接用于生产的 UI 代码，本质上是在让 AI 解决一个只有在这个团队、这个项目、这个技术栈里待了三年的人才能解决的问题。

"声明意图"比"生成代码"聪明在哪

A2UI 换了一个思路。不让 AI 写代码，让 AI 表达它想要什么界面。这个转变看起来不大，但底层逻辑完全不同。

打个比方。以前 AI 的工作方式是：厨师给你写了一份菜谱，你得自己买菜、切菜、炒菜、摆盘。A2UI 的方式是：厨师只说他想要一道什么样的菜，厨房团队按照标准流程做出来。厨师不需要知道你的灶台在哪、调料怎么摆。

这个方案的前提是：你得有一个足够完善的"厨房"——也就是完整的组件库和设计系统。AI 声明的意图最终要映射到你已有的组件上。只要你的设计系统足够完善，AI 生成的 UI 自动就是高质量的：无障碍合规、性能达标、品牌一致，因为这些能力已经内置在渲染层了。

从架构角度看，这其实是把"生成"和"渲染"彻底解耦了。AI 负责理解用户需要什么界面（这是 AI 擅长的），渲染引擎负责把意图变成像素（这是前端框架擅长的）。各司其职，互不越界。

前端工程师该紧张吗

我觉得应该有一点紧张，但不是那种"我要失业了"的紧张。

先说一个事实：前端工程师的核心价值，过去十年一直在迁移。从写 HTML/CSS，到用框架写组件，到搭设计系统，到做工程化基建。每一轮变化，都在往更高抽象层走。A2UI 做的事情，只是把这个抽象层又往上推了一步。

如果 AI 不需要写 UI 代码了，前端工程师的价值在哪？在设计系统。在渲染引擎。在组件架构。你得搭建那个能把 AI 意图变成高质量界面的"厨房"。这件事，AI 目前做不了。

换个角度想：过去你做的是"把设计稿翻译成代码"，以后你做的是"设计一套让 AI 能直接用的渲染系统"。前者是执行层，后者是架构层。这其实是价值升级。

但这有一个前提：你得有能力做架构层的事。如果你的日常还是"接到需求，写页面，提测，改bug"，那确实会面临压力。因为这个循环正在被自动化工具蚕食，而 A2UI 这类方案的出现，意味着连"写页面"这个动作本身都可能被绕过。

谷歌为什么选择"框架无关"

A2UI v0.9 有一个值得关注的设计决策：框架无关。它不是另一个 React 组件库，也不是 Tailwind 的扩展，而是一个标准协议层。

这说明谷歌判断的终局是：AI 生成 UI 这件事，不应该被绑在任何特定框架上。今天流行 React，明天可能换别的，但 AI 与 UI 之间的协议应该是稳定的。

如果这个判断对了，前端框架之争的格局会发生微妙变化。框架本身的重要性在下降——当 AI 不直接写框架代码时，你用 React 还是 Vue 对 AI 来说没区别。真正重要的是谁定义协议、谁的渲染引擎质量更高。

这让我想起 Web 早期的浏览器大战。最后赢的不是哪个网站，是标准制定者。协议层的东西一旦形成共识，迁移成本极高，生态锁定也最深。

没那么美好的一面

A2UI 的落地门槛不低。

"框架无关的声明式 UI"听起来很美，但前提是你要有一套足够完整的组件体系和设计系统。大部分公司嘴上说自己有设计系统，实际上 Figma 文件散落各处，组件库三年没维护，设计规范靠口耳相传。这种状态下引入 A2UI，等于给混乱加了一层协议包装。

另一个问题是表达力的上限。声明式模型天然受限于预定义组件的能力范围。如果你的组件库没有某个复杂交互——比如带虚拟滚动的数据表格、带行内编辑的表单——AI 再怎么声明意图也渲染不出来。这时候就得回退到"生成代码"的老路上。

还有一些实际问题：协议层的调试怎么做？AI 声明了一个意图，渲染出来的效果不对，是 AI 的问题还是渲染引擎的问题？这个链路排错可能比直接看代码更头疼。

0.9 版本大概率解决不了所有这些问题。但方向本身是对的。

这件事的底层趋势

跳出 A2UI 本身，我看到的是一个更大的趋势：AI 与前端的关系，正在从"AI 写代码"变成"AI 表达意图"。

这个趋势是确定的。因为"写代码"是手段，"表达意图"才是目的。当手段可以被更好的方式替代时，它一定会被替代。

A2UI 未必是最终标准，0.9 版本也未必能大规模落地。但它提出的范式——AI 不写代码、声明意图、平台渲染——这个模式大概率会成为未来 AI 与 UI 交互的主流方式。

对前端工程师来说，与其焦虑 AI 写的代码比你好，不如想想：当 AI 不再需要写代码时，你能提供什么 AI 不需要提供的东西。

答案大概率是：那个负责把 AI 意图变成高质量界面的系统本身。