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

ErpanScript

18人浏览 · 2026-07-13 17:19:35

ErpanScript · 2026-07-13 17:19:35 发布

在这里插入图片描述

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

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

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

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

只是因为训练语料多吗？

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

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

在这里插入图片描述

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

JS 纯粹性与 DSL 的认知负担

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

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

大模型最擅长预测什么？是标准的、图灵完备的常规编程语言（比如纯 JavaScript 或 Python）。

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

// 在大模型的使用，这根本不是 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-if、v-for、v-model），另一套是下方的 script setup 响应式逻辑。

<!-- 大模型在生成长组件时，极其容易在这里的模板层丢失数据映射 -->
<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>

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

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

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

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

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

在这里插入图片描述

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

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

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

前端组件的文本化（复制粘贴🤣）

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

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

在这里插入图片描述

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

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

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

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

好了，今天写道这里吧🙌

请添加图片描述