一、制造业头部集团：知识散在图纸、车间和老师傅的记事本里
（一）项目起点：一个没人能当场回答的问题
某制造业头部集团的会议室里，有过一场略显尴尬的讨论。新来的设备工程师提了一个很具体的问题：某条产线上的液压系统在低温环境下启动时抖动，以前是怎么处理的。会议室里坐着设备、工艺和信息中心的人，没人能当场答上来。答案其实是有的，只是散在好几个地方，老技师手写的维修记录本、早年的工艺变更单附件、还有某个工作群里的聊天记录。那次会之后，集团管理层决定认真做一件事：企业AI知识库。
这不是突然冒出来的需求。集团规模扩大后，新员工进来的速度比老师傅带人的速度快，很多问题被反复问，答案每次都要重新找一遍。信息化部门早年做过文档管理系统，文件按部门和年份归档，能用，但不好用，员工要的是答案，系统给的是文件夹。内部搜索也上过，关键词对不上就搜不出来，车间里管它叫另一个找不到东西的地方。
后来他们找到了数商云，谈的是知识库智能体开发这件事。需要说明的是，那时候集团内部对智能体还没有统一理解，有人以为是一个能自动写报告的机器人，有人以为是升级版的搜索框。项目真正开始之后大家才慢慢明白，难点不在模型，而在那些原本没人愿意碰的脏活：哪些知识该进库、谁说了算、答错了谁负责。
（二）跨部门坐下来，先吵的是“什么算知识”
启动会上，信息中心的想法很直接，把现有文档全部灌进去，越快越好。业务部门当场反对。设备部给的理由很实在，车间里真正值钱的东西，很多根本不在文档里，而是老技师脑子里那套听声音就知道哪里不对劲的判断。工艺部担心另一件事，如果把过期的工艺变更单也塞进去，智能问答给出的答案可能是错的，后果比没有答案更严重。
争论的结果是成立一个不大的工作组，设备部、工艺部、质量部和信息中心各出人，返聘的老技师也被拉进了评审。他们做的头一件事不是技术选型，而是圈范围。先挑出被反复问到的问题，设备故障处理、来料异常判定、工艺参数变更说明、售后返修记录，范围之外的先不动。
圈完范围，又撞上更麻烦的问题：知识怎么组织。原来的目录按部门和文件类型分，找东西的人必须先知道这属于哪个部门。工作组的做法是把它推翻，改成按问题来组织。同一个问题下面挂手册节选、维修记录、变更单、现场照片，还有一段口述录音，谁提供的不重要，能解决问题才重要。这一步花的时间比预想的长，后来回头看，它基本决定了整个企业知识库智能体好不好用。
（三）知识库智能体开发中几次不情愿的返工
1. 让智能问答听懂车间里的说法
试运行没几天就有人投诉。车间里的叫法和手册完全不一样，发闷、嗡一下、跳闸这类词在手册里查不到，智能问答总把一整段标准条款贴出来，老师傅看了直摇头。项目组做了一件很土但有用的事，让一线员工把平时怎么问问题写下来，整理成一份对照关系，把车间叫法和标准术语接起来。同时改了提问引导，如果问题太含糊，智能体先反问一句，而不是硬猜。调整之后，一句那台老压机发闷也能指向对应的故障条目。
2. 权限这件事，不能等回答的时候再判断
工艺参数、成本数据，还有涉及人员的记录，不能人人可见。讨论过的方案是在回答环节再判断权限，被安全部门否掉，内容一旦进了检索范围，风险就已经存在了。调整之后改成在入库环节就给每条知识打上标记，检索时按身份过滤。碰到没权限的内容，智能体不假装不知道，而是明确说这属于受限范围，并给出申请路径。这个改动让上线时间往后推了，但没有一个业务部门反对。
3. 让愿意讲经验的人被看见
老技师的抵触非常真实，把经验交出去，自己的价值在哪里。项目组没有靠开会说服，而是做了几件不起眼的事。一件是把答错的记录整理成纠错任务，派回给对应岗位的人，改对了在系统里署名。另一件是在部门例会上把被采纳的答案拿出来讲一句。过了一阵，主动去改答案的人多了起来。有位老技师后来自己录了几段口述，说这东西比带徒弟讲一遍省事。
（四）上线之后，变化落在具体的人身上
最直接的变化发生在新员工身上。以前遇到问题先找人问，问不到就搁着；现在先在智能问答里试一遍，确实不确定再去问。老师傅被打断的次数少了，这一点他们自己最先感觉到。信息中心的角色也变了，从被叫去找文件的人变成维护知识入口的人，日常要看的不是文件有没有归档，而是哪些问题一直没人答好。
项目结束后，集团的信息化团队接手了后续维护。数商云在交付时把智能体开发平台和知识库搭建的工具链都留了下来，源码交付意味着改一个答案、加一类知识不需要每次都走外部支持流程。这个安排在采购评审里不算加分项，用起来之后才显出价值。
二、能源行业头部企业：安全规程这类知识，宁可说“不确定”
（一）现场要的是“此刻该做什么”
某能源行业头部企业的巡检人员分布很散，很多人常年在站点上，手里是防爆终端或者值班室的电脑。他们不缺规程，缺的是在现场把规程翻到对的那一页。管理层最初想先做一个内部智能客服，把报销、培训报名、宿舍安排这类问题接住，技术团队则希望直接碰专业场景。两边后来并到了一起，员工不管问什么都走同一个入口，后面接的是不同的知识范围。
这种安排听起来简单，实际考验的是知识边界怎么划。行政类的问题容错高，答得不够准还能补救；规程类的问题不一样。安全监督部门的态度很明确，涉及作业票、动火、有限空间这些内容，答案错一个字都不行。
（二）不许“猜”：把拒答当成一种能力
不少团队做智能问答时习惯把回答率往上顶，答不上来也要给一个意思相近的。这个项目反着来。项目组跟安全监督部一起列了一份清单，写清楚哪些问题必须给出处、哪些问题只能由人来答。智能体在规程范围内的回答要标注来源章节，超出范围就明确说这不在它能确认的范围，请对方联系值班负责人。
起初有人担心这样体验差，用下来反倒是一线更信任它，因为它不瞎说。有个细节挺说明问题，值班负责人后来发现，员工问的问题开始变得更具体了，泛泛的这个怎么办少了，说明他们已经先自己看过一遍规程再来提问。
（三）验证靠一线，不靠会议室
上线前的验证方式跟很多项目不一样。项目组没有在会议室里做演示，而是把有经验的巡检员请过来，让他们拿着手机随便问，专门挑毛病。挑出来的问题，有的是知识本身缺失，有的是知识在、但组织得让人找不到。前者补内容，后者改结构。
数据也不出集团。整个系统部署在集团自己的机房里，跑在国产化环境上。数商云在智能体开发平台上做的国产化适配在这里派上了用场，源码交付也让集团的信息化团队能自己接手后续调整，不必事事等外部排期。对能源行业来说，这条约束比功能清单重要。
（四）变化写在班前会上
班前会的内容变了。以前是照着规程念，现在会让员工先拿手机问几个问题，当场答不上来的记下来反馈。安全管理部门的培训材料更新也因此有了依据，哪些条款员工总在问、哪些总问错，看得清清楚楚。新员工敢问了，因为不用怕问得太幼稚被人笑话。这种变化没法用某个指标衡量，但值班负责人心里有数。
三、零售与物流行业头部企业：把知识库智能体放到客户听得见的地方
（一）口径不一致，比没人回答更伤客户
某零售与物流行业的头部企业，客服团队规模在大促前后起伏很大，临时补进来的人培训周期短，遇到政策类问题容易答得不一样。客户投诉里有一部分不是没人管，而是前后两个人说法对不上。企业原来也有知识库，但那是给内部看的，条款写得很正式，客服临场要转译成客户能听懂的话，转着转着就走了样。
业务部门最初的判断是培训没做到位，后来才发现问题出在知识本身，同一件事在不同部门的理解里就不完全一致，客服只是把这种不一致传给了客户。这个结论让项目组把力气从培训转到了知识库上。
（二）顺序反过来：先定口径，再写答案
这次知识库搭建的顺序跟前面两个项目不一样。通行做法是先整理文档，再想怎么用；项目组反过来，先由业务、法务和客服一起把争议最多的问题挑出来，逐条确定对外口径，再倒推需要哪些文档支撑。口径定了，答案怎么写也有了约束，不能用内部术语，不能承诺做不到的事，涉及赔付的只讲规则不举例子。
这一步走得慢，但省掉了后面反复改答案的麻烦。数商云的智能体开发平台在这里主要用来做知识版本管理和检索调优，业务侧的同事不写代码，也能自己调整某条答案的措辞和生效范围。
（三）智能客服和人的分工要提前划清
对外的场景里，智能客服不可能什么都接。项目组把边界划清楚了，规则清楚、口径唯一的问题交给智能体；涉及个案、情绪激烈的转人工，而且转接的时候把前面几轮对话带过去，客户不用从头再讲一遍。人工处理完留下的记录会进入知识库的候选池，由业务和法务看过之后再决定要不要采纳。这个环节看着慢，但它挡住了客服随手改口径的口子。
上线之后还有一个意外收获，客服主管能从被问得最多的问题里看出产品说明哪里写得含糊，这些反馈被送到了商品和运营部门。原本只是客服用的工具，慢慢变成了业务侧了解客户困惑的窗口。
（四）把三个项目放在一起看，难的地方其实一样
制造业、能源、零售物流这几个项目放在一起看，会发现共同点比差异多。模型能力不是瓶颈，选哪个大模型应用方案也不是最难的决定。难的是知识治理：谁有权决定一条知识进不进库，过期了谁负责下架，答错了怎么追到源头。权限设计看着是技术活，本质上是组织问题。还有人的意愿，尤其是那些经验最值钱的人，愿不愿意把经验交出来。
数商云在这几个项目里的角色，更像提供一套可以改、可以接手的智能体开发平台。知识库搭建的工具链、智能问答的调试环境、国产化适配、源码交付，目的是让企业自己的团队在项目结束后还能继续往前推，而不是每改一个答案都要重新走一遍外部流程。
如果贵集团也在面对类似的情况，文档不算少，员工要的答案却总是找不到，模型试过几轮，效果停在做演示的阶段，欢迎联系数商云获取详细方案，也可以预约顾问交流或者申请演示。先把问题看清楚，再决定要不要动手，顺序比速度重要。
评论