前端AI编程工具实战测评：React与Vue项目选型与工作流指南

前端圈子这两年最明显的变化，不是某个框架又发了大版本，而是写代码的方式本身在变。以前我们讨论的是"用 React 还是 Vue"，现在讨论的是"这段逻辑让哪个 AI 来写更靠谱"。我从 2023 年开始陆续把 AI 编程工具塞进日常开发流程，从最早的补全插件到现在的 Agent 式工作流，踩过的坑能写一本小册子。这篇就围绕前端开发场景，把目前主流的几类 AI 编程工具做一次实打实的对比测评，重点聊 React、Vue 项目里的真实表现，以及怎么把它们嵌进 workflow 里而不是当成玩具。不管你是刚入门的初级前端，还是带团队的技术负责人，都能从里面找到可以直接抄的配置和选型思路。

1. 先搞清楚前端场景下 AI 工具到底在解决什么问题

1.1 前端开发的特殊性决定了工具选型逻辑

很多人选 AI 编程工具的思路是错的——看排行榜、看参数、看谁家模型大。但前端开发和后端、算法场景有本质区别，直接套用别人的推荐往往翻车。

前端的核心特点是上下文碎片化。一个 React 组件的逻辑可能散落在 JSX、hooks、样式文件、类型定义、测试文件里，AI 要给出可用代码，必须同时理解这几块。Vue 的单文件组件稍微集中一些，但<script setup>、<template>、<style scoped>三块之间的隐式关联（比如 template 里引用的变量来自 script，style 里的 class 来自 template）同样是上下文难题。

第二个特点是视觉反馈闭环短。后端改个接口逻辑，跑测试就知道对不对；前端改个样式，得看浏览器渲染结果。这意味着 AI 工具如果只能生成代码、不能理解"这段代码渲染出来长什么样"，价值就打折扣。这也是为什么纯文本补全类工具在前端场景里，效果普遍不如能读截图、能跑预览的工具。

第三个特点是生态更新极快。React 19 的 Server Components、Vue 3.5 的响应式优化、Vite 6 的配置变更，这些新东西在训练数据里往往是缺失的。一个 2024 年初训练出来的模型，你问它 React 19 的usehook 用法，它大概率给你编一个看起来很像但跑不通的答案。所以选工具时，是否支持联网检索最新文档、是否能读取你项目里的 node_modules 类型定义，比模型本身的代码能力更关键。

1.2 三类工具的能力边界划分

市面上的 AI 编程工具，按介入深度可以分成三层，每层解决的问题完全不同，混着比没有意义。

我自己的用法是三层混用：补全层负责"手速"，对话层负责"查资料和写独立函数"，Agent 层负责"整块功能落地"。下面几章的对比，也是按这个分层来展开的，因为把补全工具和 Agent 工具放一起比"谁更强"，本身就是伪命题。

1.3 一个反直觉的结论：模型不是最重要的变量

测了这么多工具，我最大的体会是：同一个模型，套不同的工具壳，前端场景下的实际产出质量能差出三倍。

原因在于前端任务对"上下文组装"极度敏感。同样是让 GPT 或 Claude 写一个 Vue 组件，工具 A 只把你的光标前后 50 行喂进去，工具 B 把整个组件的 script、template、style 加上项目里的类型定义一起喂进去，结果完全不是一个档次。工具 B 生成的代码能直接跑，工具 A 生成的代码你还得手动补 import、改 props 类型。

所以这篇测评里，我会把"上下文组装能力"单独拎出来讲，这比单纯看模型跑分有用得多。选工具时，先看它怎么理解你的项目结构，再看它用什么模型。

2. 补全层工具：日常写代码的"手速放大器"

2.1 补全工具在前端项目里的真实命中率

补全类工具（编辑器内联提示那种）是使用频率最高的，因为它不打断你的思路。但它的价值高度依赖场景，我拿一个真实的 Vue 3 项目做了两周统计。

在写<script setup>里的响应式逻辑时，补全命中率大概在 60% 左右——比如你写了const count = ref(，它能猜到你要ref(0)；你写了watch(，它能补出监听对象和回调的骨架。但在写<template>里的复杂指令时，命中率掉到 30% 以下，因为模板里的变量名、组件名、事件名高度依赖项目自定义，通用模型猜不准。

React 项目里情况类似但更极端。写 hooks 逻辑时补全很顺，写 JSX 结构时经常给你补出语法正确但业务无关的代码。我印象最深的一次，写一个列表渲染，我打了{items.map(，它补出了(item) => <div>{item}</div>)，看起来对，但我的 items 是对象数组，需要取item.name，它没猜出来。这种"半对"的补全反而比不补更烦，因为你得停下来改。

提示：补全工具的价值在"减少机械输入"，不在"替你思考业务"。把它当成高级的输入法，心态就对了。

2.2 补全工具的配置细节：这些参数决定体验

补全体验好不好，一半看工具，一半看配置。我踩过的几个关键配置点，分享出来。

延迟阈值。补全提示如果弹得太快，你打字时它会一直闪，干扰视线；弹得太慢，你代码都写完了它才出来。我实测下来，200-300ms 的延迟比较舒服。大部分工具默认是 100ms 左右，建议手动调高。

触发字符。默认情况下，你打任何字符它都可能触发。但在前端项目里，打<触发组件补全是有用的，打.触发属性补全也有用，但打普通字母时频繁触发就很烦。我的做法是只保留<、.、(、=这几个触发字符，其他关掉。

多行补全的接受方式。单行补全按 Tab 接受没问题，但多行补全（比如补一个完整的函数体）如果也按 Tab，很容易误触。我习惯把多行补全改成Ctrl+Enter接受，单行还是 Tab，这样误触率大幅下降。

排除文件。这个很多人忽略。补全工具默认会索引整个项目，包括node_modules、dist、.git。前端项目里node_modules动辄几万个文件，索引它会拖慢整个编辑器。一定要在配置里排除掉，只索引src目录。

{ "completion.exclude": [ "**/node_modules/**", "**/dist/**", "**/.git/**", "**/*.min.js" ], "completion.delay": 250, "completion.triggerCharacters": ["<", ".", "(", "="] }

2.3 补全工具处理 React 和 Vue 的差异

同样是补全，React 和 Vue 的体验差异挺大，值得单独说。

React 的 JSX 本质是 JavaScript 表达式，补全工具理解起来相对容易，因为它就是在补 JS。但 React 的 hooks 规则（比如不能在条件语句里调用 hooks）是运行时约束，补全工具经常无视这个规则给你补出违规代码。我遇到过好几次，在if块里打use，它照样给你补useState，跑起来直接报错。

Vue 的模板语法是自定义 DSL，补全工具需要专门适配。好的工具能理解v-for里的作用域变量、v-model绑定的响应式变量、defineProps定义的类型。差一点的工具在模板里基本是瞎猜。我测下来，对 Vue 模板支持好的工具，通常也会对 Svelte、Angular 模板支持得不错，因为它们都做了 DSL 层面的适配。

一个实用技巧：如果你主写 Vue，选工具时专门测一下它在<template>里的补全质量，这是区分工具好坏的分水岭。具体怎么测？新建一个组件，写一个v-for循环，看它能不能正确补出循环项的属性访问。

3. 对话层工具：查文档、写函数、做 Code Review

3.1 对话工具的核心价值是"带上下文的问答"

对话层工具（侧边栏 Chat 那种）解决的是补全层解决不了的问题：需要理解意图、需要查资料、需要跨文件推理的任务。

前端开发里，我用对话工具最多的三个场景：一是查 API 用法，比如"Vue 3.5 里useTemplateRef怎么用"；二是写独立的工具函数，比如"写一个防抖函数，支持立即执行选项"；三是 Code Review，把一段代码贴进去问"这段逻辑有什么问题"。

这三个场景对工具的要求完全不同。查 API 用法，要求工具能联网或能读最新文档；写工具函数，要求模型本身代码能力强；Code Review，要求工具能理解业务上下文。所以选对话工具时，要看你主要用它干什么。

3.2 联网检索能力：前端工具选型的一票否决项

前面说过，前端生态更新快，训练数据永远滞后。所以对话工具是否支持联网检索最新文档，我认为是一票否决项。

举个真实例子。Vue 3.5 引入了useId和useTemplateRef，我让一个不支持联网的工具解释useTemplateRef，它给出的答案是编的——语法看起来像那么回事，但实际跑不通。换一个支持联网的工具，它直接去查了 Vue 官方文档，给出的用法准确无误。

React 这边更明显。React 19 的usehook、Server Actions、useOptimistic，这些新 API 在不联网的工具里基本是重灾区。我甚至遇到过工具把 React 18 的useTransition用法套到 React 19 的useOptimistic上，生成了一段四不像的代码。

注意：判断工具是否真联网，有个简单方法——问它一个最近一周才发布的前端库版本号，看它能不能答对。答不对的，联网能力基本是摆设。

3.3 对话工具喂上下文的正确姿势

对话工具的效果，七分靠你怎么喂上下文。我总结了几个前端场景下的喂法。

贴代码要贴全。很多人只贴出问题的那几行，但前端代码的 bug 往往在上下文里。比如一个 React 组件的状态更新不生效，你只贴setState那行没用，得把整个组件、相关的 hooks、父组件传的 props 都贴上。我的习惯是，贴一个组件就贴完整的文件，别省。

说清楚技术栈版本。前端版本差异巨大，Vue 2 和 Vue 3 的写法完全不同，React 17 和 19 的 API 也有区别。提问时开头就写清楚"Vue 3.4 + TypeScript + Vite"，能省掉大量来回确认。

给期望的输出格式。如果你要的是一个能直接用的组件，就明确说"给我完整的单文件组件，包含 script setup、template、style"。不然工具可能只给你一个函数片段，你还得自己拼。

分步问，别一次问太多。前端任务往往涉及多个文件、多个关注点。一次问"帮我实现一个带搜索、分页、排序的表格"，工具大概率给你一个能跑但很粗糙的版本。拆成"先实现基础表格""再加搜索""再加分页"，每步验证，质量高得多。

3.4 Code Review 场景下的实测对比

Code Review 是我用对话工具的高频场景，测下来不同工具差异明显。

我拿一段有典型问题的 React 代码去测：一个useEffect里做了数据请求，但依赖数组是空的，导致请求参数变化时不重新请求；同时setState在组件卸载后可能触发警告。好的工具能同时指出这两个问题，并给出修复方案（加依赖、加清理函数）。差的工具只看到"用了 useEffect"，然后泛泛地说"注意依赖数组"，没抓到具体问题。

Vue 场景下，我测的是一段有响应式陷阱的代码：用reactive定义了一个对象，然后整体替换它，导致响应式丢失。好的工具能指出"reactive 定义的对象不能整体替换，应该用 ref 或者逐个属性赋值"。这个坑很典型，能识别出来的工具，说明它对 Vue 响应式原理有真正的理解，而不是表面套模板。

一个经验：Code Review 时，把项目的 ESLint 配置也贴给工具，让它按你的规范来 review，比让它自由发挥有用得多。不然它会给你一堆风格建议，而忽略真正的逻辑问题。

4. Agent 层工具：整块功能落地的正确打开方式

4.1 Agent 工具和对话工具的本质区别

Agent 层工具是这两年最热的方向，但很多人用错了。它和对话工具的本质区别是：对话工具你问它答，Agent 工具你给目标它自己干。

具体到前端，对话工具是你贴一段代码问"怎么改"，Agent 工具是你告诉它"把首页的商品列表改成支持无限滚动"，然后它自己去读文件、改代码、跑构建、看报错、再改，直到跑通。

这个能力听起来很美好，但实际用起来，前端场景下的坑特别多。最大的问题是前端没有可靠的自动化验证手段。后端 Agent 改完代码跑测试就知道对不对，前端 Agent 改完代码，构建能过不代表页面渲染正确，页面渲染正确不代表交互逻辑对。所以前端 Agent 工具，目前还离不开人工把关。

4.2 用时间流方式组织 Agent 任务

热词里提到"时间流的方式来开发代码"，这个思路我用下来确实有效。所谓时间流，就是把一个功能拆成按时间顺序排列的小任务，每个任务有明确的输入和输出，Agent 一次只做一个。

举个例子，让 Agent 实现一个"用户列表页"，不要一次性丢给它。拆成时间流：

1. 第一步：创建页面组件骨架，包含路由配置
2. 第二步：实现数据请求 hook，返回 loading、data、error
3. 第三步：实现列表渲染，先用静态数据
4. 第四步：接入真实请求，处理 loading 和 error 状态
5. 第五步：加分页逻辑
6. 第六步：加搜索过滤

每一步做完，你验证一下，再进下一步。这样做的原因很简单：Agent 一次性做太多，出错后你很难定位是哪一步的问题；而且前端任务之间往往有依赖，前一步的产出是后一步的输入，分步做能让 Agent 拿到准确的上下文。

我实测下来，分步做的成功率比一次性做高出很多。一次性让 Agent 实现整个页面，十次有六七次跑不通，得反复修；分步做，十次有八九次能顺利推进。

4.3 Agent 工具在前端项目里的典型翻车场景

Agent 工具在前端翻车，我总结了几类高频场景，提前知道能省很多时间。

过度修改。你让它改一个按钮的样式，它顺手把整个组件的结构重构了。这是最烦的，因为你的 git diff 会变得巨大，review 起来痛苦。应对方法是给 Agent 明确的边界，比如"只修改 Button 组件的 style 部分，不要动 script 和 template 结构"。

无视项目约定。每个前端项目都有自己的约定，比如组件放哪个目录、状态管理用哪个库、请求封装在哪。Agent 不知道这些，会按通用做法来，结果和项目风格冲突。应对方法是把项目约定写成一个文档，每次让 Agent 干活时先让它读这个文档。

依赖版本乱装。Agent 需要某个库时，会直接npm install，但它装的版本可能和项目现有依赖冲突。我遇到过 Agent 装了一个新版本的日期库，结果和项目里已有的版本冲突，整个构建挂了。应对方法是让 Agent 装依赖前先问你，或者锁定它只能用项目已有的依赖。

测试代码瞎写。Agent 写测试经常是"为了通过而写"，断言写得很水，测了等于没测。前端测试本来就难写，Agent 写的测试我基本都要重写。应对方法是明确告诉它测试要覆盖哪些边界情况，别让它自由发挥。

4.4 Agent 工具的权限控制与安全边界

Agent 工具能读写文件、能跑命令，权限给大了很危险。我踩过一次坑：让 Agent 清理项目里的无用文件，它把src/assets下一个还在用的图片删了，因为它的静态分析没识别出这个图片是通过动态路径引用的。

所以权限控制很重要。我的做法是分三级：

• 只读级：Agent 只能读文件、给建议，不能改。用于代码审查、方案设计。
• 受限写级：Agent 能改src下的文件，但不能碰配置文件、不能跑npm install、不能执行 git 操作。用于日常功能开发。
• 完全级：Agent 能跑命令、装依赖、执行 git。只在明确知道要干什么时用，且用完立刻降级。

另外，Agent 跑命令时，一定要在 git 干净的状态下跑。这样万一它改乱了，git checkout .就能回滚。我现在的习惯是，让 Agent 干活前先 commit 一次，干完看 diff，不对就回滚。

5. React 与 Vue 项目里的工具适配差异

5.1 React 项目的 AI 工具适配要点

React 项目用 AI 工具，有几个特有的适配点。

JSX 的上下文理解。React 组件里，JSX 和逻辑是混在一起的，AI 工具需要理解这种混合。好的工具能根据 JSX 里用到的变量，反推你需要哪些 state 和 props。差的工具会把 JSX 当成普通模板，生成的代码变量对不上。

hooks 规则的遵守。前面提过，AI 工具经常无视 hooks 规则。选工具时，专门测一下它在条件语句、循环里会不会生成 hooks 调用。这个测试很简单：写一个if (condition) {然后打use，看它补什么。

TypeScript 类型的准确性。React + TS 项目里，类型定义是 AI 工具的重要上下文。好的工具能读取你的类型定义，生成的代码类型正确；差的工具会瞎编类型，或者用any糊弄。我测过一个工具，让它写一个接收User类型 props 的组件，它直接用了any，这种工具在 TS 项目里基本没法用。

React 19 新特性的支持。如果你在用 React 19，Server Components、usehook、Server Actions 这些新东西，只有支持联网或更新及时的工具才能正确处理。用之前先测一下，别等它生成一堆跑不通的代码才发现。

5.2 Vue 项目的 AI 工具适配要点

Vue 项目用 AI 工具，适配点和 React 很不一样。

单文件组件的三块联动。Vue 的<script setup>、<template>、<style>三块之间有隐式关联，AI 工具必须同时理解。我测过一个工具，在 template 里补全时，完全不知道 script 里定义了哪些变量，补出来的东西全是错的。选工具时，专门测一下它能不能在 template 里正确补全 script 定义的变量。

响应式 API 的正确使用。Vue 3 的ref、reactive、computed、watch各有适用场景，AI 工具经常用错。比如该用ref的地方用了reactive，导致整体替换时响应式丢失。好的工具能根据使用场景选对 API。

组合式函数的组织。Vue 3 的组合式 API 鼓励把逻辑抽成 composable，AI 工具需要理解这种组织方式。我让工具写一个"表单校验"的 composable，好的工具会返回一个包含validate、errors、reset的对象，差的工具会直接写成一个组件内的函数。

Vue 生态库的适配。Vue 项目常用 Pinia、Vue Router、VueUse 这些库，AI 工具需要知道它们的用法。特别是 VueUse，里面几百个工具函数，AI 工具如果不知道，会重复造轮子。选工具时，测一下它知不知道 VueUse 里常用的函数，比如useDebounceFn、useLocalStorage。

5.3 跨框架项目的工具选择策略

有些项目同时有 React 和 Vue，或者在做框架迁移，这种场景下工具选择要更谨慎。

我的建议是按主框架选工具，按次框架配规则。比如你主写 Vue，偶尔维护一个 React 老项目，那就选一个 Vue 支持好的工具，然后针对 React 项目单独配置一套规则（比如告诉工具这个项目用 React 18、用 class 组件还是函数组件、状态管理用什么）。

另外，跨框架项目里，AI 工具容易"串味"——在 Vue 项目里生成 React 风格的代码，或者反过来。应对方法是在项目根目录放一个.ai-rules之类的配置文件，明确写清楚这个项目的技术栈和约定，让工具每次干活前先读。

6. 把 AI 工具嵌进前端 workflow 的实操方案

6.1 从需求到上线的完整 AI 介入点

AI 工具不是孤立用的，得嵌进整个开发流程。我梳理了一下前端开发从需求到上线，AI 可以介入的点。

这张表的关键是：每个阶段都有明确的人工把关点。AI 可以加速，但不能替代判断。我见过有人让 Agent 从需求到上线全自动，结果上线后发现一堆边界问题，回滚都来不及。

6.2 一套可复用的 AI 辅助开发配置

分享一套我目前在用的配置，适配 Vue 3 + TypeScript + Vite 项目，React 项目改改也能用。

项目根目录放一个 AI 规则文件，内容包含技术栈、目录约定、代码规范、常用库。每次让 AI 干活前，先让它读这个文件。

# 项目 AI 协作规则 ## 技术栈 - Vue 3.4 + TypeScript 5.3 + Vite 5 - 状态管理：Pinia - 路由：Vue Router 4 - UI 库：Element Plus - 工具库：VueUse ## 目录约定 - 组件放 src/components，按功能分子目录 - 页面放 src/views - 组合式函数放 src/composables - API 封装放 src/api ## 代码规范 - 组件用 <script setup lang="ts"> - 样式用 scoped，不写全局样式 - 请求统一走 src/api 里的封装，不直接调 axios - 类型定义放 src/types ## 禁止事项 - 不要装新依赖，需要时先问 - 不要改 vite.config.ts 和 tsconfig.json - 不要动 .env 文件

编辑器配置，前面提过的补全配置，加上 Agent 工具的权限配置。

一个任务模板，每次让 Agent 干活时按这个模板描述任务：

任务：实现用户列表页的分页功能 范围：只改 src/views/UserList.vue 输入：现有代码已实现列表渲染，数据来自 useUserList composable 输出：加分页组件，页码变化时重新请求 约束：用 Element Plus 的 Pagination 组件，不要改 composable 验证：改完后跑 npm run build，确保构建通过

这个模板的关键是范围、输入、输出、约束、验证五要素齐全。缺了任何一个，Agent 都容易跑偏。

6.3 团队协作场景下的 AI 工具规范

如果是团队用 AI 工具，光有个人配置不够，得有团队规范。

统一工具和版本。团队里每个人用的工具不一样，生成的代码风格会五花八门。我的建议是团队统一一套工具，至少统一补全工具和 Agent 工具，对话工具可以各用各的。

AI 生成代码的标记。团队里要约定，AI 生成的代码在 commit message 里标记出来，方便 review 时重点关注。我见过团队用[AI]前缀标记，review 时优先看这些 commit。

共享规则文件。前面说的 AI 规则文件，要放进 git 仓库，团队共享。有人改了技术栈或约定，同步更新这个文件。

定期复盘 AI 生成代码的问题。我们团队每两周复盘一次，看 AI 生成的代码里，哪类问题最多，然后针对性调整规则文件。比如发现 AI 老是用any，就在规则里明确禁止any。

新人培训。新人入职时，专门讲一下团队的 AI 工具用法和规范。不然新人用 AI 工具瞎搞，生成的代码质量参差不齐，review 起来很痛苦。

6.4 实测下来最省时间的几个用法

最后分享几个我实测下来，真正省时间的 AI 用法，都是前端场景的。

批量改样式。项目要换主题色，几十个组件里的颜色值要改。让 Agent 批量处理，比手动改快得多。但要注意，改完得肉眼过一遍，因为有些颜色值是动态计算的，Agent 可能改错。

写类型定义。根据 API 返回的 JSON，让 AI 生成 TypeScript 类型定义，这个准确率很高，省时间。我一般把 JSON 贴给对话工具，让它生成 interface，然后手动微调。

写单元测试骨架。让 Agent 根据组件生成测试文件骨架，包含 describe、it 的结构，然后自己填断言。骨架生成能省一半时间。

排查构建错误。构建报错时，把错误信息贴给对话工具，让它分析原因。前端构建错误往往信息量大、指向不明确，AI 能帮你快速定位。

写 commit message。让 AI 根据 git diff 生成 commit message，这个虽然省不了多少时间，但能让 commit 记录更规范。

查冷门 API 用法。前端库太多，总有你没用过的 API。对话工具查这个很快，比翻文档快。但要注意验证，特别是新版本的 API。

7. 选型决策：不同阶段的前端开发者怎么选

7.1 初级前端：先建立正确的使用习惯

初级前端用 AI 工具，最大的风险是过度依赖，导致基本功不扎实。我见过不少新人，离开 AI 就不会写代码，连一个简单的数组去重都要问 AI。

我的建议是，初级前端用 AI 工具，重点放在"学习"而不是"代劳"。具体做法：

• 让 AI 解释代码，而不是直接生成代码。看到不懂的代码，问 AI"这段代码在干什么"，比让它帮你写更有价值。
• 让 AI 出题，而不是给答案。比如让它"给我出 10 道 Vue 响应式的练习题"，然后自己做。
• 生成的代码，逐行看懂再用。看不懂的，问 AI 解释，别直接复制。
• 面试题相关的知识，别用 AI 糊弄。热词里有"初级前端开发工程面试题"，这些题背后的原理，得自己搞懂，AI 只能帮你查漏补缺。

工具选择上，初级前端用补全工具 + 对话工具就够了，Agent 工具先别碰，容易养成坏习惯。

7.2 中级前端：用 AI 提升产出效率

中级前端是 AI 工具的最大受益群体。基本功有了，缺的是效率。这个阶段，三层工具都可以用起来。

补全工具提升手速，对话工具查资料和写独立函数，Agent 工具做整块功能。重点是把 AI 嵌进 workflow，形成自己的高效流程。

这个阶段要注意的是别让 AI 拉低代码质量。中级前端容易犯的错是，AI 生成什么就用什么，不 review。我见过有人用 Agent 生成了一堆重复代码，项目里同样的工具函数写了五遍。所以用 AI 的同时，要保持对代码质量的敏感。

工具选择上，可以开始尝试 Agent 工具，但要从简单任务开始，逐步建立信任。

7.3 高级前端 / 技术负责人：用 AI 放大团队效能

高级前端和技术负责人用 AI 工具，重点不在个人效率，在团队效能。

具体来说，要做几件事：制定团队的 AI 工具规范、搭建共享的规则文件、建立 AI 生成代码的 review 流程、定期复盘 AI 使用中的问题。

工具选择上，要选支持团队协作的工具，比如能共享配置、能统一规则的。个人用什么工具是小事，团队统一才是大事。

另外，技术负责人要关注 AI 工具对团队能力结构的影响。AI 能替代的重复劳动，就别让团队花时间；AI 替代不了的架构设计、技术选型、复杂问题排查，要重点培养团队这方面的能力。

7.4 一张选型决策表

最后给一张决策表，按不同维度帮你快速定位。

选工具这件事，没有标准答案，只有适不适合。我的核心建议是：先想清楚你要 AI 帮你解决什么问题，再选工具。别看着别人推荐什么就用什么，前端场景太特殊，别人的最优解未必是你的。

我在实际使用中最大的体会是，AI 工具的价值不在于它多聪明，而在于它能不能稳定地嵌进你的工作流。一个能力中等但用起来顺手的工具，比一个能力顶尖但总打断你思路的工具，价值高得多。所以选型时，多花时间在"怎么用"上，少花时间在"比参数"上。工具是死的，workflow 是活的，把 workflow 跑通了，什么工具都能用好。