mm_ai 1.0.0

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

@@ -0,0 +1,20 @@
+# API接口联调方法
+
+## 前置条件
+
+- [ ] 已有API接口设计文档（路由、参数、响应格式）
+- [ ] 后端已完成API接口实现
+- [ ] 前端已编写完页面和交互逻辑
+
+## 流程概览
+
+分析接口文档 → 检查后端实现 → 检查前端调用 → 编写数据转换协议 → 逐接口验证 → 修复问题
+
+## 详细步骤
+
+### 步骤1：分析接口文档
+分析API接口设计文档，从文档中提取每个接口的以下信息：
+- 请求方法、请求路径
+- 请求参数（路径参数、查询参数、请求体）
+- 响应格式（成功响应结构、错误响应结构）
+- 状态码说明

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

@@ -0,0 +1,52 @@
+# API接口联调规范
+
+## 适用对象和范围
+
+本规范适用于所有前后端API联调对接的场景，包括阅读接口文档、测试入参传参、编写数据转换协议。
+
+---
+
+## 1. 以接口文档为准
+
+**规则**：联调过程中必须以API接口设计文档为准，禁止直接对照代码联调。
+
+- ✅ 正确：先读取API文档，再对照后端实现
+- ❌ 错误：直接看后端代码猜测接口格式
+
+**违反后果**：脱离文档联调导致接口规范不一致，后续维护困难。
+
+---
+
+## 2. 数据转换规范
+
+**规则**：禁止在前端直接修改后端返回的原始数据结构，必须通过转换函数处理。
+
+- ✅ 正确：定义 `transformResponse()` 函数进行数据转换
+- ❌ 错误：`response.data.user_id = response.data.id; delete response.data.id;`
+
+**违反后果**：直接修改原始数据导致后续代码逻辑混乱，难以追踪数据来源。
+
+---
+
+## 3. 异常场景测试规范
+
+**规则**：必须测试异常场景，包括空数据、错误参数、网络超时等。
+
+- ✅ 正确：测试空列表返回、参数缺失、超时等情况
+- ❌ 错误：只测试正常路径
+
+**违反后果**：未测试异常场景导致线上出现问题时无法处理。
+
+---
+
+## 4. 联调记录规范
+
+**规则**：联调结果必须记录到联调报告中，每个接口的状态必须明确标注。
+
+| 状态 | 含义 |
+|------|------|
+| ✅ 通过 | 请求和响应均正常 |
+| ⚠️ 有差异 | 存在字段名或格式差异，已记录 |
+| ❌ 失败 | 接口不可用或返回错误 |
+
+**违反后果**：不记录联调结果导致问题追踪困难，不知道哪些接口已完成联调。

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

@@ -0,0 +1,100 @@
+# API接口联调技巧
+
+## 1. 使用转换函数隔离前后端格式差异
+
+**适用场景**：后端返回的数据格式与前端的期望格式不一致时。
+
+**具体做法**：编写独立的转换函数，集中管理所有数据格式转换。
+
+**对比说明**：
+
+| 维度 | 散落在各处的转换 | 集中管理的转换函数 |
+|------|----------------|------------------|
+| 可维护性 | 修改格式需搜索所有代码 | 只改转换函数 |
+| 可测试性 | 难以单独测试 | 可单独测试转换函数 |
+| 可读性 | 业务逻辑中混入转换代码 | 业务逻辑清晰 |
+
+**示例**：
+```javascript
+// 集中转换处理
+const apiTransforms = {
+  // 用户列表转换
+  userList: (data) => ({
+    userId: data.user_id,
+    userName: data.user_name,
+    createdAt: data.created_at?.split('T')[0],
+    statusText: { 1: '启用', 2: '禁用' }[data.status] || '未知'
+  }),
+  
+  // 创建用户请求转换
+  createUser: (data) => ({
+    user_name: data.userName,
+    email: data.email
+  })
+};
+```
+
+**注意事项**：转换函数应该放在独立的 `api/transforms.js` 文件中，不要混在组件代码中。
+
+---
+
+## 2. 使用浏览器开发者工具调试接口
+
+**适用场景**：需要排查接口请求/响应的具体数据时。
+
+**具体做法**：使用浏览器开发者工具的Network面板查看请求详情。
+
+**检查清单**：
+- [ ] 请求URL是否正确
+- [ ] 请求方法是否正确（GET/POST/PUT/DELETE）
+- [ ] 请求头是否正确（Content-Type、Authorization）
+- [ ] 请求体格式是否正确（JSON/FormData）
+- [ ] 响应状态码是否符合预期
+- [ ] 响应体结构是否与接口文档一致
+
+**注意事项**：Network面板可以过滤请求类型（XHR/Fetch），方便只查看API请求。
+
+---
+
+## 3. 使用mock数据先行联调
+
+**适用场景**：后端接口尚未完成，但前端需要先开发时。
+
+**具体做法**：在前端代码中使用mock数据模拟后端响应。
+
+**对比说明**：
+
+| 维度 | 等待后端完成 | 使用mock数据 |
+|------|------------|-------------|
+| 开发效率 | 前端等待后端 | 前后端并行开发 |
+| 联调风险 | 联调时才发现问题 | 提前发现问题 |
+| 代码切换 | 无 | 添加环境判断 |
+
+**示例**：
+```javascript
+// api/index.js
+const USE_MOCK = process.env.NODE_ENV === 'development';
+
+export async function getUsers(params) {
+  if (USE_MOCK) {
+    return mockData.users;  // 返回mock数据
+  }
+  const response = await fetch('/api/users?' + new URLSearchParams(params));
+  return response.json();
+}
+```
+
+**注意事项**：mock数据应该尽量接近真实数据结构，包括边界情况（空数据、错误等）。
+
+---
+
+## 4. 常见问题速查
+
+| 问题 | 原因 | 解决方案 |
+|------|------|---------|
+| 接口返回404 | 路由路径错误 | 检查请求URL与后端路由是否一致 |
+| 接口返回500 | 服务器异常 | 查看后端日志，检查参数和业务逻辑 |
+| 跨域请求被拦截 | 未配置CORS | 后端配置 `cors` 中间件 |
+| 请求体为空 | Content-Type不匹配 | 检查请求头的 `Content-Type` |
+| 响应字段为undefined | 字段名不匹配 | 检查snake_case和camelCase的转换 |
+| 中文乱码 | 编码问题 | 确保请求和响应都使用UTF-8 |

package/common/work/develop/api_integration/work.json

@@ -0,0 +1 @@
+{"name":"api_integration","description":"前后端API联调对接，包括阅读接口文档、测试入参传参、编写数据转换协议","type":"dynamic","group":"develop"}

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

@@ -0,0 +1,29 @@
+# 工具构建 - 方法文档
+
+## 操作流程
+
+### 步骤1：分析工具需求
+- 明确工具的核心功能
+- 定义输入参数和输出结果
+- 确定使用场景
+
+### 步骤2：创建工具目录
+- 创建 `./tool/{工具名称}/` 目录
+
+### 步骤3：编写工具代码
+- 编写index.js，包含async main(params)入口函数
+- 实现参数校验和核心逻辑
+- 统一返回格式
+
+### 步骤4：编写工具配置文件
+- 编写tool.json
+- 配置name、title、description、params、returns等
+
+### 步骤5：注册工具
+- 调用工具创建功能注册到系统
+- 传入完整参数
+
+### 步骤6：自检确认
+- 逐项核对工具配置
+- 验证参数定义完整性
+- 确认返回值格式正确

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

@@ -0,0 +1,35 @@
+# 工具构建 - 规则文档
+
+## 任务目标
+根据需求设计并实现工具代码，包括工具的逻辑、参数、返回值等，确保工具功能正确、结构清晰。
+
+## 输入条件
+- 工具需求（功能、输入、输出）
+- 工具命名规范参考
+- 目标智能体已明确
+
+## 必须遵守的规则
+
+### 规则1：工具命名规范
+- 工具名称（name）：小写蛇形，如 `user_query`、`data_export`
+- 工具标题（title）：中文名称，如 "用户查询工具"
+- 功能描述（description）：清晰描述，50字以内
+
+### 规则2：工具参数定义
+- 每个参数必须定义类型、是否必填、默认值、描述
+- 参数类型支持：string、number、boolean、array、object
+- 必填参数必须有非空校验
+
+### 规则3：返回值规范
+- 成功返回：`{ code: 0, msg: '成功', data: {...} }`
+- 参数错误返回：`{ code: 400, msg: '错误描述' }`
+- 执行异常返回：`{ code: 500, msg: error.message }`
+
+### 规则4：工具配置规范
+- 必须编写tool.json配置文件
+- 配置包含：name、title、description、version、params、returns、group、main、func_name
+
+## 输出要求
+- 工具脚本文件（index.js）
+- 工具配置文件（tool.json）
+- 已注册到系统的工具实体

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

@@ -0,0 +1,23 @@
+# 工具构建 - 技巧文档
+
+## 最佳实践
+
+### 设计技巧
+- 工具功能单一职责，一个工具只做一件事
+- 参数设计考虑未来扩展性
+- 返回值包含足够的信息便于调用方处理
+
+### 编码技巧
+- 使用JSDoc完整注释每个参数
+- 参数校验放在最前面，快速失败
+- 错误信息要清晰指明问题
+
+### 配置要点
+- tool.json的params和returns与代码保持一致
+- group字段选择合适的分组便于管理
+- version从1.0.0开始
+
+### 常见问题
+- **参数遗漏**：列出所有参数逐一核对
+- **返回值不一致**：统一使用{code, msg, data}格式
+- **注册失败**：检查tool.json格式是否正确

package/common/work/develop/build_tool/work.json

@@ -0,0 +1 @@
+{"name":"build_tool","description":"根据需求设计实现工具代码，含参数定义、返回值规范和注册流程","type":"dynamic","group":"develop"}

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

@@ -0,0 +1,53 @@
+# 代码封装方法
+
+## 前置条件
+
+- [ ] 已明确需要封装的功能逻辑
+- [ ] 已确定封装形式（函数/类/模块/NPM包）
+
+---
+
+## 流程概览
+
+```
+分析功能需求 → 选择封装形式 → 编写封装代码 → 导出模块 → 验证可用性
+```
+
+---
+
+## 详细步骤
+
+### 步骤1：分析功能需求
+
+明确需要封装的功能逻辑和输入输出。
+
+### 步骤2：选择封装形式
+
+根据复杂度选择：
+- 简单工具函数 → 函数封装
+- 有状态对象 → 类封装
+- 相关功能集合 → 模块封装
+- 跨项目复用 → NPM包封装
+
+### 步骤3：编写封装代码
+
+按照所选封装形式编写代码，包含JSDoc注释。
+
+### 步骤4：导出模块
+
+使用 `module.exports` 导出。
+
+### 步骤5：验证可用性
+
+确保模块可被正确引用和调用。
+
+---
+
+## 产出物说明
+
+| 封装形式 | 产出物 |
+|---------|--------|
+| 函数封装 | 包含函数的 `.js` 文件 |
+| 类封装 | 包含类的 `.js` 文件 |
+| 模块封装 | 包含多个导出项的 `.js` 文件 |
+| NPM包封装 | 包含 `package.json` 的完整包目录 |

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

@@ -0,0 +1,54 @@
+# 代码封装规范
+
+## 适用对象和范围
+
+本规范适用于所有通用Node.js代码封装场景，包括函数封装、类封装、模块封装和NPM包封装。
+
+---
+
+## 1. 命名规范
+
+**规则**：函数名使用小驼峰（camelCase），变量/参数使用小写蛇形（snake_case），类名使用大驼峰（PascalCase），常量使用全大写蛇形（SCREAMING_SNAKE_CASE），文件名使用小写蛇形。
+
+| 类型 | 规范 | 示例 |
+|:----|:-----|:-----|
+| 函数名 | camelCase | `formatAmount`、`getUserList` |
+| 变量/参数 | snake_case | `user_list`、`max_length` |
+| 类名 | PascalCase | `CacheManager`、`HttpClient` |
+| 常量 | SCREAMING_SNAKE_CASE | `MAX_RETRY_COUNT` |
+| 文件名 | snake_case | `cache_manager.js` |
+
+**违反后果**：命名不一致导致代码可读性差。
+
+---
+
+## 2. 注释规范
+
+**规则**：函数和类必须使用JSDoc格式注释。
+
+```javascript
+/**
+ * 格式化金额
+ * @param {number} amount - 金额
+ * @param {string} currency - 货币符号
+ * @return {string} 格式化后的金额字符串
+ */
+```
+
+**违反后果**：缺少JSDoc注释导致IDE无法提供类型提示。
+
+---
+
+## 3. 导出规范
+
+**规则**：必须使用 `module.exports` 或 `exports.xxx` 导出模块。
+
+**违反后果**：导出方式不规范导致模块无法被正确引用。
+
+---
+
+## 4. 框架无关规范
+
+**规则**：通用模块禁止引入框架特定的API（如 `$.xxx`、`$.utils`）。
+
+**违反后果**：引入框架API导致模块失去通用性，只能在特定框架下使用。

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

@@ -0,0 +1,34 @@
+# 代码封装技巧
+
+## 1. 单一职责原则
+
+**适用场景**：决定是否将功能拆分为独立模块时。
+
+**具体做法**：每个模块只做一件事，如果模块功能超过一个，考虑拆分。
+
+**注意事项**：模块粒度过细会导致文件过多，过粗则复用性差。
+
+---
+
+## 2. 使用默认参数简化调用
+
+**适用场景**：函数参数较多且大部分有默认值时。
+
+**示例**：
+```javascript
+function createUser({ name, email, role = 'user', status = 'active' }) {
+  // 使用解构默认值
+}
+```
+
+**注意事项**：使用对象参数代替多个位置参数，提高可读性。
+
+---
+
+## 3. 常见问题速查
+
+| 问题 | 原因 | 解决方案 |
+|------|------|---------|
+| 模块导出后为undefined | 导出方式错误 | 检查 `module.exports` |
+| 循环依赖 | 模块互相引用 | 重构模块结构，引入中间层 |
+| 全局变量污染 | 未使用模块作用域 | 使用 `const/let` 代替 `var` |

package/common/work/develop/code_encapsulation/work.json

@@ -0,0 +1 @@
+{"name":"code_encapsulation","description":"通用Node.js代码封装技能，与框架无关，含函数/类/模块/NPM包封装形式及规范","type":"dynamic","group":"develop"}

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

@@ -0,0 +1,24 @@
+# 工具创建规范 - 方法文档
+
+## 操作流程
+
+### 步骤1：需求确认
+- 明确工具名称（name）
+- 确定工具标题（title）
+- 编写功能描述（description）
+- 定义参数（params）和返回值（returns）
+- 确定分组（group）
+
+### 步骤2：编写tool.json
+- 从零开始编写配置
+- 逐字段填写，确保理解每个字段含义
+- 参数定义完整（类型、必填、描述）
+
+### 步骤3：创建工具
+- 调用工具创建功能
+- 传入完整参数
+
+### 步骤4：创建后自检
+- 读取刚创建的tool.json
+- 逐项核对所有字段
+- 确认配置正确性

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

@@ -0,0 +1,34 @@
+# 工具创建规范 - 规则文档
+
+## 任务目标
+按标准化流程创建工具，确保tool.json配置正确，避免配置错误。
+
+## 输入条件
+- 工具需求（功能、输入、输出）
+- 工具命名规范
+- 目标智能体信息
+
+## 必须遵守的规则
+
+### 规则1：标准化配置流程
+- 从零编写tool.json，不得直接复制其他工具的配置
+- 每个字段必须理解其含义后再填写
+- 配置完成后逐项自检
+
+### 规则2：tool.json必填字段
+- **name**：小写蛇形，唯一标识
+- **title**：中文名称
+- **description**：功能描述，50字以内
+- **params**：参数定义，每个参数包含type、required、desc
+- **returns**：返回值定义，包含type和desc
+- **group**：分组，如default、develop、service
+
+### 规则3：自检要求
+创建完成后必须逐项核对：
+- 工具名称是否正确
+- 所有参数是否完整定义
+- 返回值格式是否清晰
+- 主入口路径是否正确
+
+## 输出要求
+- 创建完成的工具（tool.json + index.js）

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

@@ -0,0 +1,26 @@
+# 工具创建规范 - 技巧文档
+
+## 最佳实践
+
+### 配置编写技巧
+- 先列大纲再逐项填写
+- 参数名使用小写蛇形
+- 描述简洁明了，避免歧义
+
+### 自检清单
+- name是否符合命名规范
+- title是否清晰表达功能
+- description是否在50字以内
+- params是否覆盖所有输入
+- returns是否定义清晰
+
+### 常见错误
+- **忘记必填参数**：列出所有参数逐一检查
+- **类型定义错误**：确认使用正确的类型名称
+- **路径配置错误**：确认main指向正确的文件路径
+- **分组不当**：选择最匹配的功能分组
+
+### 经验要点
+- 参数顺序按重要程度排列
+- 可选参数设置合理的默认值
+- 返回值包含足够的信息

package/common/work/develop/create_tool_standard/work.json

@@ -0,0 +1 @@
+{"name":"create_tool_standard","description":"按标准化流程创建工具，确保tool.json配置正确避免错误","type":"dynamic","group":"develop"}

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

@@ -0,0 +1,20 @@
+# 数据库设计方法
+
+## 前置条件
+
+- [ ] 已获取需求文档，了解数据实体和关系
+- [ ] 已获取架构设计文档（如有）
+
+## 流程概览
+
+分析数据需求 → 设计表结构 → 设计索引策略 → 编写SQL建表脚本 → 输出数据库设计文档
+
+## 详细步骤
+
+### 步骤1：分析数据需求
+分析需求文档，提取数据实体和关系。分析架构设计文档（若存在），提取数据字段需求。
+
+### 步骤2：设计表结构
+对每个实体，设计数据库表：
+- 表名：snake_case格式
+- 字段：包含字段名、类型、长度、是否为空、默认值

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

@@ -0,0 +1,95 @@
+# 数据库设计规范
+
+## 适用对象和范围
+
+本规范适用于所有设计数据库模型的场景，包括表结构设计、索引优化、关系设计和SQL编写。
+
+---
+
+## 1. 表名规范
+
+**规则**：表名必须使用小写蛇形（snake_case），单数形式。
+
+- ✅ 正确：`user_accounts`、`order_items`、`product_categories`
+- ❌ 错误：`UserAccounts`、`userAccounts`、`users`（复数）
+
+**违反后果**：表名不规范导致SQL语句可读性差，与ORM默认映射冲突。
+
+---
+
+## 2. 字段名规范
+
+**规则**：字段名必须使用小写蛇形（snake_case）。
+
+- ✅ 正确：`user_name`、`created_at`、`is_active`
+- ❌ 错误：`userName`、`createdAt`、`isActive`
+
+**违反后果**：字段名不规范导致SQL语句可读性差。
+
+---
+
+## 3. 主键规范
+
+**规则**：每个表必须有主键，通常为自增INT或UUID。
+
+- ✅ 正确：`id INT AUTO_INCREMENT PRIMARY KEY`
+- ❌ 错误：无主键或使用业务字段做主键
+
+**违反后果**：无主键导致数据无法唯一标识，影响数据操作和性能。
+
+---
+
+## 4. 数据库规范化
+
+**规则**：数据库设计必须满足至少第三范式（3NF），禁止存储冗余数据。
+
+- ✅ 正确：用户信息存在 `users` 表，订单信息存在 `orders` 表，通过 `user_id` 关联
+- ❌ 错误：在 `orders` 表中同时存储 `user_name`、`user_email` 等用户信息
+
+**违反后果**：冗余数据导致数据不一致（更新异常），浪费存储空间。
+
+---
+
+## 5. 索引策略规范
+
+**规则**：必须为以下字段创建索引：
+- 主键（自动创建）
+- 业务唯一字段（创建唯一索引）
+- 经常作为查询条件的字段（创建普通索引）
+- 多条件查询的字段组合（创建复合索引）
+
+- ✅ 正确：为 `email` 创建唯一索引，为 `status` 创建普通索引
+- ❌ 错误：不为查询字段创建索引
+
+**违反后果**：缺少索引导致查询性能差，大数据量时响应缓慢。
+
+---
+
+## 6. 外键规范
+
+**规则**：关联其他表的字段必须注明参照关系，命名使用 `{参照表名}_id`。
+
+- ✅ 正确：`user_id`（参照 users 表）、`order_id`（参照 orders 表）
+- ❌ 错误：`uid`、`oid`（含义不明确）
+
+**违反后果**：外键命名不明确导致表关系难以理解。
+
+---
+
+## 7. 字段类型规范
+
+**规则**：字段类型必须根据实际数据选择，避免过度使用大类型。
+
+| 数据类型 | 适用场景 |
+|---------|---------|
+| INT/BIGINT | 整数ID、计数 |
+| VARCHAR(n) | 变长字符串，n为最大长度 |
+| TEXT | 长文本（超过VARCHAR上限） |
+| DATETIME/TIMESTAMP | 日期时间 |
+| DECIMAL(m,n) | 金额等精确小数 |
+| TINYINT | 布尔值（0/1） |
+
+- ✅ 正确：状态用 `TINYINT`，姓名用 `VARCHAR(50)`，金额用 `DECIMAL(10,2)`
+- ❌ 错误：状态用 `VARCHAR(255)`，金额用 `FLOAT`
+
+**违反后果**：字段类型选择不当导致存储浪费或精度丢失。