cykj/hzdyjs

0 Fork 0

Files

T

📝 主要改进：
• Cursor配置模块化：拆分为前端、后端、移动端、文档、API测试5个专门规范文件
• API文档重新组织：按业务模块拆分到docs/开发文档/API/目录下
• 新增维修分类功能完整测试方案和自动化测试脚本
• 后端热启动脚本完善，支持Linux/Windows双平台
• 强化文档同步更新规范，确保代码与文档一致性

🔧 技术改进：
• 优化Cursor AI工作流程和代码生成质量
• 完善API测试规范（AES+RSA双重加密登录方法）
• 提升开发效率和代码质量标准化程度

�� 测试覆盖：
• 维修分类管理功能端到端测试验证通过
• 包含页面加载、CRUD操作、搜索功能等核心测试用例

更新时间：2025-07-01

2025-07-01 17:53:05 +08:00

25 KiB

Raw Blame History

Cursor Rules - 项目文档管理规范

项目结构说明

前端工程：web/ (基于 Vue 3 + TypeScript + Element Plus)
后端工程：backend/ (基于 RuoYi-Vue-Plus + Spring Boot 3.4.6)
移动端工程：mobile/ (基于 uniapp + uView UI 构建的校园管理移动端应用)
文档管理：docs/ (项目的需求、设计、开发、测试、部署文档)

项目文档管理规范

1. 文档结构管理 (docs/)

🔴 文档目录组织（中文化架构）

docs/
├── 项目总览/               # 项目基本信息和架构概览
│   ├── README.md          # 项目总览主文档
│   └── 项目总览模板.md     # 项目总览标准模板
├── 业务模块/               # 业务模块文档（为AI提供业务上下文）
│   ├── README.md          # 业务模块管理总览
│   ├── 业务模块开发模板.md  # 业务模块标准开发模板
│   ├── hq-satisfaction-survey/     # 后勤满意度调查模块
│   ├── hall-reservation/          # 报告厅预约模块
│   ├── system-management/         # 系统管理模块
│   └── user-management/           # 用户管理模块
├── 变更管理/               # 变更管理中心
│   ├── README.md          # 变更管理流程和规范
│   └── code-adjust-record.md      # 代码调整记录
├── 开发文档/               # 开发指南和技术规范
│   ├── README.md          # 开发文档总览
│   ├── API.md             # API接口完整文档
│   └── API文档模板.md      # API文档标准模板
├── 设计文档/               # 设计文档
│   ├── README.md          # 设计文档说明
│   └── database/          # 数据库设计
│       ├── hzdyjs_xg.sql         # 完整数据库模型
│       ├── 01-workflow-module.sql        # 工作流模块SQL
│       ├── 02-code-generator-module.sql  # 代码生成模块SQL
│       ├── 03-logistics-module.sql       # 后勤管理模块SQL
│       ├── 04-job-scheduler-module.sql   # 任务调度模块SQL
│       ├── 05-system-management-module.sql # 系统管理模块SQL
│       ├── 06-test-module.sql            # 测试模块SQL
│       ├── SQL文件说明.md                # SQL文件拆分说明
│       ├── mysql-database-standard.md   # MySQL数据库建设规范
│       ├── database_msg.md              # 环境配置信息
│       └── README.md                    # 数据库设计说明
├── 需求文档/               # 需求文档
│   ├── README.md          # 需求管理说明
│   ├── 后勤报告厅预约需求/ # 报告厅预约系统需求
│   └── 后勤满意度调查需求/ # 满意度调查系统需求
├── 测试文档/               # 测试文档（按需求维度组织）
│   ├── README.md          # 测试文档管理总览
│   ├── 后勤管理/           # 后勤管理相关测试文档
│   │   ├── 物业报修/       # 物业报修系统测试文档
│   │   ├── 满意度调查/     # 满意度调查系统测试文档
│   │   └── 报告厅预约/     # 报告厅预约系统测试文档
│   ├── 系统管理/           # 系统管理相关测试文档
│   ├── 用户管理/           # 用户管理相关测试文档
│   └── 工作流管理/         # 工作流管理相关测试文档
├── 部署文档/               # 部署文档
│   └── README.md          # 部署指南
├── 中间件配置/             # 中间件配置文档
│   ├── README.md          # 中间件配置说明
│   └── mysql-config.md    # MySQL配置文档
├── 知识库/                 # 知识库
├── 报告文档/               # 报告文档
├── structure-optimization-plan.md # 文档结构优化方案
└── README.md              # 文档体系总说明

🔴 重要文档说明

工程本地启动指导.md (项目根目录)：包含完整的环境配置和启动指南
技术要求更新：Node.js 20.15.x+, npm 10.7.x+
数据库环境：支持本地安装或使用阿里云测试环境
前端访问地址：http://localhost (非 3000 端口)

2. 🚨 强制性文档同步更新规则

📋 核心原则：代码与文档必须同步更新

⚠️ 超级重要：每次使用 Cursor AI 进行代码调整后，必须立即同步更新相应的项目文档！

🔴 强制更新触发条件

每次代码调整必须检查并更新以下文档：

后端代码调整时的强制文档更新：

✅ API 接口变更：
- 必须立即更新 docs/开发文档/API.md
- 新增接口：添加完整接口文档（地址、参数、响应、权限、示例）
- 修改接口：更新参数说明、响应格式、错误码
- 删除接口：标记为已废弃，说明替代方案
- 权限变更：更新权限要求说明
✅ 数据库变更：
- 更新 docs/设计文档/database/ 下的相关文档
- 新增表：添加表结构说明和字段注释
- 修改表：更新字段变更和索引调整
- 数据迁移：记录迁移脚本和注意事项
✅ 业务逻辑变更：
- 更新对应 docs/业务模块/[模块名称]/ 下的业务文档
- 更新业务流程图和业务规则说明
- 修改用户故事和功能需求
✅ 配置变更：
- 更新 docs/中间件配置/ 下的配置文档
- 更新 docs/部署文档/ 下的部署说明

前端代码调整时的强制文档更新：

✅ 页面功能变更：
- 更新对应业务模块的用户操作文档
- 更新 UI 设计规范文档
✅ API 调用变更：
- 检查前端 API 调用是否与后端 API 文档一致
- 更新 API 对接说明文档
✅ 组件变更：
- 更新组件使用说明和属性文档

移动端代码调整时的强制文档更新：

✅ 功能变更：更新移动端功能说明文档
✅ API 对接变更：更新移动端 API 调用文档
✅ 用户流程变更：更新用户操作指南

📚 docs 文档变更时的强制同步更新规则：

⚠️ 超级重要：每当 docs/目录下的文档结构或重要内容发生变更时，必须立即同步更新.cursorrules 文件！

🔴 文档结构变更：
- 新增/删除目录：同步更新.cursorrules 中的"文档目录组织"章节
- 重命名目录：更新所有相关路径引用
- 调整文档层级：更新文档结构说明
🔴 重要文档变更：
- 新增标准模板：在"文档模板体系"中添加说明
- 更新开发规范：同步调整.cursorrules 中对应的规范要求
- 修改工作流程：更新"文档更新标准工作流程"
🔴 技术环境变更：
- 环境要求调整：更新.cursorrules 中的技术栈规范
- 配置信息变更：同步更新相关配置说明
- 启动流程调整：更新开发指导相关内容
🔴 业务模块变更：
- 新增业务模块：在.cursorrules 中添加模块说明
- 模块架构调整：更新业务模块文档管理规范
- API 接口变更：确保.cursorrules 中的 API 规范同步

强制检查清单：

.cursorrules 中的文档目录结构是否与实际一致
重要文档路径引用是否全部更新
新增的开发规范是否已同步到.cursorrules
技术要求和环境配置是否保持一致

⏰ 时间填写强制性规范

🚨 重要：每次记录变更必须填写真实的当前时间！

强制性时间填写要求：

变更时间：必须填写变更发生的实际时间，不得使用错误或虚假时间
时间格式：严格按照 YYYY-MM-DD HH:mm:ss 格式填写
时区规范：使用北京时间（UTC+8）
获取方法：
- 在 macOS/Linux 系统中使用 date "+%Y-%m-%d %H:%M:%S" 命令
- 在 Windows 系统中使用 Get-Date -Format "yyyy-MM-dd HH:mm:ss" 命令
- 或使用当前系统显示的时间
验证要求：变更时间必须与实际代码修改时间相符

错误示例：

❌ 使用 1 月份时间但实际是 6 月份
❌ 使用固定模板时间不修改
❌ 时间格式不正确

正确示例：

✅ 2025-06-30 15:43:20 （实际是 6 月 30 日下午 3 点 43 分）
✅ 2025-06-30 18:30:00 （实际是 6 月 30 日晚上 6 点 30 分）

📝 变更记录排序规范

🚨 重要：变更记录必须按照倒序排列，最新记录在最上面！

记录排序要求：

排序原则：按时间倒序排列，最新的变更记录放在文件最上面
新增记录：每次新增变更记录都必须插入到文件开头（标题下方）
时间顺序：确保后面的记录时间早于前面的记录时间
便于查看：这样安排便于快速查看最近的变更情况

正确的排序示例：

# 代码调整记录

## 调整记录 - 2025-06-30 18:30:00 ← 最新记录

## 调整记录 - 2025-06-30 15:43:20 ← 次新记录

## 调整记录 - 2025-06-29 10:20:00 ← 更早记录

## 调整记录 - 2025-06-28 14:15:00 ← 最早记录

错误示例：

❌ 新记录添加到文件末尾
❌ 时间顺序混乱
❌ 按正序排列（最早在上面）

🔄 文档更新标准工作流程

Cursor AI 辅助开发的文档更新流程：

1. **AI代码生成/修改完成**
   ↓
2. **立即检查文档更新需求**
   - 是否涉及API变更？
   - 是否涉及数据库变更？
   - 是否涉及业务逻辑变更？
   - 是否涉及配置变更？
   - 是否涉及docs文档结构变更？
   ↓
3. **立即更新相关文档**（不得延后！）
   - 使用标准模板格式
   - 确保信息准确完整
   - 添加真实示例
   - ⚠️ 填写真实的当前时间，不得使用模板时间
   ↓
4. **检查并更新.cursorrules文件**（重要！）
   - 如有docs文档结构变更，同步更新.cursorrules
   - 如有技术要求变更，同步更新技术栈规范
   - 如有开发流程变更，同步更新工作流程
   ↓
5. **记录变更日志**（按倒序插入到当日文件开头！）
   - 检查并创建当日变更记录文件：`code-adjust-record-YYYY-MM-DD-{username}.md`
   - 在当日文件开头添加新记录（倒序排列）
   - 无需维护索引文件，专注于自己的变更记录
   - 标注已同步更新的文档列表
   - 标注是否已更新.cursorrules文件
   ↓
6. **验证文档准确性**
   - 确保文档与实际代码一致
   - 验证示例可以正常运行
   - 验证.cursorrules与实际项目状态一致
   - 确认记录时间排序正确
   ↓
7. **提交代码和文档变更**

📝 变更记录文件管理规范

🚨 重要：从 2025-06-30 开始，变更记录按日期和用户分文件管理！

📁 文件命名规范

文件格式: code-adjust-record-YYYY-MM-DD-{username}.md
存放位置: docs/变更管理/ 目录
命名示例: code-adjust-record-2025-06-30-zlwu.md
获取用户名: 使用 git config --get user.name 命令获取
获取日期: 使用 date "+%Y-%m-%d" 命令获取

🔄 文件创建和使用流程

检查当日文件是否存在：

USERNAME=$(git config --get user.name)
TODAY=$(date "+%Y-%m-%d")
FILENAME="docs/变更管理/code-adjust-record-${TODAY}-${USERNAME}.md"

文件不存在时创建新文件：
- 使用标准模板创建当日变更记录文件
- 文件头包含日期、用户名、排序说明
记录变更时：
- 在当日文件开头插入新记录（倒序排列）
- 无需维护索引文件，每人管理自己的变更记录

👥 多用户协作规范

独立管理: 每个用户有独立的日变更文件，完全避免多人同时编辑冲突
无需协调: 不需要维护共享索引文件，每人管理自己的变更记录
用户名一致性: 确保 git 用户名配置正确，保持文件命名的一致性
文件归档: 历史文件保留，便于追溯和审计
查找便利: 通过文件名快速定位特定日期和用户的变更记录

📋 每日变更文件标准格式

# 代码调整记录 - YYYY-MM-DD - {username}

> 📅 **记录日期**: YYYY-MM-DD  
> 👤 **记录人员**: {username}  
> 📌 **排序说明**: 本文件按照时间倒序排列，最新的变更记录在最上面

## 调整记录 - YYYY-MM-DD HH:mm:ss

**变更 ID**: CHG-YYYYMMDD-001
**变更时间**: YYYY-MM-DD HH:mm:ss （⚠️ 必须填写真实的当前时间！）
**变更人员**: [开发者姓名/Cursor AI 辅助]
**变更类型**: 🆕 新功能/🐛Bug 修复/🔧 重构优化/📚 文档更新/⚙️ 配置调整
**影响级别**: 🔴 重大变更/🟡 中等变更/🟢 小变更

### 📋 变更概述

**变更目的**: [简述变更原因和目标，1-2 句话]
**影响范围**: [列出受影响的模块、功能或文件]

### 📁 涉及文件

**后端文件**:

-   backend/[具体文件路径 1]
-   backend/[具体文件路径 2]

**前端文件**:

-   web/[具体文件路径 1]
-   web/[具体文件路径 2]

**配置文件**:

-   [配置文件路径]

### 🔧 变更内容详述

**业务逻辑变更**:

1. [具体业务逻辑的变更说明]
2. [新增或修改的业务规则]

**技术实现变更**:

1. [技术方案的调整说明]
2. [代码结构的优化内容]

**接口变更**:

-   **新增接口**: [新增接口列表]
-   **修改接口**: [修改的接口及变更内容]
-   **废弃接口**: [废弃的接口及替代方案]

**数据库变更**:

-   **新增表**: [新增表及字段说明]
-   **修改表**: [表结构变更内容]
-   **数据迁移**: [数据迁移脚本或说明]

### 📖 文档同步更新记录

**API 文档**:

-   [ ] ✅ 已更新 docs/开发文档/API.md
-   [ ] ✅ 已更新模块 API 接口设计文档

**业务文档**:

-   [ ] ✅ 已更新业务模块文档
-   [ ] ✅ 已更新用户操作手册

**技术文档**:

-   [ ] ✅ 已更新数据库设计文档
-   [ ] ✅ 已更新架构设计文档

**其他文档**:

-   [ ] ✅ 已更新部署文档
-   [ ] ✅ 已更新配置文档

**规范文件**:

-   [ ] ✅ 已检查并同步更新.cursorrules 文件
-   [ ] ✅ 已确认文档结构与.cursorrules 一致

### 🧪 测试验证

**功能测试**:

-   [ ] 单元测试通过
-   [ ] 集成测试通过
-   [ ] 功能验收测试通过

**文档验证**:

-   [ ] 文档内容与代码实现一致
-   [ ] 示例代码可以正常运行
-   [ ] 接口文档已验证准确性

### 📝 备注

**已知问题**: [如有已知问题需要说明]
**后续计划**: [后续的改进或扩展计划]
**相关链接**: [相关的 Issue、PR 或文档链接]

---

3. 🔧 业务模块文档管理（为 Cursor AI 提供完整上下文）

业务模块文档标准结构

每个业务模块都必须包含以下完整文档：

业务模块/[模块名称]/
├── README.md                    # 模块总览
├── 需求分析/
│   ├── 业务需求说明.md           # 详细业务需求
│   ├── 功能需求清单.md           # 功能点清单
│   ├── 非功能需求.md             # 性能、安全要求
│   └── 用户故事.md               # 用户使用场景
├── 技术设计/
│   ├── 数据库设计.md             # 表结构设计
│   ├── API接口设计.md            # 接口定义
│   ├── 架构设计.md               # 模块架构
│   └── 技术选型.md               # 技术决策说明
├── 实现文档/
│   ├── 后端实现说明.md           # 后端代码结构
│   ├── 前端实现说明.md           # 前端代码结构
│   ├── 关键业务逻辑.md           # 核心算法逻辑
│   └── 代码规范.md               # 编码规范
├── 测试文档/
│   ├── 测试计划.md               # 测试策略
│   ├── 测试用例.md               # 具体测试用例
│   └── 测试报告.md               # 测试结果
└── 运维文档/
    ├── 部署指南.md               # 部署步骤
    ├── 监控配置.md               # 监控指标
    └── 故障处理.md               # 常见问题

🤖 Cursor AI 开发提示词模板

新功能开发提示词：

基于以下业务模块文档为 [功能名称] 开发代码：

业务上下文：docs/业务模块/[模块名称]/需求分析/
技术规范：docs/业务模块/[模块名称]/技术设计/
代码结构：docs/业务模块/[模块名称]/实现文档/
API规范：docs/开发文档/API.md

请确保：
1. 遵循项目编码规范
2. 使用标准的代码结构
3. 添加完整的注释
4. 生成单元测试代码
5. 立即更新相关文档

开发完成后请同步更新：
- docs/开发文档/API.md（如涉及API）
- docs/业务模块/[模块名称]/相关文档
- docs/变更管理/code-adjust-record.md

文档更新提示词：

根据刚才的代码变更，请更新以下文档：

变更内容：[具体变更说明]
影响模块：[模块名称]

需要更新的文档：
1. docs/开发文档/API.md - [具体更新内容]
2. docs/业务模块/[模块名称]/[具体文档] - [具体更新内容]
3. docs/设计文档/database/ - [如涉及数据库变更]

请使用标准的文档模板格式，确保信息准确完整。

4. 📚 API 文档管理规范

🔴 强制性 API 文档更新规则

⚠️ 超级重要：任何 API 接口的新增、修改、删除都必须立即同步更新 docs/开发文档/API.md 文档！

API 文档标准格式

使用 docs/开发文档/API/API文档模板.md 中的标准格式：

#### 接口名称

**接口地址**: `HTTP方法 /api/路径`
**接口描述**: 接口功能的详细描述
**权限要求**: 权限代码或"需要登录"

**请求参数**:
| 参数名 | 类型 | 必填 | 说明 | 示例值 |
|--------|------|------|------|--------|
| param1 | String | Y | 参数说明 | "example" |

**响应示例**:

```json
{
    "code": 200,
    "msg": "操作成功",
    "data": {}
}
```

错误码:

错误码	说明	解决方案
400001	参数错误	检查请求参数


### 🚨 API变更强制检查清单

当进行以下操作时，必须更新 `docs/开发文档/API.md`：

**Controller层变更**：
- [ ] 新增Controller类 → 在API.md中添加新的模块章节
- [ ] 新增@RequestMapping方法 → 添加完整的接口文档
- [ ] 修改@RequestMapping路径 → 更新接口地址
- [ ] 修改HTTP方法 → 更新接口方法
- [ ] 删除接口方法 → 标记为已废弃并说明替代方案

**参数和响应变更**：
- [ ] 新增请求参数 → 更新请求参数表格
- [ ] 修改参数类型或必填属性 → 更新参数说明
- [ ] 修改响应数据结构 → 更新响应示例
- [ ] 新增错误码 → 更新错误码说明表

**权限和安全变更**：
- [ ] 新增@SaCheckPermission注解 → 更新权限要求
- [ ] 修改权限代码 → 更新权限说明
- [ ] 修改接口访问级别 → 更新权限要求说明

## 5. 📊 文档模板体系

### 已创建的标准模板：
- **`docs/项目总览/项目总览模板.md`** - 项目基本信息模板
- **`docs/业务模块/业务模块开发模板.md`** - 业务模块开发标准模板
- **`docs/开发文档/API/API文档模板.md`** - API接口文档标准模板

### 模板使用规范：
1. **新项目或模块开发时**：复制对应模板，替换占位符
2. **文档更新时**：参考模板格式，保持结构一致
3. **Cursor AI生成文档时**：使用模板作为格式参考

## 6. 🔍 文档质量控制

### 文档完整性检查清单：
- [ ] 文档结构符合标准模板
- [ ] 内容与实际代码实现一致
- [ ] API文档包含完整示例
- [ ] 业务逻辑描述清晰准确
- [ ] 技术实现说明详细
- [ ] 变更历史有完整记录
- [ ] 所有占位符已替换为真实内容

### 文档准确性验证：
- [ ] API接口示例可以正常调用
- [ ] 数据库脚本可以成功执行
- [ ] 配置文档与实际配置一致
- [ ] 部署文档可以成功部署

## 7. 🧪 测试文档管理规范

### 🔴 测试文档组织原则
- **按需求维度分类**：测试文档必须按照业务需求模块进行组织，不得混合存放
- **结论性文档独立存放**：测试结论性文档必须存放在 `docs/测试文档/` 目录下
- **测试代码独立存放**：测试相关代码必须只存放在 `test/` 目录下
- **日期标识规范**：每次创建的测试文档必须以日期结尾来区分版本

### 🔴 测试文档目录结构规范

docs/测试文档/ ├── README.md # 测试文档管理总览 ├── [业务模块]/ # 按业务模块分类 │ ├── [具体功能]/ # 具体功能测试 │ │ ├── [功能]接口测试报告-YYYY-MM-DD.md # 接口测试报告 │ │ ├── [功能]功能测试报告-YYYY-MM-DD.md # 功能测试报告 │ │ ├── [功能]性能测试报告-YYYY-MM-DD.md # 性能测试报告 │ │ └── [功能]集成测试报告-YYYY-MM-DD.md # 集成测试报告 │ └── ... └── ...

test/ ├── package.json # 测试依赖配置 ├── [功能]-api-test.js # API 接口测试脚本 ├── [功能]-detailed-test.js # 详细测试分析脚本 ├── [功能]-performance-test.js # 性能测试脚本 └── ...


### 🔴 测试文档强制要求

#### 1. 测试结论性文档放置规则
- **强制位置**：必须放置在 `docs/测试文档/` 目录下
- **分类方式**：按照需求维度创建子文件夹存放
- **命名规范**：文档名称必须以日期结尾（格式：YYYY-MM-DD）
- **示例路径**：

docs/测试文档/后勤管理/物业报修/物业报修接口测试报告-2025-01-26.md docs/测试文档/系统管理/用户管理/用户管理功能测试报告-2025-01-26.md


#### 2. 测试代码存放规则
- **强制位置**：只能存放在 `test/` 目录下
- **禁止混合**：test目录下不得存放测试结论性文档
- **代码分类**：按功能模块组织测试脚本
- **示例文件**：

test/pm-repair-api-test.js # 物业报修 API 测试 test/user-management-test.js # 用户管理测试 test/custom-login-script.js # 登录认证工具


#### 3. 测试文档必含信息
每个测试结论性文档必须包含以下信息：
- **📁 测试代码路径**：明确标注对应的测试脚本位置
- **🔧 使用方法**：详细说明如何运行测试脚本
- **📊 测试结果**：完整的测试结果和数据分析
- **🎯 结论建议**：明确的测试结论和改进建议
- **⚠️ 问题记录**：发现的问题和解决方案

#### 测试文档标准模板格式：
```markdown
# [功能模块]测试报告

## 🎯 测试概览
**测试时间**: YYYY-MM-DD HH:mm:ss （⚠️必须填写真实的当前时间！）
**测试范围**: [具体测试范围]
**需求模块**: [所属业务模块]

## 📁 测试代码路径
**测试脚本位置**:
- **主要测试脚本**: `test/[功能]-api-test.js`
- **详细分析脚本**: `test/[功能]-detailed-test.js`
- **辅助工具脚本**: `test/[工具名].js`

**使用方法**:
```bash
cd test
npm install
node [功能]-api-test.js

✅ 测试结果总结

[测试结果详细内容]

🎯 结论

[测试结论和建议]

测试执行: 基于 test/ 目录下的测试脚本 文档路径: docs/测试文档/[模块]/[功能]/[报告名称]-YYYY-MM-DD.md


### 🔴 强制工作流程

#### 测试执行流程：

编写测试代码
- 在 test/ 目录下创建测试脚本
- 确保代码可独立运行 ↓
执行测试
- 运行测试脚本获取结果
- 记录详细的测试数据 ↓
创建测试报告
- 在 docs/测试文档/ 按需求维度创建报告
- 文档名称必须包含日期后缀
- 必须包含测试代码路径信息 ↓
清理 test 目录
- 删除 test 目录下的结论性文档
- 只保留测试代码和配置文件 ↓
更新文档索引
- 更新相关 README.md 文件
- 在变更记录中记录测试活动


### 🔴 违规检查和纠正
- **检查要点**：
  - [ ] test/目录下是否只有代码文件
  - [ ] docs/测试文档/下是否按需求维度组织
  - [ ] 测试报告是否包含代码路径信息
  - [ ] 文档命名是否包含日期后缀

- **纠正措施**：
  - 立即移动错误放置的文档到正确位置
  - 补充缺失的测试代码路径信息
  - 按规范重新组织文档结构

25 KiB Raw Blame History Unescape Escape

Cursor Rules - 项目文档管理规范

项目结构说明

项目文档管理规范

1. 文档结构管理 (docs/)

🔴 文档目录组织（中文化架构）

🔴 重要文档说明

2. 🚨 强制性文档同步更新规则

📋 核心原则：代码与文档必须同步更新

🔴 强制更新触发条件

后端代码调整时的强制文档更新：

前端代码调整时的强制文档更新：

移动端代码调整时的强制文档更新：

📚 docs 文档变更时的强制同步更新规则：

⏰ 时间填写强制性规范

强制性时间填写要求：

错误示例：

正确示例：

📝 变更记录排序规范

记录排序要求：

正确的排序示例：

错误示例：

🔄 文档更新标准工作流程

Cursor AI 辅助开发的文档更新流程：

📝 变更记录文件管理规范

📁 文件命名规范

🔄 文件创建和使用流程

👥 多用户协作规范

📋 每日变更文件标准格式

3. 🔧 业务模块文档管理（为 Cursor AI 提供完整上下文）

业务模块文档标准结构

🤖 Cursor AI 开发提示词模板

新功能开发提示词：

文档更新提示词：

4. 📚 API 文档管理规范

🔴 强制性 API 文档更新规则

API 文档标准格式

✅ 测试结果总结

🎯 结论

25 KiB

Raw Blame History