中/EN
实战 SOP
实战 SOP

知识库自动更新工作流：让文档库自己跟上业务

知识库自动更新 n8n 工作流：内容源触发->抓取正文->去重->LLM 摘要+关键词+分类->向量化写入知识库->通知。让文档库自己跟上业务。配 .json 模板下载与进阶（全量重扫/陈旧检测/权限）。

发布于 2026年8月2日5 分钟阅读
<!-- workflow-knowledge-base-update | resource | 知识库自动更新工作流：让文档库自己跟上业务 -->

知识库建完那天是最新鲜的，第二天就开始过时。产品改了一版文档没同步、运营发了新 SOP 没入库、工程写了篇故障复盘躺在 GitHub Wiki 里没人捞、销售更新了报价单知识库还停留在上季度。等到新员工入职搜"退款流程"，搜出来的是半年前的旧版，照着操作才发现规则早变了，这种事故在合规要求高的行业（金融、医疗）会直接变成线上事故。人工维护知识库的死结在于：写文档的人不负责入库，负责入库的人不知道有新文档，最后知识库变成"历史的快照"而不是"当前的事实"。更隐蔽的是知识库"看起来满"的假象：条目几百条，一半过期、一半重复、关键的新流程反而没进库，用户搜不到就只能问人，问答记录又回流不到知识库，形成"越用越废"的恶性循环。这个 n8n 工作流把内容源（RSS、飞书文档、GitHub Wiki、Webhook 上传）接到知识库，新文档一发布自动抓取正文、去重、让大模型出摘要+关键词+分类、向量化写入知识库并触发索引重排，跑完推一条 Slack/飞书消息"知识库已更新 N 条"。知识库从"人工搬运"变成"管道自流"，搜索结果永远基于最新文档而不是上季度的那份。

工作流链路

内容源触发（RSS Feed Read 订阅技术博客 / 飞书文档事件 / GitHub Wiki Webhook / Webhook 上传新文档）-> 抓取正文（HTTP Request 拉全文，超长截断）-> 去重（Code 节点按 URL+标题 hash 生成去重键，查已入库命中则跳过）-> LLM 摘要+抽关键词+分类（HTTP Request 调 Moonshot/DeepSeek，输出 title/summary/keywords/category/tags/language 六字段）-> 向量化+写入知识库（HTTP Request 调向量库 API 生成 embedding 并 upsert，或写入 Notion/Confluence/飞书知识库）-> 更新索引/触发重排 -> 通知（Slack/飞书机器人"知识库已更新 N 条"）。

这套链路的核心价值不是省了入库那一下，而是把"入库"从靠人记着变成靠管道兜底：只要内容源在更新，知识库就自动跟上，搜不到新内容的情况只可能发生在内容源没接入（检查管道）而不是忘了入库（检查人）。它还顺带解决了"摘要质量"问题——人工写摘要容易漏要点或夹带主观，LLM 按固定 Prompt 出的结构化摘要一致性强，关键词和分类也让后续按模块、按主题检索成为可能，而不是只能全文搜。

下载模板

知识库自动更新工作流n8n JSON

使用步骤

  1. 导入：n8n -> Workflows -> Import from File，选 workflow-knowledge-base-update.json
  2. RSS 订阅源节点：填你的内容源 RSS 地址。技术博客用 RSS Feed Read 直接收；飞书文档用飞书的文档事件 Webhook 转进来；GitHub Wiki 没有原生 RSS，用 Schedule Trigger 定时拉 API 或接 GitHub Webhook（push 事件）；人工上传走 Webhook 节点。多源接入的关键是字段统一，不同源原始字段名不同，在 Code 节点归一成 title / url / content / source 四字段
  3. 抓取正文节点：HTTP Request GET 文档链接拿全文。RSS 通常只给摘要，正文要二次拉取；HTML 页面建议接 readability 类抽取正文，否则正文里混着导航和页脚噪声，LLM 摘要质量会掉。超长文档在 Code 节点截断到 8k 字符以内，超出部分单独分片入库
  4. 去重 hash 节点：Code 节点按 URL+标题拼出 key 做 hash，前缀 kb_ 避免和其他工作流冲突。去重键别只看 URL（同一篇被改了链接就漏）也别只看标题（不同文档同名就误杀），URL+标题组合最稳
  5. 查已入库节点：HTTP Request 查向量库或存储里是否已有该 hash。Qdrant 用 scroll + filter on hash；Pinecone 用 query + metadata filter；Postgres 直接 select hash 列。返回 exists 字段供下一步 IF 判断
  6. IF 命中跳过节点：exists=true 走空分支（结束），exists=false 走 LLM 分支。命中跳过不报错，n8n 日志里只是"no output"，正常现象
  7. LLM 摘要分类节点：填 Moonshot/DeepSeek/Qwen key，8k 上下文够用，Prompt 见下。类目冻结为产品文档/技术文档/运维手册/FAQ/公告/其他六类，覆盖内部知识库九成场景；别在第一层就开十几个细类，模型会乱。Prompt 改版时记 prompt_version 字段进 metadata，回溯历史数据时按版本号重新跑分类，别拿今天的标准评判昨天的数据
  8. 向量化入库节点：调向量库 API 先生成 embedding 再 upsert。Qdrant/Pinecone/Weaviate 都支持单次请求完成 embedding+写入；如果向量库不内置 embedding，先调 OpenAI/BGE embedding API 拿向量再 upsert。metadata 必带 title/url/source/hash/category/updated_at，方便后续按源/分类过滤和陈旧检测。embedding 模型一旦选定别轻易换，换了要全量重算，旧向量和新向量不在同一空间会乱搜
  9. 通知节点：Slack incoming webhook 或飞书自定义机器人，消息带标题+分类+来源链接，方便人工抽查摘要质量。批量入库时聚合"N 条"而不是一条一条推，否则刷屏
  10. 试运行：手动喂一篇测试文档（含已知 URL），看去重是否命中、LLM 摘要是否合理、向量库是否写入了带 metadata 的记录、通知是否到达

配套 Prompt（LLM 摘要+分类）

Prompt
你是知识库文档分析助手。读下面文档正文，输出 JSON：
- title：文档标题（原文有则用，否则从正文推断）
- summary：150 字内摘要，覆盖核心结论而非流水账
- keywords：3-5 个关键词数组
- category：产品文档 / 技术文档 / 运维手册 / FAQ / 公告 / 其他（六选一，不得自创类目）
- tags：1-3 个标签
- language：zh / en
规则：类目必须从六类选；不编造正文之外的事实；摘要基于原文，不补充推测。
文档正文：{{content}}

进阶

  • 定期全量重扫：Schedule Trigger 每周跑一次，把内容源全量重拉一遍，对每篇算 hash 查库。命中且 content 一致就跳过；命中但 content 变了（正文 hash 不等于入库时的 content_hash）就触发"文档更新"分支：重新摘要+向量化，覆盖旧记录，metadata 里记 version+1。这是防止"原文改了但知识库还是旧版"的关键
  • 陈旧检测：给每条入库记录打 updated_at 时间戳，Schedule 每月扫一次，超过 180 天没更新的标记 stale，在知识库前端展示"此文档可能过时"提示，或推飞书让 owner 复核。owner 字段从 source 反推（飞书文档取 owner，GitHub Wiki 取 repo owner）
  • 权限/可见性控制：内部知识库常分"全员可见"和"部门可见"。入库时按 source 或 category 打 visibility 标签，向量库 metadata 带 visibility，检索时按当前用户部门过滤。别把所有文档塞一个 collection 再靠应用层过滤，向量库层面做 metadata filter 才是正路
  • 增量 vs 全量：默认跑增量（只处理新增和变更），全量重扫放低频（每周或每月）。全量重扫前先备份当前索引，跑完对比新旧，异常回滚

合规提示

内部知识库含公司信息、客户案例、内部流程，喂给外部 LLM 做摘要前先确认：①LLM 服务是否签了数据处理协议（DPA）、是否承诺不用于训练；②向量库选型注意数据隔离，优先私有部署（Qdrant/Weaviate 自建）或租户隔离的 SaaS（Pinecone 的 namespace、Weaviate 的 multi-tenancy）；③含 PII 或商业机密的文档先在 Code 节点脱敏再送 LLM，原文存内库只供授权回溯；④跨境数据传输注意《个人信息保护法》和 GDPR 的出境要求，向量库和 LLM 服务在同一区域更稳。

参考来源

本文由 AI 辅助生成，经人工审核编辑。最后更新：2026-08-02

相关文章

实战 SOP

邮件营销自动化工作流：分群个性化到 A/B 自优化闭环

邮件营销自动化 n8n 工作流：定时拉订阅者->按标签/行为分群->LLM 按分群生成 A/B 个性化邮件(主题行+正文)->SMTP 发送->Webhook 追踪打开点击->回写指标->IF 打开率低于阈值且样本足够->触发 LLM 换文案重测。含合规提示(已订阅授权/一键退订/CAN-SPAM/GDPR/电子商务法/不推断敏感属性)。配 .json 模板下载。

2026年8月4日5 分钟阅读