为什么 AI 写前端时,总是优先选择 React,而不是 Vue?

如果你在过去几个月里,高强度使用过 CodexCursor 或者是 Claude Code 等 AI 编程工具,你一定会察觉到一个让国内前端开发者极度不适的现象:

当你扔给 AI 一张设计图,或者一段自然语言需求,让它帮你生成前端组件时,如果不做任何额外的 Prompt 限制,它默认吐出来的代码,永远是 React 加上 Tailwind CSS🤔。

作为一个 Vue 开发者,你必须在提示词里反复强调:请使用 Vue3script setup 语法! 。但即便如此,AI 生成的 Vue 代码里,也经常会诡异地夹杂着 className,甚至试图在 template 模板层里写 map 映射。

在框架使用者眼里,这可能又是一场框架优劣的口水战。但我想讲的是,大模型这种压倒性的框架偏好,其实暴露出的是底层技术架构的根本性差异。


只是因为训练语料多吗?

当你抛出这个问题时,绝大多数人给出的答案是:因为 React 拥有全球最庞大的生态,在 GitHub 上的开源项目和代码语料远超 Vue。大模型吃进去的 React 代码多,吐出来的自然也就多。

这句话本身没错,但这只是一层极其懒惰的表象解释🤷‍♂️。

大模型本质上是一个基于概率的 Token 预测机器。它在生成代码时,不仅受语料数量的影响,更受语言结构(AST)纯粹性 的制约。真正让 AI 对 Vue 感到吃力并且频繁产出幻觉的,是两者在底层设计哲学上的巨大鸿沟🤔。


JS 纯粹性与 DSL 的认知负担

在我们人类程序员眼里,Vue 极度优雅。它的单文件组件(SFC)把 <template><script><style> 物理隔离,逻辑清晰,极度符合人类对网页结构的直觉认知。

但在大模型的眼里,Vue 其实是一个极其复杂的 DSL(领域特定语言)。

大模型最擅长预测什么?是标准的、图灵完备的常规编程语言(比如纯 JavaScriptPython)。

ReactJSX 表面上看起来是标签,但在 AST(抽象语法树)层面,它本质上就是纯粹的 JavaScript 函数调用。核心的控制流(if/elsemapswitch)完全遵循原生 JS 的语法规则。大模型在预测下一个 Token 时,上下文是高度连贯和内聚的👇。

tsx 复制代码
// 在大模型的使用,这根本不是 HTML,这只是一个标准的 JS 纯函数
export function UserList({ users }) {
  return (
    <ul>
      {users.length > 0 
        ? users.map(u => <li key={u.id}>{u.name}</li>)
        : <li>暂无数据</li>}
    </ul>
  );
}

Vue 则不同。大模型在生成 Vue 代码时,必须在脑海里强行维护两套完全割裂的上下文: 一套是基于 HTML 扩展的模板语法(v-ifv-forv-model),另一套是下方的 script setup 响应式逻辑。

vue 复制代码
<!-- 大模型在生成长组件时,极其容易在这里的模板层丢失数据映射 -->
<template>
  <ul>
    <template v-if="userList.length > 0">
      <li v-for="u in userList" :key="u.id">{{ u.name }}</li>
    </template>
    <li v-else>暂无数据</li>
  </ul>
</template>

<script setup lang="ts">
import { ref } from 'vue';
// 当代码超过 300 行,AI 很容易忘了上面绑定的变量到底是 users 还是 userList
const userList = ref([]);
</script>

当上下文长度超过几百行后,大模型极容易在 templatescript 之间的变量绑定上产生灾难级的幻觉。它可能会在模板里写出一个未经声明的 ref 变量,或者在脚本里写了一堆逻辑,却忘了通过模板指令去驱动视图。

人类更擅长处理结构隔离,而机器更擅长处理逻辑同源🖐️。


那组件物理拆分的阻力是什么?

在大模型的日常协作中,最深水区的痛点其实是代码的重构与拆分。

大模型写代码有一个通病:喜欢把所有的逻辑都塞进一个巨大的文件里。当这个缝合怪组件膨胀到上千行时,你必须命令它进行拆分。

React 里,拆分组件的成本极低。大模型只需要在同一个文件里,顺手多写几个首字母大写的 Function,就可以直接完成细粒度的逻辑抽离。这种按需内联拆分的能力,极其契合 AI 的线性文本生成逻辑。

但在 Vue 的生态里,创建一个新组件通常意味着必须在文件系统里新建一个 .vue 文件,并且要处理繁琐的 import 路径、父子组件 props 传递和 emits 事件分发。多文件并发生成和底层路径映射,恰恰是当前所有 AI 编程工具最容易翻车的软肋。

这直接导致了 AI 在写大型 Vue 项目时,代码极易走向失控。


前端组件的文本化(复制粘贴🤣)

最后,我们无法回避整个前端组件库生态的残酷站队。

在 AI 自动生成 UI 的时代,像 Shadcn UI 这种纯粹基于 Tailwind CSSRadix UI 的方案成为了绝对的统治者。为什么?因为它的组件根本不是作为一个 npm 依赖包黑盒存在的,而是可以直接被大模型阅读、复制并内联修改的纯文本源码

这种 代码即 UI 的模式,让 AI 可以直接透视并定制组件的每一个像素。而 Vue 生态里占据主导地位的(如 Element PlusAnt Design Vue),依然是沉重的全局安装包。大模型无法透视黑盒内部的代码,在遇到定制化需求时,只能绝望地去瞎猜文档配置参数😖。


在做技术选型时,我们往往会夹杂着太多关于好与坏的执念。

如果是完全由纯开发者主导开发,Vue 极低的心智负担、清晰的关注点分离,依然是中大型业务团队稳盘的绝佳利器。

但如果我们正在迈入一个由 AI 主导代码生成的新纪元,我们就必须面对残酷的现实:React 那种一切皆函数、一切皆 JavaScript 的纯粹性,确实极大地降低了机器的认知负荷

好了,今天写道这里吧🙌

相关推荐
京东云开发者1 小时前
GPT-5.6、ChatGPT Work 与 Codex 更新食用指南
前端
Cao_Ron1 小时前
用 ECharts graph 画出卡片式矩形节点
前端
skiyee1 小时前
换个底座的 Wot Starter 居然让 AI 更懂项目!
前端·ai编程
anyup1 小时前
这一套绝了!AI 大模型写故事,星云 SDK 驱动 3D 数字人实时演绎
前端·人工智能·aigc
耀耀切克闹灬2 小时前
短链跳转
前端
孟陬2 小时前
高质量全方位的 AI 工具 sse-stuntman — Mock SSE 接口
前端·node.js·openai
Cao_Ron2 小时前
给 ECharts 6 graph 节点叠加角标:从原理到性能优化
前端
WebGirl2 小时前
内网穿透方式
前端
hoLzwEge3 小时前
前端项目的基石:深入解读 package.json 的作用与核心配置
前端·前端框架