婚庆公司知识库怎么搭建？先让资料进入工作闭环

刘坚伟在个人智能知识库逐字稿里说，Obsidian 适合做长期记忆，Codex 适合执行。两者只用一个都不够：资料库里堆满文件，却没有任务入口，知识不会自己变成方案；AI 能写能改，但读不到公司资料，只能给出通用回答。

放到婚庆公司里，这个分工很清楚。知识库负责保存新人需求、场地限制、报价版本、供应商确认、执行表和复盘。AI 负责在授权范围内做提取、整理、对比和草拟。最终确认仍由策划师、销售或项目负责人完成。存储层不能替执行层做决定，执行层也不能覆盖原件。

不少团队只保存会议摘要，看起来干净，真正改方案时却找不到客户当时怎样表达、谁提出异议、哪些内容只是待确认。摘要是加工结果，不是事实原件。刘坚伟每天用录音保存碎片想法，再同步完整逐字稿，原因就在这里：一份个人简介装不下一个人持续变化的判断，一段总结也装不下整次沟通的语境。

婚礼项目至少要保留三类原件：客户提供的问卷或文件、沟通录音或逐字稿、策划师现场记录。AI 可以从中提取字段，但提取结果必须标记来源并等待人工确认。若把摘要直接当成客户结论，后续设计、报价和执行会沿着一个没有被确认的假设继续走。

“合同一个文件夹、图片一个文件夹、录音一个文件夹”方便行政归档，却不方便完成一场婚礼。真正工作时，我们需要看到的是某一对新人的完整上下文：需求、场地、预算、参考图、方案、修改记录、供应商和当天执行。

6 月 17 日的项目课程把项目定义为专属工作空间，而不只是文件夹。这个原则可以直接迁移到婚庆公司：项目名称要具体，边界要清楚，所有资料都要能回答“属于哪场婚礼、哪一阶段、由谁负责”。如果同一份供应商资料要复用，可以保留公共档案，再在项目中记录本次引用的版本，避免改了公共文件却不知道哪些旧项目受影响。

刘坚伟在录音里有一个很重的判断：知识不做输出，就只是放在软件里的文件。婚庆公司更容易验证这句话。一场复盘里写了“进场时间不够”，下一个项目的场地确认表却没有增加进场窗口，这条知识等于没有被使用。

知识库需要给每类资料安排出口。客户原话进入需求确认；场地图进入设计边界；报价变更进入版本对比；供应商反馈进入执行清单；课堂录音可以进入员工培训或内容生产。AI 的作用是缩短整理时间，不是替团队决定出口。没有明确输出任务的资料，先不要急着做复杂自动化。

婚礼工作里有许多不能静默改写的内容：客户确认、报价、场地限制、施工要求、人员时间和安全边界。AI 草拟一版方案后，团队要知道它读了哪些资料、依据哪个版本、谁做了修改、谁最终批准。

刘坚伟用原始录音校准文案声音，又用专门审校减少 AI 腔，说明“生成出来”离“可以使用”还有一道门。对公司内部知识库，这道门更严格。涉及客户承诺、费用和现场执行的输出，不允许只看文字是否顺畅；要逐项回到原件核对。旧版本不能覆盖删除，因为后续还要解释一次变更是从哪里发生的。

刘坚伟的知识库工作流会把拆解结果、二创结果和修改继续回流到 Obsidian。这样下一次调用时，AI 读到的不只是最初资料，也能读到后来怎样使用、哪里被纠正、最终采用了什么版本。

婚庆公司也需要同样的回写。婚礼结束后，把现场照片与效果图差异、物料增减、供应商表现、客户反馈和预算偏差写回项目；再把可复用的规则提炼到公司公共知识库。项目事实与公共方法要分开：前者保留完整上下文，后者经过负责人审核后才供其他项目调用。否则一次特殊情况很容易被系统误当成长期规则。