zhibo/Log/环境/1-AI指南.md
xiao12feng8 1258c0f1fd 合并master-backup:恢复所有功能
- 作品点赞、关注、收藏功能
- 作品搜索和标签功能
- 作品编辑和删除功能
- 我的收藏页面(MyCollectionsActivity)
- 我的点赞页面(MyLikesActivity)
- 完善的ProfileActivity功能
- 优化的PublishWorkActivity
- 完整的WorkDetailActivity编辑删除功能
2026-01-08 15:41:25 +08:00

10 KiB
Raw Blame History

手动引用

  1. 你明白我的意思吗。有没有不清楚的问题,请先询问我然后进行开发。有歧义要先询问我之后再进行下一步,不能你自己猜测可能的结果

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_searchcode_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、部署路径

常见操作

编译后端

cd Study-Vue-redis
mvn clean package -DskipTests

启动后端

java -jar ry-study-admin/target/ry-study-admin.jar

查询数据库

mysql -u root -proot study -e "你的SQL语句"

查看端口占用

netstat -ano | findstr :端口号

停止Java进程

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-xxxAI会

  • 优先使用工具自行查找信息
  • 查看配置文件获取参数
  • 执行命令查询状态
  • 搜索代码定位问题
  • 不会直接询问你已有的信息

适用场景

  • 1-查看当前运行的端口 → 执行 netstat -ano 命令
  • 1-数据库连接信息 → 读取 application-druid.yml
  • 1-查找登录接口 → 使用 grep_search 搜索代码
  • 1-Redis配置 → 读取 application.yml 的Redis部分

2-确认需求再执行

当你说 2-xxxAI会

  • 分析需求是否明确
  • 检查是否有歧义
  • 列出需要补充的信息
  • 确认后再开始执行

适用场景

  • 2-修复登录bug → 会先问具体是什么bug复现步骤报错信息
  • 2-部署到服务器 → 会先问:服务器地址?部署路径?环境信息?
  • 2-优化性能 → 会先问:哪里性能差?瓶颈在哪?目标是什么?
  • 2-添加新功能 → 会先问:功能的具体需求?业务场景?

3-简洁文档

当你说 3-xxxAI会

  • 只写必要内容
  • 重点突出,步骤清晰
  • 使用Markdown格式
  • 不会写冗余内容

适用场景

  • 3-生成部署文档 → 只写部署步骤,不写原理
  • 3-API使用说明 → 只写接口参数和返回值
  • 3-配置说明 → 只写关键配置项
  • 3-修复记录 → 只写问题、方案、结果

特殊说明

  • 如果不加 3-,默认不会主动生成文档
  • 你可以指定文档路径:3-生成部署文档到log/部署.md

4-理解功能逻辑

当你说 4-xxxAI会

  • 搜索相关代码
  • 阅读核心逻辑
  • 用简洁语言总结功能
  • 提供实际应用场景
  • 确认理解正确后再修改

适用场景

  • 4-学习记录功能 → 会分析代码,总结逻辑,给出应用场景
  • 4-视频进度计算 → 会说明如何计算、何时更新、防快进逻辑
  • 4-用户认证流程 → 会说明登录、Token、权限验证的完整流程
  • 4-文件上传机制 → 会说明上传路径、大小限制、存储方式

输出格式

功能逻辑总结:
1. 触发条件xxx
2. 核心流程xxx
3. 数据处理xxx
4. 返回结果xxx

应用场景示例:
当用户xxx时系统会xxx

5-记录配置信息

当你说 5-xxxAI会

  • 识别配置信息
  • 自动记录到 log/项目配置清单.md
  • 添加时间和用途说明
  • 提醒你查看更新

适用场景

  • 5-新增OSS配置 → 记录endpoint、bucket、accessKey等
  • 5-Redis密码改了 → 更新配置清单中的Redis配置
  • 5-添加百度API → 记录API Key、Secret、接口地址
  • 5-服务器部署信息 → 记录服务器IP、路径、账号

记录位置

  • 文件:log/项目配置清单.md
  • 格式:按分类自动追加到对应章节

组合使用

你可以组合使用多个编号:

示例11,4-视频进度功能

  • 先用工具查找代码原则1
  • 再理解功能逻辑原则4

示例22,3-部署到生产环境

  • 先确认服务器信息原则2
  • 再生成简洁的部署文档原则3

示例31,5-查看Redis配置

  • 先读取配置文件原则1
  • 再记录到配置清单原则5

快速对照表

你想要什么 使用编号 AI会做什么
查询信息 1-xxx 主动用工具查找
避免误解 2-xxx 先确认需求
生成文档 3-xxx 写简洁文档
理解代码 4-xxx 分析逻辑+场景
记录配置 5-xxx 自动记录到文件

最后更新: 2025-12-12