241 lines
9.4 KiB
Markdown
241 lines
9.4 KiB
Markdown
---
|
||
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 配置，降级为手动提供设计参数
|