技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

海豹核心(SealDice Core):把 TRPG 骰点机器人做成一件可交付的工程

项目背景与痛点

TRPG 跑团对骰点机器人的需求看起来简单:掷个 3d6、查个角色卡、抽张牌堆。但真要长期跑团,需求就不简单了——要能暗骰、要能算奖惩骰、要能存几十张角色卡、要在群里做权限隔离、要能加载自定义规则。

而这个领域的工具链,长期是破碎的。Dice! 绑定酷Q,平台一停摆生态就断层;塔骰依赖 Node 运行时,对只想在 Windows 上双击运行的桌游店老板不友好;各类 Python 骰子则把部署成本转嫁给用户。更麻烦的是平台碎片化:QQ 群、Discord 服务器、KOOK 频道、Telegram 群组,协议各不相同,一个机器人想全平台覆盖,往往要维护多套代码。

海豹核心的定位很清楚:一个 Go 单二进制,内置管理面板,抽象掉 IM 平台差异,把插件生态用 JS 统一起来。它解决的核心问题在于分发与长期可维护性,功能多少反而是次要的。

核心技术揭秘

海豹的架构是典型的分层适配器模式:平台差异被隔离在最外层,业务逻辑完全建立在归一化的消息模型上。

graph TD A[IM 平台(QQ/Discord/KOOK/Telegram)] --> B[平台适配器层] B --> C[消息归一化为 MessageElement] C --> D{"消息类型判定"} D -->|"指令消息"| E[命令路由与前缀解析] D -->|"普通消息"| F[事件钩子分发] E --> G[骰点表达式引擎] E --> H[角色卡与牌堆存储] F --> I[JS 插件运行时] G --> J[结果渲染与文本封装] H --> J I --> J J --> K[回包构造] K --> B B --> A

几个值得说的实现细节:

骰点引擎的复杂度并不低。 它不是一次算术求值;它更像一个小型表达式语言:4d6k3(保留最高 3 个)、d20+5、(1d4+1)d6(骰数本身是表达式)、COC 的奖惩骰 pb、理智检定、暗骰前缀。这意味着解析器必须是带优先级的递归下降结构,词法层要能区分“骰数”和“骰面”两个位置的表达式,而不是简单正则切分。同时随机源必须是并发安全且可复现的——跑团场景里,玩家会因为一次离谱的连出大成功要求“查日志”,骰点记录的可追溯性直接关系到社群信任。

消息必须串行处理。 这是骰子类应用最容易被忽视的坑:三个玩家几乎同时掷骰,如果并发处理,回复顺序可能错乱,导致日志和回复对不上号。海豹以账号—群维度组织 Dice 实例,消息入队后按会话顺序消费,牺牲一点吞吐换取语义正确——对聊天机器人,这个取舍是对的。

存储层是自研的轻量 KV,内存索引加异步落盘,而不是直接上 SQLite。好处是零依赖、单文件备份、跨平台一致性极好;代价是复杂查询能力弱,数据量大了以后检索只能靠内存全扫。

JS 插件跑在 goja 上,宿主把 seal.replyToSender、事件钩子、牌堆读写注入运行时。选择纯 Go 的 JS 引擎而非 V8,是为了保持交叉编译的纯净(CGO 一旦引入,Android/macOS 的构建链立刻变复杂)。这是一次非常“工程导向”的取舍。

功能亮点与差异

和同类相比,海豹的杀手锏不是骰点算法多花哨,而是三点:

其一,内嵌 WebUI。//go:embed 把前端打进了二进制,配置、日志、插件管理、角色卡编辑全部图形化。这一下把目标用户从“会敲命令行的开发者”扩展到了“只会双击 exe 的团长”,这是国内骰子生态里最实际的一步。

其二,平台抽象的一致性。同一份配置、同一套群规则、同一批插件,换个平台基本能平移。对同时运营 QQ 群和 Discord 服务器的社群,这直接省掉一套维护成本。

其三,对既有生态的有意兼容。牌堆格式、前缀习惯、部分插件 API 的命名,明显在向老用户招手。迁移成本是生态型工具的第一道生死线,海豹在这上面做过功课。

应用场景与落地建议

适合:跑团社群的固定群组机器人、桌游店/线上团的基础设施、TRPG 教学内容演示、需要私有化部署(数据不出内网)的团队。

落地时注意几点:

  • 别把 QQ 侧当生产级 SLA。走 OneBot 方案意味着依赖第三方协议实现,账号风控与协议变更不在你控制范围内,重要群建议双平台冗余。
  • 限流与刷屏控制。大群高频掷骰会触发平台侧频率限制,建议在适配器层做发送队列与合并。
  • 数据备份常态化。存储是文件形态,容器化部署时务必把数据目录挂成 volume,并做定期快照——跑团数据丢了是真的找不回来。
  • 插件要审。JS 运行时不是安全沙箱,不要加载来源不明的插件。
  • 单实例承载几千群问题不大,真正的瓶颈通常在平台侧的反向连接稳定性,而非骰点计算本身。

综合评价

优点:工程完成度高。单二进制分发、跨平台适配层干净、WebUI 显著降低使用门槛、插件体系让规则扩展不必改核心代码。它在“能长期跑下去”这件事上的投入,远超多数同类项目。

缺点:goja 决定了插件生态的天花板——ES6+ 支持有限、异步模型别扭,复杂插件写起来会硌手;自研 KV 在数据规模上去后缺乏查询能力,属于早期设计对后期的负债;核心逻辑集中在少数维护者手里,插件 API 文档相对简陋,新插件作者的摸索成本不低。

一句话:它是一个被认真当作产品在做的基础设施,而不是一个爱好者脚本。 如果你的需求是“稳定、好部署、跨平台、能自己写扩展”,它目前是国产方案里最省心的选择;如果你需要的是极端灵活的规则内核或大规模数据检索,得做好自己动手补的准备。

简要分析

热度分
460
价值分
204
活跃状态
活跃

语言占比

Batchfile
CSS
Go
HTML
JavaScript
Python
Shell
TypeScript
Vue

Release