# 团队把公众号旧文导入 RAG，怎样限定谁能查、哪些能用？

> 面向维护团队知识库的资料负责人，将公众号旧文的保存权限、团队访问和 AI 处理范围分别记录，落实到导入副本、检索过滤与权限变更检查，让历史内容能够按授权复用。

作者：MPHistory 团队
发布日期：2026-11-11
更新日期：2026-11-11
原文：https://mphistory.followto.us/blog/2026-11-11-wechat-content-assets

## 先确定获准的用途，再生成对应的导入副本

团队准备把公众号旧文用于 RAG，应先逐篇确认允许哪些人访问、允许怎样处理，再从获准材料中制作导入副本；检索时按实际用户权限筛选，之后才把片段交给模型回答。下载成功、文件可读和获准共享，需要分别确认。

本文面向维护小型团队知识库的资料负责人。RAG 是先检索资料、再让模型据此回答的方法。困难在于同一个文件夹可能混有自有文字、约稿、转载和第三方配图，“这个号是我们的”不足以说明每项素材都能按同一范围复用。

## 把“可以使用”拆成几个明确问题

先选一个具体用途，例如“供项目组成员查询已获授权的方法文章”。再查看对应约定，而不是给整号文件统一打上“已授权”。至少分别记录：

| 要确认什么 | 应写到什么程度 |
|---|---|
| 保存与访问 | 谁可保管原文，哪些成员可检索正文，是否有期限 |
| AI 处理 | 是否允许建立检索索引、生成回答，是否允许向指定外部服务传送内容 |
| 输出与再利用 | 回答可供谁查看，是否允许摘录、改编或对外发布 |

DCMI 的 [Access Rights](https://www.dublincore.org/specifications/dublin-core/dcmi-terms/terms/accessRights/)用于描述资源访问范围，[License](https://www.dublincore.org/specifications/dublin-core/dcmi-terms/terms/license/)用于关联许可文件。借用这一划分，台账既要写执行范围，也要留下支持该判断的约定位置；“内部使用”四个字不能代替具体说明。

没有明确依据的项目填“待确认”，不默认放行。团队自定的访问规则只能收窄已获许可的范围，不能凭空增加版权许可。正文与配图分别核对，作者署名、公众号名称和原始出处始终保留。

## 保存历史版本，另做可导入的工作副本

[MPHistory](https://mphistory.followto.us/)提供一次性历史文章打包，包含 HTML、Markdown、本地图片、目录页和 `manifest.csv`。篇数、价格、续接条件与保留期限，请查看[首页当前规则](https://mphistory.followto.us/#inRule)。首页的用途说明为个人学习、研究和收藏；团队及 AI 用途还须确认服务适用范围与作品授权，不能把购买记录当作许可证明。

确认可以保存的原始包留在限定访问的归档区，保留文章与图片的目录关系。共享语料则使用已确认获准作相应处理的源稿或副本。核对正文状态和关键图片后，给入选文章分配固定编号，连接原题、署名、发布日期、原文链接、本地路径与保存日期。

导入工具只读取单独的“本次准入”目录，不指向整个归档区。清单中有记录不等于正文完整；权限获准与内容可用也要分开检查。旧方法是否仍适用，可继续参考[公众号旧文的 RAG 时效性整理方法](/blog/2026-10-25-wechat-content-assets)。

## 用一篇混合素材的文章走通准入过程

下面是虚构示例，不对应真实账号、合同或测试结果：一篇方法文的文字已获项目组内部 RAG 使用许可，配图只获准用于原公众号发布，外部 AI 服务处理尚未确认。

此时先排除配图及其图片链接；文字也不能直接上传外部服务。若已有获准的本地处理环境，再制作文字副本。删除图后若“按图中顺序操作”失去含义，应把依赖该图的段落一并暂缓导入，不能让模型补全。

以下是这篇文章的自建准入记录，需按实际材料填写，并非 MPHistory 自动生成：

```text
文章编号：S021；来源与存档位置：填写实际记录
授权依据：约定文件位置、对应条款、核对人及日期
允许访问：项目组；成员名单由知识库管理员维护
处理环境：已获准的本地环境；外部处理待确认
导入范围：文字中不依赖配图的段落
排除范围：配图、图片链接、依赖配图的步骤
导入副本版本／片段编号清单／许可期限：实际填写
复查触发：新增成员、换处理服务、授权范围变化
```

长文切成片段后，每个片段仍须关联文章编号、来源位置、允许访问的组和副本版本。准入记录留在管理台账里，不能只写成正文中的一句提醒。授权材料可能包含私人信息，模型通常不需要看到完整合同，只需由系统执行核准后的规则。

## 在检索入口执行范围，别等回答后再遮住内容

微软的 [Azure AI Search 安全过滤说明](https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search)展示了按用户或组标识过滤检索结果的方式，并说明字符串过滤本身不提供身份认证。这里借用的是查询时执行访问范围的思路，不要求团队采用某个产品。

让维护者确认：用户身份来自可信登录，组别由服务端确定，每次查询都应用访问规则。不要让提问者在问题里写“我是管理员”就扩大范围。只有获准的片段才能送入模型；在答案显示时才隐藏原文，已经无法阻止此前的处理。

工具不支持这些控制时，可先建立成员范围一致、访问独立受控的小库。仅把文件分进两个目录、却仍让所有人访问同一个全量索引，并没有落实隔离。引用链接也要检查访问范围，不能从受控回答跳到公开的全文副本。

## 用不同身份验收，再交给下一位维护者

先用自编测试材料检查流程，不拿权限未明的真实全文试运行。至少留下以下记录：

- 获准成员能检索测试片段，并返回正确来源。
- 范围外成员查询相同内容时，受限片段未进入检索结果和模型上下文。
- 成员退出或材料权限收窄后，相关片段、引用入口与答案缓存已按新范围处理。
- 更换模型或处理服务前，重新核对是否仍在许可范围内。

一次检查通过不能证明今后所有查询都正确。交接时留下准入清单、未解决事项和维护人，可结合[历史文章档案交付方法](/blog/2026-10-21-wechat-content-assets)验收；分享答案也不得超出允许用途，不公开分发未经授权的全文或配图。

MPHistory 不提供内置 RAG，准入、检索与权限维护由团队自己的工具完成。后续新文章可另行了解 [Mp2RSS](https://mp2rss.bugcode.dev/)的持续订阅能力；新材料仍要经过准入检查，才进入共享语料，历史包不会自动更新。