知识库一旦缺少“唯一事实来源”，信息越多，决策反而越不可靠。同一份报价可能存在于微信聊天记录、邮件附件和文件夹中，客户资料、交付文档与模板也可能各自维护一份。它们短期看似都能使用，长期却会产生版本冲突：没人知道哪一份是最终版，更新也无法同步，临时协作者还可能接触到不该看到的资料。

“唯一事实来源”不是要求所有工作都在同一个工具里完成，而是明确哪些信息必须以某个知识库中的内容为准。客户正式资料、最终交付物、标准模板和重要决策记录，应当只有一个权威存放位置。协作平台可以承担沟通，邮件可以传输文件，临时文档可以辅助编辑，但这些位置里的副本都不应成为长期依据。

先划定权威边界

知识库至少要区分三类内容：正在处理的临时材料、已经确认的正式资料，以及可复用的标准内容。临时材料允许分散，正式资料必须回写到知识库，标准模板则应独立维护，避免被某个客户项目中的修改版本替代。

比较稳妥的结构是围绕“客户”“项目”“模板”建立最小骨架。客户条目承载背景和沟通上下文，项目条目关联报价、合同与交付物，模板区域存放提案、合同、报价单、交付清单和常见问题。文件类型不是核心分类，业务对象和使用场景才是。

用版本和回写机制避免分叉

每次项目使用模板后，如果进行了调整，应更新标准版本，并在项目记录中标注本次修改。这样，项目经验才能回流为组织资产，而不是只停留在某个客户文件夹里。最终交付文档也应标注版本和日期，避免“最后修改过的文件”被误认为“最终确认的文件”。

权限同样属于事实管理的一部分。外包开发、设计师或临时助理只应访问特定客户或特定文档；如果工具无法提供足够细的权限，就不应把整个知识库直接开放，而应建立受控的协作空间，并在任务结束后清理副本。

判断体系是否成立，可以反问三个问题：客户追问历史细节时，能否快速找到上下文；下一次交付时，能否确认使用的是最新模板；工具停止服务时，客户资料和交付文档能否恢复到可用状态。若答案是否定的，问题通常不在资料数量，而在权威边界尚未建立。