自动给文章术语加百科链接，这个方案一分钟搞定

Matrix精选 2026年06月30日 11 分钟阅读 自动给文章术语加百科链接，这个方案一分钟搞定 主作者 关注 CG艺术实验室 少数派作者 探索设计美学，加速生产力 | 博客：cgartlab.com | 公众号：尘光造梦 CG艺术实验室 关注 CG艺术实验室 少数派作者 探索设计美学，加速生产力 | 博客：cgartlab.com | 公众号：尘光造梦 联合作者 关注 CG艺术实验室 少数派作者 探索设计美学，加速生产力 | 博客：cgartlab.com | 公众号：尘光造梦 CG艺术实验室 关注 CG艺术实验室 少数派作者 探索设计美学，加速生产力 | 博客：cgartlab.com | 公众号：尘光造梦 探索设计美学，加速生产力 | 博客：cgartlab.com | 公众号：尘光造梦 11 分钟阅读 微信扫码分享 以图片分享 分享到微博 点击下方按钮可复制链接 分享 收藏 举报 Matrix 首页推荐 Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。 文章代表作者个人观点，少数派仅对标题和排版略作修改。 AI 辅助说明： 本文所表述的前端视觉设计和文字内容为作者原创。代码部分由作者提供需求、创意思路和术语词库领域的范围和定义， OpenCode 负责具体代码编写，作者最终审核手动调整后提交上线。 为什么要给术语加链接 上周有位朋友在看完博客内某篇涉及自建服务器和 NAS 的文章之后发来一条反馈： RSS 、 WebDAV 、 DDNS 、 内网穿透 ……一堆缩写和名词来回出现，看到后面得往上翻去回忆哪个是哪个。挨个用手机划词搜索又太打断阅读节奏。 这真是个好问题，值得解决。一方面，这位朋友其实已经算是深度读者了——愿意把整篇看完，还愿意花时间告诉我哪里不舒服。另一方面，我意识到一个很尴尬的事实： 我的很多文章默认读者已经了解很多基础概念，但实际上每个人接触这些概念的路径完全不同。 在我看来，读者了解概念的渠道要比知不知道这个概念更重要，对概念的认知本身出现偏差，会直接导致误读更多信息，以后只会更尴尬，这样的阅读体验或许比看不懂更加糟糕。 所谓「阅读体验」，有时候并不是排版好不好看、字间距舒不舒服这么表面的事情。 阅读体验的核心，是读者能不能顺畅地把注意力集中在你想表达的内容上，而不是被迫反复切换到另一个上下文去查一个陌生名词。 每一秒的切换和搜索，都是在消耗读者的耐心。 最终实现效果👇。 利用链接预览功能 另外，现在的手机浏览器通常也都附带按住链接可以预览的功能，这样也就并不需要完全跳转页面，快速了解一下概念后继续浏览当前页面，我觉得这个体验更好一些。 如果你是从 博客 访问的这篇文章，细心的你应该已经发现很多看不懂的词都可以点了。 现有工具的局限：读者需要主动搜索 其实这个问题已经有了太多解决方案。无论是 Safari 的划词查询，还是 Chrome 的「搜索 XXX」，甚至现在 AI 浏览器直接翻译成「人话」，都已经相当强大。 但问题在于： 它们需要读者主动发起动作，且步骤太多。 读者读到「DDNS」这个词，停下来，选中它，再等搜索出结果——这个过程哪怕只要两秒，累积在一篇有三五个陌生术语的文章里，阅读的沉浸感也已经被彻底打碎。 解法很简单，碰到一个关键概念，点一下这个词就能跳转到介绍这个概念的网站就行了。 那么问题来了，一篇长文可能涉及十几二十个术语，每次修改还要检查链接对不对、挂了没有。更麻烦的是，一个术语在文章里可能出现了好几次，我只想在第一次出现时挂链接，后面出现时保持朴素文本，不然整篇文章全是重点，也就没有重点了吧——但纯手工做这件事，基本是在跟自己过不去。 于是问题变成了， 我需要一个帮我「写完文章、按下发布，链接自动生成」的智能机器人。 构建自动嵌入链接 我的博客基于 Astro 构建，每篇文章发布之前，整个网站都会经过一次重新计算生成页面——所有的文章默认从 .md 文件变成静态 HTML 网页。这个过程恰好是给术语嵌入链接的最佳时机。 为什么不选择在浏览器端做这件事？ 运行时方案意味着你每次页面加载时都要下载一个术语表、在你的设备跑一遍字符串匹配，对设备性能和网络带宽都是额外的负担。而且如果匹配逻辑有更新，你无法在第一时间看到最新的改进变化。 如果在构建的时候直接处理好这个过程，就干净得多： 文章在编译成 HTML 的同时，术语链接就已经被嵌入进去。读者拿到的是一份已经处理好的、可以直接阅读的静态页面。 总之，把所有的计算负担交给云端去处理就好。 确定了这个方向之后，剩下的问题就是：概念怎么匹配、关键词怎么跳过、怎么优雅地和 Astro 的 Markdown 文档处理管线协作。 用人话讲原理 想象你正在看一本书（就是你们网站上的那些文章），和一堆标签（我提前准备的一本字典）。 每一张标签都写着一个名词和它的解释在哪里可以找到——比如「RSS」标签告诉你，戳它就能去维基百科看答案。 现在，不用你亲自一张一张去贴。 有一个机器人，在书的每一页被印刷之前，先快速扫一遍全文，找到标签的名词，把第一张标签贴到这个词第一次出现的位置，然后换个地方继续找。 它还很聪明，知道标题里、代码框里、已经贴过的位置不能贴。 全部贴完之后，书就印刷出版了。你拿到手的时候，看到不懂的词身上已经有一个可以点的小标签了。 几乎所有的概念来源我都用了维基百科，它是目前最全、最稳定、支持语言最多的公共知识库，下文也会进行详细说明。 附上整个运行机制的流程图如下👇： 这就是全部过程，如果你对具体的技术细节毫无兴趣，看到这里就够了。 实现解剖：两个插件的接力赛 从专业角度看，说回代码层面，这套机制由两个插件完成，分别跑在 Astro Markdown 处理管线的不同阶段。 第一阶段：remark-glossary remark-glossary 是一个 remark 插件（处理 Markdown AST 的阶段），它的任务极其简单： 读取文章 frontmatter 里的 lang 字段，把它存到 vfile.data.glossaryLang 中。 文章没有声明 lang 时默认中文（ zh ）。这个字段在后面会被第二个插件用到——中文文章用 zh.wikipedia.org ，英文文章用 en.wikipedia.org ，繁体中文保持 zh.wikipedia.org 。 为什么需要单独一个插件来做这件事？因为 Astro 的 Markdown 管线里，remark 阶段最先执行，此时 frontmatter 已经被解析好了。如果等到后面的 rehype 阶段再去拿 frontmatter ，虽然也能拿到，但让一个插件只做一件事，是清晰的工程习惯。 第二阶段：rehype-glossary rehype-glossary 是核心引擎，运行在 rehype 阶段（此时 Markdown 已经被转为 HTML AST）。它做以下事情： 读取语言 ——从 vfile.data.glossaryLang 拿到当前文章的语言 检查标签 ——如果文章 tags 包含「周刊」或「W