每周自动审计知识库：小改AI重写，大改派Jira

原文要点

ResilNext 发布的 n8n 免费模板（编号18982）：每周定时运行，配置知识库 API 地址、当前产品版本、陈旧度阈值和 Slack 频道；通过 HTTP 拉取文章，按发布时长、浏览趋势、有用度计算陈旧信号并过滤；抽取链接用 HTTP HEAD 校验失效情况，从 PostgreSQL 读反馈让 Claude 做情绪分析；按陈旧程度分流，用 Tavily 搜索加 Claude 核查事实、算质量分、做 SEO 审计并回写审计历史；再从 PostgreSQL 取工单热点话题让 Claude 找知识缺口；Claude 把更新分为 minor/major，minor 直接重写并 PATCH 回知识库，major 建 Jira 工单给专家复核，差异入库，周报发 Slack 并推送到外部分析端点。

这次做成什么

搭起这条每周知识库审计流的骨架，并用本站设计的「单篇文章试跑」方案先验证：陈旧度过滤→链接校验→minor/major 分类→minor 重写 PATCH 的最小闭环，再开全量。

准备什么

• 一个支持列出文章并对 /{articleId} 发起 PATCH 更新的知识库 API 及其 token
• Anthropic API 密钥（情绪、核查、SEO、缺口、审计、重写多处调用，会产生费用）
• PostgreSQL 库及凭据，且建好四张表（见 artifact 的 DDL）
• Jira 实例的 API URL、项目 key、API token 和用于指派的 assignee 值
• Slack 凭据与目标频道 ID；Tavily API 密钥；可选的外部分析端点 URL 和 token

具体怎么做

1. 导入模板并填配置节点

   在 n8n 导入编号18982模板，打开 Schedule Trigger 设为每周（如周一 06:00）；在配置节点填入知识库 API base URL、当前产品版本号、staleness 阈值（如发布超过180天且近30天浏览下降）、Slack 频道 ID。

2. 建 PostgreSQL 四张表并接通凭据

   用下方 artifact 的 DDL 在库中创建 support_tickets、article_feedback、article_audit_history、article_change_log 四张表；在模板各 Postgres 节点连接凭据；若你的表名不同，逐节点把 SQL 里的表名改成你的 schema。

3. 连接五个外部凭据

   依次为 Anthropic（Claude）、知识库 HTTP 节点（header 里放 Bearer token）、Tavily、Jira（URL/项目key/token/assignee）、Slack 添加凭据；模板对 Claude 有六处不同用途的调用，全部共用同一 Anthropic 凭据即可。

4. 先单篇试跑最小闭环

   本站建议的验证方案：临时在拉取文章节点后加一个 Limit 节点只保留 1 篇，向 article_feedback 插入下方合成数据，手动执行；确认该文被判为 minor 后 PATCH 请求体包含重写后的正文，article_change_log 写入一条差异记录，Slack 收到周报；通过后再删掉 Limit 开全量。

可直接复制的材料

CREATE TABLE support_tickets (
  id SERIAL PRIMARY KEY,
  topic TEXT NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT now()
);
CREATE TABLE article_feedback (
  id SERIAL PRIMARY KEY,
  article_id TEXT NOT NULL,
  comment TEXT NOT NULL,
  helpful BOOLEAN,
  created_at TIMESTAMP NOT NULL DEFAULT now()
);
CREATE TABLE article_audit_history (
  id SERIAL PRIMARY KEY,
  article_id TEXT NOT NULL,
  quality_score NUMERIC,
  audit_result JSONB,
  audited_at TIMESTAMP NOT NULL DEFAULT now()
);
CREATE TABLE article_change_log (
  id SERIAL PRIMARY KEY,
  article_id TEXT NOT NULL,
  change_type TEXT NOT NULL,
  diff JSONB,
  changed_at TIMESTAMP NOT NULL DEFAULT now()
);

你是知识库维护专家。下面是文章正文、失效链接清单、用户反馈情绪、事实核查结果，以及当前产品版本号。

当前产品版本：{{ $json.product_version }}
文章正文：{{ $json.body }}
失效链接：{{ $json.broken_links }}
反馈情绪：{{ $json.sentiment }}
事实核查：{{ $json.fact_check }}

第一步，判断更新复杂度并只输出一个词：minor 或 major。判定标准：仅涉及错别字、失效链接替换、截图说明过期、单句事实修正的判 minor；涉及产品功能逻辑变化、流程步骤整体过时、需要产品或法务确认的判 major。
第二步，若判为 minor，另起一行输出「---REWRITTEN---」，然后给出修订后的完整正文（保持原有标题层级，直接可 PATCH 回知识库）；若判为 major，输出一行 Jira 工单摘要，格式：「[KB审计] 文章ID + 主要问题 + 建议复核人角色」。

INSERT INTO article_feedback (article_id, comment, helpful, created_at) VALUES
('kb-2041', '按步骤操作到第3步就报错了，界面和截图完全不一样', false, now() - interval '2 days'),
('kb-2041', '内容太旧，提到的按钮在新版本里已经改名', false, now() - interval '5 days'),
('kb-2041', '排查思路有用，但例子里的参数名不对', true, now() - interval '9 days');
INSERT INTO support_tickets (topic, created_at) VALUES
('SSO登录失败', now() - interval '1 day'),
('SSO登录失败', now() - interval '3 days'),
('数据导出格式', now() - interval '4 days');

输入与输出示例

本站虚构演示，未实际运行模板；重写正文由 Claude 生成时请以实际返回为准。

输入

kb-2041 文章发布于210天前、近30天浏览量下降40%、含1个404链接，反馈为上文三条（两条负面），当前产品版本 5.2，正文仍引用 4.x 的按钮名称「同步设置」。

对应输出

分类结果：minor
---REWRITTEN---
（修订后正文节选）「在 5.2 版本中，原『同步设置』按钮已更名为『数据同步』，位于 设置 > 集成 页面……」，失效链接替换为当前文档地址；随后 PATCH 请求将该正文写回 /kb-2041，article_change_log 新增一条 change_type=minor_rewrite 的记录，Slack 周报显示「本周审计1篇：minor 1篇已自动更新，major 0篇」。

做完检查这些

• 单篇试跑时 Limit 后只有1篇文章进入审计分支，其余文章不受影响
• 被判 minor 的文章触发了对知识库 /{articleId} 的 PATCH 且响应为成功状态码
• article_change_log 表新增一行，diff 字段包含修改前后内容
• article_feedback 中不存在的 article_id 不会导致情绪分析节点报错中断
• 周报 Slack 消息中 minor 数、major 数与 change_log、Jira 实际新建工单数一致

容易卡住的地方

• 知识库 API 必须真的支持 PATCH 到 /{articleId}，只支持整库导入的系统（如部分静态文档站）无法自动回写，需把该分支改为导出修订稿
• 原模板未附 PostgreSQL 建表语句，表结构是本站在此补的简化版，导入后必须逐节点核对字段名，不匹配会报 SQL 错误
• minor 判定交给模型存在误判风险，建议上线初期把阈值调严，把边缘情况都路由到 Jira 人工复核
• Tavily、Anthropic、Jira、Slack 任一凭据失效都会让对应分支中断，周报里可能只缺一部分而不整体失败
• 知识缺口分析依赖 support_tickets 表有真实工单数据，空表时该分支输出为空属正常现象