一、设备停在工地上，工程师最先找的不是手册
（一）现场要的是下一步，不是一段原理
某工程机械行业头部集团的服务网络铺得很开，设备分布在矿山、港口、基建工地这些环境里，一旦停机，客户那边的压力会直接压到服务工程师身上。服务车开到现场，工程师蹲在设备旁边，仪表上跳出一串故障码，他把手册翻到对应章节，手册写的是常规工况下的排查顺序。可眼前这台设备刚经历过长时间连续作业，液压系统温度偏高，电控部分还在报一条关联提示。手册上那几行字，不足以让他判断先动哪一处。
接下来发生的事，几乎每个服务人员都熟悉。他掏出手机，把故障码和现场照片发到服务群里，点名问几位老师傅。电话回过来，老师傅让他先看某个压力值，再判断是传感器的问题还是阀组的问题。设备修好了，客户满意了，整个过程却没留下可以复用的东西——聊天记录留在群里，通话内容留在当事人的记忆里。同样的故障换到另一个区域出现，很可能又是从头问一遍。
（二）知识散落在哪里，谁也画不出一张完整的图
这家集团的服务资料门类比外人想象的杂。原厂手册和零件图册由技术部门维护，改版慢，内容严谨但偏理论；服务通报、技改通知、临时处理方案由服务管理部门发出，走邮件、走工作群，时效强、留存弱，发出去之后往往没人再整理；工单系统里存着大量维修记录，可写记录的人图省事，只留结果，不留判断依据；再往外，是各地服务人员的个人笔记、现场照片、录下来的培训音频，还有代理商自己总结的土办法。
这些内容单看都有价值，凑在一起就互相打架。同一个故障码，手册上是一种说法，服务通报里补了一种说法，某位老师傅在群里给出的又是更贴近现场的说法。系统把结果不分轻重地摆在使用者面前，工程师还得自己判断该信哪一个。更麻烦的是判断依据常常没写清楚，是标准工况、高温工况还是高海拔工况，全靠猜。
（三）业务方和IT方，先要把问题对齐
项目刚启动时，双方对要做的事情理解并不一致。IT部门的想法是先把文档统一管起来，做一套能搜索的资料库，把散落的文件收拢到一处。服务管理部门的回答很直接：现场不缺文档，缺的是下一步该干什么，而且这个判断必须有出处，不能是模型随口编出来的。争论了几轮之后，问题被重新写了一遍——现场需要的是有人对着故障现象给出排查方向，并告诉他这个方向来自哪份手册、哪条通报、哪次维修记录。这句话成了整个项目的验收基准，也成了后来与数商云团队沟通时摆在最前面的那条需求。
二、需求定型：不是加一个搜索框，而是开发一套企业知识库智能体
（一）目标从检索改成了问答
传统搜索以文档为单位返回结果，智能问答以问题为单位返回答案，这两件事在使用体验上差得很远。工程师问这个故障码在高温工况下怎么排查，他希望拿到的是排查顺序和判断依据，而不是一份手册的下载入口。数商云团队在前期调研阶段做了一件很实在的事：跟着服务人员跑现场，看他们怎么提问、问谁、拿到答案之后怎么用、用完之后会不会记下来。调研结束，需求的表述明显变了——要搭建的是一个企业AI知识库，外面套一层会追问、会引用出处、也会承认自己不知道的智能体。
措辞的变化背后是设计的变化。搜索只需要把文档找出来，问答却要对答案负责。一旦对答案负责，哪些内容可以进知识库、答案里要不要带出处、找不到的时候怎么回复，这些问题就全都冒了出来。
（二）语料治理比选模型更花时间
知识库搭建这件事，真正难的部分是把散在各处的资料变成能检索、能追溯、能更新的语料。数商云团队进场后先立的不是模型参数，而是规则：每条知识必须有来源、有生效时间、有适用范围、有维护责任人。没有来源的口头经验可以进库，但要经过确认流程，由技术部门或者资深服务人员认可。规则立起来之后，工作量比想象中大得多，因为不少资料在整理过程中才暴露出问题——不同批次设备的配置存在差异，同一张图纸在不同项目上有改动，同一段培训音频里讲过的做法后来又被推翻。
（三）技术路线上的取舍
选型阶段讨论最久的是几件事：模型放在哪里、知识怎么组织、以后的维护权在谁手里。集团在信息安全上有明确要求，最终选择了可以本地化部署、适配国产软硬件环境的方案。另一个被反复提到的是源码交付——服务知识是活的，集团不希望每次调整都要等外部团队排期，把智能体的开发框架、检索逻辑、接口层源码拿到手，自己的IT团队后续能接着改。
数商云的智能体开发平台在这个环节提供的是工程化的部分：语料接入、切分策略、检索配置、提示词模板、接口编排都可以在平台上配置，也可以导出源码继续开发。这些能力是背景，真正推着项目往前走的，是前面那条规则——答案必须能追溯。
三、开发过程中的几场硬仗
（一）把互相矛盾的说法摆到桌面上
1. 版本冲突不是对错问题，而是适用条件问题
同一个部件，手册、服务通报和现场笔记给出不同的说法，这是项目组最早碰上的一类麻烦。简单按时间取最新的做法被否掉了，因为最新的说法未必覆盖所有工况。项目组把技术部门和服务管理部门拉到一起逐条核对，把标准工况和特殊工况分开标注，答案里也写明适用条件。核对下来发现，相当一部分矛盾其实来自场景差异，不是谁写错了。
2. 图纸、扫描件、表格、录音，怎么进知识库
这些内容靠人工录入不现实。项目组用了文档解析和图像识别，把图纸上的关键标注、表格里的参数抽出来，再和设备型号、批次关联起来。识别不出来的部分不硬塞进库，而是留一个原文位置的入口，让人能自己翻过去看。培训音频做了转写，再由技术人员校对，把口语里的冗余部分去掉。
3. 老师傅的判断逻辑，怎么变成可检索的表达
资深服务人员的判断往往是一连串如果这样、就先看那里。项目组请了几位老师傅，把常见的排查过程录成对话，再由技术人员整理成结构化的判断链条，最后请本人确认。这个过程慢，但结果扎实，知识库里那些来自一线的条目，反而被引用得最多。
（二）检索和生成之间要有分工
智能问答不能靠大模型自由发挥。项目把流程拆开：检索负责找依据，生成负责把依据讲成人话。检索端做了多路召回，把手册条款、服务通报、历史工单、培训材料放在一起比对，给不同来源设置权重；生成端被要求必须给出引用来源，遇到资料没有覆盖的问题，宁可回答知识库里暂时没有相关内容、建议联系技术支持，也不允许编造。针对高频故障场景，系统还做了意图识别，先把问题归到具体的设备类别和故障现象上，再进入检索。
这套分工在测试阶段被反复打磨。早期版本给出的答案太长，工程师看到大段原理就失去耐心；调整之后，答案先给排查顺序，再给判断依据，出处附在最后，解释性的内容收起来按需展开。这种组织方式是从使用者的动作顺序倒推出来的，不是从技术的方便程度倒推出来的。
（三）接通工单和客服系统
智能客服这一层是后来加进去的。经销商和客户服务热线每天接到大量重复咨询，其中不少问题在知识库里其实有答案。项目把知识库智能体的接口接到客服工作台上，坐席在通话过程中就能查到建议话术和排查步骤。工单系统则反过来给知识库供料：工单关闭的时候，系统把处理过程和更换部件的信息整理成条目，经过审核后进入知识库。两头的接口打通之后，知识库有了持续更新的通道，不再是项目交付时的那一批静态资料。
（四）权限这件事比想象中麻烦
同一个问题，集团内部技术人员、区域服务经理、代理商工程师、外部客户能看到的内容不一样。有些技术通报涉及设计变更，不能对代理商全量开放；有些客户专属的改造方案，只对特定项目组可见。项目在知识库底层做了按角色、按组织、按设备归属的内容过滤，检索阶段就把没有权限的内容排除在外，而不是等答案生成出来再想办法遮挡。
四、上线之后的磨合，比开发阶段更考验人
（一）试点从最难的地方开始
试点没有挑轻松的场景，选的是故障排查和备件确认——问得最多，答错的代价也最大。上线初期，工程师的反馈很直接：答案太长了，引用的手册版本不对，我要的是先看哪里，不是听原理。项目组把这些意见逐条记下来，回头调整答案结构和检索权重。有些问题出在语料上，比如某份通报的生效时间没标清楚，检索时被当成了通用规则；有些问题出在交互上，提问入口藏得太深，工程师宁可直接打电话。
（二）让一线愿意用，靠的是细节
一套知识库智能体能不能活下来，取决于服务人员赶时间的时候会不会想起它。项目组做了几件看起来不起眼的事：在工单界面里嵌入提问入口，不用切换系统；在服务群里定期推送知识库更新的条目；把使用频率高的内容放到首页推荐。有位区域服务经理的说法很实在，以前遇到没见过的故障，下意识的反应是打电话，现在会先去问一下，问不到再打电话。这句话比任何上线报告都能说明问题。
（三）跨部门坐到了一张桌子上
项目推进过程中，技术部门、服务管理部门、IT部门和代理商管理方形成了一个固定的沟通机制。技术部门确认技术口径，服务管理部门判断适用场景，IT负责系统对接和权限，代理商那边提供一线的使用反馈。这个机制在项目结束之后保留了下来，因为它解决的是一个长期问题：知识不是一次性交付的，得有人持续照看。
五、变化发生在哪些地方
（一）找答案的路径短了
以前现场工程师要先想起资料在哪个系统、哪个群、哪个人手里，再去翻；现在他在工单界面里把故障现象描述一遍，就能拿到带出处的排查方向。这不是效率数字上的变化，而是动作顺序的变化——从找人问，变成先查再问。服务管理部门注意到，技术支持来电的结构也在变，问基础问题的少了，讨论疑难工况的多了。
（二）新人的成长曲线不一样了
新入职的服务工程师过去靠师傅带，跟着跑现场，慢慢积累判断力。现在他们可以在知识库里看到别人处理过的类似问题，连判断依据一起看。带人的师傅负担轻了一些，新人敢自己动手的时间提前了。更有意思的是，新人提交的工单质量比以前好，因为他们知道该记录什么，也见过好的记录长什么样。
（三）知识开始反向流动
知识库最初是拿来用的，用了一段时间之后，它开始收。服务人员在现场发现的新情况、遇到的例外工况，通过工单和反馈入口回到知识库，经过确认成为新条目。技术部门也会从检索记录里看到哪些问题被反复问到，反过来判断哪些地方需要补充说明、哪些设计需要优化。这个方向上的流动，是项目组当初没有完全预料到的收获。
六、这套做法不止用在售后维修
（一）知识密集的场景，问题长得都差不多
这家工程机械集团的智能体上线后，先在售后服务站稳了脚，随后培训部门和销售支持部门也接了进去。培训端用它做现场问答演练，销售端用它查配置差异和历史改造案例。类似的需求在其他行业也在发生。某能源行业头部企业的设备检修规程同样厚重，检修人员需要在作业前确认步骤和风险点；某物流行业头部集团的客服和网点管理，也要在很短时间内给出统一口径的回答。这些场景的共同点很清晰：知识量大、变化快、使用者没有时间读长文档，而且答案必须能追溯到出处。
（二）做知识库智能体开发，绕不开的几件事
回头看这个项目，能被直接复制的东西不多，但有几件事绕不开。语料治理要先于模型调优，垃圾进、垃圾出这条规律在知识库里体现得特别明显；智能问答必须接受答不出来，宁可承认不知道，也不能编；系统上线只是开始，得有明确的维护责任人和更新机制，否则知识库会随着时间慢慢失效。这几件事跟选哪个模型关系不大，跟项目的组织方式关系很大。
（三）关于数商云
数商云在这个方向上提供的是企业知识库智能体和知识库搭建的工程化能力：智能体开发平台把语料接入、检索策略、生成规则、接口编排串起来，支持本地化部署和国产化环境适配，也支持源码交付，方便企业自己的技术团队接手后续迭代。对于正在评估大模型应用落地路径的企业来说，有一件事值得先想清楚——你要解决的是文档找不到，还是问题没人答。这两个问题的解法差别很大。
如果所在的团队也在面对服务知识分散、响应依赖个人的情况，欢迎联系数商云获取详细方案，也可以预约顾问交流或者申请演示。把具体的场景摆出来聊，往往比看通用介绍更有用。
评论