Vue 项目中的 Vibe Coding 实战指南
Vibe Coding 这个词,通俗来说就是——你提需求,AI 动手实现。你描述目标,AI 阅读代码、修改代码、执行命令;你负责方向把控、成果验收与关键决策。简单讲,就是用自然语言与 AI(比如 Cursor Agent)协作完成软件开发。

本指南专门面向 Vue 3 项目,旨在提供一套可重复、可落地、不空谈的 Vibe Coding 工作流程——从如何明确业务需求,到技术如何选型、架构怎样设计、Skill 和 Rule 如何制定,再到日常开发与质量保障。它不限定于特定业务,但可以作为任何 Vue 项目的启动模板来使用。
1. 核心理念:Vibe Coding ≠ 无约束地生成代码
许多 Vibe Coding 项目最后都出了问题。究其原因,套路几乎一样:需求草草带过 → AI 直接修改代码 → 风格不一致、架构走形、后续维护困难。
正确的做法是 “人定方向 + AI 执行 + 机器校验” 三段式:
人:业务目标、边界、验收标准
AI:调研、选型建议、实现、重构、补充测试
机器:ESLint / vue-tsc / Vitest / CI / Git Hook
规矩越前置,AI 就越像一位“带规范的结对程序员”,而非“碰运气的代码生成器”。规矩就是那道“软约束”,先把框架立好,再让 AI 动手。
2. 完整流程总览
| 阶段 | 人的职责 | AI 的职责 | 产出物 |
|---|---|---|---|
| ① 需求澄清 | 明确用户、场景、约束、验收标准 | 追问遗漏点、整理 PRD 草稿 | 需求说明 / 用户故事 |
| ② 技术选型 | 最终拍板方案 | 对比方案、列出 trade-off | ADR / 技术栈文档 |
| ③ 架构设计 | 确认分层与边界 | 目录结构、模块图、数据流 | docs/architecture.md |
| ④ Skill | 决定安装哪些、是否自研 | 检索社区 Skill、起草 SKILL.md | .cursor/skills/ |
| ⑤ Rules + Lint | 确认团队规范 | 生成 .mdc、补充 ESLint 规则 | .cursor/rules/、lint 配置 |
| ⑥ 迭代开发 | 拆分任务、验收 | 读取上下文、小步修改代码 | 功能代码 |
| ⑦ 验证 | 关键路径人工测试 | 运行 lint/test、修复报错 | 可合并的 PR |
原则:先文档与规矩,再写功能;先架构与边界,再让 AI 操作。
3. 阶段 ①:澄清业务需求(一切起点)
在让 AI 写任何一行代码之前,先要把需求讲清楚,达到 AI 和人都能准确执行 的程度。模糊的需求是翻车的首要原因。
3.1 需求应包含的要素
| 要素 | 说明 | 示例 |
|---|---|---|
| 用户与场景 | 谁在使用、在什么设备/环境下使用 | iPad 横屏排练、后台运营人员 |
| 核心用户旅程 | 从开始到完成目标的步骤 | 登录 → 选择项目 → 编辑 → 导出 |
| 功能边界 | 做什么、不做什么 | 本期不做离线同步、不做多租户 |
| 非功能需求 | 性能、兼容性、安全性、合规性 | 首屏 < 3s、支持 Chrome/Safari、数据不出境 |
| 验收标准 | 可测试的完成定义 | “导出的文件可被 X 软件打开且无乱码” |
| 现有约束 | 必须沿用的技术栈、设计系统、API | 已有 REST 后端、必须使用 Element Plus |
3.2 用 AI 帮忙“补全需求”
很多时候,需求初稿都不够完整。你可以先让 AI 扮演 需求分析师,而不是程序员:
我是一个 Vue 3 前端开发者,需要实现 [一句话描述]。
请列出:① 可能遗漏的用户场景 ② 边界情况 ③ 非功能风险 ④ 需要我确认的问题清单。
不要写代码,只输出结构化的需求追问。
AI 应输出一个 问题清单,你逐条回答后,才能进入下一阶段。要避免 AI 在假设尚未验证的情况下,直接替你选型或开始编码。
3.3 需求文档最小模板
建议在 docs/ 或 Issue 中保留一份短 PRD,一页以内即可:
# [功能名]## 背景
## 用户与场景
## 用户故事(As a … I want … So that …)
## 范围(In / Out)
## 验收标准(Given / When / Then 或 checklist)
## 依赖与风险
后续所有的 Architecture、Skill、Rule、Prompt,都应能够 回溯到这份 PRD。这是根基,根基稳固,上层才不会歪斜。
4. 阶段 ②:AI 辅助技术选型
需求明确后,再讨论“用什么技术实现”。这一步需牢记:AI 提供建议,人做决策。选型不能拍脑袋,也不能依赖代码生成。
4.1 选型时要提供给 AI 的上下文
业务需求:[粘贴 PRD 摘要]
团队能力:[熟悉 Vue,不熟悉 React Native]
硬性约束:[必须 Web + 可选 App、后端已是 Ja va、部署在阿里云]
偏好:[TypeScript、倾向开源、可接受 WASM 体积]
请给出 2~3 套前端技术方案,对比:开发效率、维护成本、包体积、生态、风险。
最后给出推荐方案与“若不选推荐方案的后果”。
不要直接生成项目代码。
4.2 Vue 项目常见选型维度
| 维度 | 典型选项 | 选型考量 |
|---|---|---|
| 框架 | Vue 3 | 团队主栈;默认使用 Composition API + |
| 构建 | Vite | 生态默认;SSR 需 Nuxt |
| UI 库 | Element Plus / Naive UI / Vant / Ionic Vue | B 端 vs C 端 vs 移动端壳 |
| 状态管理 | Pinia | 全局状态;服务端状态可用 TanStack Query |
| 路由 | Vue Router | 标准方案 |
| 跨端 | Capacitor / uni-app | 原生能力 vs 一套代码多端 |
| SSR/SSG | Nuxt 3 | SEO、首屏性能、同构 |
| 测试 | Vitest + Vue Test Utils + Playwright/Cypress | 单元测试 + E2E 分工 |
| 样式 | Tailwind / SCSS / CSS Modules | 与设计系统是否一致 |
4.3 输出:技术决策记录(ADR)
让 AI 把结论整理成 Architecture Decision Record。这能防止 AI 在后续对话中擅自更换技术栈:
# ADR-001:前端技术栈## 状态:已采纳
## 背景
## 决策
- Vue 3 + Vite + TypeScript + Pinia + Vue Router
- UI:Element Plus
## 备选方案及未采纳原因
## 后果(正面 / 负面)
把这个 ADR 放入仓库(如 docs/adr/),同时在 .cursor/rules/ 中添加一条 alwaysApply 规则,引用这个主栈。这样 AI 就不会擅自给项目引入 React 或 Options API 全家桶了。
5. 阶段 ③:AI 辅助架构设计
选型确定后,先画架构再写页面。这是 Vibe Coding 中最容易被跳过、也最容易翻车的步骤。很多人觉得“代码能跑就行”,结果后期维护痛苦不堪。
5.1 架构设计要回答的问题
- 代码放在哪里?(目录与分层)
- 数据如何流动?(Props / Emit / Store / API / 本地缓存)
- 哪些是纯逻辑、哪些是 UI?(可否单元测试)
- 模块边界是什么?(谁不能 import 谁)
- 扩展点在哪里?(新页面、新 API、新插件)
5.2 推荐 Prompt:让 AI 出架构草案
基于以下 PRD 和 ADR,为 Vue 3 项目设计前端架构。要求:
1. 给出 src/ 目录树及每个目录的一句话职责
2. 画数据流(用户操作 → 组件 → composable → api/lib → 后端/存储)
3. 说明 Pinia store 与 composable 的分工原则
4. 列出 3 条“禁止事项”(如:页面组件不得直接 axios、lib 不得 import .vue)
5. 给出 2~3 个核心模块的组件拆分草图(props/emits)约束:Composition API + script setup;不引入新框架。
输出 markdown,不要写实现代码。
5.3 Vue 项目通用分层模型
这一套模型适用于大多数中大型 Vue 应用:
src/
├── views/ # 路由级页面:编排、布局、组合 composable
│ └── feature/
│ ├── IndexPage.vue
│ └── components/ # 仅该 feature 使用的子组件
├── components/ # 跨 feature 复用的展示组件
├── composables/ # useXxx:组合式逻辑、副作用、与 Vue 生命周期绑定
├── stores/ # Pinia:跨页面共享、可持久化的应用状态
├── api/ # HTTP 客户端、请求封装、DTO 类型
├── lib/ # 纯 TS 领域逻辑(无 Vue 依赖,易于单元测试)
├── router/
├── assets/
└── types/
经验法则:
| 层级 | 放置内容 | 不放置内容 |
|---|---|---|
views/ | 页面编排、路由参数、组合子面板 | 复杂算法、直接 DOM 操作 |
composables/ | 表单状态、分页、轮询、与 ref 绑定的逻辑 | 与 UI 无关的纯计算(应下沉到 lib) |
stores/ | 用户信息、全局 UI 偏好、购物车等 | 巨型“万能 store” |
lib/ | 格式化、校验、解析、业务规则 | import { ref } from 'vue' |
api/ | REST/GraphQL 调用 | 业务分支判断 |
5.4 架构文档应固化到仓库
AI 生成的架构草案,经你修订后,写入 docs/architecture.md。内容需包含:
- 目录约定
- 数据流图(推荐使用 mermaid)
- Store 划分表
- 命名规范(组件、composable、emit)
- 与后端/API 的边界
之后在每次开发的 Prompt 中,都可以写上:“遵循 docs/architecture.md”。有了这句话,AI 就不会自己搞出一套新目录结构了。
5.5 用 AI 做“架构 Review”
首版架构或重大功能上线前,让 AI 帮你 Review 一下:
阅读 docs/architecture.md 和 src/views/order/ 下的实现。
找出:① 违反分层的文件 ② 重复逻辑 ③ 难以测试的部分 ④ 建议拆分的 composable。
输出优先级 P0/P1 的重构清单,不要直接改代码。
6. 阶段 ④:查询、安装与定义 Skill
Skill 是什么?它是教 AI 如何完成某类任务 的操作手册,包含工作流、检查清单、领域步骤。它存放在:
- 项目级:
.cursor/skills/(团队共享,随仓库版本管理) - 个人级:
~/.cursor/skills/(跨项目)
6.1 Skill 与 Rule 的分工
| Skill | Rule | |
|---|---|---|
| 作用 | 教“怎么做一件事”的流程 | 约束“在这个项目里必须/禁止怎样写” |
| 粒度 | 任务型(写 composable、做 Code Review) | 规范型(目录、命名、分层) |
| 示例 | vue-best-practices | globs: **/*.vue 的组件约定 |
两者相互补充:Skill 管方法,Rule 管边界。
6.2 如何“查询”现有 Skill
社区与官方来源:
- vuejs-ai/skills — Vue / Pinia / composable 等
- Cursor 文档与社区分享的 Skill 仓库
- 团队内部 Git 仓库中的
.cursor/skills/
安装方式示例:
# Cursor CLI(网络可达时)
npx skills add vuejs-ai/skills
--skill vue-best-practices
--skill vue-pinia-best-practices
-a cursor -y
Vue 项目常见起步 Skill:
| Skill | 用途 |
|---|---|
vue-best-practices | Composition API、SFC、组件拆分、响应式 |
vue-pinia-best-practices | Store 写法、解构陷阱、持久化 |
create-adaptable-composable | MaybeRef 可复用 composable |
在 Prompt 中要 显式激活:Use vue skill, …(具体的调用方式,以 Cursor 当前版本为准)。
6.3 何时需要“自定义 Skill”
社区 Skill 覆盖的是 框架通用实践,不覆盖你独特的 业务领域。出现以下情况,就应该自研 Skill:
- 有固定的领域工作流(比如“新增一种导出格式”的 6 步检查清单)
- 有第三方 SDK 的非 obvious 用法(WASM、Canvas、WebRTC)
- 有团队统一的 PR Review / 发布流程
- 同一类任务,AI 反复犯同样的错误
6.4 自定义 Skill 的结构
.cursor/skills/your-domain-feature/
├── SKILL.md # 必需:frontmatter + 步骤说明
├── reference.md # 可选:详细 API、协议
└── examples.md # 可选:正反例
SKILL.md frontmatter 示例:
---
name: vue-feature-module
description: >-
Add a new feature module to this Vue app: views, composable,
api, and tests. Use when creating routes or feature folders.
---
正文应包含:
- 触发条件(何时使用本 Skill)
- 分步工作流(有序步骤,可勾选)
- 必须阅读的仓库文件列表
- 完成后的验证命令(
npm run lint等) - 反模式(不要做什么)
让 AI 帮你起草 Skill:
我们项目做 [领域简述]。AI 在 [具体任务] 时经常 [犯错描述]。
请为 Cursor 起草一个项目 Skill:name、description、分步 workflow、
验证清单、3 条 anti-patterns。格式符合 SKILL.md frontmatter 规范。
6.5 Skill 维护
- 与代码一起 PR Review;Skill 过时了,比没有 Skill 更危险
- 大 Skill 拆成
SKILL.md+reference/,避免单次上下文过长 - 在
docs/或.cursor/skills/README.md记录安装与更新命令
7. 阶段 ⑤:定义 Rules 与 Lint(为 IDE 立规矩)
Skill 解决“怎么做”,Rule + Lint 解决“不能越界的线”。规矩立得硬,代码质量才有下限。
7.1 Cursor Rules(.cursor/rules/*.mdc)
建议按关注点拆分,而不是一个巨型 rule 文件:
| Rule 文件 | globs 示例 | 内容 |
|---|---|---|
vue-core.mdc | **/*.{vue,ts} | script setup、路径别名、命名 |
vue-pages.mdc | **/*.vue | 页面 / 组件放置、props-emits |
pinia-stores.mdc | src/stores/** | store 命名、持久化、storeToRefs |
api-layer.mdc | src/api/** | 错误处理、类型、禁止在组件里裸 fetch |
domain-lib.mdc | src/lib/** | 纯 TS、禁止 import Vue |
project-stack.mdc | alwaysApply: true | ADR 摘要:栈、测试命令、分支策略 |
Rule 编写原则:
- 每条规则 可执行(“用 storeToRefs”而非“注意响应式”)
- 引用 仓库内真实路径 作为范本(
参考 src/stores/user.ts) - 控制在 50 行以内 为宜;细节放
docs/ - 使用
globs精准触发,减少无关上下文噪音
让 AI 生成 Rule 草案:
根据 docs/architecture.md,生成 3 个 Cursor rule 文件(.mdc):
1. Vue 页面与组件放置
2. Pinia store 约定
3. src/lib 纯函数边界
每个 rule 含 frontmatter(description、globs)、条目化约束、一个正确示例。
7.2 ESLint + TypeScript + Git Hook
AI 生成的代码,必须通过 机器门禁。这是硬兜底,否则 Vibe Coding 不可持续。
推荐基线(Vue 3 + TS):
eslint + eslint-plugin-vue + @vue/eslint-config-typescript
vue-tsc(类型检查)
Vitest(单元测试)
husky + lint-staged(提交前)
CI 中复跑 lint / typecheck / test
package.json 脚本示例:
{
"scripts": {
"lint": "eslint src tests",
"typecheck": "vue-tsc --noEmit",
"test:unit": "vitest run"
},
"lint-staged": {
"*.{vue,ts,js}": "eslint --max-warnings 0"
}
}
.husky/pre-commit:
npm run typecheck
npx lint-staged
在 Rule 或 Skill 中写清楚:“改完代码必须跑 lint + typecheck”,并且在 Prompt 末尾也附上相同要求。
7.3 可选:AGENTS.md
有些团队会在根目录加一个 AGENTS.md,相当于给 AI 一份 项目入口说明(如何启动、测试命令、目录地图、链接到 architecture)。与 Rules 类似,但更偏“入职引导索引”。
8. 阶段 ⑥:日常 Vibe Coding 开发循环
规矩就绪后,进入高频迭代。推荐 单次任务一个闭环,不要一把梭。
8.1 任务拆分
把 PRD 拆成 可在一个会话内完成 的小任务:
- “订单列表页:composable 分页 + 表格组件 + 空状态”
- “把整个电商后台做完”
8.2 标准 Prompt 模板
Use vue skill.## 背景
[链到 PRD 或 architecture 的一两句话]## 任务
[具体、可验收的一句话]## 约束
- 遵循 docs/architecture.md 与 .cursor/rules/vue-pages.mdc
- 不修改 [明确不动的模块]
- Composition API + script setup + TypeScript## 相关文件(可选)
@src/views/order/IndexPage.vue## 完成后
npm run lint && npm run typecheck && npm run test:unit
简述改动文件与如何手动验证。
8.3 AI 开发逻辑(Agent 侧应遵循的顺序)
1. 读需求与约束 → 确认任务范围
2. 读 architecture、相关 rule、现有同类代码
3. 规划改动文件列表(先列表,再动手)
4. 小步修改:优先 lib/composable,再改 UI
5. 跑 lint / typecheck / test,修到通过
6. 输出:改了什么、如何验证、已知限制
Vue 特有注意点:
- 新组件默认
,Props down / Emits up - 从 Pinia 解构状态用
storeToRefs - 列表性能:大列表考虑虚拟滚动;避免在列表项里堆抽象组件
- 路由级页面做 编排,业务逻辑进 composable / lib
8.4 适合交给 AI 的工作
| 类型 | 示例 |
|---|---|
| 样板代码 | CRUD 表格、表单、对话框、路由注册 |
| 重构 | 从巨型 .vue 抽 useXxx |
| 类型与 lint | 补类型、修 ESLint、修 vue-tsc 报错 |
| 测试 | 为 lib/ 纯函数写 Vitest |
| 文档 | ADR、API 说明、组件 props 文档 |
8.5 需人工主导、AI 辅助的工作
| 类型 | 原因 |
|---|---|
| 安全与权限模型 | AI 易遗漏边界 case |
| 支付、隐私、合规 | 需法务/安全 review |
| 核心领域算法 | 需规格 + 单元测试 + 人工验算 |
| 包体积与性能预算 | 需性能分析,非猜测 |
| 破坏性 API 变更 | 需版本策略与迁移计划 |
9. 阶段 ⑦:验证、Review 与持续改进
9.1 验证层次
L1 机器:lint + vue-tsc + unit test(每次提交)
L2 本地:npm run dev 手动走用户旅程
L3 集成:E2E(Playwright / Cypress)关键路径
L4 人审:架构边界、安全、UX、无障碍
Prompt 中要求 AI 自己跑 L1;L2~L4 由你或 CI 负责。
9.2 用 AI 做 Code Review
Review 本次 diff(不要改代码):
1. 是否违反 docs/architecture.md
2. 是否有重复逻辑可抽 composable/lib
3. 是否有明显性能问题(大列表、watch 滥用)
4. 测试是否覆盖核心分支
输出按严重程度排序的 findings。
9.3 从失败中更新 Skill / Rule
如果 AI 重复犯同一错误,一个有效的思路是:
- 不要只在聊天里纠正一次
- 把纠正写进 Rule(硬约束)或 Skill(流程步骤)
- 必要时加 单元测试 锁定行为
Vibe Coding 的复利来自:每一次翻车都让规矩变强一点。
10. Vibe Coding 的优劣(Vue 项目视角)
10.1 优势
| 优势 | 说明 |
|---|---|
| 交付速度快 | 表单、列表、路由、Store 样板极快 |
| 降低入门成本 | 新人通过对话 + architecture 快速定位模块 |
| 规范可编码 | Skill + Rule 把团队习惯注入 AI 上下文 |
| 重构友好 | “抽到 composable”类机械搬迁 AI 擅长 |
| 文档即 spec | PRD / ADR / architecture 可直接当 Prompt 附件 |
10.2 劣势与风险
| 风险 | 表现 | 缓解 |
|---|---|---|
| 上下文有限 | 漏读关联文件,改了一处坏另一处 | 小任务、显式 @ 文件、先规划后改 |
| 架构漂移 | 每个会话一种写法 | ADR + Rules + architecture 固化 |
| 幻觉 API | 编造不存在的 Vue 库 API | 以 lockfile 和现有代码为准;typecheck 兜底 |
| 上帝组件 | 逻辑全堆进 .vue | Rule 限制 + 强制 composable 拆分 |
| 测试债务 | 改完不跑 test | pre-commit + Prompt 要求跑 test |
| 过度抽象 | 无意义的 helper 层 | “最小 diff”写进 Rule |
| 隐私 | 业务数据进入模型 | 企业隐私设置、脱敏、本地模型(若可用) |
10.3 何时适合 / 不适合
适合 Vibe Coding:
- greenfield 或中等复杂度的 Vue 功能模块
- UI 迭代、Design system 落地
- 技术债清理(lint、类型、拆组件)
- 有清晰 PRD 和 architecture 的迭代
应降低 AI 自主权:
- 金融、医疗等强合规场景的核心链路
- 无规格的复杂算法
- 大规模迁移(Vue 2→3、换 UI 库)需分阶段人工掌舵
11. 新项目 Checklist(可直接复制)
## Vibe Coding 启动清单- [ ] PRD:用户、范围、验收标准
- [ ] ADR:Vue 3 技术栈定稿
- [ ] docs/architecture.md:目录、数据流、Store 划分
- [ ] 安装社区 Vue Skill(vue-best-practices 等)
- [ ] 自定义领域 Skill(如有)
- [ ] .cursor/rules/:vue / pinia / api / lib 分层规则
- [ ] ESLint + vue-tsc + Vitest + husky
- [ ] CI:lint + typecheck + test
- [ ] 首个 feature 用小任务 + 标准 Prompt 试跑一轮
- [ ] 根据翻车更新 Rule / Skill
12. 附录:Prompt 速查
需求澄清
针对 [功能],列出必须确认的 10 个问题,按优先级排序。不要写代码。
技术选型
给定 PRD 和约束,输出 2 套 Vue 前端方案对比表 + 推荐 ADR 草稿。
架构设计
输出 src/ 目录树、数据流 mermaid、Pinia 划分、3 条禁止事项。不要写实现。
创建 Skill
为 [任务类型] 起草 .cursor/skills/xxx/SKILL.md,含 workflow 与 anti-patterns。
创建 Rule
根据 architecture 生成 .mdc rule:globs、可执行条目、正例一行。
功能开发
Use vue skill. 任务:… 约束:architecture + rules. 完成后 lint + typecheck + test。
架构 / Code Review
Review [路径或 diff],只输出 findings,按 P0/P1 排序,不改代码。
13. 总结
正确的 Vue Vibe Coding 路径:
- 先讲清业务 — PRD 与验收标准是一切的前提
- 再让 AI 帮选型与架构 — 人拍板,AI 调研与起草,结果写入 ADR / architecture
- 然后立规矩 — 社区 Skill + 自研 Skill + Cursor Rules + Lint/Hook
- 再小步开发 — 显式约束、读现有代码、最小 diff、机器验证
- 最后从失败中迭代规矩 — Rule / Skill / 测试与文档同步进化
Vibe Coding 的价值不在于“少写代码”,而在于 在明确边界内放大实施速度。边界越清晰,AI 越可靠;规矩越薄,翻车越频繁。
