Q1：作为FDE，你应用AI的具体场景是什么？在这个场景下遇到的具体问题长什么样？
我当时服务的是德国斯图加特一家制造零部件的企业，大概有七八十名员工。企业有多条产线，也有很多不同型号的产品。
这个行业有一个明显的特点，很多生产知识非常细。比如生产不同零部件时，需要调整参数，也会涉及不同金属材料的比例。因为零部件最终面对的使用环境不同，有些可能需要应对强酸环境，有些需要耐磨损，所以不同的材料配比、设备操作和生产经验，会直接影响产品质量。
真正让企业焦虑的，是这些知识并不完全存在于标准文档里，相当一部分经验掌握在老师傅手里。
老师傅知道某个产品应该怎么调、什么情况下参数应该发生变化、设备出现某种状态时应该怎么处理。这些东西很多属于长期实践形成的隐性经验，很难简单靠一份操作手册完整记录下来。
企业最担心的是，如果人走了，经验会不会也跟着人一起走了。
所以我进场之后，没有先问“要用什么模型”，先去看他们到底怎么培养新人。
现在回头看，这一步其实比后面选什么模型更重要。因为企业最开始说的是“我们想把老师傅的经验沉淀下来”，但这句话还不能直接变成一个AI项目。
我必须继续往业务里走，直到把它变成一个更具体的问题，新人学习过程中到底缺哪些知识，这些知识在哪里，以及怎样才能让它在真正需要的时候被找到。
Q2：在你参与之前，这个问题过去是怎么解决的？
过去主要还是靠“人带人”。
新人进入企业之后，要经历一套比较长的培训和实习过程，老师傅在这个过程中承担了很重要的带教角色。根据我当时了解到的情况，培养一个新人可能需要两三个月甚至更长。
制造业里的很多经验，本来就是在长期实践中形成的，老师傅不仅知道标准答案，还知道什么时候不能机械地照标准答案执行，所以过去依靠师徒制，其实是一种非常自然的知识传递方式。
真正的问题，是企业的业务环境开始变化了。一方面，老师傅自己的生产任务很重，没有足够时间持续带新人；另一方面，一些经验丰富的员工开始接近退休。与此同时，企业又希望把过去依赖个人的经验沉淀成组织能够长期使用的知识。
所以我做的，是先把老师傅最有价值的经验留下来，让那些过去必须反复问老师傅的问题，可以通过另一种方式完成第一次解答；真正复杂、需要判断的问题，再回到老师傅这里。这样，老师傅的时间就不需要一直消耗在重复性的知识传递上。
从这个角度看，我做的事比“传统培训改AI培训”更进一步，是在重新分配人在培训流程里的作用。
Q3：后来你使用AI解决这个问题的整体思路和关键步骤是什么？
整个项目真正花时间的地方，其实在于前后几个环节怎么串起来，把知识库搭出来只是其中一步。
第一步，先进入业务，把技术往后放。
一开始，我原本比较习惯通过访谈了解客户需求，高层、中层、一线员工都会聊。
但实际做项目的时候，我发现一个问题，一线员工不一定愿意花很多时间接受访谈，而且很多日常工作中的细节，他自己也未必能在访谈里完整描述出来。所以后来我调整了方法。
除了访谈，我会直接跟着员工走一遍他每天的工作流程，看他一天具体在做什么、在哪里停下来、哪里需要问别人、哪些问题不断重复出现。
这样得到的问题，比单纯问一句“你有什么痛点”具体得多。
这个项目里，我也是先找到主管，把生产线和新人培训流程梳理出来，然后统计新人最常出现的问题、最容易反复出错的知识，以及哪些内容属于老师傅才能掌握的隐性经验，最后把这些内容整理成一张知识地图。
第二步，把人的经验变成AI能够使用的知识。
知识地图有了之后，下一步才真正进入知识处理。
企业本身已经存在一部分知识文档，我先把这些已有材料导入，再通过文档解析、RAG等方式进行处理。但只有文档还不够，我更重要的一项工作，是把老师傅过去存在脑子里的隐性经验抽象出来，让它能够进入企业的知识体系，最终能够被AI理解和检索。
这里很容易出现一个误区，觉得把文档扔进去，AI能回答问题，知识库就算做完了。我没有按这个标准验收。
前期调研时统计出来的那些高频问题，本身就会成为后面的测试集。比如当时我会看文档解析是否能够达到大约95%，问题召回片段的准确率是否能够达到80%以上，在一个最小范围的测试里达到约定标准，我才认为这条技术路径初步跑通。
我觉得这正是FDE和单纯做技术开发不太一样的地方，前面发现的问题，最后一定要重新回到这些问题上验证。
第三步，把AI放回原来的培训流程。
技术通路跑通以后，项目其实还没有结束。如果只是给员工一个新的AI入口，让大家自己去用，很多时候最后是用不起来的。
所以我继续往业务流程里做。当时企业原本就有新人培训环节，我把AI知识能力接进了他们实际使用的平台，并进一步设计了一套类似在线课程打卡的培训流程。
新人能够看到自己在规定时间内完成了多少学习内容；带教师傅也能够回到平台查看新人当前的学习进度；每节课程还会设置问答，对学习结果做一次简单验收。也就是说，AI进入了原来的新人培训流程，没有额外增加一个“聊天机器人”。
第四步，陪着企业把它真正用起来。
上线以后，我还持续调整前端易用性、页面和实际问答效果。这个过程不是一天两天，当时仅陪跑就接近两个月，整个项目如果从立项、调研一直算到最终陪跑，大约经历半年；如果只算真正投入在项目里的时间，大约四个月左右。
所以企业AI落地很少是“系统上线=项目结束”。真正的落地，往往发生在上线之后。
员工怎么使用、哪里不习惯、老师傅愿不愿意看、新人能不能看懂，这些问题最后都会反过来要求我继续修改产品。
Q4：相比传统方式，使用AI后的实际效果如何？
从实际业务变化来看，有几个变化是比较明确的。
首先，过去分散在老师傅个人经验里的知识，开始被系统化整理，企业第一次能够比较完整地知道哪些经验真正不能随着老师傅退休而流失。
其次，老师傅的角色开始发生变化，从重复回答所有问题，逐渐转向关注新人学习进度以及处理更复杂的问题。
第三，培训本身变得更可追踪。以前新人“学到了哪里”“到底掌握了多少”，很大程度依赖带教师傅自己的观察，现在这些进展都能在平台上被清楚地看到和跟踪。
对我来说，这个项目真正的价值，在于企业原本高度依赖个人的经验传承过程，开始变成一套能够沉淀、检索、学习和追踪的组织流程。
Q5：在部署AI过程中，是否遇到了新问题或挑战？你是怎么解决的？
这个项目里，我觉得至少有三个挑战值得单独拿出来讲。
第一个挑战，是用户说不清需求，也说不清经验。
最开始我采用访谈，希望通过和不同层级员工交流了解问题。但做下来才意识到，一线员工未必愿意投入很多时间，而且很多隐性的工作习惯很难靠问答完整说出来。
所以我后来减少对纯访谈的依赖，直接跟着员工走他的日常流程。这是一个很小的调整，但对FDE来说非常重要。有时候你不能继续追问用户“你需要什么”，得自己去现场看，看他到底怎么工作。
第二个挑战，是技术指标不能由FDE自己关起门来定义。
比如文档解析率、召回准确率做到多少算合格，没有一个可以直接套用的行业标准。我的做法是先做一个小范围测试，看看当前条件下大概能达到什么水平，再和客户沟通他们真正需要什么，最后双方共同确定验收标准。所以验收标准本身，也是业务沟通的一部分。
第三个挑战，是技术跑通以后，员工不一定愿意用。
所以后来我花了很多时间调整前端页面、学习流程和易用性。我没有要求新人改变整个工作习惯去适应AI，尽量把AI放进他们已经存在的培训和协作环境里。
我做企业项目时一直比较坚持这一点，如果客户已经有能够解决问题的技术栈、平台或者模型，我会尽可能复用，避免为了展示技术能力把客户已有的东西全部推翻重做。因为站在客户角度看清楚“什么已经能用、什么真正需要改”，本身就是建立信任的过程。
Q6：根据你的经验，我们怎么才能更好地把AI部署到实际业务中？
做完这个项目以后，我更清楚地认识到，FDE最重要的能力其实不在“知道多少模型”上。我更愿意把FDE理解成一个团队，团队里有人需要真正进入客户现场，判断业务问题；有人要把需求变成能在客户环境里跑起来的东西；还需要更专业的技术人员保证架构、性能和未来的扩展性。
但不管角色怎么分，最后做的都是同一件事，把企业模糊的问题，变成可落地、可验证的AI解决方案，再把它真正推进到企业业务流程里。如果让我把这次项目里的经验再压缩一下，我会总结成四点。
第一，不要从“企业想做什么AI”开始，要从“企业每天到底怎么工作”开始。
用户自己有明确需求当然很好，但即使没有明确需求，只要他的业务SOP足够清晰，我也可以沿着流程一个环节一个环节去判断哪里适合AI。所以对企业来说，在做AI之前，把自己的核心业务流程先梳理清楚，本身就非常重要。
第二，不要急着推翻客户已有的东西。
我做前期调研时，会先看企业现在用了什么技术栈、什么平台、什么模型，哪些东西能够继续复用。如果已有能力能够解决问题，就尽可能沿用。FDE要做的，是找到客户成本和业务效果之间更合适的方案，不必去证明自己的技术方案最复杂。
第三，前期发现的问题，要直接变成后面的测试标准。
这个案例里，新人高频问题在访谈结束后没有停留在报告里，直接变成了知识库测试集。我认为这是非常关键的一步。只有这样，AI最终验证的才是“能不能解决真实业务问题”，单纯的技术指标漂不漂亮退居其次。
第四，AI一定要进入流程，不能停在Demo里。
知识库能回答问题，只能证明技术通路跑通了。新人真的愿意学、带教师傅真的愿意看、学习结果能够被验收，这才说明它开始进入业务。所以我最后花了接近两个月陪跑。很多企业AI项目真正困难的部分，其实在最后这一公里，怎么让AI和企业原来的业务流程真正连接起来。
这就是我对FDE这个角色的理解。AI能力还会继续变强，做AI应用的门槛也会越来越低，但企业自身的流程、组织和真实业务环境不会因此自动变得清晰。FDE真正要解决的，就是AI与企业之间最后这一公里的问题。未来技术会变、模型会变、服务形式也会变，但这种“深入现场、发现问题、验证方案、进入流程”的能力，我认为仍然会长期存在。