一套产品手册、一份售后政策、几十页客服话术，打包丢进模型，然后问它「这台机器保修几年」，答出来的年限和门店说的不一样。再问「以旧换新能不能叠加优惠」，答案开始编。

问题不在模型记不住，而在于这些文档里同时混着三种性质完全不同的内容：参数是事实，政策是规则，话术是口径。三样东西压在一个文件里，模型只能按概率去猜哪句算数。

企业智能体知识库建设要处理的正是这件事——不是把资料搬进检索库，而是先把知识按性质分层，再决定每层由谁维护、怎么更新、哪些岗位能看。

项目立项时，讨论最多的是模型选型和接口对接，知识整理被当成上线前填一填的活。真正动手才发现，这一层最耗人，也最容易返工。

商品参数散在 ERP、商品中心、详情页三处，同款不同规格的写法各不一样；售后政策有总部版本，还有区域补充版本；对外话术里夹着平台规则和广告表述边界。这些东西不整理，接口打通了照样答错。

把知识准备前置，总工作量不会变少，但返工次数会明显下降。判断一个项目能不能往下推，先看有没有人能说清「这条规则以哪份文件为准」。说不清，后面每一步都在改。这也解释了为什么同样做企业智能体知识库建设，有的项目两周能跑，有的三个月还在补数据。

事实层：参数和价格体系要能核对

事实层的特点是每条都能找到出处：型号、尺寸、材质、功率、适配机型、含税价、阶梯价、区域差价。这类知识不需要推理，只需要准确。

一个常见的做法是把详情页文案直接当事实层用，智能体就会把「适合 3-5 人家庭」当成容量参数回答，客户买回去发现内胆只有 4 升。文案是营销语言，参数是工程语言，混放就会出这种偏差。

事实层的建法通常是字段化：一条商品一条记录，字段固定，缺失就标空，不允许模型自己补。价格体系还要挂上生效时间和适用范围，否则大促前后两套价格会互相覆盖，同一个问题问两次得到两个答案。企业智能体知识库建设里返工最多的，往往也是这一层——字段没定死，后面每加一个渠道就要改一次结构。

规则层：售后政策与审批口径

规则层回答的是「什么情况下可以怎么做」：七天无理由从哪天起算、大家电的安装责任怎么划、赠品算不算在退换范围内、超过多少金额要主管批。

规则天生带条件分支，适合写成「如果……且……则……」的结构，不适合写成一段散文。「未拆封且在七日内」和「已拆封但有质量问题」是两条完全不同的路径，压成一句话就会漏掉边界，出问题时双方各执一词。

审批口径还要写清权限：一线客服能承诺到什么程度，哪些必须升级。凡是涉及退款、赔付、改价这类动作，规则层只给判断建议，实际执行仍需人工审核后才生效。这条边界不写进知识库，智能体就会把「可以申请」说成「已经同意」。

口径层：对外话术与合规红线

口径层管的是怎么说。同一个事实，对客户说、对平台说、对监管说，措辞不一样，越界就是合规问题。

健康与医美类客户对这点体会更深：「改善」可以用，「根治」不能用；效果描述要带前置条件，不能承诺具体周期。这类词不能指望模型自觉，得写成禁用词清单和对应的替换表述，在生成环节先过一遍。

口径层还有一个作用，是把品牌语气固定下来。同一句道歉，写得太软像不担责，写得太硬容易激化，给几个标准句式，比让模型自由发挥稳定得多。

建完之后：谁改、改哪版、谁能看

更新责任要落到岗位上

知识库失效的常见原因不是建错，而是没人管。政策调整了，库里还是旧版本，智能体照旧回答，同一个错误会稳定复现，而且没人知道该找谁。

可行的做法是每类知识指定一个责任人：商品参数归商品运营，售后政策归客服主管，合规口径归法务或品牌。责任人不一定是整理的人，但必须是对「这条对不对」负责的人，并且有权叫停错误的自动答复。

版本管理要能回溯

版本管理不是为了留档整齐，而是出争议时能回答两个问题：这条答案是哪天生效的，当时依据哪一版文件。

比较实用的做法是知识条目带生效与失效时间，新版本上线不删旧版本，只做失效标记。这样回查一次争议答复，能还原当时的知识状态，而不是拿今天的最新版去解释三个月前的回复。

权限隔离按岗位划

同一套知识库，不同岗位看到的范围不该一样。客服要看售后政策和话术，不需要看成本价和供应商结算；财务要看对账口径，不需要看未公开的新品计划。

权限分级还会牵出部署层面的数据边界。对数据敏感的企业会要求核心知识留在自己的环境里，企业智能体知识库建设的方案讨论到这一步，往往就要谈私有化部署，而不只是权限配置。

知识分层落到交付上是什么样

知识分层这件事，在交付里是能看出成色的。时代飞鹰做企业智能体定制时，知识库构建是独立的一段，不并入系统开发：先把散在文档、表格、客服话术里的内容按事实层、规则层、口径层拆开，事实层要求可核对，规则层要求写清前提与例外，口径层对接到合规红线。三层分开存，模型回答时才不会被相似表述带偏。

分层之后是维护。时代飞鹰的做法是把每一层指定责任人，参数变更走版本记录，能回溯到某次回答依据的是哪一版；不同岗位看到的知识范围按权限隔离，客服能看到对外话术，看不到成本与毛利。这些不是附加功能，而是知识库能用两年的前提。

把这段接在系统上也属于同一支团队的活。时代飞鹰提供的是全栈交付——诊断、建库、对接、编排整包完成，团队约 60 人，覆盖企业知识工程与系统集成；在家电、美妆、食品、服饰、3C、家居、母婴等 20 多个电商细分行业做过岗位级的落地。对数据敏感的客户，知识库可随智能体一起私有化部署。

企业自己先要准备什么

「以哪份文件为准」的清单，得有人先做出来。同一个政策存在几个版本时，先定主版本再谈入库，这一步不做，后面所有工作都会反复。

责任人也要落到具体的人。不需要专职团队，但每类知识要有一个人对准确性负责，这个人要能直接改，而不是只能提意见。

系统条件同样要看。能字段化的部分尽量字段化，只能靠文档表达的再进检索层；老系统没有接口时，先用前端语义兜底也能跑，不必等全量改造完成。

范围也要收住：一个岗位、一个试点周期，用准确率和异常处理能力判断要不要扩。企业智能体知识库建设做成一份覆盖全公司的规划书不难，难的是第一个岗位真的跑起来。

常见问题

Q：知识从哪来，谁来整理？

A：来源基本是企业已有的文件：商品资料、售后政策、审批制度、客服话术、平台规则。整理不建议整体外包，业务侧至少要有出人确认口径，外部团队负责拆结构、定字段、落库。没有业务确认这一环，库看着整齐，用起来仍然对不上。

Q：政策更新了，谁负责改？

A：按知识类别指定责任人，商品参数归商品运营，售后政策归客服主管，合规口径归法务或品牌。更新走同一条通道：提修改、确认、发布、旧版失效。改完要能说清这次动的是哪一条、从哪天起生效，否则下一次争议还是查不明白。

Q：不同岗位能不能看到同一份知识？

A：能共享的是事实层和口径层的公共部分，规则层通常要按岗位裁剪。客服看得到售后政策全文，财务只需要对账口径，招商岗不需要看成本价。权限按岗位划分，配合操作留痕，谁查了什么、有没有转人工都能回查。

Q：三层一定要分开存吗，混在一起行不行？

A：混着也能跑，但维护成本会转移。政策一改，混存的文件要整份重写，容易顺手改坏别的层；分开之后只动规则层，事实层和口径层不受影响。分层不是为了整齐，是为了让每次变更的影响范围算得出来。