mm_ai 1.0.0

package/common/work/develop/database_design/prompt/trick.md

@@ -0,0 +1,71 @@
+# 数据库设计技巧
+
+## 1. 使用ER图辅助设计
+
+**适用场景**：需要理清多个实体之间的复杂关系时。
+
+**具体做法**：先用文本描述实体关系，再设计表结构。
+
+**示例**：
+```text
+用户(1) ----< 订单(N)   一个用户可以有多个订单
+订单(1) ----< 订单项(N) 一个订单可以有多个商品
+商品(1) ----< 订单项(N) 一个商品可以出现在多个订单中
+```
+
+**注意事项**：多对多关系需要中间表（关联表）来实现。
+
+---
+
+## 2. 合理使用索引
+
+**适用场景**：需要优化查询性能时。
+
+**具体做法**：根据查询场景选择合适的索引类型。
+
+**对比说明**：
+
+| 索引类型 | 适用场景 | 示例 |
+|---------|---------|------|
+| 主键索引 | 唯一标识 | id |
+| 唯一索引 | 业务唯一字段 | email、id_card |
+| 普通索引 | 查询条件字段 | status、category_id |
+| 复合索引 | 多条件查询 | (status, created_at) |
+
+**注意事项**：
+- 复合索引遵循"最左前缀"原则
+- 索引不是越多越好，写操作会受影响
+- 小表（<1000行）不需要索引
+
+---
+
+## 3. 使用EXPLAIN分析查询
+
+**适用场景**：需要排查SQL查询性能问题时。
+
+**具体做法**：在SQL前加 `EXPLAIN` 查看执行计划。
+
+**示例**：
+```sql
+EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 1;
+
+-- 关注以下字段
+-- type: ALL 表示全表扫描，需优化
+-- possible_keys: 可能使用的索引
+-- key: 实际使用的索引
+-- rows: 扫描行数，越小越好
+```
+
+**注意事项**：`type=ALL` 或 `rows` 很大时，说明需要添加索引。
+
+---
+
+## 4. 常见问题速查
+
+| 问题 | 原因 | 解决方案 |
+|------|------|---------|
+| 查询速度慢 | 缺少索引或SQL写法不当 | 添加索引，优化SQL |
+| 数据不一致 | 未使用事务或外键 | 添加事务控制和外键约束 |
+| 死锁 | 事务顺序不一致 | 统一事务中的表操作顺序 |
+| 存储空间增长快 | 字段类型过大或未归档 | 优化字段类型，定期归档历史数据 |
+| 连接超时 | 连接池配置不当 | 调整连接池大小和超时时间 |

package/common/work/develop/database_design/work.json

@@ -0,0 +1 @@
+{"name":"database_design","description":"设计数据库模型，包括表结构、索引和关系设计","type":"dynamic","group":"develop"}

package/common/work/develop/design_api/prompt/method.md

@@ -0,0 +1,22 @@
+# 设计API接口 - 方法
+
+## 流程概览
+
+```
+分析需求 → 设计路由 → 定义格式 → 编写文档 → 评审优化
+```
+
+## 步骤1：分析功能需求
+读取需求文档，提取需要暴露的API接口列表，识别实体资源和操作类型（增删改查）。
+
+## 步骤2：设计RESTful路由
+对每个资源设计标准RESTful路由，以表格列出所有路由。
+
+## 步骤3：定义请求和响应格式
+对每个API接口定义：请求参数（路径参数、查询参数、请求体）、响应格式（成功/错误）、HTTP状态码。
+
+## 步骤4：编写API文档
+包含接口概述、路由表、详细接口说明（含请求/响应示例）、错误码说明。
+
+## 步骤5：评审优化
+检查路由命名是否符合RESTful规范、参数定义是否完整、错误处理是否覆盖异常场景。

package/common/work/develop/design_api/prompt/rule.md

@@ -0,0 +1,60 @@
+# 设计API接口 - 规范
+
+## 1. RESTful路由命名规范
+
+| 操作 | 方法 | 路径格式 |
+|------|------|---------|
+| 列表查询 | GET | `/api/{resources}` |
+| 获取单个 | GET | `/api/{resources}/{id}` |
+| 创建 | POST | `/api/{resources}` |
+| 更新 | PUT | `/api/{resources}/{id}` |
+| 删除 | DELETE | `/api/{resources}/{id}` |
+
+### 命名原则
+- 使用名词复数形式：`/users`、`/orders`，禁止使用动词式路由如 `/getUser`
+- 嵌套资源：`/users/{userId}/orders`
+- 路径全部小写，单词用下划线分隔：`/order_items`
+
+## 2. HTTP状态码规范
+
+| 状态码 | 含义 | 使用场景 |
+|--------|------|---------|
+| 200 | 成功 | GET、PUT、DELETE成功 |
+| 201 | 创建成功 | POST创建资源成功 |
+| 400 | 参数错误 | 请求参数校验失败 |
+| 401 | 未认证 | 缺少或无效的认证信息 |
+| 403 | 无权限 | 认证通过但无操作权限 |
+| 404 | 未找到 | 资源不存在 |
+| 409 | 冲突 | 资源已存在（如重复创建） |
+| 500 | 服务器错误 | 服务器内部异常 |
+
+## 3. 响应格式规范
+
+统一响应格式：
+
+```json
+// 成功响应
+{
+  "code": 0,
+  "message": "success",
+  "data": { ... }
+}
+
+// 错误响应
+{
+  "code": 40001,
+  "message": "参数错误：用户名不能为空",
+  "data": null
+}
+```
+
+## 4. 参数规范
+- 路径参数：用于定位资源，如 `/{id}`
+- 查询参数：用于过滤和分页，如 `?page=1&size=20`
+- 请求体参数：用于创建/更新资源，使用JSON格式
+- 所有参数必须有明确的类型说明和取值范围
+
+## 5. 向后兼容规范
+- 已有接口的路径和参数不能随意修改
+- 新增参数必须设为可选（非必填）
+- 如需破坏性变更，必须升级API版本（如 `/api/v2/`）

package/common/work/develop/design_api/prompt/trick.md

@@ -0,0 +1,13 @@
+# 设计API接口 - 技巧
+
+## 1. 分页设计
+统一使用 `page`（页码）和 `size`（每页条数）参数，响应中返回 `total`（总数）。
+
+## 2. 字段选择
+支持 `fields` 参数让客户端选择返回字段，减少数据传输。
+
+## 3. 排序规范
+支持 `sort` 参数，格式为 `field:asc|desc`，如 `sort=created_at:desc`。
+
+## 4. 错误码设计
+业务错误码使用5位数字：前2位代表模块，后3位代表具体错误。

package/common/work/develop/design_api/work.json

@@ -0,0 +1 @@
+{"name":"design_api","description":"设计RESTful API接口","type":"dynamic","group":"develop"}

package/common/work/develop/design_architecture/prompt/method.md

@@ -0,0 +1,18 @@
+# 系统架构设计方法
+
+## 步骤
+
+### 1. 分析需求
+分析需求文档，提取功能需求和非功能需求（QPS、可用性、安全性）。
+
+### 2. 设计模块划分
+将系统划分为5层：前端层、API网关层、业务服务层、数据访问层、基础设施层。创建架构设计文档。
+
+### 3. 技术选型
+对每个模块选择技术栈，列出选型理由和备选方案。
+
+### 4. 设计接口规范
+定义模块间通信方式（RESTful API / gRPC / 消息队列）。
+
+### 5. 输出文档
+确保文档包含：架构概述、模块划分、技术选型、接口规范、部署架构、安全设计、性能预估。

package/common/work/develop/design_architecture/prompt/rule.md

@@ -0,0 +1,29 @@
+# 系统架构设计规范
+
+## 1. 分层设计
+
+系统必须按分层架构划分：前端层、API网关层、业务服务层、数据访问层、基础设施层。
+
+✅ 每层职责清晰，层间通过接口通信
+❌ 所有逻辑混在一起，没有分层
+
+## 2. 技术选型有依据
+
+每个技术选型必须列出选型理由和备选方案。
+
+✅ "选用Vue.js：团队熟悉、生态丰富、性能满足需求；备选：React"
+❌ "就用Vue.js"（没有理由）
+
+## 3. 非功能需求
+
+架构设计必须体现性能、安全和可扩展性要求。
+
+✅ "系统需支持1000QPS，99.9%可用性"
+❌ 只考虑功能不考虑性能
+
+## 4. 文档命名
+
+核心架构文档必须固定使用 `架构设计文档(ADD).md`。
+
+✅ `./project/{项目名}/doc/架构设计文档(ADD).md`
+❌ `projectx_architecture_design_v1.0.md`

package/common/work/develop/design_architecture/prompt/trick.md

@@ -0,0 +1,19 @@
+# 系统架构设计技巧
+
+## 1. KISS原则
+
+只在必要时引入复杂度，能用简单方案就不用复杂方案。
+
+| 方案 | 复杂度 | 适用场景 |
+|------|--------|---------|
+| 单体应用 | 低 | 团队<10人，业务简单 |
+| 微服务 | 高 | 团队>50人，业务复杂 |
+| 事件驱动 | 中 | 需要异步处理，高并发 |
+
+## 2. 常见问题
+
+| 问题 | 原因 | 解决 |
+|------|------|------|
+| 架构过于复杂 | 过度设计 | 简化设计，非核心功能拆分到后续迭代 |
+| 技术选型有风险 | 选用了不成熟的技术 | 准备备选方案，标注风险等级 |
+| 模块边界不清 | 职责划分不明确 | 重新划分模块职责和边界 |

package/common/work/develop/design_architecture/work.json

@@ -0,0 +1 @@
+{"name":"design_architecture","description":"系统架构设计","type":"dynamic","group":"develop"}

package/common/work/develop/design_database/prompt/method.md

@@ -0,0 +1,18 @@
+# 数据库设计方法
+
+## 步骤
+
+### 1. 分析数据需求
+分析需求文档，提取数据实体和关系。
+
+### 2. 设计表结构
+对每个实体设计表：表名（snake_case）、字段（名/类型/长度/是否为空/默认值）、主键、外键。编写表结构文档。
+
+### 3. 设计索引
+分析查询场景，设计主键索引、唯一索引、普通索引、复合索引。编写索引设计文档。
+
+### 4. 编写SQL脚本
+编写建表SQL脚本。
+
+### 5. 输出设计文档
+输出数据库设计文档。

package/common/work/develop/design_database/prompt/rule.md

@@ -0,0 +1,36 @@
+# 数据库设计规范
+
+## 1. 表名
+
+表名使用小写蛇形（snake_case），单数形式。
+
+✅ `user_accounts`、`order_items`、`product_category`
+❌ `UserAccounts`、`userAccounts`、`users`（复数）
+
+## 2. 字段名
+
+字段名使用小写蛇形（snake_case）。
+
+✅ `user_name`、`created_at`、`is_active`
+❌ `userName`、`createdAt`、`isActive`
+
+## 3. 主键
+
+每个表必须有主键，通常为自增INT或UUID。
+
+✅ `id INT AUTO_INCREMENT PRIMARY KEY`
+❌ 无主键或用业务字段做主键
+
+## 4. 第三范式
+
+数据库设计至少满足第三范式（3NF），禁止存储冗余数据。
+
+✅ 用户信息在users表，订单在orders表，通过user_id关联
+❌ 在orders表中同时存储user_name、user_email
+
+## 5. 索引
+
+为查询条件字段创建索引。
+
+✅ 为email创建唯一索引，为status创建普通索引
+❌ 不为查询字段创建索引，导致全表扫描

package/common/work/develop/design_database/prompt/trick.md

@@ -0,0 +1,18 @@
+# 数据库设计技巧
+
+## 1. 索引使用原则
+
+| 索引类型 | 适用场景 | 示例 |
+|---------|---------|------|
+| 主键索引 | 唯一标识 | id |
+| 唯一索引 | 业务唯一字段 | email、id_card |
+| 普通索引 | 查询条件字段 | status、category_id |
+| 复合索引 | 多条件查询 | (status, created_at) |
+
+## 2. 常见问题
+
+| 问题 | 原因 | 解决 |
+|------|------|------|
+| 查询速度慢 | 缺少索引 | 为查询字段添加索引 |
+| 数据不一致 | 未使用事务或外键 | 添加事务控制和外键约束 |
+| 存储空间增长快 | 字段类型过大 | 优化字段类型，定期归档 |

package/common/work/develop/design_database/work.json

@@ -0,0 +1 @@
+{"name":"design_database","description":"设计数据库模型","type":"dynamic","group":"develop"}

package/common/work/develop/develop_fullstack/prompt/method.md

@@ -0,0 +1,21 @@
+# 全栈开发方法
+
+## 步骤
+
+### 1. 分析需求
+分析需求文档和API设计文档。
+
+### 2. 搭建后端
+调用后端开发能力，根据API设计文档搭建服务端。
+
+### 3. 实现API
+调用后端开发能力实现API接口。
+
+### 4. 开发前端
+根据技术栈选择对应开发方式。
+
+### 5. API联调
+完成前后端联调对接。
+
+### 6. 生成部署文档
+生成部署指南文档。

package/common/work/develop/develop_fullstack/prompt/rule.md

@@ -0,0 +1,22 @@
+# 全栈开发规范
+
+## 1. 后端先于前端
+
+开发顺序：先搭建后端服务 → 实现API → 开发前端 → API联调。
+
+✅ 后端API完成后才开发前端页面
+❌ 前端写完后发现后端接口不匹配，全部重改
+
+## 2. 联调前置
+
+禁止在未完成API联调的情况下交付功能模块。
+
+✅ 联调通过后再标记"已完成"
+❌ 前端写完后不联调就交付，上线后接口报错
+
+## 3. 职责分离
+
+全栈开发应调用专业技能完成具体工作，禁止直接编写后端或前端代码。
+
+✅ 使用 `call_agent` 调用专业智能体
+❌ 在fullstack_development中直接写API代码

package/common/work/develop/develop_fullstack/prompt/trick.md

@@ -0,0 +1,18 @@
+# 全栈开发技巧
+
+## 1. 先定义接口再并行开发
+
+前后端按同一份接口文档并行开发，减少联调时的返工。
+
+| 维度 | 各自为政 | 统一接口文档 |
+|------|---------|------------|
+| 联调效率 | 反复修改 | 一次通过 |
+| 一致性 | 容易不一致 | 保证一致 |
+
+## 2. 常见问题
+
+| 问题 | 原因 | 解决 |
+|------|------|------|
+| 联调时接口不匹配 | 未按接口文档开发 | 重新读取接口文档，修正代码 |
+| 前端等待后端 | 后端开发滞后 | 使用mock数据先行开发 |
+| 后端接口变更 | 需求变更未同步 | 更新接口文档后通知前端 |

package/common/work/develop/develop_fullstack/work.json

@@ -0,0 +1 @@
+{"name":"develop_fullstack","description":"全栈开发协调","type":"dynamic","group":"develop"}

package/common/work/develop/develop_mini_program/prompt/method.md

@@ -0,0 +1,18 @@
+# 开发小程序 - 方法
+
+## 流程概览
+```
+分析需求 → 开发页面 → 实现功能 → 测试交付
+```
+
+## 步骤1：分析需求
+读取需求文档，创建小程序目录。
+
+## 步骤2：开发页面
+对每个页面创建WXML/WXSS/JS/JSON四个文件。
+
+## 步骤3：实现功能
+编写全局逻辑和配置。
+
+## 步骤4：测试交付
+检查文件完整性。

package/common/work/develop/develop_mini_program/prompt/rule.md

@@ -0,0 +1,19 @@
+# 开发小程序 - 规范
+
+## 1. JS代码规范
+- 函数命名使用小驼峰（camelCase）
+- 变量和参数命名使用小写蛇形（snake_case）
+- 常量命名使用全大写蛇形（SCREAMING_SNAKE_CASE）
+- Page/Component方法名使用小驼峰：`onLoad()`、`onShow()`
+- 缩进统一使用2个空格
+- 变量声明：能用 `let` 就别用 `const`
+- 注释使用JSDoc格式
+
+## 2. WXSS命名规范
+- 组件命名用下划线 `_` 拼接
+- 状态变体用连字符 `-` 拼接
+- 全部小写，禁止驼峰
+
+## 3. 禁止行为
+- 禁止使用不兼容的API（小程序API与浏览器API不同）
+- 禁止在未测试的情况下提交代码

package/common/work/develop/develop_mini_program/prompt/trick.md

@@ -0,0 +1,10 @@
+# 开发小程序 - 技巧
+
+## 1. 全局配置
+利用 `app.json` 的全局配置减少重复代码。
+
+## 2. 组件复用
+将公共UI封装为自定义组件，提高复用性。
+
+## 3. 数据缓存
+合理使用 `wx.setStorageSync` 缓存频繁使用的数据，减少网络请求。

package/common/work/develop/develop_mini_program/work.json

@@ -0,0 +1 @@
+{"name":"develop_mini_program","description":"开发微信小程序","type":"dynamic","group":"develop"}

package/common/work/develop/develop_mm_server/prompt/method.md

@@ -0,0 +1,27 @@
+# mm服务端开发 - 方法
+
+## 流程概览
+```
+读取技能规范 → 确定开发场景 → 创建App应用 → 创建Plugin插件 → 创建API接口 → 创建Pendant/Task → 验证完整性
+```
+
+## 步骤1：读取技能规范
+在创建任何文件之前，先使用 `read_skill` 读取对应mm框架技能规范。
+
+## 步骤2：确定开发场景
+根据需求判断应采用哪种开发方式（App/Plugin/Pendant/Template/Task/API）。
+
+## 步骤3：创建App应用
+参考 `mm_app_config` 和 `mm_app_script` 技能创建。
+
+## 步骤4：创建Plugin插件
+参考 `mm_plugin_config` 和 `mm_plugin_script` 技能创建。
+
+## 步骤5：创建API接口
+参考 `mm_api_config` 和 `mm_api_script` 技能创建。
+
+## 步骤6：创建Pendant/Task等
+参考对应技能规范创建。
+
+## 步骤7：验证完整性
+验证所有文件已正确创建，内容格式符合对应技能规范。

package/common/work/develop/develop_mm_server/prompt/rule.md

@@ -0,0 +1,16 @@
+# mm服务端开发 - 规范
+
+## 1. 核心原则
+创建mm框架项目文件时，必须先读取对应的mm框架技能规范，严格按照规范来创建，不得自行臆测格式。
+
+## 2. 命名规则
+- App名称：小写蛇形（snake_case）
+- 插件名：小写蛇形（snake_case）
+- API路由组名：`api_{app_name}_{type}`，type只能是client/manage/web
+- API接口名：小写蛇形
+- 挂件名：小写蛇形
+- 任务名：小写蛇形
+- 数据表文件名：`{table_name}.db.json`
+
+## 3. 代码规范
+所有函数必须写在 `module.exports = { }` 的 `{}` 内部，函数之间通过 `this.xxx()` 调用。

package/common/work/develop/develop_mm_server/prompt/trick.md

@@ -0,0 +1,10 @@
+# mm服务端开发 - 技巧
+
+## 1. 先读规范再动手
+每次创建新文件前都先读对应规范，避免格式错误。
+
+## 2. 善用模板
+mm框架各组件有固定模板，按模板填充内容效率更高。
+
+## 3. 命名一致性
+保持App名、插件名、API名的命名一致性，便于维护。

package/common/work/develop/develop_mm_server/work.json

@@ -0,0 +1 @@
+{"name":"develop_mm_server","description":"基于MMos框架开发服务端","type":"dynamic","group":"develop"}

package/common/work/develop/develop_module/prompt/method.md

@@ -0,0 +1,21 @@
+# 开发模块 - 方法
+
+## 流程概览
+```
+分析模块需求 → 设计模块结构 → 编写模块代码 → 编写测试用例 → 编写使用文档
+```
+
+## 步骤1：分析模块需求
+读取需求文档，确定模块的功能接口和外部依赖。
+
+## 步骤2：设计模块结构
+设计模块的导出接口和内部实现结构（index.js入口、lib/内部实现、test/测试）。
+
+## 步骤3：编写模块代码
+编写入口文件和内部实现文件，使用JSDoc注释。
+
+## 步骤4：编写测试用例
+覆盖正常路径和异常路径。
+
+## 步骤5：编写使用文档
+包含安装方式、API说明、使用示例、注意事项。

package/common/work/develop/develop_module/prompt/rule.md

@@ -0,0 +1,24 @@
+# 开发模块 - 规范
+
+## 1. 代码规范
+- 函数命名使用小驼峰（camelCase）
+- 变量和参数命名使用小写蛇形（snake_case）
+- 常量命名使用全大写蛇形（SCREAMING_SNAKE_CASE）
+- 模块导出使用 `module.exports = { functionName }`
+- 缩进统一使用2个空格
+- 变量声明：能用 `let` 就别用 `const`
+- 注释使用JSDoc格式
+
+## 2. 模块结构
+```
+{模块名}/
+├── index.js          ← 模块入口，导出公共API
+├── lib/              ← 内部实现文件
+├── test/             ← 测试文件
+└── README.md         ← 使用文档
+```
+
+## 3. 模块原则
+- 禁止模块存在外部副作用
+- 禁止在未编写文档的情况下发布模块
+- 禁止使用无意义文件名

package/common/work/develop/develop_module/prompt/trick.md

@@ -0,0 +1,10 @@
+# 开发模块 - 技巧
+
+## 1. 小步迭代
+先实现核心功能并导出，再逐步扩展。
+
+## 2. 错误优先
+先写错误处理和边界情况的代码，再写正常路径。
+
+## 3. 依赖注入
+通过参数传入外部依赖，而不是在模块内部直接require，便于测试。

package/common/work/develop/develop_module/work.json

@@ -0,0 +1 @@
+{"name":"develop_module","description":"开发可复用Node.js模块","type":"dynamic","group":"develop"}

package/common/work/develop/develop_node_server/prompt/method.md

@@ -0,0 +1,27 @@
+# 搭建Node服务端 - 方法
+
+## 流程概览
+```
+分析需求 → 初始化项目结构 → 编写应用入口 → 编写中间件 → 编写配置 → 编写工具函数 → 验证服务启动
+```
+
+## 步骤1：分析需求
+读取需求文档和架构设计文档，了解服务端技术栈要求。
+
+## 步骤2：初始化项目结构
+创建server目录和子目录，生成package.json。
+
+## 步骤3：编写应用入口
+创建Express/Koa实例，注册全局中间件，导出app实例。
+
+## 步骤4：编写中间件
+编写认证鉴权、错误处理、请求日志等中间件。
+
+## 步骤5：编写配置
+编写配置聚合和数据库连接配置。
+
+## 步骤6：编写工具函数
+编写统一响应格式等工具函数。
+
+## 步骤7：验证服务启动
+确保app.js能正确导入所有中间件和配置。

package/common/work/develop/develop_node_server/prompt/rule.md

@@ -0,0 +1,24 @@
+# 搭建Node服务端 - 规范
+
+## 1. 目录结构规范
+```
+./project/{项目名}/server/
+├── app.js              ← 应用入口
+├── config/             ← 配置文件
+├── middleware/          ← 中间件
+├── routes/             ← 路由定义
+├── controllers/        ← 控制器
+├── models/             ← 数据模型
+└── utils/              ← 工具函数
+```
+
+## 2. 代码规范
+- 函数命名使用小驼峰（camelCase）
+- 变量和参数命名使用小写蛇形（snake_case）
+- 常量命名使用全大写蛇形（SCREAMING_SNAKE_CASE）
+- 缩进统一使用2个空格
+- 注释使用JSDoc格式
+
+## 3. 安全规范
+- 禁止将敏感信息（密码、密钥）硬编码在代码中
+- 必须使用环境变量管理配置

package/common/work/develop/develop_node_server/prompt/trick.md

@@ -0,0 +1,10 @@
+# 搭建Node服务端 - 技巧
+
+## 1. 中间件顺序
+错误处理中间件必须放在最后注册，否则无法捕获错误。
+
+## 2. 环境配置
+使用 `.env` 文件管理环境变量，区分开发/测试/生产环境。
+
+## 3. 统一响应格式
+封装统一的成功/失败响应函数，保持API响应格式一致。

package/common/work/develop/develop_node_server/work.json

@@ -0,0 +1 @@
+{"name":"develop_node_server","description":"搭建Node.js服务端应用","type":"dynamic","group":"develop"}

package/common/work/develop/develop_plugin/prompt/method.md

@@ -0,0 +1,21 @@
+# 开发插件 - 方法
+
+## 流程概览
+```
+分析插件需求 → 设计插件接口 → 编写插件代码 → 编写配置文件 → 测试验证
+```
+
+## 步骤1：分析插件需求
+读取需求文档，确定插件需要实现的扩展点和接口规范。
+
+## 步骤2：设计插件接口
+定义标准接口：init(config)、execute(context)、destroy()。
+
+## 步骤3：编写插件代码
+实现插件的具体功能，函数使用JSDoc注释。
+
+## 步骤4：编写插件配置文件
+包含插件名称、版本、描述、依赖、配置项。
+
+## 步骤5：测试验证
+测试插件的安装、加载、执行和卸载流程。