zhibo/Log/1-AI指南.md
2025-12-15 11:21:21 +08:00

371 lines
9.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# AI工作指南
## 🚀 快速引用
**使用方法**:在对话中使用编号快速调用对应原则
| 编号 | 原则 | 用法示例 |
|------|------|---------|
| **1** | 主动获取信息 | `1-查询数据库配置` |
| **2** | 确认需求再执行 | `2-修复登录bug` |
| **3** | 简洁文档 | `3-生成部署文档` |
| **4** | 理解功能逻辑 | `4-学习记录功能` |
| **5** | 记录配置信息 | `5-Redis配置` |
**示例**
- 输入 `1-端口占用` → AI会主动使用命令查询端口而不是询问你
- 输入 `2-部署到服务器` → AI会先确认服务器地址、环境等信息
- 输入 `4-视频进度功能` → AI会先查找代码、理解逻辑、总结应用场景
- 输入 `5-新增OSS配置` → AI会自动记录到配置清单文件
---
## 工作原则
### 原则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秒上报一次进度
- → 确认理解无误后,再讨论优化方案
---
### 原则5记录配置信息
**遇到配置信息时,自动记录到配置清单文件**
**需要记录的信息类型:**
- 外部API接口地址和密钥
- 数据库连接信息(地址、端口、账号)
- 本地服务端口和访问地址
- 重要文件路径和位置
- 第三方服务配置
- 环境变量设置
📝 **记录位置:**
- 文件路径:`log/项目配置清单.md`
- 每次遇到新的配置信息时自动追加
- 记录时间和用途说明
**示例:**
- 发现使用了OSS存储 → 记录OSS的endpoint、bucket等信息
- 配置了Redis → 记录Redis的host、port、密码
- 调用百度API → 记录API Key和Secret
- 部署到服务器 → 记录服务器IP、部署路径
---
## 常见操作
### 编译后端
```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. 最后才询问用户
---
## 📞 快速引用详细说明
### 使用格式
```
编号-你的请求内容
```
### 各编号的详细说明
#### **1-主动获取信息**
当你说 `1-xxx`AI会
- ✅ 优先使用工具自行查找信息
- ✅ 查看配置文件获取参数
- ✅ 执行命令查询状态
- ✅ 搜索代码定位问题
- ❌ 不会直接询问你已有的信息
**适用场景**
- `1-查看当前运行的端口` → 执行 `netstat -ano` 命令
- `1-数据库连接信息` → 读取 `application-druid.yml`
- `1-查找登录接口` → 使用 `grep_search` 搜索代码
- `1-Redis配置` → 读取 `application.yml` 的Redis部分
---
#### **2-确认需求再执行**
当你说 `2-xxx`AI会
- ✅ 分析需求是否明确
- ✅ 检查是否有歧义
- ✅ 列出需要补充的信息
- ✅ 确认后再开始执行
**适用场景**
- `2-修复登录bug` → 会先问具体是什么bug复现步骤报错信息
- `2-部署到服务器` → 会先问:服务器地址?部署路径?环境信息?
- `2-优化性能` → 会先问:哪里性能差?瓶颈在哪?目标是什么?
- `2-添加新功能` → 会先问:功能的具体需求?业务场景?
---
#### **3-简洁文档**
当你说 `3-xxx`AI会
- ✅ 只写必要内容
- ✅ 重点突出,步骤清晰
- ✅ 使用Markdown格式
- ❌ 不会写冗余内容
**适用场景**
- `3-生成部署文档` → 只写部署步骤,不写原理
- `3-API使用说明` → 只写接口参数和返回值
- `3-配置说明` → 只写关键配置项
- `3-修复记录` → 只写问题、方案、结果
**特殊说明**
- 如果不加 `3-`,默认不会主动生成文档
- 你可以指定文档路径:`3-生成部署文档到log/部署.md`
---
#### **4-理解功能逻辑**
当你说 `4-xxx`AI会
- ✅ 搜索相关代码
- ✅ 阅读核心逻辑
- ✅ 用简洁语言总结功能
- ✅ 提供实际应用场景
- ✅ 确认理解正确后再修改
**适用场景**
- `4-学习记录功能` → 会分析代码,总结逻辑,给出应用场景
- `4-视频进度计算` → 会说明如何计算、何时更新、防快进逻辑
- `4-用户认证流程` → 会说明登录、Token、权限验证的完整流程
- `4-文件上传机制` → 会说明上传路径、大小限制、存储方式
**输出格式**
```
功能逻辑总结:
1. 触发条件xxx
2. 核心流程xxx
3. 数据处理xxx
4. 返回结果xxx
应用场景示例:
当用户xxx时系统会xxx
```
---
#### **5-记录配置信息**
当你说 `5-xxx`AI会
- ✅ 识别配置信息
- ✅ 自动记录到 `log/项目配置清单.md`
- ✅ 添加时间和用途说明
- ✅ 提醒你查看更新
**适用场景**
- `5-新增OSS配置` → 记录endpoint、bucket、accessKey等
- `5-Redis密码改了` → 更新配置清单中的Redis配置
- `5-添加百度API` → 记录API Key、Secret、接口地址
- `5-服务器部署信息` → 记录服务器IP、路径、账号
**记录位置**
- 文件:`log/项目配置清单.md`
- 格式:按分类自动追加到对应章节
---
### 组合使用
你可以组合使用多个编号:
**示例1**`1,4-视频进度功能`
- 先用工具查找代码原则1
- 再理解功能逻辑原则4
**示例2**`2,3-部署到生产环境`
- 先确认服务器信息原则2
- 再生成简洁的部署文档原则3
**示例3**`1,5-查看Redis配置`
- 先读取配置文件原则1
- 再记录到配置清单原则5
---
### 快速对照表
| 你想要什么 | 使用编号 | AI会做什么 |
|-----------|---------|-----------|
| 查询信息 | `1-xxx` | 主动用工具查找 |
| 避免误解 | `2-xxx` | 先确认需求 |
| 生成文档 | `3-xxx` | 写简洁文档 |
| 理解代码 | `4-xxx` | 分析逻辑+场景 |
| 记录配置 | `5-xxx` | 自动记录到文件 |
---
*最后更新: 2025-12-12*