团队第四次作业—beta冲刺

这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/SoftwareEngineering24/homework/15658
团队名称	星云—维鲁姆
团队成员-学号	丁宇轩-3124004316
这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/SoftwareEngineering24
这个作业的目标	解决AI模型的离线问题，和信息难以保存的问题

一、项目介绍与问题迭代

1. Alpha 冲刺后存在的问题
   AI 助手频繁离线，核心功能可用性低
   火山方舟 API 调用超时、网络波动时，助手直接进入离线模式，用户提问无响应，攻略也无法正常查看，严重影响使用体验。

攻略数据无持久化存储，复用性差
攻略数据仅存在本地 JSON 缓存中，无法跨设备同步，也无法在 API 离线时提供内容支持。
功能边界受限，依赖本地客户端运行
助手只能在电脑上运行，无法随时随地访问，用户使用场景受限，难以触达更多玩家。
2. 探索思路与解决过程
解决离线问题：引入 MySQL 数据库作为攻略数据持久化存储方案，实现 “优先查库、无数据再调用 API” 的降级逻辑，即使 API 超时，也能正常返回已保存的攻略内容，彻底解决 “离线模式无法使用” 的问题。
数据结构优化：按「地图 + 攻略分类」建立联合索引，实现了攻略的高效检索，用户点击分类和地图后，能秒级加载对应内容，大幅提升响应速度。
未来拓展规划：计划开发微信小程序版本，实现移动端轻量化访问，并尝试对接三角洲行动官方公开数据接口，实现实时更新地图、武器数据，让助手数据和游戏版本保持同步。

二、项目特色功能
1. MySQL 持久化攻略库，永不离线
核心实现：将所有攻略数据存入 MySQL 数据库，用户提问时优先检索数据库，命中则直接返回内容，无需调用 API；无命中时再调用 AI 生成，生成后自动入库。
效果：彻底解决了 API 超时导致的离线问题，现在即使网络不佳，也能正常查看所有已保存的攻略，可用性大幅提升。
2. 书架式分类检索，精准获取攻略
实现了「阵容打法 / 阴间点位」两大分类，搭配「航天基地 / 长弓溪谷 / 零号大坝」等地图的二级筛选，用户可以按场景快速找到对应攻略，不用在聊天记录里翻找。
攻略点击即可查看详情，包含来源链接、更新时间，信息完整透明。

三、关键模块自动化单元测试
1. MySQL 攻略读写测试
测试用例：向game_strategies表插入一条攻略，再通过地图 + 分类检索该攻略。
测试结果：查询返回结果与插入数据完全一致，数据库读写功能稳定，检索响应时间小于 100ms。
2. API 调用降级逻辑测试
测试用例：模拟 API 超时场景，发送一个数据库中已存在答案的问题。
测试结果：助手直接从数据库返回内容，未触发 API 调用，无离线提示，功能正常。

四、团队协作记录与个人体会
团队协作记录
数据库设计与实现：完成了攻略表、配装表的创建，实现了索引优化，编写了批量导入攻略的 SQL 脚本。
业务逻辑改造：修改了 AI 问答模块的调用逻辑，实现了 “数据库优先” 的降级策略，解决了离线问题。
未来规划讨论：确定了小程序开发和官方数据对接的拓展方向，完成了初步的技术调研。
个人体会与收获
在本次 beta 冲刺中，我最大的收获是理解了 “降级设计” 的重要性 —— 原本以为 API 是唯一的核心，没想到通过 MySQL 持久化，不仅解决了离线问题，还让助手的响应速度和稳定性都得到了质的提升。这次实践让我明白，一个好的产品不是依赖单一功能，而是要有完整的容错和备份方案。同时，也让我对后续小程序开发和数据对接有了更清晰的认识，学会了如何把本地项目拓展到更广阔的平台，让更多用户受益。

五、项目 GitHub 仓库链接
https://github.com/Nebula-Verum/demo-repository