mm_ai 1.0.0

package/common/work/design/scene_design/prompt/rule.md

@@ -0,0 +1,29 @@
+# 场景设计规范
+
+## 适用对象和范围
+
+本规范适用于所有设计场景环境布局、氛围光影和多角度描述的场景。
+
+---
+
+## 1. 空间布局规范
+
+**规则**：禁止缺少空间布局描述，必须明确区域划分和主要物体位置。
+
+**违反后果**：无空间布局导致场景无法在故事中一致呈现。
+
+---
+
+## 2. 多角度描述规范
+
+**规则**：必须覆盖入口视角、中央视角、俯瞰至少3个视角。
+
+**违反后果**：缺少多角度描述导致场景空间感不完整。
+
+---
+
+## 3. 环境氛围规范
+
+**规则**：光线、色调、声音至少3项必须填写。
+
+**违反后果**：氛围缺失导致场景情感表达不足。

package/common/work/design/scene_design/prompt/trick.md

@@ -0,0 +1,20 @@
+# 场景设计技巧
+
+## 1. 用五感描写场景
+
+**适用场景**：需要让场景更生动时。
+
+**具体做法**：不仅描述视觉，还要描述声音、气味、温度和触感。
+
+## 2. 场景与剧情联动
+
+**适用场景**：场景需要服务于剧情时。
+
+**具体做法**：场景的氛围应与当前剧情的情绪基调一致。
+
+## 3. 常见问题速查
+
+| 问题 | 原因 | 解决方案 |
+|------|------|---------|
+| 场景布局不合理 | 空间规划不当 | 调整区域划分和动线 |
+| 场景与剧情冲突 | 方位描述矛盾 | 统一方位描述 |

package/common/work/design/scene_design/work.json

@@ -0,0 +1 @@
+{"name":"scene_design","description":"设计场景的环境布局、氛围光影和多角度描述，确保场景在故事中呈现一致","type":"dynamic","group":"design"}

package/common/work/design/storyboard_design/prompt/method.md

@@ -0,0 +1,10 @@
+# 分镜设计方法
+
+## 流程概览
+
+分析需求 → 设计分镜
+
+## 步骤
+
+1. 分析剧本和场景设计文档
+2. 设计分镜，确定镜头角度、画面构图和转场方式

package/common/work/design/storyboard_design/prompt/rule.md

@@ -0,0 +1,9 @@
+# 分镜设计规范
+
+## 1. 剧本一致性
+
+分镜必须与剧本中的场景描述和角色动作一致。
+
+## 2. 镜头语言清晰
+
+每个镜头的角度、运镜方式和构图必须明确。

package/common/work/design/storyboard_design/prompt/trick.md

@@ -0,0 +1,3 @@
+# 分镜设计技巧
+
+镜头服务于叙事：镜头的选择应服务于故事的情感和节奏需求。

package/common/work/design/storyboard_design/work.json

@@ -0,0 +1 @@
+{"name":"storyboard_design","description":"将剧本转化为镜头语言，包括镜头角度、运镜方式、构图规则和角色走位","type":"dynamic","group":"design"}

package/common/work/design/test_responsive/prompt/method.md

@@ -0,0 +1,18 @@
+# 响应式测试 - 方法
+
+## 流程概览
+```
+确定测试设备范围 → 逐尺寸测试 → 记录问题 → 生成测试报告
+```
+
+## 步骤1：确定测试设备范围
+确定要测试的屏幕尺寸列表。
+
+## 步骤2：逐尺寸测试
+对每个屏幕尺寸检查布局自适应、导航可用性、图片缩放、文本可读性、交互元素可点击性。
+
+## 步骤3：记录问题
+按错误报告格式记录每个问题（问题现象、位置、修改建议）。
+
+## 步骤4：生成测试报告
+以矩阵表格展示每个尺寸×每个页面的测试结果。

package/common/work/design/test_responsive/prompt/rule.md

@@ -0,0 +1,12 @@
+# 响应式测试 - 规范
+
+## 1. 测试范围
+- 必须覆盖桌面、平板、移动端三种设备
+- 桌面端：1920×1080, 1440×900, 1366×768
+- 平板端：1024×768, 768×1024
+- 移动端：375×667, 414×896, 360×640
+
+## 2. 测试原则
+- 禁止仅测试单一尺寸就判定通过
+- 禁止忽略影响功能使用的布局问题
+- 调试完成后必须清理临时文件

package/common/work/design/test_responsive/prompt/trick.md

@@ -0,0 +1,10 @@
+# 响应式测试 - 技巧
+
+## 1. 设备模拟
+使用浏览器开发者工具的Device Mode模拟不同设备。
+
+## 2. 断点测试
+在CSS断点附近测试，最容易发现布局问题。
+
+## 3. 问题定位
+复制CSS到temp目录逐步调试，定位后再修改原文件。

package/common/work/design/test_responsive/work.json

@@ -0,0 +1 @@
+{"name":"test_responsive","description":"响应式测试","type":"dynamic","group":"design"}

package/common/work/design/ui_design/prompt/method.md

@@ -0,0 +1,10 @@
+# UI设计方法
+
+## 流程概览
+
+分析需求 → 设计UI规范
+
+## 步骤
+
+1. 分析画风指南和需求文档
+2. 制定UI设计规范，包括色彩、字体、间距和组件

package/common/work/design/ui_design/prompt/rule.md

@@ -0,0 +1,9 @@
+# UI设计规范
+
+## 1. 画风一致
+
+UI风格必须与画风指南一致。
+
+## 2. 规范统一
+
+所有界面必须遵循统一的色彩体系、字体规范和间距规范。

package/common/work/design/ui_design/prompt/trick.md

@@ -0,0 +1,3 @@
+# UI设计技巧
+
+以用户为中心：UI设计应优先考虑用户体验的易用性和直观性。

package/common/work/design/ui_design/work.json

@@ -0,0 +1 @@
+{"name":"ui_design","description":"制定UI设计规范和组件库说明，输出设计标准文档","type":"dynamic","group":"design"}

package/common/work/design/world_building/prompt/method.md

@@ -0,0 +1,32 @@
+# 世界观构建方法
+
+## 前置条件
+
+- [ ] 已获取概念文档
+
+## 流程概览
+
+框架设定 → 定义世界法则 → 设计力量体系 → 设计文明格局 → 宏观历史 → 输出世界观圣经 → 一致性校验
+
+## 详细步骤
+
+### 步骤1：框架设定
+分析概念文档，确定世界的基本框架。
+
+### 步骤2：定义世界法则
+包含物理法则差异、超自然法则、世界边界、核心规则。
+
+### 步骤3：设计力量体系
+包含力量等级划分、各等级能力范围、成长路径。
+
+### 步骤4：设计文明格局
+确定文明分布、种族设定、势力关系。
+
+### 步骤5：宏观历史
+编写历史年表、重大事件、时代划分。
+
+### 步骤6：输出世界观圣经
+综合以上内容输出完整世界观文档。
+
+### 步骤7：一致性校验
+与地图和背景设计进行一致性校验。

package/common/work/design/world_building/prompt/rule.md

@@ -0,0 +1,17 @@
+# 世界观构建规范
+
+## 适用对象和范围
+
+本规范适用于所有构建世界宏观规则和运行逻辑的场景。
+
+## 1. 内部一致性规范
+
+**规则**：世界观内部规则不能矛盾，核心规则一旦设定不可违反。
+
+## 2. 与地图一致性规范
+
+**规则**：世界观中的文明分布必须与地图上的地域一致。
+
+## 3. 与背景一致性规范
+
+**规则**：力量体系、科技水平必须与时代背景匹配。

package/common/work/design/world_building/prompt/trick.md

@@ -0,0 +1,12 @@
+# 世界观构建技巧
+
+## 1. 从核心规则出发
+
+先定义世界的根本规则（如"死者不可复生"），所有设计围绕核心规则展开。
+
+## 2. 常见问题速查
+
+| 问题 | 原因 | 解决方案 |
+|------|------|---------|
+| 世界观与地图矛盾 | 文明分布与地形不符 | 修正世界观或地图 |
+| 力量体系与角色矛盾 | 角色拥有不存在的力量 | 修正角色设计或力量体系 |

package/common/work/design/world_building/work.json

@@ -0,0 +1 @@
+{"name":"world_building","description":"构建世界的宏观规则和运行逻辑，包括世界法则、力量体系、文明格局和宏观历史","type":"dynamic","group":"design"}

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

@@ -0,0 +1,18 @@
+# API接口设计方法
+
+## 前置条件
+
+- [ ] 已获取需求文档，了解需要暴露的API接口列表
+- [ ] 已识别实体资源和操作类型（增删改查）
+
+## 流程概览
+
+分析功能需求 → 设计RESTful路由 → 定义请求和响应格式 → 编写API文档 → 评审优化
+
+## 详细步骤
+
+### 步骤1：分析功能需求
+分析需求文档，提取需要暴露的API接口列表，识别实体资源和操作类型（增删改查）。
+
+### 步骤2：设计RESTful路由
+对每个资源，设计标准RESTful路由。

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

@@ -0,0 +1,107 @@
+# API接口设计规范
+
+## 适用对象和范围
+
+本规范适用于所有设计RESTful API接口的场景，包括路由规划、参数定义、返回格式和错误处理。
+
+---
+
+## 1. 路由命名规范
+
+**规则**：路由路径必须使用名词复数形式，禁止使用动词。
+
+- ✅ 正确：`GET /api/users`、`POST /api/users`、`GET /api/users/{id}`
+- ❌ 错误：`GET /api/getUser`、`POST /api/createUser`、`GET /api/user`（单数）
+
+**违反后果**：动词式路由不符合RESTful规范，接口风格不统一，增加前端对接复杂度。
+
+---
+
+## 2. HTTP方法规范
+
+**规则**：必须按照标准RESTful语义使用HTTP方法。
+
+| 方法 | 用途 | 示例 |
+|------|------|------|
+| GET | 查询列表/详情 | `GET /api/users`、`GET /api/users/{id}` |
+| POST | 创建资源 | `POST /api/users` |
+| PUT | 全量更新 | `PUT /api/users/{id}` |
+| PATCH | 部分更新 | `PATCH /api/users/{id}` |
+| DELETE | 删除资源 | `DELETE /api/users/{id}` |
+
+- ✅ 正确：创建用户用 `POST /api/users`
+- ❌ 错误：创建用户用 `GET /api/users?action=create`
+
+**违反后果**：HTTP方法使用不当导致接口语义不清晰，缓存和代理无法正确工作。
+
+---
+
+## 3. 状态码规范
+
+**规则**：必须使用标准HTTP状态码表示接口执行结果。
+
+| 场景 | 状态码 | 说明 |
+|------|--------|------|
+| 查询成功 | 200 OK | 正常返回数据 |
+| 创建成功 | 201 Created | 资源已创建 |
+| 参数错误 | 400 Bad Request | 请求参数不合法 |
+| 未授权 | 401 Unauthorized | 需要登录 |
+| 无权限 | 403 Forbidden | 权限不足 |
+| 资源不存在 | 404 Not Found | 请求的资源不存在 |
+| 服务器错误 | 500 Internal Server Error | 服务器内部异常 |
+
+- ✅ 正确：创建资源返回 `201 Created`
+- ❌ 错误：创建资源返回 `200 OK` 但body中包含创建结果
+
+**违反后果**：状态码使用不规范导致前端无法通过状态码判断请求结果，增加处理复杂度。
+
+---
+
+## 4. 响应格式规范
+
+**规则**：所有接口必须返回统一的JSON响应格式。
+
+**成功响应**：
+```json
+{
+  "code": 0,
+  "message": "success",
+  "data": { ... }
+}
+```
+
+**错误响应**：
+```json
+{
+  "code": 40001,
+  "message": "参数错误：用户名为必填项",
+  "data": null
+}
+```
+
+- ✅ 正确：统一 `code` + `message` + `data` 格式
+- ❌ 错误：每个接口返回不同格式
+
+**违反后果**：响应格式不统一导致前端需要为每个接口单独处理响应解析。
+
+---
+
+## 5. 接口安全规范
+
+**规则**：禁止在接口中暴露敏感信息（密码、token、内部IP、数据库结构等）。
+
+- ✅ 正确：`{"id": 1, "name": "张三", "email": "zhang@example.com"}`
+- ❌ 错误：`{"id": 1, "name": "张三", "password": "123456", "token": "xxx", "internal_ip": "10.0.0.1"}`
+
+**违反后果**：暴露敏感信息存在严重安全风险。
+
+---
+
+## 6. 向后兼容规范
+
+**规则**：已有接口的路径和参数不能随意修改，如需修改必须走版本号升级。
+
+- ✅ 正确：`/api/v1/users` → `/api/v2/users`（大版本升级）
+- ❌ 错误：直接修改 `/api/users` 的参数结构
+
+**违反后果**：随意修改已有接口导致前端调用崩溃，影响线上服务。

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

@@ -0,0 +1,78 @@
+# API接口设计技巧
+
+## 1. 合理使用查询参数过滤
+
+**适用场景**：列表接口需要支持筛选条件时。
+
+**具体做法**：使用查询参数（query parameters）而非路径参数做筛选。
+
+**对比说明**：
+
+| 维度 | 路径参数 | 查询参数 |
+|------|---------|---------|
+| 语义 | 标识资源 | 过滤条件 |
+| 必填性 | 通常是必填 | 通常是可选 |
+| 组合 | 不可组合 | 可自由组合 |
+
+**示例**：
+```javascript
+// ✅ 推荐：查询参数过滤
+GET /api/users?status=active&role=admin&page=1&size=20
+
+// ❌ 不推荐：路径参数过滤
+GET /api/users/status/active/role/admin
+```
+
+**注意事项**：查询参数应该使用snake_case命名，保持与后端字段一致。
+
+---
+
+## 2. 使用嵌套路由表示资源关联
+
+**适用场景**：资源之间存在从属关系时。
+
+**具体做法**：使用嵌套路由 `/parent/{parentId}/child` 表示资源层级。
+
+**示例**：
+```javascript
+// 用户下的订单
+GET /api/users/{userId}/orders
+POST /api/users/{userId}/orders
+
+// 订单下的商品
+GET /api/orders/{orderId}/items
+```
+
+**注意事项**：嵌套层级不建议超过2层，超过时应考虑扁平化设计。
+
+---
+
+## 3. 批量操作使用自定义端点
+
+**适用场景**：需要批量创建、更新或删除时。
+
+**具体做法**：使用 `POST /api/{resources}/batch` 作为批量操作的端点。
+
+**示例**：
+```javascript
+// 批量创建
+POST /api/users/batch
+Body: { "users": [{...}, {...}] }
+
+// 批量删除
+POST /api/users/batch-delete
+Body: { "ids": [1, 2, 3] }
+```
+
+**注意事项**：批量操作应该返回每个资源的操作结果，而非整体成功/失败。
+
+---
+
+## 4. 常见问题速查
+
+| 问题 | 原因 | 解决方案 |
+|------|------|---------|
+| 接口返回格式不统一 | 未定义统一响应结构 | 定义 `{code, message, data}` 统一格式 |
+| 路由路径冲突 | 路径设计不合理 | 使用 `/api/v{version}/` 前缀隔离版本 |
+| 参数校验错误信息不清晰 | 校验逻辑过于简单 | 详细说明每个参数的取值范围和格式 |
+| 接口响应时间过长 | 未做分页或数据量过大 | 列表接口必须分页，设置默认pageSize |

package/common/work/develop/api_design/work.json

@@ -0,0 +1 @@
+{"name":"api_design","description":"设计RESTful API接口，包括路由规划、参数定义、返回格式和错误处理","type":"dynamic","group":"develop"}

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

@@ -0,0 +1,21 @@
+# API接口开发方法
+
+## 前置条件
+
+- [ ] 已获取API设计文档（路由、参数、响应格式）
+- [ ] 已了解数据模型定义
+- [ ] 已搭建好服务端框架
+
+## 流程概览
+
+分析API设计文档 → 编写路由定义 → 编写参数校验器 → 编写数据模型 → 编写控制器 → 注册路由到应用入口 → 验证接口完整性
+
+## 详细步骤
+
+### 步骤1：分析API设计文档
+分析API设计文档，提取每个接口的以下信息：
+- 请求方法（GET/POST/PUT/DELETE）
+- 路由路径
+- 请求参数（路径参数、查询参数、请求体）
+- 响应格式
+- 业务逻辑描述

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

@@ -0,0 +1,93 @@
+# API接口开发规范
+
+## 适用对象和范围
+
+本规范适用于所有实现后端API接口的场景，包括路由处理器、控制器、业务逻辑、参数校验和数据模型编写。
+
+---
+
+## 1. 分层职责规范
+
+**规则**：必须严格遵循分层架构，每层只做自己的事。
+
+| 层次 | 职责 | 禁止做的事 |
+|------|------|-----------|
+| 路由（routes） | URL映射和方法分发 | 写业务逻辑 |
+| 控制器（controllers） | 处理请求、调用服务、返回响应 | 直接操作数据库 |
+| 模型（models） | 数据访问和数据库操作 | 处理请求/响应 |
+| 校验器（validators） | 请求参数校验 | 修改数据 |
+
+- ✅ 正确：路由只做 `router.get('/users', userController.list)`
+- ❌ 错误：在路由中写 `router.get('/users', async (req, res) => { await db.query(...) })`
+
+**违反后果**：分层混乱导致代码耦合度高，难以维护和测试。
+
+---
+
+## 2. 命名规范
+
+**规则**：函数使用小驼峰（camelCase），变量和参数使用小写蛇形（snake_case），常量使用全大写蛇形（SCREAMING_SNAKE_CASE）。
+
+| 标识符类型 | 命名法 | 示例 |
+|-----------|--------|------|
+| 函数 | camelCase | `function getUserData(user_id) {}` |
+| 变量/参数 | snake_case | `let user_name = 'xxx';` |
+| 常量 | SCREAMING_SNAKE_CASE | `const MAX_RETRY_COUNT = 3;` |
+
+**违反后果**：命名不一致导致代码可读性差。
+
+---
+
+## 3. 缩进规范
+
+**规则**：统一使用2个空格缩进。
+
+**违反后果**：缩进不一致导致代码结构混乱。
+
+---
+
+## 4. 注释规范
+
+**规则**：函数必须使用JSDoc格式注释。
+
+```javascript
+/**
+ * 获取用户数据
+ * @param {number} user_id - 用户ID
+ * @returns {Promise<Object>} 用户数据对象
+ */
+async function getUserData(user_id) { ... }
+```
+
+**违反后果**：缺少JSDoc注释导致IDE无法提供类型提示。
+
+---
+
+## 5. 参数校验规范
+
+**规则**：所有用户输入必须经过参数校验，禁止信任任何外部输入。
+
+- ✅ 正确：校验器检查字段类型、格式、必填性
+- ❌ 错误：直接将用户输入传给数据库查询
+
+**违反后果**：未校验用户输入存在SQL注入等安全风险。
+
+---
+
+## 6. 错误处理规范
+
+**规则**：控制器中的异步操作必须使用 try/catch 捕获异常，返回统一错误格式。
+
+- ✅ 正确：
+```javascript
+async function list(req, res) {
+  try {
+    const users = await userModel.findAll();
+    res.json({ code: 0, data: users });
+  } catch (error) {
+    res.status(500).json({ code: 500, message: error.message });
+  }
+}
+```
+
+**违反后果**：未捕获异常导致服务器崩溃或返回500但不含有用信息。

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

@@ -0,0 +1,108 @@
+# API接口开发技巧
+
+## 1. 使用路由前缀统一管理版本
+
+**适用场景**：需要支持多个API版本时。
+
+**具体做法**：使用 `express.Router()` 的prefix参数统一添加版本前缀。
+
+**示例**：
+```javascript
+// routes/index.js
+const router = require('express').Router();
+const userRoutes = require('./user_routes');
+
+router.use('/api/v1/users', userRoutes);
+
+module.exports = router;
+```
+
+**注意事项**：版本号建议放在路由层，而不是在每个路由路径中手动添加。
+
+---
+
+## 2. 封装统一响应工具函数
+
+**适用场景**：需要确保所有接口返回格式一致时。
+
+**具体做法**：在 `utils/response.js` 中封装成功和失败的响应函数。
+
+**对比说明**：
+
+| 维度 | 每个接口手动构造响应 | 统一响应函数 |
+|------|-------------------|-------------|
+| 代码量 | 每个接口都要写格式 | 一行调用 |
+| 一致性 | 容易遗漏字段 | 自动保证格式统一 |
+| 修改 | 需改所有接口 | 只改响应函数 |
+
+**示例**：
+```javascript
+// utils/response.js
+exports.success = (res, data, message = 'success') => {
+  res.json({ code: 0, message, data });
+};
+
+exports.fail = (res, message, code = 400) => {
+  res.status(code).json({ code, message, data: null });
+};
+
+// controllers/user_controller.js
+const { success, fail } = require('../utils/response');
+
+exports.list = async (req, res) => {
+  try {
+    const users = await userModel.findAll();
+    success(res, users);
+  } catch (error) {
+    fail(res, error.message, 500);
+  }
+};
+```
+
+**注意事项**：错误码应与前端约定一致，建议维护一个错误码表。
+
+---
+
+## 3. 使用事务处理关联操作
+
+**适用场景**：需要同时操作多个表，保证数据一致性时。
+
+**具体做法**：使用数据库事务包裹多个操作。
+
+**示例**：
+```javascript
+// 使用数据库事务
+async function createOrder(userId, items) {
+  const conn = await db.getConnection();
+  try {
+    await conn.beginTransaction();
+    
+    const order = await conn.query('INSERT INTO orders ...');
+    for (const item of items) {
+      await conn.query('INSERT INTO order_items ...', [order.id, ...]);
+    }
+    
+    await conn.commit();
+    return order;
+  } catch (error) {
+    await conn.rollback();
+    throw error;
+  } finally {
+    conn.release();
+  }
+}
+```
+
+**注意事项**：事务会锁表，尽量保持事务简短，避免在事务中执行耗时操作。
+
+---
+
+## 4. 常见问题速查
+
+| 问题 | 原因 | 解决方案 |
+|------|------|---------|
+| 路由404 | 路由未注册或路径错误 | 检查 `app.js` 中是否 `use` 了路由 |
+| 请求体为空 | 未配置body解析中间件 | 添加 `express.json()` |
+| 参数校验不通过 | 校验规则过于严格 | 检查校验器的字段名和类型是否匹配 |
+| 数据库查询超时 | 缺少索引或查询量过大 | 添加索引或优化查询条件 |
+| 跨域请求被拦截 | 未配置CORS | 添加 `cors` 中间件 |

package/common/work/develop/api_implementation/work.json

@@ -0,0 +1 @@
+{"name":"api_implementation","description":"实现后端API接口，包括路由处理器、控制器、业务逻辑、参数校验等","type":"dynamic","group":"develop"}