评论系统的三个反直觉设计：为什么默认关闭比默认开启更好

问题的起点

给知识库产品加评论功能，听起来是个标准需求。但当你真正开始设计时，会发现一个核心矛盾：评论是用户参与的入口，也是垃圾内容的入口。

大多数产品的做法是「默认开启 + 事后审核」。我们选了相反的路：默认关闭 + 主动开启 + 前置过滤。这个决策背后，是对 SaaS 产品责任边界的重新思考。

背景：为什么评论功能不是「加个表单」那么简单

AgentBooks 是一个为 AI Agent 提供知识库的 SaaS 产品。用户用它发布文档，Agent 通过 API 读取内容。评论功能的需求很明确：让读者能在文档下留言，作者能在 Dashboard 管理。

但有两个约束条件改变了设计方向：

用户是内容创作者，不是社区运营者 — 他们没有精力每天审核评论
垃圾评论的成本由平台承担 — 如果默认开启，每个新用户的第一条评论可能就是 spam，这会让他们对产品失去信任

所以问题变成了：如何在不增加用户负担的前提下，让评论功能可用？

关键决策 1：默认关闭，而不是默认开启

大多数评论系统是「默认开启 + 垃圾过滤」。我们反过来：默认关闭 + 主动开启。

为什么？

因为评论功能的价值不是普适的。对于 API 文档、内部知识库、技术规范这类内容，评论可能根本不需要。强制开启只会让用户面对两个选择：要么关掉它，要么忍受垃圾评论。

备选方案是什么？

可以做成「默认开启 + 一键关闭」。但这有个隐藏成本：用户在发现第一条垃圾评论之前，不会意识到需要关闭。这时他们已经对产品产生了负面印象。

权衡点在哪？

默认关闭会降低功能的可见性，但它把选择权交给了用户。如果你需要评论，开启它；如果不需要，它不会打扰你。这是 SaaS 产品的基本礼貌：不要替用户做他们没要求的事。

关键决策 2：Spam 过滤器默认开启，但不能误伤

评论开启后，下一个问题是：如何过滤垃圾？

我们的规则包括：

长度检查（5~500 字符）
外链检测（包含 URL 直接拒绝）
垃圾词检测（casino、viagra、click here 等）
纯数字/纯符号检测
重复内容检测（同一 IP 短时间内发相似内容）

但第一版上线后，所有中文评论都被判为 spam。

原因是正则表达式 /^[\d\W\s]+$/ 把中文当成了「非单词字符」（\W）。在 JavaScript 的正则引擎里，\w 只匹配 [a-zA-Z0-9_]，中文、日文、韩文全部被归类为 \W。

修复方案：

把 \W 改成 \p{P}\p{S}（Unicode 标点和符号类），加上 /u flag 启用 Unicode 模式。这样只有真正的符号会被拦截，正常文字不受影响。

为什么不用白名单？

可以加中文范围 [\u4e00-\u9fff]，但这只解决中文。日文、韩文、阿拉伯文还是会出问题。Unicode 属性类是语义化的 ——「标点就是标点」，不管什么语言。

这里的教训是：

正则表达式里的 \w 和 \W 是 ASCII 时代的遗物。任何面向用户输入的文本处理，都应该用 Unicode-aware 模式。更广泛地说：你的代码假设的「正常输入」范围，决定了你会误伤多少真实用户。

关键决策 3：Spam 评论不占 IP 配额

我们设计了两层限制：

同一 IP 对同一文档只能评论一次
同一 IP 每小时最多评论 5 次

但有个问题：如果用户的评论被误判为 spam，他会被配额限制锁住，无法重试。

解决方案：

Spam 评论不计入 IP 配额。只有 approved 的评论才会消耗配额。

为什么这样设计？

因为 spam 过滤器不可能 100% 准确。如果误判锁住了用户，他会认为「这个网站的评论功能坏了」，而不是「我的评论被判为垃圾」。让用户有重试的机会，是对误判的容错设计。

备选方案：

可以做成「spam 评论进入待审核队列，用户看到等待审核提示」。但这增加了作者的审核负担，违背了「不增加用户负担」的原则。

权衡点：

这个设计会被滥用吗？会。恶意用户可以无限发 spam 而不被限制。但我们选择相信大多数用户是善意的，为少数恶意用户设计会惩罚所有人。

方法论总结

1. 默认值是产品态度的体现

「默认开启」传递的信号是「我们认为你需要这个」。「默认关闭」传递的信号是「我们尊重你的选择」。对于非核心功能，默认关闭是更安全的选择。

2. 规则的边界由最坏情况定义

Spam 过滤规则看起来是在定义「什么是垃圾」，实际上是在定义「什么是正常」。如果你的「正常」只包括英文，你就会误伤所有非英文用户。

3. 容错设计优于完美规则

与其追求 100% 准确的 spam 检测，不如设计一个「误判后用户还能重试」的机制。完美的规则不存在，但好的容错设计可以降低误判的代价。

4. 功能的价值不是普适的

不是所有知识库都需要评论，不是所有评论都需要公开。给用户选择权，而不是替他们做决定。

5. 代码的假设决定了产品的边界

\w 假设「单词」只包括 ASCII 字符，这个假设在 1990 年代是合理的，在 2026 年是灾难。检查你的代码里有多少隐藏的假设，它们会在你意想不到的地方爆炸。

结尾

评论功能的本质不是「让用户说话」，而是「让用户在可控的范围内说话」。

默认关闭不是保守，是尊重。Spam 过滤不是防御，是定义边界。容错设计不是妥协，是承认不完美。

最后一个问题：如果你的产品有一个功能，90% 的用户不需要，但 10% 的用户非常需要，你会默认开启还是默认关闭？