215 lines
5.3 KiB
Markdown
215 lines
5.3 KiB
Markdown
# AI工作指南
|
||
|
||
## 项目结构
|
||
|
||
### 1. 后端 + 管理后台
|
||
- **路径**: `Study-Vue-redis/`
|
||
- **技术栈**: Spring Boot + MyBatis + Vue.js
|
||
- **说明**: 包含后端API服务和管理后台前端
|
||
|
||
### 2. APP项目
|
||
- **路径**: `fronted_uniapp/`
|
||
- **技术栈**: uni-app (Vue.js)
|
||
- **说明**: 移动端应用，可打包为Android/iOS
|
||
|
||
### 3. 数据库
|
||
- **导入脚本**: `log/数据库/dump-study-202512070856.sql`
|
||
- **数据库名**: `study`
|
||
- **默认账号**: `root` / `root`
|
||
|
||
### 4. 开发环境
|
||
- **本地开发**: Windows环境，运行正常
|
||
- **部署环境**: Linux服务器，存在环境差异问题
|
||
- **注意**: 部署前需要测试环境兼容性
|
||
|
||
---
|
||
|
||
## 工作原则
|
||
|
||
### 原则1：主动获取信息
|
||
**优先使用工具获取信息，减少询问**
|
||
|
||
✅ **应该做的：**
|
||
- 使用`grep_search`查找代码
|
||
- 使用`read_file`读取配置文件
|
||
- 使用`run_command`检查端口占用、进程状态
|
||
- 查询数据库获取数据状态（配置文件中有账号密码）
|
||
- 查看日志文件分析问题
|
||
|
||
❌ **不应该做的：**
|
||
- 直接询问"端口是多少"（应该用命令查询）
|
||
- 询问"数据库密码是什么"（应该读取配置文件）
|
||
- 询问"这个文件在哪里"（应该用find_by_name搜索）
|
||
|
||
**例外情况：**
|
||
- 报错信息（需要用户提供控制台输出）
|
||
- 运行结果（需要用户反馈测试结果）
|
||
- 业务需求（需要用户明确需求细节）
|
||
|
||
---
|
||
|
||
### 原则2：确认需求再执行
|
||
**信息不完整时，先确认再行动**
|
||
|
||
✅ **检查清单：**
|
||
- [ ] 用户需求是否明确？有无歧义？
|
||
- [ ] 是否需要补充信息才能执行？
|
||
- [ ] 能否通过工具自行获取缺失信息？
|
||
- [ ] 执行前是否理解了预期结果？
|
||
|
||
**示例：**
|
||
- 用户说"修复这个bug" → 先确认具体是哪个bug，复现步骤是什么
|
||
- 用户说"部署到服务器" → 先确认服务器地址、环境、部署方式
|
||
- 用户说"优化性能" → 先确认性能瓶颈在哪里，优化目标是什么
|
||
|
||
---
|
||
|
||
### 原则3：简洁文档
|
||
**只在需要时写文档，内容精简实用**
|
||
|
||
✅ **文档要求：**
|
||
- 用户明确要求时才写文档
|
||
- 用户会指定文档路径
|
||
- 只写必要内容，不要冗余
|
||
- 重点突出，步骤清晰
|
||
- 使用Markdown格式
|
||
|
||
❌ **避免：**
|
||
- 自动生成大量README
|
||
- 过度详细的注释
|
||
- 重复的说明文档
|
||
- 长篇大论的总结
|
||
|
||
**例外情况：**
|
||
- SQL脚本（需要记录修改）
|
||
- 部署步骤（需要明确指引）
|
||
- 配置文件（需要说明参数）
|
||
|
||
---
|
||
|
||
### 原则4：理解功能逻辑
|
||
**充分理解现有功能后再修改**
|
||
|
||
✅ **功能理解流程：**
|
||
1. 使用`grep_search`和`code_search`查找相关代码
|
||
2. 阅读核心逻辑，理解业务流程
|
||
3. 用简洁语言总结功能逻辑
|
||
4. 提供实际应用场景示例
|
||
5. 确认理解正确后再进行修改
|
||
|
||
**示例：**
|
||
- 用户说"优化学习记录功能"
|
||
- → 先查找StudyLearningRecord相关代码
|
||
- → 理解当前如何记录学习进度
|
||
- → 总结：每次上报时更新learning_record和learning_detail
|
||
- → 场景：学生观看视频时每10秒上报一次进度
|
||
- → 确认理解无误后，再讨论优化方案
|
||
|
||
---
|
||
|
||
## 常见操作
|
||
|
||
### 编译后端
|
||
```bash
|
||
cd Study-Vue-redis
|
||
mvn clean package -DskipTests
|
||
```
|
||
|
||
### 启动后端
|
||
```bash
|
||
java -jar ry-study-admin/target/ry-study-admin.jar
|
||
```
|
||
|
||
### 查询数据库
|
||
```bash
|
||
mysql -u root -proot study -e "你的SQL语句"
|
||
```
|
||
|
||
### 查看端口占用
|
||
```powershell
|
||
netstat -ano | findstr :端口号
|
||
```
|
||
|
||
### 停止Java进程
|
||
```powershell
|
||
taskkill /F /IM java.exe
|
||
```
|
||
|
||
---
|
||
|
||
## 工作流程
|
||
|
||
### 1. 接收需求
|
||
- 阅读用户请求
|
||
- 识别关键信息
|
||
- 判断是否需要补充
|
||
|
||
### 2. 信息收集
|
||
- 优先使用工具获取
|
||
- 必要时向用户确认
|
||
- 确保信息完整
|
||
|
||
### 3. 分析问题
|
||
- 定位问题根源
|
||
- 查看相关代码
|
||
- 理解业务逻辑
|
||
|
||
### 4. 实施修改
|
||
- 最小化修改范围
|
||
- 保持代码风格一致
|
||
- 添加必要注释
|
||
|
||
### 5. 验证结果
|
||
- 编译测试
|
||
- 提供验证步骤
|
||
- 记录修改内容
|
||
|
||
---
|
||
|
||
## 经验总结
|
||
|
||
### BUG修复经验
|
||
|
||
#### 多视频时长问题（2025-12-12）
|
||
**问题**: 多个视频课件共用一个总时长字段
|
||
**方案**: 动态更新courseware.duration，每个课件独立存储
|
||
**教训**: 数据设计要考虑一对多关系
|
||
|
||
#### 防快进检测（2025-12-12）
|
||
**问题**: 用户拖动到末尾就能完成
|
||
**方案**: 添加累计观看时长检测（>=80%）
|
||
**教训**: 前端数据可被篡改，后端必须验证
|
||
|
||
#### 观看时长共用（2025-12-12）
|
||
**问题**: Mapper XML缺少coursewareId过滤
|
||
**方案**: 添加WHERE条件
|
||
**教训**: SQL查询必须明确过滤条件
|
||
|
||
#### 异常数据清理（2025-12-12）
|
||
**问题**: duration<=0的脏数据影响统计
|
||
**方案**: 清理异常数据，代码中过滤
|
||
**教训**: 数据验证要在代码和数据库两层进行
|
||
|
||
---
|
||
|
||
## 注意事项
|
||
|
||
1. **修改前先备份** - 重要文件修改前先备份
|
||
2. **测试后再部署** - 本地测试通过再部署到服务器
|
||
3. **保持代码风格** - 遵循项目现有代码规范
|
||
4. **避免过度设计** - 简单问题简单解决
|
||
5. **记录关键修改** - 重要修改需要记录在log目录
|
||
|
||
---
|
||
|
||
## 遇到问题时
|
||
|
||
1. 先查看日志文件
|
||
2. 使用grep搜索相关代码
|
||
3. 查询数据库验证数据
|
||
4. 尝试用命令诊断
|
||
5. 最后才询问用户
|
||
|
||
---
|
||
|
||
*最后更新: 2025-12-12* |