准备运行环境
选择 Linux 云主机，做好域名、SSH、Docker 和基础防火墙配置，让后面的服务有一个稳定的家。
阅读环境准备 →一个可复现的个人实验项目
从零搭建
鸣潮 Bot
把一台云服务器变成稳定、可维护的游戏助手。这里记录从消息接入、插件编排到上线维护的完整过程，也记录那些真正帮我解决问题的细节。
WAVES BOT / BUILD JOURNAL
潮
把想法变成
可以长期运行的服务
01消息进入
02插件处理
03结果送达
WHY THIS LOG
从组件分工开始，
理解每一步为什么这样做。
Bot 能跑起来只是第一步。真正费时间的是把不同服务接起来、把登录状态保存好、让插件互不干扰，并在故障发生时知道该从哪一跳开始查。
这份记录以个人学习和技术分享为目的，聚焦消息机器人、容器化部署和日常维护，不代表鸣潮官方，也不提供外挂、账号交易或代练服务。
THE BUILD ROUTE
六个阶段，拼出一条完整链路
先理解每一层负责什么，再决定要不要把它部署到自己的服务器。
接入 QQ 消息
理解 QQ 客户端、OneBot 适配层和事件消息之间的关系，先确认消息能进能出。
阅读消息接入 →连接 AstrBot
用 AstrBot 负责插件编排和 AI 能力，把平台适配与具体业务拆开，方便单独排查。
阅读服务连接 →部署 GSUID Core
把鸣潮相关功能放在独立核心中，通过 WebSocket 与上层连接，登录入口和业务处理分开。
阅读核心部署 →整理插件能力
签到、查询、抽卡和帮助等功能按插件组织，配置与数据分离，更新时不碰用户数据。
阅读插件安装 →上线与持续维护
使用反向代理、日志、备份和最小重启策略，让“能用”逐步变成“可长期运行”。
阅读维护方法 →THE ARCHITECTURE
一条消息要经过哪些地方？
每个组件只做一件事，故障时才能快速找到消息消失的那一跳。
MESSAGE FLOW / 01
AQQ 用户发送指令 / 接收结果
事件
BPMHQ · LLBot平台连接 / OneBot
WebSocket
CAstrBot插件编排 / 权限
适配器
DGSUID Core鸣潮功能 / 数据
01
平台层
只负责把 QQ 的消息转换成统一事件，不在这里堆业务逻辑。
02
编排层
负责插件生命周期、权限和消息分发，让不同功能相互独立。
03
业务层
把鸣潮查询、签到等能力收在核心服务里，数据和配置单独保存。
1
用户打开专属登录链接登录链接按敏感信息处理，使用范围与有效期以插件实现为准。
2
代理转发到业务服务公网只开放必要路径，管理路径默认拒绝。
3
完成回调后回到 QQ成功与失败都留下可定位的日志，不记录敏感凭证。
FIELD NOTES
把容易踩坑的地方写在前面
将部署中的经验整理成步骤，给每一次修改留下依据。
MAINTENANCE NOTES
上线之后，按这张清单维护
稳定不是一次配置出来的，而是每次变更都留下记录、可以回退。
✓
改配置前先备份记录文件时间、大小和校验值，保留明确的回退点。
✓
只重启受影响的服务插件问题不牵连 QQ 登录，Core 问题不重启整套链路。
✓
验证真实链路看健康检查、日志和最小实际消息，不只看容器状态。
✓
不把凭证写进日志Token、Cookie、密钥和带签名的媒体链接都要脱敏。
FAQ
开始之前，先回答几个问题
这是不是鸣潮官方服务？+
不是。这是个人技术学习和分享项目，只记录消息机器人部署、插件开发与服务器维护，不代表游戏官方。
一定要有云服务器才能搭建吗？+
不一定。本地电脑、家用服务器或云主机都可以作为实验环境。选择云主机主要是为了让服务持续在线。
新手应该先学哪一部分？+
建议先理解“消息从 QQ 到插件，再回到 QQ”的链路，再学习 Docker 和反向代理。先能定位问题，比一次性记住所有命令更重要。
这里会公开登录凭证或个人信息吗？+
不会。文章只使用脱敏示例，真实 Token、Cookie、QQ 登录数据和服务器凭证不会出现在页面中。
KEEP BUILDING