批量词条解释方案

你提到了一个非常关键的系统瓶颈。如果每发布一篇文章，就要为其中的 8 个词条分别调用 8 次 AI 接口，不仅响应时间极慢（会导致接口超时），而且API 费用会激增。这确实会让系统退化到无法实用的状态。

为了解决这个问题，我们绝对不能用“1个词条调1次AI”的愚公移山方式。以下是业界成熟的**“单次批量提取 + 全局复用库 + 异步处理”**黄金方案，不仅不需要人工，还能把 AI 开销降到极低。

核心方案：全局词条库 + 增量处理

其核心逻辑是：“一次生成，全网复用；已有词条，绝不重构。”

第一步：建立独立的 `terms`（词条表）

不要把词条和解释直接写死在文章表里，而是建立一个全局的词条公共库：

id: 自增主键
term_name: 词条名称（如：红茶，发酵，茶多酚）
definition: 词条解释（一两句话的简短定义，用于悬浮窗或百科卡片）
slug: 词条唯一的 URL 别名（用于 SEO 静态页，如 /terms/hongcha）

第二步：AI“单次批量提取”与定义（单次调用）

当 AI 生成完文章后，只向 AI 发起一次批量请求，让它同时完成“提取”和“定义”工作，并且要求它输出 JSON 格式。

你可以使用这样的 Prompt 模板：

“请阅读以下文章，提取出 5-8 个最核心的专业词条。要求输出为标准的 JSON 格式，其中 Key 是词条名称，Value 是该词条的简短定义（50字以内）。
示例输出：
{
"红茶": "红茶是经过完全发酵的茶类，以茶芽叶为原料，经萎凋、揉捻、发酵、干燥等工序精制而成。",
"发酵": "在茶叶制作中指茶叶中的多酚类物质在酶的催化下发生氧化聚合的过程。"
}”

通过这种方式，一篇文章只需要调用 1 次 AI 接口，就拿到了所有的词条和解释。

第三步：程序自动去重与入库（零成本复用）

当后端系统收到 AI 返回的 JSON 数据后，进行如下处理：

比对数据库：遍历 AI 提取出的词条。如果词条（如“红茶”）在数据库的 terms 表中已经存在，则直接跳过，使用数据库里已有的解释。
增量写入：如果不存在（比如产生了一个新词条“茶黄素”），才将它存入 terms 表。
建立关联：在文章和词条之间建立多对多关系（或直接在文章渲染时动态匹配）。

效果： 随着你的网站文章越来越多，全局词条库（terms）会越来越完善。运行到后期，新文章里 90% 的词条其实都已经存在于数据库中了，AI 几乎不需要再为它们生成定义，API 成本和时间消耗会呈指数级下降。

进一步优化：引入异步队列 (Queue)

即使合并成了一次 AI 请求，由于要等待 AI 生成 JSON，文章发布接口依然可能要等待 3-5 秒，影响用户（或你作为管理员）的发布体验。为了让过程更顺畅，可以引入异步队列：

前台秒级响应：你点击“发布文章”，文章立刻成功发布并上线，用户可以立刻阅读。
后台默默工作：系统将“词条提取”的任务丢进后台队列（如 Celery、Redis Queue、或 Go Goroutine）。
数秒后自动链接：后台任务调用 AI 获取词条、入库，并自动在文章正文中加上超链接。整个过程对前台用户无感知。

总结

绝不单兵作战：一次 Prompt 获取所有词条和定义（JSON 格式）。
全局缓存复用：建立公共 terms 表，已有词条绝不重复向 AI 提问，越用越省钱。
异步后台处理：把耗时的 AI 处理放到后台，确保前台发布不卡顿。