cz-web/.claude/skills/auto-dev/SKILL.md

name, description, version

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

zc-web 自动化开发全流程

本 skill 驱动从设计稿/PRD 到可运行代码的完整自动化管线。所有生成的代码必须严格遵循 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 读取原型文件：

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

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

PRD 内容要求：

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

提示词模板：

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

---

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

连接验证

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

批量读取设计稿数据

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

输出要求：

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

---

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

以下是我的产品需求文档，请帮我：
- 梳理出所有需要的页面清单，按功能模块分组
- 规划 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<{事件名: [参数类型]}>()

提示词模板

基于蓝湖 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 定义实体类型

提示词模板

为每个页面生成对应的 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>

---

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

请扫描整个项目的 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 等违规

验证命令：

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