婚庆公司知识库怎么搭：不是堆文件，先跑通六步业务闭环

“把公司资料都放进去”不是目标。销售要找客户需求和跟进记录，策划要找问卷、场地限制和预算判断，设计要找已经确认的视觉方向，执行要找尺寸、物料、人员与时间。不同任务需要的资料和答案不一样。

刘坚伟在 AI 直播里提醒，使用聊天式 AI 时要带着明确目标和自己的思路，而不是无目的闲聊。企业知识库也是同样道理。先选一个高频任务，例如把客户咨询整理成待确认清单，或者把已确认方案转成执行表。目标越具体，越容易判断资料是否够、输出是否能用。

第一版只要跑通一个真实项目，不必一次收完公司十年的文件。选定任务后，写清输入是什么、负责人是谁、输出给谁、完成标准是什么。

婚礼项目中的问卷、语音、图片、报价和客户确认都可能成为后续判断依据。核心方法库明确要求，原始资料要保留，自动提取结果必须经过确认，不能静默覆盖人工录入。

刘坚伟用 TicNote 记录碎片化表达，再同步到 Obsidian。这个动作有两个价值：一是留下真实说法，二是让后续整理能回到原文核对。如果只保存 AI 总结，转写错误、时间变化和语气边界会一起被抹掉。

因此，一条知识至少保留原件、整理稿和确认状态。原件只读，整理稿允许修订，确认状态说明它能不能进入报价、课程或客户交付。AI 输出永远不能反过来冒充原始事实。

文件能搜到，不等于可以直接使用。婚礼业务里，旧价格、旧课时、历史供应商安排和机器转写内容，都可能在今天失效。没有来源和时间，员工会把一个看似完整的答案当成当前口径。

知识条目至少应标注：来自哪次录音或项目，记录日期，属于哪个客户或课程，谁确认过，以及事实等级。可以分成当前已核验、第一方当前口径、历史待确认和不可使用。涉及金额、结果承诺和人物经历时，未核验内容不得自动进入对外文案。

这一步看起来比“让 AI 直接回答”慢，却能减少更贵的错误。婚庆公司知识库的价值不是回答得快，而是在需要承担责任时知道答案从哪里来。

Obsidian负责长期保存，Codex一类 Agent 负责读取、整理和执行，这是刘坚伟在个人知识库录音里的分工。但企业里不能让 Agent 默认读取全部资料，更不能让一次对话直接改写原件、报价或客户确认。

可以按任务授权：内容助理只能读已批准的课堂与品牌资料；项目助理只读当前婚礼的问卷、图片和确认记录；执行助理可以生成清单，但发布、报价和对外发送必须经过负责人复核。员工离开项目后，对应权限也要停止。

权限边界解决的是“能不能读”，执行门禁解决的是“能不能做”。两者都明确，AI 才是助理；只有一个万能入口，它就会把不同客户、不同版本和不同责任混在一起。

刘坚伟没有把录音同步到 Obsidian 就结束。他让工具拆解内容、做二次创作，再把拆解过程和结果回流到知识库。这使一次输入能留下过程，也让下次调用看到已经验证过的成果。

婚庆公司可以把同样的闭环放进业务：客户问卷进入项目，策划师确认需求；知识库生成待确认问题和方案骨架；团队执行后记录差错；复盘再更新模板。没有回流，知识库只会越来越旧，员工每次仍从头判断。

回流时不要覆盖历史。新结论要带版本和生效时间，旧版本保留适用范围。这样才能解释某次报价、设计或执行为什么采用当时的判断。

知识库建完后，至少拿三个真实问题测试：能否找到正确来源，能否给出下一步动作，能否指出哪些信息仍需人工确认。只给一段流畅答案，没有来源或边界，不能算通过。

还要做反向检查。换一个客户、删掉一份关键资料、放入一条旧口径，看系统会不会混用信息；让新员工按输出完成任务，看是否还需要口头补充大量细节。问题出在哪里，就回到字段、权限、模板或验收标准修改。

验收记录本身也要回到知识库。保留测试问题、引用到的原件、人工修改和最终决定，下一次改规则时才知道它解决了什么，也能发现同一种错误是否再次出现。

婚庆公司知识库不是文件仓库，也不是一个什么都能问的聊天框。它要把真实业务资料变成可追溯、可执行、可复盘的工作链。刘坚伟在完美一刻婚礼培训学院的 AI 实操训练中，把个人知识沉淀、Agent 执行和业务验收放在一起。