博客 AI 摘要及优化

博客 AI 摘要及优化

💡 原文中文,约4300字,阅读约需11分钟。
📝

内容提要

作者因AI摘要服务消耗过快,决定自建方案:将摘要存入文章Front Matter或summary.json,用Hugo模板渲染到文章开头,并可选打字机效果与自定义CSS,实现静态化、低成本维护。

🔎

延伸解读

从依赖服务到静态自建:成本与可控性的权衡

作者最初购买 TianliGPT 服务,但 Key 消耗过快,多次购买仍无法覆盖全部文章,导致 AI 摘要成为“历史包袱”。自建方案将摘要数据静态化,避免了持续付费和接口依赖,符合其 Hugo 静态博客的初衷。这提醒读者:第三方 AI 服务虽便捷,但长期使用需评估成本与可持续性,尤其是内容量大的站点。

两种数据存放方式的取舍:JSON 与 Front Matter

作者先选择将摘要集中存放在 data/summary/summary.json,便于统一维护且不破坏现有文章;后改为放入文章 Front Matter。两种方式各有优劣:JSON 适合批量管理,但需额外匹配 slug;Front Matter 与文章绑定更紧密,迁移时不易丢失。读者可根据文章数量和维护习惯选择,若文章频繁增删,Front Matter 可能更直观。

渲染与增强:模板插入与打字机效果

通过修改 Hugo 的 single.html 模板,在 {{ .Content }} 前插入代码,从 JSON 中按 slug 匹配摘要并渲染。若需打字机效果,需引入 TypeIt 插件并隐藏原始内容,通过 JS 读取文本后动态显示。注意:打字机效果会增加页面 JS 依赖,可能影响加载性能;若追求简洁,可省略此步骤,仅保留静态渲染。

❓

Q&A

为什么作者决定自己动手优化博客的 AI 摘要功能?

作者使用 TianliGPT 服务时,购买的 Key 很快消耗完,多次购买仍不够,且只有不到三分之二的文章有摘要,感觉像无底洞,成为历史包袱。为了不妥协 Geek 精神,并符合 Hugo 静态博客数据静态化的初衷,决定自己改造。

自建 AI 摘要时,作者最终选择将摘要数据放在哪里?

作者最终选择将 AI 摘要放在文章的 Front Matter 里(方式 2),而不是放在 data 目录下的 .json 文件中。这样方便后期维护,也不破坏现有文章。

如何将 summary.json 中的 AI 摘要渲染到每篇文章的开头?

修改 Hugo 文章模板文件(如 single.html),在 {{ .Content }} 之前插入代码:通过 resources.Get 获取 data/summary/summary.json,用 transform.Unmarshal 解析,然后根据当前文章的 slug 匹配摘要,并渲染到 <div class="post-ai"> 中。

如何为 AI 摘要添加打字机效果?

首先取消 <div id="ai-explanation" class="ai-explanation"></div> 的注释,并给 <div class="ai-explanation-content" style="display: none;"> 添加 display: none 隐藏。然后引入 TypeIt 库的 JS,在 DOMContentLoaded 事件中从 .ai-explanation-content 获取文本,用 TypeIt 实例化并设置参数(如 speed: 50, lifeLike: true 等)。

AI 摘要的 CSS 样式如何设置?

文章提供了简单的 CSS 示例:.post-ai 设置背景色、圆角、内边距、边框等;.ai-title 使用 flex 布局,设置颜色、圆角等;.ai-title-icon 设置图标大小;.ai-explanation 设置上边距、内边距、背景色、边框、字体大小等。

作者如何看待 AI 摘要的必要性?

作者认为 AI 摘要不是必要的,集成只是为了方便有相同阅读习惯的人。个人博客内容对他人可能是低价值数据,但 AI 摘要能帮助快速辨别文章是否值得细读。

🏷️

标签

➡️

继续阅读