01# Vibe Coding工作流设计思维：前端开发者的协作框架

Vibe Coding工作流设计思维：前端开发者的协作框架

上周我接手了一个任务管理应用的重构。原开发者用AI生成了大量Vue组件，但组件之间样式不统一，状态管理混乱，连基本的拖拽排序都跑不起来。我花了两天时间才理清逻辑，重新设计了组件结构。

我用了两天才理清逻辑，重新设计了组件结构。问题很清楚：Vibe Coding是"指挥AI写代码"。如果前端开发者不建立正确的工作流思维，AI生成的代码只会制造更多技术债。

前端Vibe Coding的特殊性

前端开发和后端开发在Vibe Coding中有本质区别。后端逻辑相对独立，一个函数、一个API接口可以单独验证。但前端是一个整体。组件嵌套、状态联动、样式叠加，牵一发而动全身。

你让AI"做一个任务卡片组件"，它可能给你一个能用的组件，但样式不符合你的设计系统，状态管理方式和你项目里的Pinia冲突，甚至引入了你项目里没有的依赖。前端Vibe Coding需要更精细的规划和配置。

组件化思考：让AI理解你的设计模式

在传统开发中，你设计组件结构时会在脑子里过一遍：这个组件需要哪些props，状态放在哪里，和父组件怎么通信。

在Vibe Coding中，这些思考必须提前写成明确的指令。AI不会主动去猜测你的组件设计模式，它只会按照它认为"合理"的方式生成代码。

我通常会在AGENTS.md或.cursorrules里写清楚：

组件设计原则：
1. 所有组件使用Composition API + <script setup>
2. 状态管理统一使用Pinia，不在组件内滥用ref/reactive管理跨组件状态
3. 样式使用Tailwind CSS，不写自定义CSS
4. 组件文件结构：组件逻辑、类型定义、样式（如果有）放在同一个文件
5. 公共组件放在src/components/ui，业务组件放在src/components/features

这些不是"建议"，而是"约束"。AI生成代码时会严格遵守这些规则。

迭代式开发：从骨架到细节

前端开发最怕的是"一步到位"。你让AI"实现完整的任务管理功能"，它可能给你一个几百行的大组件，里面包含了所有逻辑，根本无法维护。

正确的做法是迭代式开发。我通常分三步，每步都有明确的目标和验证标准。

第一步：搭骨架（30分钟） 让AI生成基础组件结构，只要能跑通，不需要完美。这时候的验证标准是：组件能渲染，没有控制台错误。

比如TaskCard组件，我只要求它显示任务标题和状态标签。没有样式，没有交互，甚至连数据都是写死的。但这一步很重要，因为它确立了组件的基本结构：props有哪些，events有哪些，组件在页面中的位置。

我会给AI这样的提示词：

创建TaskCard.vue组件，要求：
1. 使用<script setup>和TypeScript
2. Props：task对象（id, title, status, priority）
3. 只显示标题和状态标签（待办/进行中/已完成）
4. 不需要样式，不需要交互
5. 导出组件

第二步：加逻辑（1-2小时） 在骨架基础上，逐步添加功能。每添加一个功能，就验证一次。验证标准是：功能正常，没有引入新的bug。

顺序很重要。我通常按这个顺序：

1. 状态切换（点击状态标签可以切换状态）
2. 编辑功能（双击标题可以编辑）
3. 删除功能（点击删除按钮可以删除）
4. 拖拽排序（可以拖动改变顺序）

每一步都让AI只修改相关部分。比如做状态切换时，我只要求AI：

给TaskCard组件添加状态切换功能：
1. 点击状态标签时，在todo/in-progress/done之间循环切换
2. 切换时触发update:status事件
3. 状态标签用不同颜色区分：todo灰色，in-progress蓝色，done绿色
4. 其他功能不变

这样每次改动都很小，如果出问题很容易定位。

第三步：调细节（3-4小时） 逻辑通了之后，再调整样式、动画、响应式布局。这时候可以给AI看设计稿，让它微调UI。

这一步最耗时，但也是最出效果的。我会分几个子步骤：

1. 基础样式：宽度、间距、字体、颜色
2. 交互状态：hover效果、active状态、focus样式
3. 动画效果：过渡动画、加载状态
4. 响应式：移动端适配、平板适配

每一步都要求AI只修改样式，不改变逻辑。这样如果样式出问题，逻辑还是好的。

这种迭代方式有两个好处：一是每次改动小，容易验证；二是如果AI改坏了，容易回退。最重要的是，你始终知道代码的状态，不会失控。

自动化验证：让AI帮你测试

前端测试是Vibe Coding中最容易忽略的环节。AI生成的代码可能看起来能用，但边界情况、错误处理、性能问题都需要验证。

我通常会配置自动化测试工作流。在.cursorrules里写：

测试要求：
1. 每个公共组件必须有单元测试（Vitest + Vue Test Utils）
2. 关键交互流程必须有E2E测试（Cypress）
3. 测试文件放在组件同目录，命名为ComponentName.test.ts
4. 测试覆盖率要求：语句覆盖80%，分支覆盖70%

然后让AI生成代码时，同时生成对应的测试用例。这样每次修改后，跑一遍测试就能发现问题。

实践项目：任务管理Web应用

接下来我们用一个具体的项目来演示这些思维。这是一个任务管理Web应用，功能包括：

• 任务CRUD（创建、读取、更新、删除）
• 状态管理（待办、进行中、已完成）
• 优先级标记（高、中、低）
• 拖拽排序（改变任务顺序）
• 实时预览（编辑时即时看到效果）
• 响应式设计（移动端适配）
• 主题切换（深色/浅色模式）

技术栈选择：

• 前端框架：Vue 3 + TypeScript
• 构建工具：Vite
• 状态管理：Pinia
• 样式方案：Tailwind CSS
• 拖拽排序：VueDraggable
• 测试框架：Vitest + Cypress

我们不会一次性实现所有功能。按照迭代式开发，第一阶段只做基础的任务卡片和列表，第二阶段加拖拽排序，第三阶段做响应式和主题切换。

配置先行：在写代码前先立规矩

很多开发者拿到需求就直接让AI开始写代码，这是Vibe Coding的大忌。正确做法是先配置好规则，再开始开发。

对于前端项目，我通常会在项目初始化后做三件事：

1. 写好AGENTS.md 这个文件告诉AI这个项目是什么、有什么规矩。对于前端项目，重点写清楚技术栈、组件规范、状态管理方式、样式方案。

我会写这样的内容：

# 项目概述
任务管理Web应用，使用Vue3 + TypeScript + Tailwind CSS + Pinia

# 技术栈约束
- 前端框架：Vue 3.3+，必须使用Composition API + <script setup>
- 构建工具：Vite 5
- 状态管理：Pinia（不要使用Vuex）
- 样式方案：Tailwind CSS（不要写自定义CSS，除非必要）
- 类型检查：TypeScript严格模式
- 测试框架：Vitest + Vue Test Utils

# 组件规范
1. 组件文件命名：PascalCase（如TaskCard.vue）
2. 组件目录结构：组件逻辑、类型定义、样式放在同一个文件
3. 公共组件放在src/components/ui，业务组件放在src/components/features
4. 每个组件必须定义Props和Emits类型
5. 组件内不处理业务逻辑，只处理UI逻辑

# 状态管理规范
1. 全局状态使用Pinia store
2. Store文件放在src/stores/
3. 每个Store只管理一个功能模块（如useTaskStore管理任务）
4. 不在组件内使用ref或reactive管理跨组件状态

# 样式规范
1. 使用Tailwind CSS utility classes
2. 颜色使用CSS变量（如text-primary, bg-secondary）
3. 间距使用统一的设计系统（如p-4, m-2）
4. 响应式使用Tailwind的断点（sm:, md:, lg:）

2. 配置.cursorrules 如果是用Cursor，我会在.cursorrules里写更详细的前端规范。这些规范会自动应用到每次AI对话中，不需要重复说明。

# Vue组件开发规范
- 使用<script setup>和TypeScript
- Props必须定义类型，使用defineProps<{...}>()
- Emits必须定义类型，使用defineEmits<{...}>()
- 组件内不直接操作DOM，使用ref和模板引用
- 组件通信优先使用props和events，避免全局状态

# Tailwind CSS使用规范
- 优先使用Tailwind utility classes
- 颜色使用主题色（text-primary-500, bg-gray-100）
- 间距使用标准间距（p-1到p-12, m-1到m-12）
- 字体使用标准字体大小（text-sm, text-base, text-lg）
- 不写自定义CSS，除非Tailwind无法实现

# TypeScript规范
- 所有函数参数和返回值必须定义类型
- 使用interface定义复杂类型
- 不使用any，使用unknown或具体类型
- 使用泛型提高代码复用性

# 错误处理规范
- 组件内使用try-catch处理异步错误
- 使用onErrorCaptured处理后代组件渲染错误
- 控制台错误必须处理，不能忽略

3. 设计组件清单 在写任何代码前，先列出所有需要的组件，定义好每个组件的props和events。这个清单可以放在docs/components.md里，让AI在开发时参考。

我会设计这样的清单：

# 组件清单

## 基础组件
### TaskCard
- Props: task (Task), editable (boolean)
- Events: update:task, delete
- 功能：显示单个任务，支持编辑和删除

### TaskList  
- Props: tasks (Task[]), editable (boolean)
- Events: update:tasks
- 功能：显示任务列表，支持拖拽排序

### TaskForm
- Props: task (Task | null)
- Events: submit, cancel
- 功能：创建或编辑任务

## 状态组件
### StatusBadge
- Props: status (TaskStatus)
- 功能：显示任务状态标签，不同状态不同颜色

### PriorityBadge
- Props: priority (TaskPriority)
- 功能：显示任务优先级标签

## 布局组件
### AppHeader
- Props: title (string)
- 功能：应用头部，包含标题和主题切换

### AppSidebar
- 功能：侧边栏导航

## 业务组件
### TaskBoard
- 功能：看板视图，包含多个TaskList
### TaskDetail
- Props: taskId (string)
- 功能：任务详情页

这些配置看起来费时间，但能避免后续90%的返工。AI看到这些规则后，生成的代码会符合你的项目规范，不需要反复修改。

本篇小结

前端Vibe Coding的核心是"规划大于执行"。AI需要明确指令才能执行，它不会自动理解你的意图。

记住四条就够了。写代码前先设计好组件结构，想清楚每个组件的props和events，AI才不会被你带着绕。然后从骨架、逻辑到细节逐步推进，每次改动越小越好，出问题能快速回退。测试工作流要在开发前配好，让AI生成的代码自己验证自己。最后，AGENTS.md和.cursorrules在写第一行代码前就要立好，规矩在前面，返工在后面。

下一篇我们进入实战，用Cursor搭建这个任务管理应用。你会看到Rules怎么配、Agent模式怎么开发Vue组件、Tab补全怎么用。

---

参考资源：

• Vue 3 官方文档
• Tailwind CSS 官方文档
• Pinia 官方文档
• Vitest 官方文档