制造业经验不能只住在老师傅脑子里

一家德国斯图加特的制造零部件企业，有七八十名员工、多条产线和很多不同型号的产品。新人要学会的不只是操作手册里的标准步骤，还包括材料怎么配、参数什么时候要调整、设备出现某种状态时应该怎么处理。

这些经验很多掌握在老师傅手里。企业真正担心的不是“有没有一个 AI 工具”，而是老师傅退休或离开之后，经验是否也会一起离开。

这个案例里，FDE没有从选模型开始，而是从新人每天怎么学习、什么时候需要问人、哪些问题不断重复出现开始。最后交付的也不是一个孤立的聊天窗口，而是一套接入原有培训平台的 AI 辅助培训流程。

这件事值得拆开看，因为它完整呈现了一个企业 AI 项目从场景发现到实际使用的四个问题：落地场景是什么，难点在哪里，如何落地，最后产生了什么变化。

落地场景：把师徒带教中的重复问题交给 AI#

制造业的经验传承，本来就不适合被简单理解成“把文档数字化”。

不同零部件面对的使用环境不同，有些需要耐受强酸，有些需要承受磨损。生产人员因此要结合产品型号、金属材料、设备状态和过往经验做调整。标准文档可以说明“通常应该怎么做”，但老师傅还知道“什么情况下不能机械地照做”。

过去，新人进入企业后主要靠师傅带着学。培养周期可能达到两三个月甚至更长。师傅一边完成自己的生产任务，一边回答新人反复提出的问题；新人学到了哪里、哪些内容还没有掌握，也很大程度依赖师傅自己的观察。

这个方式并不是错误答案。它能把隐性经验传给新人，也能在现场根据情况做判断。问题在于，老师傅的生产任务越来越重，一些经验丰富的员工接近退休，而企业又希望把依赖个人的知识沉淀成组织可以长期使用的能力。

所以这个项目的场景不是“用 AI 替代老师傅”，也不是单独做一个企业知识库，而是重新分配培训流程中的工作：

• 高频、重复、相对明确的问题，先由 AI 完成第一次解答；
• 新人按照课程和问答完成学习，系统记录进度；
• 老师傅查看学习情况，把时间集中到复杂判断、纠错和关键经验传递上；
• AI 无法确定或需要现场判断的问题，仍然回到老师傅和业务人员这里。

这个定义很重要。它把“经验沉淀”转成了一个可以设计和验收的业务流程：新人能不能更快找到知识，师傅能不能少回答重复问题，培训过程能不能被追踪。

落地难点：真正困难的不是把文档接进模型#

用户说不清需求，经验也说不清#

项目开始时，最自然的办法是访谈高层、中层和一线员工，问他们有什么痛点。但一线员工未必愿意投入大量时间访谈，而且许多日常习惯已经变成了下意识动作，用户自己也不一定能完整讲出来。

因此，FDE后来把方法从“继续追问用户需要什么”调整为“直接跟着用户工作一遍”：观察员工一天的流程，记录他在哪些地方停下来、什么时候需要问别人、哪些问题反复发生、哪些知识只有老师傅能解释。

对这个案例来说，现场观察比一份泛泛的需求报告更接近真实问题。最后形成的不是一个抽象的“企业需要知识管理”，而是一张知识地图：新人最常问什么，最容易错在哪里，哪些内容有现成文档，哪些内容只存在于老师傅的经验里。

显性文档不等于可用知识#

企业已经有一部分文档，但“把文档导入知识库”并不意味着知识已经完成整理。文档可能缺少上下文，老师傅的经验又没有被记录；即使模型能生成一段流畅回答，也不代表它找到了正确的依据。

这个项目要同时处理两种知识：一类是企业已有的显性文档，另一类是分散在个人经验里的隐性知识。后者需要先被抽象、组织和表达，才可能进入检索与问答流程。

技术指标没有现成的行业答案#

文档解析率做到多少算合格，召回到的片段准确到什么程度才足够支持培训，不能由 FDE 自己关起门来决定。指标太低，系统无法使用；指标一味追高，又可能让项目成本和周期失控。

案例中的做法是先用小范围测试摸清当前条件下的能力，再和客户共同确定验收标准。前期发现的新人高频问题直接变成测试集，阶段性目标包括文档解析约 95%、问题召回片段准确率达到 80% 以上。这里的关键不在数字本身，而在于测试题来自真实业务，而不是来自一份脱离现场的 benchmark。

技术跑通后，员工不一定愿意用#

如果只是增加一个 AI 入口，让新人自己去发现和使用，项目很容易停在 Demo 阶段。新人可能不知道什么时候该问，老师傅也未必愿意再打开一个新系统，培训结果仍然无法被验收。

所以这个项目的难点最后落到了产品和流程上：如何把 AI 放进员工已有的培训环境里，如何让新人知道下一步学什么，如何让师傅看到学习进度，如何让问答成为课程的一部分，而不是额外增加一个工具负担。

如何落地：从现场观察到流程内嵌的四步#

第一步，先看业务怎么工作，再决定技术怎么用#

FDE先和主管梳理生产线与新人培训流程，再跟着员工走完整的日常工作。这个过程要回答的不是“企业想不想做 AI”，而是：

1. 新人在哪些节点最容易卡住？
2. 哪些问题每天重复出现？
3. 哪些知识已经写在文档里，哪些只能向老师傅询问？
4. 哪些内容适合第一次由 AI 解答，哪些必须保留人工判断？

这些问题最后沉淀成知识地图，也成为后续产品和评测的共同输入。

第二步，把文档和隐性经验一起整理成知识体系#

已有文档通过文档解析和 RAG 进入系统，但项目没有把“能检索文档”当成终点。老师傅掌握的参数调整、异常处理和经验判断，需要被进一步抽象成可以理解、检索和复用的知识单元。

这里的产品工作不是简单增加更多资料，而是明确知识的来源、适用条件和使用边界。一个好的回答不仅要告诉新人“应该怎么做”，还要让他知道这个结论适用于什么产品、什么材料或什么设备状态；超出知识范围的问题，则应该回到老师傅处理。

第三步，把真实问题变成测试集和验收标准#

前期调研中收集的高频问题没有停在调研报告里，而是直接进入测试集。每一次迭代都回到这些问题上，看系统能否找到相关内容、回答是否符合业务语境、哪些问题必须转人工。

这形成了一条完整的闭环：

现场观察 → 高频问题 → 知识整理 → 检索测试 → 回到现场验证

因此，验收不只看模型是否能生成通顺文本，也不只看一个脱离业务的召回分数，而是看它能不能解决新人真实遇到的问题。技术指标需要服务于业务任务，不能替代业务任务。

第四步，把 AI 接回原有培训平台，并持续陪跑#

项目没有另起一个“聊天机器人”作为培训入口，而是把 AI 知识能力接进企业原本使用的平台，并设计了类似在线课程打卡的流程：

• 新人可以看到规定时间内完成了多少学习内容；
• 每节课程配套问答，对学习结果做一次简单验收；
• 带教师傅可以查看新人的学习进度；
• 复杂问题仍然回到老师傅，由人完成判断和指导。

上线后的近两个月，FDE还在持续调整前端页面、学习流程和实际问答效果。整个项目从立项、调研到陪跑大约经历半年，实际投入时间约四个月。这个时间说明，AI 项目里的“最后一公里”不是上线按钮，而是让真实用户在原有工作方式里逐渐用起来。

落地成果：经验从个人记忆变成组织流程#

案例没有提供收入、产量或培训周期缩短等经营结果，因此不应该把它包装成一组漂亮的 ROI 数字。但从工作方式来看，至少发生了四个明确变化。

变化前	落地后的变化
关键经验分散在老师傅个人记忆里	企业开始系统整理哪些经验需要被长期保留
新人遇到问题就反复打断老师傅	高频问题先由 AI 完成第一次解答，复杂问题再回到老师傅
带教进度主要靠个人观察	新人的课程完成情况和问答结果可以被记录、查看和追踪
培训依赖个人能力和临场安排	培训变成能够沉淀、检索、学习和验收的组织流程

最值得注意的成果不是“企业拥有了一个知识库”，而是人的角色发生了变化。老师傅不再需要把时间平均分配给所有重复问题，而是更多关注学习进度、异常情况和需要经验判断的复杂问题。AI也没有被设计成新的权威，而是成为培训流程里的第一响应层。

这正是 FDE 项目和普通技术交付的差别：交付结束之后，客户不只是拿到一个系统，还应该更清楚自己的流程、知识和验收标准，知道下一次类似问题该怎么继续推进。

这个案例给 FDE 的四个提醒#

第一，不要从“企业想做什么 AI”开始，要从“企业每天到底怎么工作”开始。即使用户没有清晰的 AI 需求，只要业务流程足够具体，就能沿着流程找到重复成本和适合验证的环节。

第二，不要为了展示技术能力而推翻客户已有的系统。已有的平台、模型和技术栈能复用就先复用，FDE要解决的是业务效果和实施成本之间的关系，而不是证明自己的方案最复杂。

第三，前期发现的问题要直接变成后面的测试标准。高频问题如果只留在调研报告里，项目就会在开发阶段失去业务锚点；一旦它们进入测试集，团队才有机会持续验证“解决的是不是原来的问题”。

第四，AI一定要进入流程，不能停在 Demo 里。知识库能回答问题，只能证明技术通路跑通了；新人愿意学、师傅愿意看、学习结果能够被验收，才说明 AI 开始成为企业工作方式的一部分。

来源与边界#

• 原始资料：Datawhale《FDE案例100.pdf》，案例一“从师徒带教到AI辅助培训：FDE用AI破解制造业经验传承难题”，案例访谈正文位于 PDF 第 7–13 页。
• 案例事实：德国斯图加特一家约七八十人的制造零部件企业；多条产线、多个产品型号；新人培养通常需要两三个月或更长；项目从立项到陪跑约半年，实际投入约四个月，后续陪跑接近两个月。
• 技术口径：文档解析约 95%、问题召回片段准确率 80% 以上，是案例中用于小范围验证的阶段性目标，不是行业统一标准，也不是公开的生产环境长期指标。
• 结果边界：原始案例主要描述知识整理、培训流程和角色变化，没有提供可独立核验的收入、产量、成本节省或培训周期缩短数据。本文没有把这些变化推演成未经证实的经营收益。
• 产品化解读：关于“第一响应层”“知识地图”“真实问题测试集”和“流程内嵌”的总结，是基于该案例的产品化分析，不代表 Datawhale 或受访企业对所有制造业场景的通用承诺。