2.2 COS 存储规划：知识原文的集中与管理

盘点完知识来源，下一个问题是：这些原文放哪？之前公司的文档东一份西一份，客服姐姐的电脑里存着一版 FAQ，我的电脑里存着另一版手册，运营的微信里还躺着好几份帮助页截图，谁也不知道哪个是新的。要搭知识库，第一步是让所有原文有一个唯一权威的落脚点。我们选了对象存储 COS：按量计费、容量不用提前规划，配合平台的知识库节点可以直接取用。如果你在纠结本地存还是云端存，可以看看NAS 家庭服务器那一本的对比思路，我们小团队最终选了云端，理由就一条——不想自己运维硬盘。

存储桶目录设计

我没有把所有文件一股脑扔进一个桶了事，而是先规划了目录结构。原则是按业务线、文档类型、版本三级分目录，这样后续取用、清理和重新建索引都很省事。目录结构这东西，前期乱定十分钟，后期每次重建索引都要骂一句。另外桶的数量也要克制：最开始我想每个业务线建一个桶，后来意识到桶越多权限越难统一管，最后只用了一个桶加多级目录，权限收窄靠目录级控制实现。

一个桶名 kb-docs 装下所有内容，权限的差异全靠目录级控制实现。

规划目录这件事看似多此一举，但后面无数次重新建索引、批量替换内容、按目录回收权限的时候，我都很庆幸当初花了半小时画这张表。命名上我用全小写加连字符，避免中文路径在某些脚本里出编码问题，这点吃过亏：最早用中文命名目录，一次批量重传时脚本编码没处理对，整个目录的文件名全乱码，只好手工改回来。另外专门留了一个 internal 目录，放那些还没确认准确性的草稿文档，和正式知识库物理隔开，防止测试时被当成正式知识喂给 AI。版本目录里老版本手册不删是有原因的：一旦客服确认某版本信息出了错，我们可以快速回滚到上个版本重建索引，知识库也该有版本管理思维。

这里还有个反面教材值得讲。最初我的目录比现在复杂得多：按客户名称开目录，每个大客户一个文件夹，知识库跟着客户走。上线一周就出问题了——客户会流失、会合并、会改名，目录跟着实体走永远在变动，而知识本身是相对稳定的。更糟的是同一个问题在不同客户目录下有不同答案，检索回来互相打架。痛定思痛后改成按业务线加文档类型走，客户这个维度完全不进知识库目录。这个原则我后来一直坚持：知识库的目录要按内容自身的性质组织，而不是按使用它的业务实体组织，前者稳定，后者易变。

权限与生命周期

权限是知识库存储最容易出事的地方。我们的桶一律设为私有读写，平台取用通过临时密钥授权，绝不开公共读。有人觉得开公共读方便测试，这是给自己埋雷——知识原文里但凡混进一条客户信息，就是一次数据事故。同时给不同目录配了生命周期规则，该转存的转存，该清理的清理，既控制成本也控制风险。规则不用一次配全，先覆盖两类：问答类高频更新的内容保持标准存储，历史归档的老版本自动转低频，跑两个月看账单再微调。

这张表的灵魂就一条：任何能读到知识库的身份，都只拿到它完成工作所需的最小范围。平台读原文不需要写权限，脚本传文件不需要读历史归档，客服看归档更不需要进桶。

这里多解释两句临时密钥。平台的知识库节点读取原文时，需要访问存储桶的凭证。直接把账号的永久密钥填进去是最偷懒也最危险的做法——一旦平台侧或日志里泄露，整个桶都暴露。正确做法是生成只允许读、且限定到具体目录的临时密钥，哪怕泄露了也只影响一个子目录。生命周期规则则解决另一头：FAQ 每月快照、手册每版本归档，一年下来桶里会堆上千个文件，历史版本自动转低频存储能省下不少钱，那些明确不再使用的草稿目录可以直接设成自动清理。这些配置听起来繁琐，但都是一次性的活儿，配完之后半年没再动过，而它们每天都在默默工作。

存储成本单独说一句。我们第一版知识库总文件量不到两百兆，存储费用每个月几毛钱，完全可以忽略。真正贵的是检索和大模型调用，那部分在第五篇成本复盘里细算。这里提一句是想给小团队打个气：别被存储成本吓住，知识库这件事的门槛从来不在钱上，在于有没有人把脏活干完。

上传管理的三种方式

文件不多的时候怎么传都行，但要长期维护一个持续更新的知识库，上传方式值得选一下。我对比了三种常用做法：

我们最后的组合是：初始化那批文件用网页上传，客服每周导出的工单和 FAQ 由我写了个定时脚本走 API 自动传，客户端工具装在我自己机器上用来临时改文件。脚本上传有个额外好处：可以在传之前自动跑一遍命名检查和脱敏校验，不合规的文件直接拦下来，流程本身成了最后一道安全网。开发这个脚本我只花了大半天，但它省下的返工时间难以估量，而且从此上传这个动作不再依赖我的记忆，这比任何规范文档都好使。本地文件改动后自动同步这点也减少了一个常见错误：改完忘了传，知识库里还是旧版，自己却以为已经更新了。操作细节见对象存储快速入门文档，里面有客户端和 API 的具体用法。顺手提醒一句，桶名和目录结构一旦定下来并在平台里配好了索引，就尽量别频繁改，改一次就要重建一次索引，还得重新验证一遍知识库。

踩坑：误传含客户信息的工单原文

这一节必须记一个真事。配置阶段我图省事，直接把客服刚导出的一份 Excel 工单原文传进了桶里，打算先测通流程再补脱敏。第二天验证权限时才惊出一身冷汗——那份文件里带着十几条未脱敏的客户手机号和公司名，而当时桶的临时密钥权限配得偏大，任何能拿到该密钥的应用都能读到全部内容。事后复盘，问题出在我把测试流程和生产存储混在了一起：图省事用的桶，就是后面正式要给智能体读的那个桶。

处理顺序是这样的：先删除文件，靠操作日志确认这段时间没有被外部访问，再把那份工单重新跑脱敏流程后上传，最后把临时密钥的权限范围从整个桶收窄到具体目录。这件事之后我立了条铁规矩：任何文件必须脱敏完才允许落盘，桶权限永远默认最小，脱敏前置到上传之前而不是事后补。想做知识库的同行，这一步千万别省——数据合规出一次事，前面所有功夫都白费。

事故之后我整理了一份上传前必查的脱敏检查清单，四条，贴在显示器旁边，任何文件落盘前逐条对：

• 第一查人物：姓名、手机号、邮箱、身份证号有没有遗漏的占位符替换。
• 第二查企业：客户公司名是否已统一替换成某企业。
• 第三查订单：订单号、合同号是否已截断或脱敏。
• 第四查备注：工单里的客服内部备注、私聊内容是否整体剔除。

顺带一个相关的小教训：共享网盘和存储桶别混用。出事之后我发现公司还有个旧习惯，客服喜欢把导出的 Excel 直接丢共享网盘给大家传看，那个盘谁都能进。我把知识原文全部迁到 COS 之后，顺带把共享网盘里的客户相关文件也清了一遍，该删的删，该脱敏的脱敏。存储方案换了，旧文件的散落问题不解决，等于只修了新房子没修地基。

更要命的是这类事故往往没有报警。工单原文静静躺在桶里，既不影响检索也不影响回答，直到某天有人翻日志或者权限审计才会发现。所以我把存储配上了云监控的异常访问告警，有人用密钥读了不该读的目录就通知我。安全这事儿指望不了运气，只能靠流程兜底。后来我们形成了一个固定动作：每月一次存储巡检，内容和权限两头一起看。巡检本身不到二十分钟，但它是唯一能让我晚上睡踏实的常规操作。更多服务器和存储上线后的运维排查经验，可以翻我写的腾讯云五件套实战。

本节小结

照着下面五条做，知识库的存储层就稳了：其一，一个桶加多级目录，别开一堆桶；其二，私有读写加临时密钥，权限收到目录级；其三，草稿和正式内容物理隔离；其四，上传走自动化脚本并内置校验；其五，定期巡检权限和内容。地基稳了，后面所有迭代都是稳的。

延伸阅读

• 本地知识库与云端存储的方案对比，见NAS 家庭服务器。
• 存储配上业务后端之后的日常运维排查，见服务器常见问题。
• 原文集齐之后怎么切片喂给 AI，见下一节文档解析与切片。