feat skills配置

2026-09-28 09:21:34 +08:00
parent 7a2efa3fea
commit 4e1bb0f82a
17 changed files with 9948 additions and 2 deletions
--- a/.claude/skills/auto-dev/SKILL.md
+++ b/.claude/skills/auto-dev/SKILL.md
@@ -0,0 +1,240 @@
+---
+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 配置，降级为手动提供设计参数