营销知识库从本地上云，构建团队协作形态的完整方案

本文记录的是 2026 年 10 月 8 日至 9 日的一次实际建设。

如果你已经在电脑里整理了一套营销知识库，也能让 AI 直接阅读和修改文件，那么“上云”要解决的，并不是让这个 AI 突然变得更聪明。真正的问题是：资料怎样保存和恢复？同事在自己的电脑上能用到哪些内容？换一个 AI 工具后，怎样保证它不会读到客户资料、内部报价和会议录音？

这次事橙营销采用的办法是：本地文件继续作为日常编辑的原件；文字版本同步到 Codeup，附件原件同步到 OSS；经过审核的少量资料进入百炼，形成可检索的副本；最后通过只读 MCP 入口，限定不同 AI 工具能查询的范围。

这几层名字有些陌生，但各自只做一件事。文章上方的架构图画出了两条路径：本机资料分别同步到 Codeup 和 OSS；经过审核的副本才进入百炼。AI 提问时，则经对应的只读 MCP 进入对应的检索范围。把这两条路径分清楚，后面的操作就容易理解了。你也可以打开完整架构图查看细节。

为什么本地营销知识库已经能用，我还要把它放到云上？

过去，我主要在自己的电脑上维护知识库。文章、方案、课件、录音提炼和公司资料都有文件，AI 可以直接查找原文、比较版本，必要时修改文件。这个方式对我本人很有效，至今仍然是日常工作的主方式。

困难出现在团队使用上。

同事在另一台电脑上使用豆包，无法直接读取我电脑里的文件。我也不希望为了方便查询，就把整个知识库打包发给每个人。里面有已经公开的课程和文章，也有尚未确认的判断、客户信息、报价和原始录音。“把文件交给 AI”和“允许它回答其中的内容”，本来就是两件不同的事。

所以，这次建设先确定了三个目标：

1. 文件要有云端版本，但本地仍然能够正常入库和修改。
2. AI 只能检索明确允许它读取的内容，不能因为文件已经上云，就默认获得整库权限。
3. 不同工具、不同人员可以拥有不同的查询范围，而且测试时能够看见实际来源。

第一步：先盘点资料，再决定什么值得上云、什么能被检索

我们没有先把所有文件扔进一个 AI 平台。

第一轮工作是盘点本地知识库：文字资料有哪些，附件有哪些，大文件有没有重复，哪些内容属于已确认的公开资料，哪些只是内部原件。对大视频，我们先比较文件哈希，确认确实是完全相同的副本，才清理重复文件。

这一步看起来不像“搭 AI 系统”，却决定了后面的系统会不会失控。一个文件上云后，至少还要回答两个问题：它在哪里保存原件？它是否允许进入 AI 的检索范围？

我们把答案分开处理。原件可以受限地保存到云端；能够被 AI 检索的资料，另做一份允许清单。客户资料、内部报价、原始录音和待整理内容，没有因为“已经上传”就自动进入公开检索库。

如果你准备照着做，可以先给资料补上四个最基本的状态：来源、当前版本、负责人、可使用范围。暂时说不清范围的文件，先保存，不急着开放给 AI。

第二步：用 Codeup 管文字版本，用 OSS 管附件原件

云端存储被我们分成了两部分。

Codeup 保存文字和版本。Markdown 文章、目录、规则和必要的结构化文件同步到私有仓库。它适合回答“谁改了这段话”“上周是什么版本”“改错了能否恢复”。Codeup 支持为私有代码库设置不同成员角色，但我们这次还没有完成整个团队按资料类别分仓库、分人员管理。Codeup 官方权限说明

OSS 保存较大的附件原件。PDF、PPT、图片和音视频由私有存储空间保管。我们为附件同步使用了受限身份，并没有把存储空间改成公开访问。OSS 也可以按文件路径范围配置读取、上传等权限。OSS 官方权限说明

这样做以后，我在本机修改知识库的方式基本没有变化：先修改和检查本地文件，再同步文字版本；有新附件时，另外执行附件增量同步。

需要特别记住一句：同步到 Codeup 或 OSS，不等于 AI 已经能够检索，也不等于员工已经获得读取权限。它们首先解决的是原件保管和版本问题。

第三步：只把审核过的资料交给百炼建立检索副本

接下来才轮到百炼。

Codeup 和 OSS 能保存文件，却不会自动替一个远程 AI 回答“市场部的 MDR 和 SDR 有什么区别”。百炼在这里承担检索工作：接收选中的资料，对内容做解析和索引，在有人提问时找出相关段落，再把来源交还给调用方。百炼数据集说明

但百炼不是我们的知识库原件，也没有被授权直接读取整个 OSS 存储空间。我们先从已经确认或公开的资料中选出第一批，再补入相关课程正文。每份进入检索库的文件都有来源和允许范围，未入选的资料不会随着附件同步一起出现。

实际测试还让我们发现了一个很朴素的问题。第一批资料里有课程索引，却没有足够的课程正文。问“MDR 和 SDR 有什么区别”时，系统可能先找到目录；目录告诉你有这一课，却讲不清这一课的内容。后来补入完整的公开课程正文，相关问题才更稳定地命中对应章节。

这说明建立索引并不是点击一次“导入成功”就结束。还要拿读者会问的问题测试：找到的是正文，还是只有标题？引用的来源对不对？如果答案不完整，是模型的问题，还是我们根本没有提供完整资料？

对我本人在本机使用 AI 来说，百炼不是必需的。我仍然可以让 AI 直接阅读、核对和修改原文件。百炼这层主要服务于其他电脑、其他 AI 工具对指定资料的受控查询。

第四步：用 MCP 给 AI 开一扇有边界的门

资料可以被检索之后，还不能直接把百炼的管理权限交给每个使用者。我们在中间增加了一个只读 MCP 服务，部署在云端函数上。

你可以把 MCP 理解为 AI 工具与企业资料之间的一扇门。豆包或 Codex 提出问题，这扇门先检查访问凭证，再把问题送到固定的检索范围；检索结果回来后，它只返回允许展示的正文、文档名称和公开来源。

这里真正重要的不是“MCP”这个缩写，而是门后面的限制：使用者不能通过提问自行指定另一个知识库，MCP 也没有上传、修改或删除原件的工具。阿里云函数计算提供了部署 MCP 服务的方式；至于允许访问什么，仍要由企业自己设计和验证。阿里云函数计算 MCP 文档

我们先做了一个“已确认公开资料”入口，随后又为 SEM 建了范围更窄的入口，只放入六份已经公开的 SEM 资料。这样，同事临时测试 SEM 问题时，专用入口不需要获得整套公开资料，更不会获得内部文件。

以后如果一个人需要两个范围，可以给他两个连接器；也可以由一个入口识别身份，分别开放两个范围。现阶段我们选择较容易检查的独立入口。入口的权限必须由服务端固定，不能靠提示词里写一句“请只看 SEM”。

第五步：测试“能查到什么”，也测试“查不到什么”

很多人测试知识库，只问一个正常问题：“你能找到我们的 SEM 文章吗？”模型答出来，就宣布连接成功。

我们这次把测试分成两面。

正向问题是“B2B 企业如何提高百度推广 ROI”。同事电脑上的豆包能够识别 SEM 检索工具，返回的文档名称和网址都属于已经公开的 SEM 页面。

反向问题故意问“GEO 客户案例、内部报价和会议录音有哪些”。这次返回的仍是 SEM 公开文档，没有出现所问的内部原件。正反向的抽样结果，支持“这个 SEM 专用入口的返回范围符合预期”。

但测试也暴露了另一种情况：AI 工具可能同时拥有它自己的“企业知识”、网页搜索或其他连接器。我们曾看到一段回答列出不在 SEM 允许清单里的资料名称；进一步复测发现，豆包存在一条与专用 MCP 彼此独立的企业知识检索路径。因此，限制 MCP 返回范围，不代表已经限制这个豆包账号能够使用的所有信息来源。对于最初那一次回答，单凭模型文字也不能断定它具体调用了哪一个来源。

从那以后，我不再只问“模型回答得对不对”，还要检查：它实际调用了哪个工具？结果里的文档名称和来源网址是什么？有没有改用另一条知识来源？

如果你要在公司里复制这套办法，至少做四项验收：

1. 正向查询：获准的资料能找到，且命中的是正文而不只是目录。
2. 反向查询：用内部报价、客户资料等不该出现的主题测试返回范围。
3. 来源检查：查看实际调用工具和结果来源，不只相信模型对自身行为的描述。
4. 撤销测试：测试凭证停用后，旧入口是否仍可访问；正式运行还要能分别撤销每个人的权限。

这仍是抽样测试，不是一次完成的系统性安全审计。

团队协作要怎样分工，才不会把更新权和查询权混在一起？

这次试点先跑通了一个最小协作单元：我继续在本机维护原件；审核后选出可公开的资料；同事在自己的 AI 工具里，通过 SEM 专用入口只读查询。这个入口能够回答问题，却不能替同事修改原件或把新文件送入百炼。

如果要把它扩展成长期团队流程，我会明确四种责任，而不是只给每个人发一个连接器：

1. 原件维护者负责修改文字、附件和版本，并说明本次改动是什么。
2. 公开范围审核者判断哪些修改可以进入检索副本，更新允许清单；内部资料不能靠“已经同步上云”自动通过审核。
3. 查询使用者只使用与岗位需要相符的入口，回答重要问题时检查来源，不把 AI 的转述当作未经核验的公司口径。
4. 系统维护者负责同步、索引更新、入口测试和凭证撤销，发现来源越界时能追到是哪一层出了问题。

将来如果不同团队还需要分别更新各自资料，就要进一步划分原件仓库与附件路径的写权限，并把“谁能修改原件”和“谁能查询副本”分别验收。截至本文记录时，这套多人更新权限尚未全面实施；已验证的是公开与 SEM 两个只读查询入口的试点。

这两天做成了什么，还没有做成什么

截至 2026 年 10 月 9 日，文字与附件已有私有云端原件；选定的公开资料和 SEM 资料已形成独立检索范围；我本机的 Codex、豆包以及同事电脑上的豆包，已经分别完成相应入口的实际查询试点。SEM 入口做了正向和反向抽样测试，测试中出现的旧访问凭证也已停用。

仍未完成的事同样明确：团队成员的个人身份和长期权限还没有全面配置；同事正式使用前，仍需在自己的账号上完成验收；豆包内置“企业知识”等其他来源须单独核对；普通 ChatGPT 网页账号的远程连接和员工授权尚未完成端到端测试。现在不能把一次跨工具试验写成“所有员工已按权限使用全部企业知识”。

给基础营销团队的一份上云顺序

如果重新做一次，我会按下面的顺序推进，而不是从“选哪个 AI 平台”开始：

1. 整理原件：明确哪些是当前版本，哪些是附件、历史版本或待确认资料。
2. 标明边界：给资料标出公开、内部通用、严格受限等使用范围；不清楚的先不开放。
3. 保存云端版本：文字进入可追溯的私有版本库，附件进入私有文件存储。
4. 建立允许清单：先选少量已确认资料做试点，不直接导入整库。
5. 建立检索副本：让远程 AI 能按问题找资料，同时保留原件与副本的区别。
6. 设置只读入口：固定每个入口可查询的范围，不把管理权限交给普通使用者。
7. 做正反向测试：同时检验应该命中的问题和不应该返回的资料。
8. 检查所有来源：MCP、平台自带企业知识和其他工具需要分别核对。
9. 规定更新方法：原文修改以后，什么时候同步云端原件、什么时候重新审核并更新检索副本，要有明确负责人。

营销知识库上云，最后得到的不应只是“文件换了一个存放位置”。真正有用的结果，是原件仍可维护，公开范围有依据，AI 知道从哪里找，使用者知道哪些内容不能查，而企业能够核对每一次重要回答的来源。

对我来说，本地知识库仍是日常工作的起点。云端让它能够保管和延伸到更多工具；权限和审核决定这种延伸是否值得信任。

如果你还想了解企业资料如何从原始记录变成可发布的内容，可以接着阅读《如何从知识库淬炼内容？一套适合B2B企业的生产流程》。