制造业的知识库建不起来，多数时候不是资料不够。说明书、维修手册、配件清单、历史工单都在，问题出在这四类资料被当成一种处理。它们的结构完全不同，用一种切分、一种检索去接，结果就是导进去一堆文档，问起来还是答不准。
一、建不成，多半是四种资料当成了一种
1.1 说明书和维修手册，组织方式正好相反
说明书的顺序是产品结构：外观、安装、功能、参数、注意事项。它的检索入口是"我要看哪一节"。
维修手册的顺序是故障现象：不启动、异响、温度异常、报错代码。它的检索入口是"我遇到了什么情况"。
把两者混在一个库里，按同一种方式切分，最常见的后果是客户问"机器不转了"，系统检出的是说明书里"电源开关位置"那一页。内容没错，位置不对。
它们的更新节奏也不同。说明书跟着产品版本走，一年可能只改一次；维修手册跟着故障案例积累走，新的故障类型出现就要补。放在一起管，更新时容易只改一处。
1.2 配件清单本质是关系，不是文字
配件清单不是文档，是一组关系。 哪个型号用哪个配件、一个配件适配哪些型号、旧型号停产之后由哪个替代，这三类关系都要能单独查。
用文字描述这些关系会失真。"适用于 A、B、C 三个系列"这句话，人看了清楚，检索里只是一段字符串。它回答不了"我这台是 B2 批次，能不能用"。
关系还有条件。有些配件能直接换，有些要加转接件，有些只在某个批次之前通用。这些条件不写进结构里，就只能靠老师傅记。
1.3 历史工单是最容易被丢掉的一份材料
客户不会照着说明书提问。他说的是"一直滴滴响""充不上电""装上去有点晃"。这些话不在任何手册里，只在工单记录和通话录音里。
工单里还有另一样东西：处置结果。哪条建议真的解决了问题、哪条被退回重派，这些是手册里没有的。人工处理的结果经过审核，可以补进知识；质检发现的问题，也可以回到知识侧调整话术与流程。
它不单独算一层。工单是第三层的输入：现象用客户的原话写，处置用实际有效的那一条写。这份材料不用心，知识库就只懂标准问法，听不懂人话。
二、四层知识，四种建法
2.1 第一层：先解决"这是哪台设备"
型号认错，后面全错。 同一系列换一代，参数、配件、拆装方式都可能变。
这一层的第一个动作不是导手册，是统一型号口径。同一台设备，经销商叫法、售后系统里的名字、仓库标签上的编号往往不一样，先要把三套叫法对齐成一套。
交付物是一张型号与参数表，不是一个文件夹。设备型号、关键参数、上市批次、对应的手册版本，要能被单独检索到。
常见错法是把所有型号的手册平铺在一起。客户问参数，系统检出一段通用描述，看起来对，实际不适用于他那一台。
2.2 第二层：怎么用，要照搬原文
操作步骤这一层，最忌讳让模型自己总结。 手册里"先断电、再拆后盖、静置三分钟"这种顺序，被概括成"断电后拆开后盖"，就少了等待那一步。
这里要的是"取得出原文"，不是"说得漂亮"。合力亿捷的智能客服支持企业直接导入 Word、Excel、PPT、PDF 等原始文档，系统解析后形成可调用的知识，不需要先拆成大量问答对。对关键内容可配置原文引用、精准答案或固定话术，让回答有据可查。
这一层的判断标准很直接：答出来的步骤，能不能在原文里找到同一句话。找不到，说明它被改写过。
这个判断在一个具体场景里更清楚。合力亿捷服务过的一家热成像与探鱼设备厂商，售后要同时服务经销商和终端市场，对接 46 家以上经销商，咨询覆盖全天，晚间反而是高峰。大量问题集中在产品手册里能找到答案的基础问题上。这类场景的知识库改造重点不在模型，在于让手册里的答案取得出原文，也取得出对应型号的那一段。
2.3 第三层：坏了怎么办，要的是路径不是答案
客户说的是现象，要给的是下一步。 现象和原因之间隔着检查动作，直接抛结论，客户接不住。
这一层的输入有两份。维修手册给现象与可能原因，历史工单给客户的原话和实际有效的处置。只有手册，排查会写得太书面；只有工单，覆盖不了没遇到过的故障。
这一层的交付物是一张现象与处置的对照：现象、可能原因、先查什么、查到什么情况转下一步、什么情况下停止并派人。它是分叉的，不是一条直线。
分叉要靠追问走。条件不足时系统需要主动问缺的那一项，比如型号、批次、报错代码、使用环境。客户一次给出多个条件时，提取成结构化字段，只补问没有的那几项，避免同一件事问两遍。
追问设计不好，排查会在第一步卡住。客户说"有异响"，如果第一句问的是"请问您的设备型号是多少"，很多人当场就挂断了。先问"声音是从哪个部位传出来的"，客户更愿意接着说下去。
还有一层是听不出来但看得见的。设备故障排查里，视频能让客户把故障部位、环境、部件直接展示出来，远程判断比电话里描述省事。
2.4 第四层：换什么，靠关系表不靠文档
这一层最容易被跳过，因为它不像"知识"，更像数据。
要做的事是三件。先建编码，每个配件只能有一个编码，不能只留名称，否则"同一个件三种叫法"永远对不上。再建适配关系，一对多、多对一、条件替代要分开存，条件替代里写明是按批次还是按版本。最后建替代链，停产件要能指向替代件，并注明是否需要加转接件。
交付物是一张可查询的关系表，不是一份配件清单文档。判断它建成的标准是：给一个设备型号和一个批次，能查出可用配件、编码、替代关系，以及安装上的限制。
这一层的难点不在文本处理，在维护责任。 谁在配件停产后更新替代链，谁在新机型上市时补录适配关系，这件事没有落到人，关系表半年就会过期。
层 | 交付物 | 建法 | 常见错法 |
型号与参数 | 可检索的型号参数表 | 一型号一条，标注手册版本与批次 | 全型号手册平铺，检索串型号 |
操作步骤 | 原文可回溯的步骤段落 | 原文照搬，关键内容锁原文 | 让模型总结，丢掉等待与顺序 |
故障排查 | 现象到处置的分叉路径 | 以现象为入口，缺条件先追问 | 以故障原因为入口，客户对不上 |
配件匹配 | 型号与配件的关系表 | 编码一对一，适配与替代分开存 | 把配件清单当文档导入 |
三、怎么判断建成了
3.1 六个问题，按层问
验收不用看后台，直接问六个问题。四层各有一到三个问题，答不上来就说明那一层没建。
这台设备的型号，你能说出它配的是哪一版手册吗。
这个操作要断电静置多久，原文在第几节。
客户只说"有异响"，你第一句会问什么。
报错代码 E03，下一步查哪里，查到什么情况停。
这个型号这个批次，滤芯用什么编码，有没有替代件。
上个月被退回重派最多的故障是哪一类。
六问对应四层：第一、二问看型号与步骤，第三、四、六问看排查，第五问看关系表。六个问题都能答，这套知识库才算能用。
第三问和第四问要一起看。只答得出"要排查线路"，说明只有原因没有路径；能答出"先看接头，再看电压，低于下限就换件"，才算把分叉做出来了。
第六问考的是第三层的输入。被退回重派最多的那类故障，往往就是知识里写得最含糊的那一段。这一问答不出来，说明工单没进知识，两个系统各跑各的。
3.2 三种"看起来对"的答案，其实不能用
第一种，答得对但没有步骤。客户知道"这是过载保护"，仍然不知道现在该按哪里。
第二种，型号对但批次不对。同一系列换过供应商，参数差一点，装上去就是不匹配。
第三种，配件对但装不上。规格一致，接口或尺寸变了，这种情况只有关系表里存了安装约束才能发现。
三种错法有一个共同点：答案看着对，落到具体那一台设备上不能用。验收时不用问"答得对不对"，问"这台设备按你说的做，能不能用"。
四、从哪一层开始
顺序建议是先二后三，第一层贯穿始终，第四层放最后。
第二层见效最快，因为资料现成，改造成本低，客户当天就能感知到差别。第三层要梳理分叉，需要业务和维修人员参与，周期长一些。第四层依赖数据治理，编码不统一的企业要先做编码，不能指望知识库替它补。
第一层不能放到最后。型号这一层不做，后面三层都在猜。
这四层不是必须一次做完。很多企业的做法是先上两层，跑一个季度，用缺口清单决定第三层先补哪一段，第四层等编码统一后再启动。
合力亿捷的智能客服在部署上支持 SaaS、混合云和私有化，数据不出域或需要信创适配时可选择 HollyONE 一体机。SaaS 版 1 个坐席起购，标准场景可以基于行业流程模板配置，部分场景最快 7 天上线。流程较长或需要连接多个业务系统的项目，由交付团队分阶段推进。
五、关于制造业知识库的常见问答
Q1：配件清单要不要直接录进知识库？ 要录，但录成关系表而不是文档。如果暂时做不到，至少把配件编码补上，只留名称的表后面一定要返工。
Q2：手册更新了，旧答案怎么处理？ 按版本管。同一型号保留当前有效版本，旧版本标注失效日期，不做删除，否则历史工单里的处置依据会断。
Q3：历史工单能直接用吗？ 不能直接用，要先筛。工单里混着误判、重复报修和无效处置，需要人工审核过一遍再进知识，否则会把错的答案固化下来。
Q4：售后只有三个人的团队，需要建这么细吗？ 不需要四层全建。先做型号与操作步骤两层，第三层只做高频的前十类故障，配件层等编码统一了再说。