Majsoul-QQBot

Majsoul-QQBot copied to clipboard

这个项目现在还在维护吗？

3

Hermioie

对重构提点建议

11

@NekoRabi 听说你想重构项目，框架选型这方面我了解得不够，不多发表评论。 如果有条件，我建议你可以考虑**把机器人命令的dispatcher逻辑解耦出来**。 dispatcher是说啥呢？就是看到一句话，决定要用什么功能模块去响应这句话的这段（分类）逻辑。 目前的设计，所有的命令处理程序各自为政，每个命令Handler都订阅了整个消息事件，然后自行判断是否要响应。 像这样的设计，如果没有更复杂的需求，那么简单的模式就是好的。但是**像这样自由的处理模式，要在其上扩展就得要打一个接一个的补丁**。 举个最简单的例子： 你有一个help命令，展示所有命令一览。 同时，你又把命令所匹配的模式，从硬编码改为了可以通过command.yml来配置。 但是，如果在command.yml当中修改了命令的关键词（模式），那么help里的命令说明是不会有所反映的。 也就是说，虽然形式上比起硬编码的命令模式，似乎通过配置文件集中化地对命令模式进行自定义管理。 但实际上，和命令的调用条件相关的逻辑，还是分散在了各个响应程序中（基本全是正则），和help字段的手动配置（位置还和command.yml不在一处） **那么把help的配置也转移到command.yml当中怎样呢？** 我觉得这要看你的野心。 如果你的想法是，能用就好，命令响应就按现在的模式，help的展示就意思意思，有空就改一改配置的位置，没空就放着它，改命令模式需要command.yml和help字段改两遍就改两遍。那维持现在的架构就好。 不知道你有没有了解过[langchain](https://github.com/hwchase17/langchain)？它的指导思想，就是把一个个功能模块，封装成叫做“工具”的接口。 “工具”不负责判断要不要响应输入，它只负责把输入处理好返回预期的输出。 大语言模型来负责决定，面对不同的发言，需要使用哪些“工具”。 而我的建议就是，对本项目的机器人，建立起一套“命令”的规范，其本质，就是上面说的这种“工具”。 这套规范的第一版实现，所使用的技术和现有版本可以一模一样。 但只要时机成熟，就可以把“监听到聊天发言”->“调用相关模块”中间的dispatching步骤，由现在的正则表达式匹配，改为由langchain来控制。 主要还是看你对这个项目有多少野心。**如果想要做得更好，重构的时候顺便拔高一点架构设计，是利大于弊的。** 一点点个人意见，仅供参考。

Sunshine40

我举个例子，玩家“Sunshine”在国际中文服，日服，国际服（英文服）各有一个同名账号——这3个账号都是我本人持有的号。 雀魂是允许不同服玩家同名的。而对于这种情况雀魂pt插件甚至会出现数据库唯一约束冲突。 此外，插件还不区分大小写，但对于某些英文玩家名称而言，大写版本和小写版本就是不同的玩家（例如玩家“sunshine”和“Sunshine”是不同的玩家），先默认他们是同名玩家再要求用参数来区分就不合理。

Sunshine40