三个月，24 个版本：AlphaCloud 成了什么样

2026 年 6 月 1 日，我们开始为版本计数。到 9 月 6 日，我们已经到了 v1.8.0。这期间共有 24 个版本，本文试图把它们连成一条线，而不是罗列成一张清单。

四个阶段

六月：模块。 蜜罐、身份组保留、临时语音、账号年龄、身份组昵称、支持呼叫。另外还有为每位用户提供长期记忆的 AI 聊天。这是基础工具包成形的阶段。

七月：工具而非功能。 用于自定义命令的高级构建器，一个带真正分支的可视化流程编辑器。然后是自动化，由你自己组合的触发器和动作。与六月的区别是根本性的：之前我们构建功能；从七月开始，我们构建积木，让服务器用它们搭建属于自己的东西。

八月：资金与防护。 一边是反破坏、AutoMod 和等级系统。另一边是完整的支付流程，包括撤回、取消和账单门户。不那么显眼，但工作量远超以往任何东西。

九月：消息构建器。 机器人发送的几乎每条消息都变得可以设计。回头看，这是七月理念的合理延续，只不过应用在文本上，而不是流程上。

版本号让我们看清了自己的什么

在 24 个版本中，7 个标为主要版本，17 个标为热修复。这听起来像是一个稳定的产品，偶尔做些修正。

但事实并非如此。看看那些所谓的热修复：

• v1.5.1 带来了两个新模块，支持时间和团队反馈，外加标志合集
• v1.6.1 带来了 AutoMod 和等级系统，这是所有模块中较大的两个
• v1.6.2 带来了反破坏、自动回复和自托管 AI 选项

三个标为 bug 修复的版本，实际上交付了六个模块。我们自己的版本规则规定，Z 大于零的 vX.Y.Z 是一次修正。我们却一再没有遵守。

为什么这很重要：版本号是服务器所有者在阅读更新日志之前，关于一次更新所能得到的唯一信息。如果“热修复”实际上意味着“三个新模块”，总有一天他们会干脆不再看它。

修了三遍的地方

在回顾时我们注意到一个模式：我们反复修补同样的地方，而且总是朝同一个方向。

斜杠命令。 v1.5.0 记录了在同时运行多个基于命令的模块的服务器上，命令可能会消失。已修复。v1.5.1 记录了在大型服务器上注册无法完成，因为它按模块、按服务器分别发出请求。同样已修复。两个不同的原因，同一个症状，如果一开始就有一个共享的地方，两者都不会发生。

昵称前缀。 v1.6.0 列出了针对单个模块的五项修正。五项。这表明最初的设计是错的，而我们修补它的时间太长，却没有将其替换。

AI。 这值得单独写一篇文章，因为这个故事太精彩了，没法在这里用两句话说完。

我们从中学到了什么

关于这三个月最诚实的一句话：看得见的部分很少是代价最高的部分。消息构建器是 v1.8.0 的头条，但 v1.7.0 的支付流程花费的时间更多，产生的 bug 更多，拖带的法律文本也比之前任何模块都多。

在接下来的几个月里，我们有两个与功能无关的打算：让版本号重新变得诚实；当一个模块已经被修补了三次，第四次就去动它的设计，而不是去修 bug。