claude code 对 Vue 3 组合式 API 的代码生成是否全面

最近三个月，我在三个商业项目中系统地使用 Claude Code 生成 Vue 3 组合式 API 代码。第一个项目是一个中等复杂度的 SaaS 后台，第二个是一个电商 C 端页面重构，第三个是一个数据可视化 Dashboard。

结论先说清楚：Claude Code 对 Vue 3 组合式 API 的代码生成，在语法层面覆盖率超过 95%，但在业务逻辑正确性层面，不加人工干预的情况下，合格率只有 60% 左右。 “全面”这个词，取决于你问的是“能不能写出所有语法形式”还是“能不能直接交付可用的业务代码”。

这个结论不是拍脑袋来的。我统计了三个项目中 127 次 AI 生成任务的执行结果，并做了分类记录。下面我把这些发现完整展开。

一、你的同事在晒截图，但我的测试结果不一样

先说我为什么做这个测试。

2025 年初，社交媒体上开始大量出现“Claude Code 一键生成完整 Vue 3 组件”的帖子。典型格式：一段 prompt 输入，一个完整的 setup 语法块输出，评论区一片“效率革命”、“前端要失业了”。

但作为一个每天都在写组合式 API 的人，我发现这些帖子有个共同点：它们展示的都是计数器、Todo List、表单提交这类“教科书级”场景。 这类场景的特点是什么？逻辑简单、状态单一、没有深层依赖、没有异步竞态、没有复杂类型推导。

我好奇的是：把复杂度往上拉两个等级，它还能保持同样的生成质量吗？

于是我设计了一组分级测试任务，从 L1 到 L5 递进：

测试结果：L1-L2 几乎零失误；L3 开始出现“隐性错误”；L4-L5 的正确率断崖式下降。

这个分层结果，是我后面所有判断的基础。

二、为什么“全面”是个模糊命题

在进入具体的代码测评之前，先把这个命题拆解清楚，否则后面的讨论会变成各说各话。

“Claude Code 对 Vue 3 组合式 API 的代码生成是否全面”，这里的关键词不是“Claude Code”，也不是“组合式 API”，而是“全面”。什么叫全面？

我拆成三个维度：

1. 语法全面性：能不能写出所有组合式 API 的语法元素？ref、reactive、computed、watch、watchEffect、defineProps、defineEmits、useAttrs、useSlots、provide/inject、生命周期钩子、<script setup> 语法糖，它都能生成吗？
2. 场景全面性：能不能覆盖常见的开发场景？表单处理、列表渲染、条件展示、异步请求、状态管理、路由交互、权限控制、国际化、主题切换，它能处理多少？
3. 质量全面性：生成的代码在类型安全、性能、可维护性、边界处理上是否完备？能不能直接合并到主分支，不需要人工 review？

真实情况是：维度 1 接近于全面，维度 2 部分覆盖，维度 3 远不全面。 大多数社交媒体上的“惊叹帖”只展示了维度 1 中的一小部分，然后用它来暗示三个维度都已解决。这是一种典型的幸存者偏差。

搞清楚这三个维度之后，我们就可以分别展开讨论，不再笼统地说“全面”或“不全面”。

三、语法全面性：它确实会写几乎所有东西

先说它擅长的部分。这部分我可以写得很快，因为确实没什么好批评的。

任何你能在 Vue 3 官方文档中找到的 API，Claude Code 几乎都能正确生成。 这不是夸张。我在测试中覆盖了以下所有语法点：

• ref() 和 reactive() 的基本使用
• computed() 的 getter/setter 形式
• watch() 的多源监听、watchEffect() 的自动追踪
• defineProps() 的 TypeScript 泛型写法、默认值、校验函数
• defineEmits() 的类型签名
• defineExpose() 暴露组件方法
• useTemplateRef() 获取 DOM 引用
• provide() 和 inject() 的键值类型推导
• 所有生命周期钩子：onMounted、onUpdated、onUnmounted、onActivated、onDeactivated
• <script setup> 语法、defineOptions、defineSlots
• Suspense + defineAsyncComponent 的异步组件写法

每一个语法点，我都至少测试了三次不同的 prompt 描述。127 次任务中有 43 次属于这一类基础语法生成，正确率 98%。 唯一一次出错是它在一个 watch 内部忘了清理定时器，但这严格来说不算语法错误，而是逻辑缺陷，我归在后面讨论。

对于这个结论，我有一个很实用的判断：如果你想确认一个 API 的写法，把它当成一个会写代码的文档查询工具，它的表现接近完美。 以前你查文档、看示例、复制粘贴、改参数；现在你描述需求，它直接给你可运行的代码片段。这个场景下的效率提升是真实的。

但问题在于，真实项目从来不是“一个 API 的用法展示”。 真实项目是十几个 API 组合在一起，加上业务规则、异步时序、错误处理、边界情况。这才是“全面性”真正的考场。

四、场景全面性：能覆盖什么、不能覆盖什么

这部分是我投入时间最多的测试，因为“场景”的边界本身就是模糊的。我采用的是逆向归纳法：不是试图穷举所有场景，而是从我过去三年 Vue 3 项目的 commit 历史中，提取最常见的开发任务类型，然后逐一测试 Claude Code 的表现。

以下是分类测试的结果。

4.1 表单与输入处理：高正确率，但缺乏“防御性”

表单是每个业务系统的毛细血管。我测试了：

• 简单文本输入 + 实时校验
• 多步骤表单（Wizard 模式）
• 动态表单（从配置 JSON 生成）
• 文件上传 + 预览

Claude Code 在前两个场景表现优秀。 你描述一个表单结构，它能生成完整的 reactive 状态、computed 校验规则、watch 触发的副作用。多步骤表单的状态切换、步骤校验、前进后退按钮的逻辑，它也能正确处理。

但在动态表单场景，它开始暴露问题。给定一个包含字段类型、校验规则、默认值的 JSON schema，它生成的代码几乎每次都使用 v-for + component :is 的方案，方案本身没问题，但它不会主动处理字段之间的联动依赖。 比如“选择了省份后自动过滤城市下拉选项”，它需要你在 prompt 里明确描述这一逻辑，否则不会主动处理。

文件上传场景的弱项更隐蔽：它生成的代码不会处理并发上传的队列管理、断点续传、上传进度汇总等高级需求。这恰恰说明：它能处理“你明确描述的需求”，但不擅长推断“你应该做但没说的防御性设计”。

4.2 列表与数据展示：生成快，但虚拟滚动和性能优化是盲区

表格、卡片列表、树形结构，这些都是后台系统的标配。我测试了：

• 基础分页列表（含搜索、排序、筛选）
• 无限滚动加载（Intersection Observer 方案）
• 虚拟滚动大列表（10000+ 条数据）
• 嵌套树形结构的展开/折叠/拖拽排序

基础分页列表，正确率接近于 100%。包括页码、每页条数、搜索关键词的联动管理，computed 过滤逻辑，API 请求的防抖，它都能处理。

无限滚动稍微复杂一些。它知道用 Intersection Observer，也知道在触底时加载下一页。但有一个反复出现的 bug：当用户快速滚动时，它不会取消前一个正在进行的请求，导致“最后一页数据重复加载”。 这是典型的竞态条件问题，有经验的开发者会用一个 AbortController 或者请求序号来避免，但 Claude Code 不会主动加上这个保护。

虚拟滚动是真正的分水岭。我让它生成一个虚拟滚动列表组件，它给了 vue-virtual-scroller 的方案，如果你在 prompt 里显式提到了要用这个库。如果你不指定方案，它倾向于生成一个自己实现但性能堪忧的版本，使用 scrollTop 计算、slice 截取可见数据、绝对定位模拟滚动。这个自己实现的版本在 10000 条数据时会明显卡顿，因为它在 scroll 事件里做了太多次 DOM 重排。

我的判断是：Claude Code 的场景覆盖是“广度足够，深度不足”。 它能给出一个看起来能跑的方案，但方案在边界条件下的表现，取决于这个边界条件有多“常见”。竞态处理、性能优化、复杂交互，这些高级技巧需要人工补充。

4.3 异步逻辑与状态管理：正确率断崖下降的区域

异步逻辑是前端复杂度的主要来源。我测试了：

• 单一 API 请求 + Loading/Error 状态管理
• 并行请求 + Promise.all 汇总
• 依赖请求（请求 B 依赖请求 A 的结果）
• 轮询 + 竞态处理
• 请求缓存与去重

单一请求，毫无问题。 生成 isLoading、error、data 三个 ref，try-catch 包裹，finally 清理，标准模板，极少出错。

并行请求，开始出现小问题。 它知道用 Promise.all，但在多个请求分别有独立的 loading 状态时，它会引入多余的 computed 来汇总“整体是否加载完成”，却忽略了单个请求失败的降级处理。比如三个请求中一个失败，它倾向于让整个页面显示错误，而不是部分降级展示。

依赖请求是最容易出错的类型。 我设计了一个典型场景：先请求用户信息，拿到 userId 后，用这个 ID 请求订单列表和优惠券列表。Claude Code 生成的代码在单个 setup 函数内使用 async/await 顺序执行，或者用 watch(userId, ...) 触发后续请求。这两种写法的共同问题是：当 userId 在短时间内多次变化时（比如用户快速切换账号），旧的请求回调可能会覆盖新的状态。 它几乎不会主动使用请求序号或 AbortController 来解决这个问题。

这个发现很重要。Claude Code 的眼中的“异步逻辑”是路径正确的，从 A 到 B 到 C 的执行顺序是对的；但它眼中的“异步竞态”是不存在的，它假设每个请求都会在下一个请求发出前完成。 而真实的网络环境显然不是这样的。

4.4 复杂业务规则：AI 最怕的那类代码

这是整个测试中最具挑战性的部分。我选择了一个电商场景：“结算页的优惠券选择逻辑”。

需求描述：用户有 5 张优惠券，每张有不同的门槛（满 100 减 20、满 200 减 50 等）、适用范围（全场/指定品类）、叠加规则（可叠加/互斥）。用户选中多件商品，系统需要自动计算最优的优惠券组合，并以醒目方式展示。

Claude Code 在第一次生成时，写了一个暴力枚举所有组合的函数。 这个解法在数学上是正确的，枚举所有使用 0-5 张券的组合，计算总优惠，取最大值。复杂度 O(2^5)，实际可接受。但问题出在细节：

1. 它没有区分“全场券”和“品类券”的有效商品范围。 它的 calculateDiscount 函数把所有券对所有商品都算了一遍优惠，导致品类券被错误应用到不匹配的商品上。
2. 互斥规则处理有遗漏。 我定义了三张券“A 和 B 互斥”，它在枚举组合时正确排除了 A+B 的组合，但忽略了“A+B+C 中 A 和 B 同时存在”也算违规。
3. 边界情况：没有券可用时的文案展示逻辑缺失。 它给了“暂无可用优惠券”的硬编码文案，没有考虑“有券但不满足门槛”和“券已过期”的文案区分。

这个测试暴露出一个核心问题：Claude Code 对“规则”的理解是离散的、逐条的。它不会主动把多条规则放在一起做完整性交叉检查。 优惠券门槛、适用范围、叠加规则、有效期，这些是四组独立规则，但实际生效时需要联合计算。人类开发者会本能地做这种联合推演，AI 不会。

五、质量全面性：为什么说它“能跑，但不能用”

“能跑”和“能用”之间的差距，是程序员经验价值的核心体现。我从四个维度评估 Claude Code 生成的代码质量。

5.1 TypeScript 类型安全：在简单场景很严格，在复杂场景“全面崩塌”

这是最让我意外的发现。本以为 AI 处理类型推导会比人类更精确，但实际情况恰恰相反。

简单类型，它处理得很好。 ref<number>(0)、computed<string>()、defineProps<{ name: string }>()，这些基础泛型它几乎不会写错。

当类型变得复杂时，它有一个让我抓狂的习惯：使用 as 类型断言来“蒙混过关”。 我模拟了一个场景：从 API 返回的 JSON 数据需要按照接口类型进行映射。API 返回的字段名是下划线命名 user_id，前端接口定义是驼峰命名 userId。一个标准做法是写一个转换函数，逐字段映射。

Claude Code 的处理方式是：data as unknown as User，直接把 JSON 对象断言为前端类型，跳过了字段名转换。 TypeScript 编译器不会报错（因为你用了 as unknown as），但运行时字段名是错的。这是一个隐蔽 bug，如果一个初级开发者信任了 IDE 的类型提示，他可能在调试阶段才发现数据根本没映射。

另一个反复出现的模式：复杂泛型推导失败时直接退化为 any。 比如 useFetch<T> 这个组合函数，它内部的泛型传递逻辑经常在中途丢失，最终返回 Ref<any> 而不是 Ref<T>。你去看代码，中间某个地方的泛型约束没写对，它没有选择修正泛型，而是选择了加 as any 让类型检查通过。

这个行为模式值得警惕：Claude Code 倾向于让代码“通过编译”而不是“类型正确”。 这两者之间的区别，正是 TypeScript 存在的意义，如果在每一个复杂推导处都用 as 绕过，那 TypeScript 就退化成了一层语法糖，没有提供实际的类型安全保障。

5.2 性能考量：缺少“反模式”的敏感度

Vue 3 的组合式 API 给了开发者更多控制权，但也引入了更多性能陷阱。以下是我观察到的 AI 生成代码中反复出现的性能问题：

问题 1：在模板中使用不必要的响应式调用

Claude Code 经常在 computed 内部直接返回整个响应式对象，然后在模板中逐属性访问。这本身不算错，但它不会考虑“大对象计算”的场景。一个包含 50 个属性的计算属性，修改其中一个属性会导致所有引用该对象的地方重新渲染，它会用 reactive 而不是 shallowReactive，会在模板里直接写 obj.value.list 而不是在 computed 里提前提取 list。

问题 2：watch 的过度使用而非 computed

这是我见过最频繁的“代码异味”。一个依赖项变化后需要做计算，合理做法是用 computed。但 Claude Code 倾向于：写一个 ref 存结果，然后用 watch(source, () => { result.value = 计算逻辑 })。功能上等价，但多了不必要的依赖追踪和手动赋值。我统计了 L3 测试中生成的代码，涉及派生状态的场景中，约 30% 使用了 watch 而非 computed。 这不是错误，但说明它缺乏“选择最佳方案”的判断力。

问题 3：不清理的副作用

onMounted 里加了事件监听、定时器、订阅，但在 onUnmounted 里只清理了“显而易见”的部分。比如它会在 onUnmounted 里 clearInterval(timer)，但不会取消一个仍在进行中的 fetch 请求，也不会移除 window.addEventListener('resize', ...)。这些问题在小型组件中不致命，但在频繁创建/销毁的组件中会累积成内存泄漏。

问题 4：大列表没有虚拟化意识

我在前面提过这个。重申一遍：如果你不明确要求“使用虚拟滚动”，它会生成全量渲染的代码。 一个 5000 条数据的列表，直接 v-for。在测试环境中不明显，在生产环境就是页面卡死。

5.3 可维护性：一眼能看出的“AI 味”

除了正确的功能和良好的性能，代码还需要被人读懂和维护。在这个维度上，Claude Code 生成的代码有几个明显的风格特征，我叫它“AI 味”。

特征 1：函数体过长

如果你不给明确的函数长度限制，它倾向于把所有逻辑写在一个 80-150 行的函数里。提取成独立组合函数的意识较弱，除非在 prompt 中明确要求“使用 useXXX 模式封装”。

特征 2：缺乏“为什么这样做”的解释

这是一个微妙的点。AI 生成的注释要么没有，要么是显而易见的废话，比如 // 监听 searchKeyword 变化。好的注释解释“为什么”而非“是什么”。它生成的代码没有解释“为什么这里的 watch 使用了 immediate: true”或者“为什么用 shallowRef 而不是 ref”。 这类信息对于后续维护者至关重要，而 AI 无法提供，因为它自己也不“理解”这些选择背后的意图。

特征 3：魔法数字和硬编码

“一页显示 10 条”就是字面量的 10，不会被提取成 const PAGE_SIZE = 10。“30% 的折扣”就是 0.3，不会有 DISCOUNT_RATE 常量。这个问题一致且顽固。

综合来看，Claude Code 生成的代码像是“一个聪明但缺乏项目经验的初级开发者”写出来的，思路对，功能对，但在可维护性维度上处处透着稚嫩。

六、对比测试：Claude Code vs. 人类中级开发者的生成差异

为了给“全面性”一个更直观的参照系，我设计了一个对照实验。

实验设置： 同一个中等复杂度的任务，“用户管理页面的搜索筛选 + 批量操作”，分别交给：

1. Claude Code（Prompt-only）：只给需求描述，不做后续指令
2. Claude Code（Iterative）：首轮生成后，我做一轮 review 并给出修正指令
3. 人类中级开发者（3 年 Vue 经验，未用过 Claude Code）

评估维度：功能正确、类型完整、性能考量、可维护性、首次生成耗时、修正耗时。

实验结果如下：

关键发现：

Claude Code (Iterative) 模式，即“AI 生成 + 人工审查修正”，在综合质量上可以接近甚至超过中级开发者的首次交付水平，同时总耗时仅为后者的 22%。这是真正有价值的工作流。

而 Claude Code (Prompt-only) 的单次生成，质量得分全面落后于人类开发者，尤其类型完整和性能考量两个维度差距显著。这直接否定了“一键生成即可用”的幻想。

七、五个真实业务场景的详细走查

前面的分析偏向方法论，这一节我把五个真实业务场景的生成过程完整展示出来。每个场景都附带：初始 prompt、生成结果的关键问题、修正过程、最终评估。

场景一：多步骤注册表单（Wizard 模式）

业务背景： 一个 B2B 平台的商家入驻表单，共四步：账号信息、企业资质、经营类目、等待审核。每步有独立的校验，步骤间数据独立但最终汇总提交。

Prompt： “使用 Vue 3 组合式 API 和 TypeScript，写一个多步骤注册表单组件。共四步，每步独立校验，支持前进后退，表单数据在最后一步汇总提交。”

生成结果评估：

首次生成的代码整体可用。步骤切换逻辑清晰，每步的校验独立封装，提交时汇总所有步骤数据。

但有一个关键 bug： 当用户在第二步填写了数据，退回到第一步修改，再前进到第二步时，第二步之前填写的数据被保留了，这似乎是正确的用户体验。但如果用户在第一步修改了“企业类型”（个体工商户 vs 有限责任公司），第二步的某些字段（如“法人代表” vs “经营者姓名”）应该根据企业类型变化而重置。Claude Code 完全没有处理“步骤间数据联动”的场景。

修正过程： 我在 prompt 中补充了“当企业类型变化时，重置第二步中的相关字段”。Claude Code 在第二轮生成了正确的 watch 逻辑。

最终评价： 修正后代码可用，耗时 12 分钟（vs 预计手写 50 分钟）。但“步骤间数据依赖”这个需求需要人工识别并提出，AI 不会主动发现。

场景二：实时搜索 + 防抖 + 下拉建议

业务背景： 一个电商搜索框，用户输入时实时展示搜索建议（防抖 300ms），选中建议后跳转到对应商品页。

Prompt： “输入框搜索建议功能，防抖 300ms，调接口获取建议列表，支持键盘上下选择。”

生成结果评估：

首次生成功能完整。ref 管理输入值和选中项，watch + setTimeout 实现防抖，键盘事件的上下箭头和回车键处理都有。

三个需要修正的问题：

1. 竞态处理缺失，快速输入导致旧请求结果覆盖新请求的问题（这是测试中最常见的 bug 类型）
2. 选中建议后未清空建议列表，用户选中一个建议后，建议下拉框应该关闭
3. 未处理请求失败时建议列表的状态，API 报错时，之前的建议列表还显示着，应该清空

修正耗时 8 分钟，最终可用。 竞态处理用了请求序号方案，属于标准解法。

场景三：权限指令与组合函数的配合

业务背景： 后台系统中，很多按钮和区块需要根据用户权限显示/隐藏。项目中既有自定义指令 v-permission，也有组合函数 usePermission。

Prompt： “实现一个权限检查系统。使用 v-permission 指令控制 DOM 元素的显示，同时提供一个 usePermission 组合函数用于逻辑判断。”

生成结果评估：

这是一个“中等偏上”的生成结果。指令和组合函数都正确实现了，使用 inject 从顶层注入权限列表，指令内部调用组合函数。

但缺少了一些企业级项目必要的设计：

• 权限码的常量定义和枚举化管理（它用了字符串字面量）
• 权限变更时的响应式更新（指令的 updated 钩子是空的）
• 没有处理“权限列表异步加载”的场景

这个场景的教训： AI 能生成“能跑的代码”，但“架构设计”层面的考量（常量管理、异步初始化、变更响应）需要人工补充。

场景四：Pinia Store 的模块化设计

业务背景： 一个电商项目的用户模块和购物车模块，分别放在两个 Pinia Store 中，购物车 Store 需要读取用户 Store 的登录状态。

Prompt： “使用 Pinia 创建两个 store：useUserStore 和 useCartStore。购物车在添加商品时需要检查用户是否已登录。”

生成结果评估：

这是正确率较高的场景。两个 Store 的结构清晰，useCartStore 中通过 useUserStore() 获取用户状态的写法正确。

微小的瑕疵：

• 购物车 Store 的 addToCart 方法中，登录检查是同步的，没有考虑“登录状态可能因 token 过期而异步变化”的场景
• 没有使用 Pinia 的 storeToRefs 来解构响应式属性，直接用了 .value

总体可用，修正成本低。 这说明“标准的 Store 互调”是一个 AI 训练数据充足的场景。

场景五：数据看板的异步数据加载与错误降级

业务背景： Dashboard 页面，四张卡片分别展示不同的 KPI，四张卡片独立请求数据。某张卡片请求失败时，不影响其他卡片正常展示。

Prompt： “Dashboard 页面，四张 KPI 卡片，每张独立请求数据。使用 Vue 3 组合式 API。”

生成结果评估：

首次生成的代码用四个组合函数分别管理每张卡片的数据。思路是对的。

一个问题： 它用了一个统一的 try-catch 包裹了四个请求，一个失败会导致整个页面显示错误状态，这恰好违背了 prompt 中“独立请求”的设计意图。

修正： 指定每个 useKpiCard 内部独立处理错误，将错误状态限制在卡片级别。

这个场景暴露了 AI 的一个深层局限：它理解了“独立请求”的实现方式（四个分开的请求函数），但没有理解其设计意图（故障隔离）。

八、什么样的 Vue 3 代码 AI 能写好，什么样的写不好

经过 127 次生成任务的观察，我总结出了一条“可生成性”的频谱。

高可生成性（正确率 > 85%）：

• 纯 UI 组件，按钮、表单、表格、卡片、弹窗等，逻辑仅限于显隐切换、类名计算、事件转发
• 标准 CRUD 操作，列表查询、创建、编辑、删除，有固定模式可循
• 单一数据源的展示逻辑，数据来自一个 API，展示在一个视图中
• 无时间依赖的纯函数，输入确定则输出确定的计算逻辑
• ECharts / 图表配置对象的生成，有明确的 JSON schema

中可生成性（正确率 60-85%）：

• 多数据源的聚合展示，需要处理异步时序
• 表单校验，基本规则覆盖好，自定义校验函数需人工修正
• Pinia Store 的基础结构设计
• 路由参数与页面状态的交互

低可生成性（正确率 < 60%，强烈建议人工主导）：

• 涉及金钱、库存、权限的精确计算逻辑
• 复杂的异步调度与竞态处理
• 性能敏感的大数据量渲染
• 跨组件、跨模块的状态同步
• 第三方 SDK 集成（支付、地图、IM）的不常见用例
• 业务特有的异常处理与降级策略

这个频谱图的价值在于：你不需要每次都测试一遍才能判断。看你的任务落在哪个区间，就能提前预判 AI 的表现。 这是一个可以复用的决策框架。

九、三个容易被忽略的真相

前面讲了很多测试数据和分类结论，这一节我想谈三个更底层的观察。它们不是具体的 bug 或功能缺陷，而是架构层面的考量。

9.1 “上下文窗口”不等于“项目理解”

Claude Code 宣传自己拥有超长上下文窗口，这给人一种错觉：我给它整个项目的代码，它就能理解整个项目，然后生成契合项目架构的代码。

实际情况是：它能“看到”更多代码，但不代表它能“理解”代码之间的关系。 我把一个包含 47 个 Vue 组件的项目完整提供给 Claude Code，然后让它在一个子组件中新增一个功能，这个功能需要调用另一个模块的 Store 方法。

它成功找到了目标 Store 文件，正确引入了 useXxxStore，方法名也是对的。但在错误处理方式上，它使用了 .catch() 而项目中其他所有地方都使用 try-catch，这个风格不一致的问题说明它并没有感知到项目的编码规范，只是“看到了”文件结构。

上下文窗口解决了“找不到”的问题，但没解决“融进去”的问题。

9.2 它擅长“翻译”，不擅长“设计”

这是我给 Claude Code 下的一个总体判断。

什么叫“翻译”？已知 Options API 的代码，改写成 Composition API，它能做得很好。已知一个功能的需求文档，转换成代码骨架，它能做得很好。

什么叫“设计”？一个模块应该拆成几个组合函数？每个组合函数的职责边界在哪里？接口怎么设计才能支持未来的扩展？

它不理解什么叫“未来会变的需求”，所以不会为变化做预留设计。 它生成的代码是“刚好满足当前需求的”，这是它的强项，也是它的局限。现实项目中，需求的稳定性远比技术实现的质量更影响架构决策，而这个维度的判断力 AI 完全没有。

9.3 它让你写更多 Prompt，但不保证你写对了 Prompt

这可能是最反直觉的一个观察。

Claude Code 的生成质量高度依赖 prompt 质量。一个逻辑完备、边界清晰、附带正反例的 prompt，能显著提升生成结果。但问题在于：能写出这种 level 的 prompt 的人，本身就已经具备了独立完成这个任务的专业能力。 他之所以选择 AI，不是因为不会写，而是因为想让 AI 承担执行层的工作，自己去做更高层的设计。

而对于那些不具备独立完成能力的人，比如 Vue 3 初学者，他们写的 prompt 往往是模糊的、主观的、缺少技术细节的。AI 会忠实执行一个模糊的 prompt，生成一段看似正确、实则充满隐性缺陷的代码，而缺乏分辨能力的初学者会信任这段代码。 这才是 AI 辅助编程最大的风险所在。

十、行动指南：在不同场景下怎么用 Claude Code 才是“全面”的

基于以上的全部测试和分析，我给出一套可操作的决策框架。

第一步：给任务分级

在向 Claude Code 提需求之前，先用 30 秒判断任务属于哪个级别：

L1 ， 样板代码任务： 你能在 10 秒内想清楚完整逻辑、所有边界情况、所有类型定义的代码。“明确而繁琐”，这是 AI 的最佳应用场景。

L2 ， 探索性任务： 你知道需求，但不确定最佳实现方式。想借 AI 生成几个方案供参考。“方向清晰、路径模糊”，AI 可以当辅助。

L3 ， 复杂度任务： 涉及多模块交互、复杂业务规则、性能敏感场景。“你需要认真设计，AI 执行其中的子任务”，人工主导，AI 辅助。

第二步：匹配策略

第三步：建立审查清单

不管哪个级别，以下检查项必须人工执行（没有例外）：

类型安全类：

• [ ] 搜索代码中所有的 as any、as unknown as，逐一确认是否有合理替代
• [ ] 检查复杂泛型函数的返回类型是否被正确推导
• [ ] 验证 API 返回数据与前端类型定义之间的映射是否有遗漏

逻辑正确类：

• [ ] 检查所有涉及异步操作的地方是否有竞态保护
• [ ] 验证互斥规则、优先级规则的组合是否正确
• [ ] 模拟边界输入（空值、极大值、并发操作）进行测试

性能与健壮类：

• [ ] 检查所有副作用（事件监听、定时器、订阅）在组件销毁时是否清理
• [ ] 大列表是否使用了虚拟滚动或分页
• [ ] 是否存在 watch 可用 computed 替代的情况

可维护性类：

• [ ] 是否存在超过 50 行的函数体
• [ ] 魔法数字和硬编码字符串是否提取为常量
• [ ] 组合函数的职责边界是否清晰

第四步：接受现实

Claude Code 不会让你的工作消失，但它会改变你的工作内容。 你花在“写基础代码”上的时间会大幅减少，但花在“审查 AI 生成的代码”上的时间会增加。你从“执行者”变成一个“审查者 + 架构决策者”。

如果你享受“从零开始敲代码”的过程，这个转变可能让你不舒服。但如果你更在意的“最终交付的质量和效率”，那么学会与 AI 高效协作是 2025 年绕不开的技能。

十一、所以，“全面”吗？

回到最初的问题：Claude Code 对 Vue 3 组合式 API 的代码生成是否全面？

如果你定义的“全面”是：能覆盖所有语法元素的生成，能在大部分常见场景中给出一个功能基本正确的初始版本，那么答案是：相当全面。

如果你定义的“全面”是：生成的代码类型安全、性能优秀、可维护、健壮且不需要人工审查就能直接上线，那么答案是：远不全面。

这两个“全面”之间的差距，不是一个技术问题，而是一个期望管理问题。

我的建议是：不要把 Claude Code 当作一个“代码生成器”来用，而应该把它当作一个“高质量草稿生成器”来用。 它给你一个不错的起点，你在这个基础上做精修和加固。人工负责“正确性”和“设计感”，AI 负责“速度”和“覆盖面”。 两者结合，才是真正的“全面”。

下一步做什么？ 如果你正在考虑在 Vue 3 项目中引入 Claude Code，建议从 L1 级别的任务开始，生成你明确知道正确答案的基础代码，感受它的工作节奏和输出风格。用两周时间建立你对它能力的直观认识，再逐渐扩展到更复杂的任务。不要在第一个项目就把最复杂的业务逻辑交给它，那几乎一定会让你失望。

了解工具的边界，比了解工具的功能更重要。 因为功能决定了你能走多快，边界决定了你会摔多惨。