从产品设计中体会到减少决策步骤的重要性

书接上回，在开始自己做产品之后，才关注产品中每一个细节的设计，每一个决策；哪些会让用户用起来顺手丝滑，哪些又不那么顺手，总是感觉磕磕绊绊。当我用这个思维来看待我的博客的时候，我发现了经营了接近 10 年的博客为什么没有评论的问题。一方面，是因为内容经常分散在不同的 UGC 平台，没有回流到 blog 沉淀，导致这里看起来冷清；另一方面，是我之前选择的评论系统天然的就筛选走了一部分人群。如果你也用 GitHub Pages 搭博客，这篇手把手教程应该能帮你避开同样的坑。详细的分析见下文。

一、为什么我决定换掉 GitHub 评论系统

我的博客托管在 GitHub Pages 上，之前用的是 Utterances——一个基于 GitHub Issues 的评论系统。它的好处是不需要额外服务器、与 GitHub 深度集成。但有一个严重问题：

读者必须拥有 GitHub 账号，并且授权登录后，才能留下评论。

这个门槛直接过滤掉了：

我写过一些偏人文的思考，也分享过产品哲学，也写过深度技术分析。这些内容本应该引发讨论，因为我尝试在不同渠道发送过它们改编版本，有各式各样的反馈。包括但不限于点赞，评论，转发和私信。对比起来，我的博客，运营时间更久，它有更长的长尾流量，自然曝光，但是为什么没有沉淀下互动呢？我认为是评论区的门槛太过于陡峭。

于是我开始寻找一款满足以下条件的评论系统：

最终我选择了 Waline。下面就是我从零开始部署的全过程，每一步都亲测有效。

二、Waline 简介

Waline 是一款开源、轻量的评论系统，由一个前端界面和一个服务端组成。

三、部署前准备

你需要一个 Vercel 账号（免费注册即可）。Waline 的服务端部署在 Vercel 上，数据库也使用 Vercel Storage 生态中的方案，整个过程都在同一个平台完成，不需要管理服务器。

四、部署 Waline 服务端与数据库

Waline 官方的 Vercel 部署流程分三步：先部署服务端，再创建数据库并初始化表结构，最后重新部署让两者打通。不需要手动填写任何环境变量。

4.1 部署 Waline 服务端

  1. 打开 Waline Vercel 部署模板，点击 Create
  2. 如果未登录，Vercel 会让你用 GitHub 账号登录
  3. 输入项目名称，点击 Create，Vercel 会基于模板创建一个新仓库并自动部署
  4. 一两分钟后部署完成，你会得到一个 xxx.vercel.app 的服务地址

4.2 创建数据库

Waline 官方推荐使用 Neon（PostgreSQL），这是一个 Serverless 数据库，通过 Vercel Storage 即可集成：

  1. 在 Vercel Dashboard 中进入 Storage 选项卡
  2. 点击 Create Database，在 Marketplace 中选择 Neon，点击 Continue
  3. 授权 Neon 账号后，选择计费方案（免费版个人博客完全够用），配置区域和数据库名称
  4. 创建完毕后，进入 Neon 控制台，打开左侧 SQL Editor
  5. 从 Waline 仓库获取数据库建表 SQL：waline.pgsql，复制全部内容，粘贴到 SQL Editor 中执行

这个小步骤很容易被忽略，但必须做。没有表结构，数据库只是一个空壳，评论数据无处存放。

4.3 重新部署打通

回到 Vercel，进入 Deployments 选项卡，找到最近一次的部署记录，点击右侧的 Redeploy。等待部署状态变为 Ready。

这个步骤的意义在于：Vercel 会自动将 Neon 数据库的连接信息（DATABASE_URL）注入到 Waline 的环境变量中，不需要手动配置任何密钥。

4.4 配置子域名

部署完成后，你会得到一个 xxx.vercel.app 的地址。我不太想把这种供应商特定的 URL 写死在博客代码里，万一以后迁移还得改。所以加了一个子域名：

我的主域名 kirinzer.com 在 Cloudflare 托管。添加一条 CNAME 记录：

类型 名称 目标 代理状态
CNAME comments xxx.vercel.app DNS only

然后在 Vercel 项目 Settings → Domains → 输入 comments.kirinzer.com → Add。Vercel 会自动签发 SSL 证书。

这样做的好处是将来不管迁移到 Fly.io、Railway 还是自建服务器，只要改一下 CNAME 记录就行，博客代码不需要动。

4.5 注册管理员

打开 https://comments.kirinzer.com/ui/，第一个注册的用户会被设定为管理员。之后就可以在管理面板中审核评论了。

五、第三步：在博客中引入 Waline 前端

我的博客是 Jekyll 构建的，使用 H2O 主题，文章模板在 _layouts/post.html。

改动 #1：添加 Waline CSS

_includes/post-head.html 和 _includes/head.html 各加一行：

<link rel="stylesheet" href="https://unpkg.com/@waline/client@v2/dist/waline.css" />

两个都加是因为 post.html 用了 post-head.html，但默认布局和首页用了 head.html——这取决于 Jekyll 主题的模板继承关系。保险起见两边都加上。

改动 #2：配置后端地址

在 _config.yml 中添加 Waline 配置：

comments:
  waline: true
  waline_url: 'https://comments.kirinzer.com'

改动 #3：替换评论容器

在 _layouts/post.html 中，删掉旧的 Disqus 容器和 Utterances 脚本，换上 Waline：

<section class="post-footer-item comment">
  <div id="waline"></div>
</section>

<script src="https://unpkg.com/@waline/client@v2/dist/waline.js"></script>
<script>
  Waline.init({
    el: '#waline',
    serverURL: 'https://comments.kirinzer.com',
    emoji: ['//unpkg.com/@waline/emojis@v1/weibo'],
    requiredMeta: ['nick'],
    login: 'enable',
  });
</script>

配置说明：

改动一共涉及 4 个文件，15 行新增，30 行删除——旧代码（Disqus 注释掉的 JS 模板、Utterances 脚本）一并清理干净。

本地验证

jekyll serve 本地跑起来，打开一篇博客文章，评论框正常渲染。试着留了一条测试评论，写了昵称，点击提交——几秒钟后显示成功。数据写入 Neon 数据库，管理面板里也能看到新记录。

六、管理面板配置

Waline 提供了一个管理面板，地址是 https://comments.kirinzer.com/ui。第一个注册的用户自动成为管理员（注册入口在 /ui/register）。登录后可以对评论进行管理：

需要注意的是，反垃圾策略和邮件通知不在 UI 里配置，而是通过 Vercel 环境变量 设置的。例如你可以在 Vercel Dashboard → 你的 Waline 项目 → Settings → Environment Variables 中添加：

反垃圾相关：

邮件通知：

这些环境变量设置完成后，Waline 会自动加载对应功能，无需重启。

注：这一步目前是可选的。没有反垃圾配置时，Waline 本身也有基础的重复评论检测能力（内容相似度过高会自动拒绝）。但建议后续加上邮件通知，方便第一时间回复读者留言。

七、数据备份

所有评论数据存储在 Neon 数据库中。你可以登录 Neon 控制台，进入项目数据库，在 Tables 中查看 wl_comment 等表，也支持 Dump 导出 SQL 格式的完整备份。

如果未来想迁移到其他数据库，Waline 也支持 LeanCloud、MongoDB、MySQL、PostgreSQL 等多种后端，做好备份随时可以切换。

八、成本与免费额度

九、结语

换上 Waline 后，我留了一条测试评论，果然丝滑了很多，简单的写一个昵称，就可以开始评论了。

这次改造的核心收获其实不是某个技术方案的替换，而是想清楚了一个道理：作为开发者，你的博客是你的客厅。不要在门口设一道只有圈内人才有钥匙的锁。

截止发文，我的博客刚完成切换。暂时还没有新的读者留言，但我相信降低门槛后，会有更多人愿意停下来聊两句。

附：快速检查清单