2026-01-07 17:36:08 +08:00
|
|
|
|
# 手动引用
|
|
|
|
|
|
1. 你明白我的意思吗。有没有不清楚的问题，请先询问我然后进行开发。有歧义要先询问我之后再进行下一步，不能你自己猜测可能的结果
|
|
|
|
|
|
2.
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-15 11:21:21 +08:00
|
|
|
|
# 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*
|
