我们代码中的法律

当我们让 Premium 可以购买时，我们以为法律部分只是页脚里的几页文字。这是错的。有些义务根本无法写进文本，因为它们决定了一个功能必须如何构建。

下面是四个尤其能说明这一点的例子。先说清楚这是什么：这是对我们实现方式的描述，而不是法律建议。下面的规则来自德国法律，也就是 AlphaCloud 运营所在地的法律。

不允许登录的取消按钮

《德国民法典》第 312k 条要求，在线订立的合同必须提供一个可直接访问的取消途径。这带来了一些无法事后靠措辞补上的要求：

• 页面必须无需登录即可使用
• 它必须出现在每个页面的页脚中
• 它需要两个步骤：先填写，再通过一个标注清楚、毫无歧义的按钮确认
• 必须发出一份文本形式的收到确认

最后一点决定了架构。取消合同是一种单方面的意思表示，在送达时生效。因此它必须始终被记录并确认，无论它来自谁。

表单永远不能拒绝你

正是在这里，显而易见的做法差点让我们犯错。

显而易见的做法是：只有当服务器 ID 和电子邮件与一个有效订阅匹配时，才接受取消。听起来很合理，但它错了两次。

首先，它会把一位输错电子邮件或填写了其他地址的真正客户拒之门外。他们的取消将不算送达，订阅会续订，而他们手里却握有曾经尝试过的证据。

其次，也是更令人不快的部分：错误消息本身就会成为一个答案。任何收到“未找到订阅”的人都会知道这个服务器没有付费。Discord 服务器 ID 不是秘密，任何成员都能读取它。这个表单会变成一个刺探他人服务器的工具。

解决方案把两件感觉像是一件事的东西分开：

	条件
意思表示的送达	无条件，始终记录并确认
取消的执行	仅当提交的电子邮件与存档的买家匹配时

其余一切都会进入一个队列，由人工审核。这是允许的，因为第 312k 条第 2 款明确允许要求提供身份信息。被禁止的只是在前面设置登录。

出于同样的原因，只有在身份得到确认后，公开回复才能写出结束日期。否则，这份确认又会变成一个可以用来探查信息的工具。

刻意需要登录的撤回

就在它旁边，有一个我们反其道而行之构建的功能：按比例退款的撤回需要登录。

这并不矛盾。第 312k 条涵盖的是取消，而不是撤回，只要非正式的途径保持开放，就根本没有义务提供在线撤回表单。区别在于后果：取消作用于未来，而退款会立即转移资金，而且无法追回。

由此产生三条规则，我们不会放宽：

无需强制说明理由。 第 355 条第 1 款明确规定撤回无需说明理由。这个字段是可选的，而且必须保持可选，无论一个必填字段对统计来说多么诱人。

14 天后，只拒绝自动化途径，绝不拒绝意思表示本身。 如果客户没有被正确告知，期限会延长至最多十二个月零十四天。因此，一概而论的“太晚了”可能是错误的。

防止重复退款的保护采取悲观策略。 标记在退款执行之前就会设置。如果之后退款失败，标记仍然保留，由人工接手。重复退款是唯一无法补救的结果。

Discord 私信不是耐久介质

第 312f 条第 3 款要求在耐久介质上提供合同确认，并且必须再现当时作出的同意。

我们起初发送的是 Discord 私信，因为我们的客户本来就在那个渠道里。但这并不满足要求。私信存在于一个我们无法控制的平台上，而且在该条款所指的意义上，它既不可保存，也不能保证不被更改。

因此我们增加了电子邮件，随之而来的是一个令人不安的依赖：如果没有设置邮件凭据，发送操作只会在日志中写入一条警告，而这项义务就没有履行。一项法定义务取决于一个环境变量，这是一种值得留意的状态。

没有增值税，而且这一点必须处处一致

AlphaCloud 是《德国增值税法》第 19 条意义上的小企业。价格均为最终价格，从不显示增值税。

这听起来像一个脚注，实际上却是一项横跨许多地方的一致性任务：价格页面、结账对话框、服务条款、隐私政策、发票页脚以及支付服务商那里的配置，都必须说同一件事。我们曾经长时间挂着一个“不含增值税”，那完全是错的。

还有 AI

自 2026 年 8 月起，欧盟《人工智能法》的透明度义务全面适用。任何与 AI 系统对话的人都必须能够认出这一点，最迟在第一次互动时。

那次审查中对我们最重要的一句话是：页脚里的一个法律页面可能并不满足要求。 告知必须发生在互动发生的地方，也就是 Discord 消息本身。这就是为什么我们的工单 AI 支持会主动自我介绍，并且有一个可见的按钮来关闭它。我们的详细评估见 AI 透明度。

共同的主线

四个例子都有相同的形态：义务看起来像一段文字，实际上却是对结构的要求。一个放错地方的登录、一条透露太多的错误消息、一份发错渠道的确认、一个允许重复退款的执行顺序。

所以我们现在把法律文本当作规格说明书来读，并且也反过来检查：代码真的在做我们条款所说的事吗？正是针对这个问题，我们发现了两处真正的偏差，关于它们另有一篇文章。