---
name: auto-dev
description: zc-web 自动化开发全流程 skill。覆盖从原型图/PRD → 蓝湖 MCP 设计稿读取 → API 接口文档 → 页面代码生成 → 组件拆分 → store/api 生成 → 自动验证修正的完整链路。当用户提到"自动化开发"、"从原型生成代码"、"蓝湖设计稿生成页面"、"PRD生成页面"、"虫子开发"、"自动拆分组件"、"生成store"时使用。
version: 1.0.0
---

# zc-web 自动化开发全流程

> 本 skill 驱动从设计稿/PRD 到可运行代码的完整自动化管线。所有生成的代码必须严格遵循 [vue-project-structure](vue-project-structure) skill 的规范。

## 前置条件

1. **项目结构确认**：用 `codegraph_files` 确认 `src/` 目录现有结构
2. **加载 vue-project-structure skill**：所有代码生成必须遵循其分层架构和数据流规范
3. **蓝湖 MCP 就绪**：确认 `lanhu` MCP 服务已启动（`curl http://localhost:8000/mcp`）

---

## 阶段一：PRD 生成

### 从原型图生成 PRD 文档

使用项目根目录的 `read_prototype.js` 读取原型文件：

```bash
node read_prototype.js [原型文件路径]
```

然后根据原型中的布局和交互逻辑，生成 PRD 文档放入 `doc/` 文件夹。

**PRD 内容要求**：

- 页面清单及功能描述
- 每个页面的交互逻辑
- 数据字段定义
- 组件拆分建议

**提示词模板**：

```
运行 ./read_prototype.js [原型文件路径] 读取原型代码，然后根据其中的布局和交互逻辑，为我生成一份 PRD 文档。放在doc文件夹中
```

---

## 阶段二：蓝湖 MCP 设计稿读取

### 连接验证

```javascript
请帮我用 MCP 看看这个蓝湖设计稿：[蓝湖链接]
```

### 批量读取设计稿数据

```javascript
请通过蓝湖 MCP 读取以下设计稿的结构化数据，提取每个页面的：
- 组件尺寸、间距、色值、字体等标注参数
- 全局设计规范（颜色变量、字号体系）
- 切图资源（SVG/PNG），按图层语义化命名
- 布局嵌套结构和循环体检测
蓝湖链接：[蓝湖项目链接]
```

**输出要求**：

- 设计参数表（色值、字号、间距、圆角、阴影）
- 组件结构树（嵌套关系、循环体标记）
- 资源清单（图片/图标路径及语义化命名）

---

## 阶段三：PRD → 页面结构规划

```javascript
以下是我的产品需求文档，请帮我：
- 梳理出所有需要的页面清单，按功能模块分组
- 规划 uni-app / Vue3 项目的页面路由结构
- 识别哪些模块可以复用，哪些是页面独有
- 输出每个页面的核心功能点和数据字段
PRD 内容：[PRD文件路径或内容]
```

**输出物**：

- 页面清单表（模块 → 页面 → 功能点 → 数据字段）
- 路由规划（`pages.json` 或 `router/routes.ts` 结构）
- 复用性分析（哪些组件/逻辑可抽取为公共）

---

## 阶段四：AI 生成页面代码并自动拆分组件

基于 PRD 页面规划和蓝湖 MCP 设计稿数据，生成完整页面代码。

### 目录结构规范（zc-web）

```
views/<page>/
├── index.vue              # 页面主组件（路由入口）
├── index.ts               # 页面出口 barrel
└── cpns/                  # 页面独有组件
    ├── <ComponentName>.vue
    └── ...
```

配套文件：

```
api/<page>.ts              # 接口层
stores/modules/<page>.ts   # 数据层（Pinia）
types/business/<page>.d.ts # 实体类型
```

### 组件拆分原则

1. **单一职责**：一个组件只做一件事，超过 300 行必须拆分
2. **三层架构**：
   - 页面容器（`index.vue`）：只负责调度和数据分发，不写业务逻辑
   - 业务子组件（`cpns/`）：当前页面私有，只接收 props + emit 事件
   - 公共基础组件（`components/`）：全局复用
3. **按数据维度拆分**：同一批接口数据渲染的区域放一个组件，不同数据源必须拆分
4. **弹窗/抽屉/复杂表单**：一律单独抽离为子组件

### 生成要求

- 父页面只做组件引入、props 分发、事件中转
- 子组件只接收 props 和通过 emit 向上抛事件，不直接调接口
- 样式使用 `<style lang="less" scoped>`，色值从蓝湖数据中精确提取
- 图片和图标使用蓝湖 MCP 导出的本地资源路径
- 组件统一 `<script setup lang="ts">`，props 用 `defineProps<Props>()` + `withDefaults`，emits 用 `defineEmits<{事件名: [参数类型]}>()`

### 提示词模板

```javascript
基于蓝湖 MCP 返回的设计稿数据和 PRD 页面规划，帮我生成 uni-app + Vue3 + TypeScript 的完整页面代码，并按以下原则自动拆分组件：
拆分原则：
1.单一职责：一个组件只做一件事，超过 300 行必须拆分
2.三层架构：页面容器（只负责调度和数据分发）→ 业务子组件（当前页面私有）→ 公共基础组件（全局复用）
3.按数据维度拆分：同一批接口数据渲染的区域放一个组件，不同数据源的模块必须拆分
4.弹窗、抽屉、复杂表单一律单独抽离为子组件
目录结构规范：
pages/
└── <page>/
    ├── index.vue              # 父页面（控制器层，零业务逻辑）
    └── components/
        ├── <Page>Search.vue   # 搜索筛选组件（纯 UI，只抛回调）
        ├── <Page>List.vue     # 列表组件（纯 UI，只渲染+抛事件）
        ├── <Page>Card.vue     # 卡片组件（可复用）
        └── <Page>Detail.vue   # 详情弹窗组件
生成要求：
1.父页面只做组件引入、props 分发、事件中转，不写业务逻辑
2.子组件只接收 props 和通过 emit 向上抛事件，不直接调接口
3.样式使用vue支持的写法，色值从蓝湖数据中精确提取
4.图片和图标使用蓝湖 MCP 导出的本地资源路径
```

---

## 阶段五：生成 API + Store（逻辑层）

为每个页面生成对应的 api 和 store 文件，遵循 zc-web 三层数据流规范（页面 → store → api）。

### 规范

| 层级  | 文件                       | 职责                                                               |
| ----- | -------------------------- | ------------------------------------------------------------------ |
| API   | `api/<page>.ts`            | 封装 axios 接口，定义路径/方法/参数类型/响应类型，不写业务逻辑     |
| Store | `stores/modules/<page>.ts` | 管理状态 + 业务逻辑（请求、loading、分页、数据格式化），不操作 DOM |
| Views | `views/<page>/`            | 纯 UI 展示，调用 Store 获取数据，用户交互调用 Store 方法           |

### 生成要求

- **store 使用 Pinia setup 写法**：`ref` 状态 + `computed` getters + 普通函数 actions
- **api 使用 `request<T>`**：统一 axios 实例，不直接 import axios
- **页面禁止直接 import api**：获取数据必须调对应 store 的 action
- **类型定义**：`types/business/<page>.d.ts` 定义实体类型

### 提示词模板

```javascript
为每个页面生成对应的 api, store 文件，放在 api/ ,stores/modules/ 目录下，遵循以下规范：
- store文件统一管理状态 + 业务逻辑（请求、loading、分页、数据格式化），不直接操作 DOM、不写 UI 代码
- api文件封装 axios，定义接口路径、方法、参数类型、响应类型，不写业务逻辑、不操作状态
- views文件纯 UI 展示，调用 Store 获取数据，用户交互调用 Store 方法，不调用 API、尽量不写业务逻辑
- api, store与 UI 组件完全解耦，只通过返回值暴露数据和方法
- store 使用 Pinia setup 写法，api 使用 request<T>
```

---

## 阶段六：自动识别并提取公共组件

```javascript
请扫描整个项目的 pages 目录，识别跨多个页面重复出现的 UI 模块（如导航栏、底部 Tab、空状态、加载动画、通用弹窗等），将它们提取到 components/common/ 目录下作为全局公共组件，并替换所有页面中的引用。
```

**提取判定规则**（与 vue-project-structure skill 一致）：

- 被 ≥2 个页面使用 → 放 `components/`
- 仅 1 个页面使用 → 放 `views/<page>/cpns/`

---

## 阶段七：自动化验证与修正

逐页对比蓝湖设计稿和生成的代码，自动检查并修复：

1. **间距、色值、字号**是否与设计稿一致
2. **布局**是否正确（flex 方向、对齐方式）
3. **圆角、阴影、渐变**是否还原
4. **图片资源路径**是否正确
5. **组件拆分**是否合理（是否有超过 300 行的组件需要进一步拆分）
6. **规范合规**：是否有 `as any`、`@ts-ignore`、直接 import api 等违规

**验证命令**：

```bash
pnpm build  # 含 vue-tsc 类型检查，零错误才算通过
```

---

## 完整工作流调用顺序

```
阶段一(PRD) → 阶段二(蓝湖MCP) → 阶段三(页面规划) → 阶段四(代码生成) → 阶段五(API+Store) → 阶段六(公共组件) → 阶段七(验证修正)
```

每个阶段可独立调用，也支持一键全流程。

---

## 注意事项

1. **始终先加载 vue-project-structure skill**：所有代码必须符合项目规范
2. **每次动手前先读取项目目录**：确认目标文件存在与现状
3. **命名一致性**：页面 `home` → `api/home.ts` + `stores/modules/home.ts` + `types/business/home.d.ts` + `views/home/` 四者同名
4. **不创建新顶层目录**：在既有职责目录中创建文件
5. **蓝湖 MCP 不可用时**：提示用户检查 Docker 容器和 Cookie 配置，降级为手动提供设计参数