我让 AI 给博客接上了 Artalk 评论系统

上一篇我写的是，我怎么用 AI 重构了整个博客。

这一篇就更具体一点了。

这次我让 AI 做的，不是首页视觉，也不是某个动画，而是一个更像“博客该有的东西”的功能: 评论系统。

更准确一点说，我让 AI 帮我把 Artalk 接进了这个站，让文章页下面真的可以留言，也让首页开始能展示最新评论。

这个改动看起来没有首页改版那么显眼，但它其实很重要。因为从这一刻开始，这个博客不再只是我一个人往外输出，它开始有了一个能把反馈收回来的入口。

这次不是补一个输入框

我一开始想做的，也不是单纯在页面底下塞一个“发表评论”按钮。

如果只是放一个最基础的评论框，这件事当然很快就能做完。但那种做法的问题是，它只是“有了评论功能”，并没有真的把评论变成这个博客体验的一部分。

所以我这次想要的，其实是三件事一起成立：

• 文章页下面要有完整的评论区，能直接留言、回复、预览。
• 本地开发时也能正常调试，不要一碰跨域或者服务地址就坏掉。
• 首页不能只是摆一个空卡片，最好也能看到最新评论，让评论这件事被看见。

也就是说，这次目标从来不是“接一个第三方插件”，而是把评论正式接进博客自己的内容结构里。

我为什么最后选了 Artalk

评论系统其实不难找，但适合个人博客长期用的，不算太多。

我最后选 Artalk，原因很直接：

• 它足够轻，不需要我为了评论再背一套很重的平台。
• 它是自托管思路，数据还是在自己手里。
• 功能够完整，基本的评论、回复、排序、图片、投票这些都有。
• 前端接入方式比较清楚，适合我现在这套 Astro 结构去接。

对我这种站来说，这就够了。

我不需要一个巨大的社区系统，我需要的是一个能稳定工作、风格可控、能跟自己的页面融合在一起的评论层。Artalk 刚好落在这个点上。

这次 AI 真正帮我做了什么

很多人一说“用 AI 做功能”，会默认理解成“把需求扔过去，然后等结果”。

但我实际的工作方式不是那样。

这次更像是我来定义方向，AI 来负责把第一版实现快速铺出来，然后我再不断改它、推它、纠正它，让它慢慢长成我真正要的样子。

比如这次 AI 帮我做的几件事就很典型：

• 把文章页评论组件先接起来。
• 给本地开发环境做了一个 Artalk 代理层，避免本地直连评论服务时出问题。
• 把评论区的视觉样式重新包了一层，让它尽量贴合我这个站原本的玻璃质感。
• 顺手把首页的 Comment Board 也接上，让它不再只是占位。

但这些都只是“起步”。

真正决定这套东西最后长什么样的，还是后面的反复调整。像评论区文案、字段提示、预览逻辑、首页显示方式、交互边界，这些都不是 AI 自己会天然做对的，而是我一轮一轮告诉它哪里不对，再逼它往我要的方向去收。

所以如果非要总结一句，我觉得这次不是“AI 帮我写了个评论系统”，而是“AI 帮我把一套评论系统快速推到了可迭代状态”。

中间其实也踩了坑

这个过程并不是一把过。

比如本地开发时，评论服务并不在站点同域下。如果直接在浏览器里连远端评论接口，本地调试就很容易碰到访问、代理或者请求链路上的问题。所以最后我让 AI 在站内补了一层接口代理，开发环境下统一从站内走：

const resolvedArtalkServer = import.meta.env.DEV ? "/api/artalk" : artalkServer;

然后再由站内的接口把请求转发到真实的 Artalk 服务。

这样做的好处是，本地和线上虽然路径不一样，但前端评论组件的配置思路是一致的，调试体验会稳定很多。

另一个很真实的问题，是评论组件本身接进来以后，并不会自动变成“适合这个站”的样子。

默认可用，不等于默认合适。

所以后面我又让 AI 继续做了很多表面上不那么“核心”，但实际上很影响体验的事情：

• 昵称、邮箱、网址这些字段重新组织。
• 评论正文补上更明确的校验提示。
• 发布按钮、空状态、错误提示的语气重新写过。
• 评论列表和投票动作重新整理，让它看起来不那么像默认插件皮肤。

这部分工作其实很能说明一件事：真正把一个功能做得像自己的东西，靠的从来不是“接上”，而是“接上以后继续改”。

首页为什么也要展示评论

我这次挺坚持的一点，是首页也要看到评论。

因为如果评论只藏在文章页最下面，那它在很多时候就像一个没人注意的附属功能。只有真正翻到文章尾部的人，才知道这里能说话。

但如果首页就有一个 Comment Board，哪怕只是展示最近几条留言，这件事的感觉就完全不一样了。

它会直接告诉来访的人：这个博客不是封闭的，它是可以留下痕迹的。

所以我最后把首页那块也接上了，只不过没有粗暴地把完整评论区直接塞进侧边卡片里，而是分成了两层：

• 上面的小卡片负责展示最近留言。
• 下面完整的评论区负责真正输入和互动。

这样处理以后，首页的信息密度不会炸掉，评论又真的被纳入了整个首页结构里。

这比单纯多一个“留言入口”要完整得多。

这次我更在意的，不是评论功能本身

说到底，我在意的不是“网站终于可以评论了”这件小事。

我更在意的是，这个站开始有了一个能持续接收外部反馈的回路。

以前这个博客更像一个展示面，我写，你看，结束。

现在它开始有一点点变成“我写，你看，你也可以回一句，然后这个站继续往下长”的感觉。

这对个人博客来说，其实是很关键的一步。

因为一个长期更新的网站，不能永远只靠作者单向输出。哪怕互动不多，哪怕评论很慢，它也应该有那个入口。那个入口本身，就意味着这个站愿意和外界发生关系。

我现在越来越习惯让 AI 做这种事

这次接评论系统，也让我更确定了一件事：

AI 最适合的，不是替我做最后判断，而是帮我把实现阶段压缩得更短。

以前像这种功能，我可能会拖很久。

不是因为不会做，而是因为它介于“挺重要”和“暂时还能先放着”之间，于是就会被不断往后推。AI 的价值就在这里，它能让我更快看到第一版，更快进入修改状态，也更快把一个想法从“以后再说”推进到“已经在线了”。

当然，前提是你自己得知道要什么。

如果你自己没有判断，AI 很容易把东西做成一个能用、但没有个性的通用答案。但如果你已经知道自己想把一个站做成什么样，它就会变成一个很好的推进器。

这次的评论系统，对我来说就是这样。

不是 AI 替我决定我要不要评论，不是 AI 替我决定评论区该长什么样，而是我已经知道这个站需要一个真正的反馈入口，所以我让 AI 帮我把这件事更快做出来。

写在最后

所以这篇文章如果要有一句最短的总结，大概就是：

我让 AI 给这个博客接上了 Artalk，但我真正完成的，不只是一个评论功能，而是给这个站补上了一条能继续对话的通路。

从现在开始，这个博客就不只是“我发了什么”，也开始变成“这里留下了什么回应”。

后面我大概率还会继续改这块。评论区的展示方式、首页的精选留言、交互细节、管理方式，应该都还会慢慢往前推。

但至少现在，它已经不是一个空位了。

如果你刚好看到了这里，也欢迎你去试着留一条。对我来说，这不只是测试功能有没有通，更像是这个博客真正开始活起来的一个标记。