从老师傅报价到AI深度协同：FDE用AI重构非标制造售前链路

访谈资料整理：依据 Datawhale《FDE案例100》所收录访谈。案例叙述与成果均归属于原访谈，本站未进行独立项目审计。

原案例封面

为什么这个案例值得看？

多品种、小批量制造企业需要从客户图纸中理解材料、尺寸和结构，再完成需求拆解、物料选择、工艺判断和成本核算。项目把多模态图纸解析、Agent 工作流、物料和供应商数据、报价规则及工艺经验串成售前链路，减少至少 50% 的相关工作量。

这个案例的价值不只在于采用了某种模型，而在于把数据、规则、系统和人工责任连接成可执行的业务链路。落地过程围绕问题识别、方案选择、交付路径、业务结果和关键难点展开。

一、企业与业务场景

项目团队这次选的是制造业里一个常见、却经常被低估的场景，非标产品的售前方案和报价。

这家企业大概有两三百人，营业规模在一二十亿元左右，业务属于典型的柔性制造，多品种、小批量，大量订单都是非标需求。

它和标准品企业不一样，标准品有固定SKU和价格，客户选完产品基本就知道多少钱；非标制造往往需要客户先发一张图纸，企业内部再去判断这个东西要做成什么样、用什么材料、关键尺寸是多少、结构和性能有什么要求、能不能生产、该用什么工艺、成本大概多少。

所以项目实践表明，这个场景只叫“报价”其实并不准确。

更准确地说，它是一条完整的链路，图纸解析、需求拆解、研发协同、生产方案、成本核算、报价。

举个具体的例子。

客户可能要加工一个轴承零部件，发来的不一定是一份标准数据，可能是PDF、CAD文件，也可能是其他不同形式的资料，里面写着材料、尺寸、关键部位要求、结构要求等信息。

过去企业需要有人把这些东西打开一项项看，再依靠专业经验，把客户的语言转成企业内部能够生产的语言。

单独看，任何一个动作都不算复杂，真正麻烦的是整条链路非常依赖人。

首先，它占用核心技术骨干。

真正懂工艺、懂材料、懂制造可行性的人，在制造企业里通常比较稀缺，但大量非标订单进来以后，他们不得不花很多时间做售前方案、看图纸、拆需求、估成本。

其次，报价准确率直接影响利润。

价格报高了，订单可能丢掉；价格报低了，单子虽然拿到，生产时才发现成本覆盖不住，利润空间被挤掉。

第三，还有一个经常被忽略的问题是响应速度。

客户的询价不会一直等项目团队，如果某个技术骨干正好在忙，报价卡在那里几天，这个售前节点就可能直接卡死，最后订单流失。

项目团队选这个场景，并没有从“AI现在能识别图纸”出发。

判断顺序正好反过来，一个场景值不值得做AI改造，FDE通常先看三件事：有没有大量知识型工作，比如分析、判断、设计和经验复用；有没有一定规模的历史数据可以使用；现有流程里有没有非常明确的效率瓶颈。

如果只是简单的自动化流程或者需求价值不高的场景，项目实践表明根本没必要上AI。

二、原有流程与核心问题

在AI介入之前，客户图纸过来以后，业务人员、技术人员或者企业里的老师傅打开文件，根据自己的经验理解客户要求，再把信息整理出来，然后去查企业自己的物料、供应商和历史价格。

本质上，这是一个纯人工的信息理解、结构化和匹配过程。

之前没有成熟的多模态能力，很难让系统直接理解不同格式的图纸，也很难把大量非结构化资料自动转成结构化信息。

企业自己的知识同样不够标准，一个零部件为什么这样报价，很多时候都写在老师傅脑子里，他清楚某个材料应该找哪个供应商，某种工艺大概需要多少成本，什么情况下该给客户留一点余量。

企业过去也试过用系统把这件事接起来，早期上过ERP和报价模板，想用固定字段把报价流程管起来。

这类系统擅长的是“业务人员把字段填进去，业务人员按规则往下跑”，最难的第一步，也就是把客户五花八门的输入理解成标准数据，始终没人解决。

所以系统最后只能覆盖标准件和固定SKU，非标部分照样回到人，模板反而多填一遍表。

问题真正爆发，是在业务规模和复杂度上升以后。

订单越来越多，非标需求越来越多，人的处理能力却不会同比增长。

一个关键技术员一天能看的图纸、能处理的询价是有限的，需求一来多，整个售前链路就开始排队。

经验长期握在少数人手里，也意味着企业很难把这种能力复制出去。

所以项目团队真正想解决的，是一个新问题：当业务规模继续扩大时，能不能不再靠增加更多人、更多老师傅来撑住报价能力。

报价能力，是影响一个制造业供应链企业生死存亡的核心能力，关系到这个企业的响应速度、服务能力以及利润空间。

三、AI 解决方案与交付路径

做这个项目，FDE没有拿着一个模型去问客户“这个模型能帮业务人员干什么”，工作顺序一直是反过来的，先理解业务，再拆流程，再判断哪些环节该用AI。

项目团队先去复现传统人工操作的业务流和数据流，通过还原实际SOP，结合AI大模型与Agent编排能力，去梳理输出企业AI再造后的新业务流程。

FDE在这里更像一个连接器，一头听懂企业在说什么，一头清楚当前大模型、Agent和各种AI工具能做到什么，再把两边拼成一个能落地的方案。

第一步，是把“报价”重新拆成一条业务链路。

前期项目团队深入做了需求调研和业务调研。

进场之后FDE先去了车间，看一个订单从图纸到交付到底经过哪些环节，又翻了一批历史报价单，找业务人员和老师傅分别聊，问他们拿到一张图纸后第一件事做什么，谁看图纸，谁做需求拆解，谁定物料，谁判工艺，谁核成本，谁最后报价，不同角色之间怎么交接。

只有把这些都搞清楚，才能知道AI应该放在哪个位置。

第二步，是先解决非结构化信息的入口。

客户发来的图纸格式不统一，有的PDF、有的CAD，所以第一步要利用多模态能力，把图纸里的材料、尺寸、结构要求等关键信息抽取出来。

但项目团队的目标不止于“识别图纸”，识别之后必须结构化，因为只有结构化以后，这些数据才能继续进入后面的业务流程。

第三步，是让AI进入企业自己的业务规则。

这一步很关键。

AI提取出客户需求之后，不能直接凭模型自己的知识报价格，企业内部有自己的物料库、供应商体系和长期形成的报价逻辑，所以报价必须基于这家企业自己的条件。

项目团队会把结构化后的客户需求，与企业自己的物料、供应商、历史数据和报价规则做匹配，再通过垂类Agent把这些环节串起来。

这样出来的结果，才是企业真正可以拿去用的报价。

这个设计也是调整出来的。

一开始项目团队想得比较直接，觉得模型看懂图纸、抽取字段，后面按规则一算就能出价。

真正到现场跑起来才发现，端到端直接出价，出来的数字经常对不上真实成本。

所以项目团队改了方案，让模型先只负责把图纸信息结构化，报价环节再回到企业自己的物料和规则库里做匹配，每一单都经过人工校准才对外输出。

第四步，是把老师傅的经验变成企业的数据资产。

企业原来的很多工艺知识都存在人脑里。

AI介入之后，项目团队开始把这些知识逐步标准化、流程化，哪些物料怎么映射，某类需求通常走什么工艺路线，报价时有哪些判断逻辑，都可以逐步沉淀下来。

同时项目团队设计了人工校准和回填机制，AI第一次给出的结果不一定完全正确，业务人员会修改，修改完之后就把这次修改重新沉淀到数据、向量数据库或者相关模型里。

这样就形成一个数据飞轮，AI生成、人工校准、数据回填、下一次结果更好。

第五步，是不等所有需求都搞清楚再开发。

前期调研不可避免，项目团队也会深入现场、开很多次会，但FDE一般不会等所有信息都完全掌握之后，再关起门来做几个月。

FDE的方式是边干边改，客户给FDE一部分输入，FDE就先给他阶段性产出，可能是Demo、一个流程，也可能是某个功能，让他先看是不是这个意思、这个东西到底能不能解决他的问题，客户反馈之后项目团队继续调整。

整个过程中可能来回几次，甚至十几次。

B端项目有一个很现实的问题，有时客户自己都不知道自己真正需要什么，FDE不能只记录需求，还要不断拿阶段性结果去帮客户澄清需求。

第六步，是先让关键人试用，再逐步推广。

产品做到可以运行之后，项目团队不会马上让所有人用，先找关键人试，让最懂业务的人拿真实订单跑，发现问题再修改；接下来再让一个业务小组试运行，这个阶段仍然不断收集问题。

这个项目里试运行周期大概是1到2个月，项目团队围绕几个真实订单不断验证，同时继续调整需求。

等到结果基本可用，再做部署、数据集成、启动会和全员培训，最后逐步扩大到整个部门。

整个推广路径就是关键人试用、业务小组试点、真实订单验证、反馈调整、部门推广。

项目经验表明这种方式比一次性开发完成再宣布上线可靠得多。

四、项目结果与业务价值

这个项目刚上线的时候，并没有立刻达到理想状态，前两个月一直处在磨合和微调阶段。

因为项目团队最终看的，是这个结果能不能真正被企业拿去报价，模型能不能输出一个结果反而是次要的。

目前来看，整体效果已经比较明显，至少能减少50%以上的相关工作量。

但如果只把“节省50%工作量”当成全部价值，还是低估了这个项目。

项目团队内部评估效果，会看几个层面。

第一是响应速度，原来人工完成一套报价要多久，现在通过这套流程要多久；第二是报价结果本身的可用性和准确率；第三是前面图纸解析的准确率；最后还是要回到第四层，它到底给企业运营带来了多少价值。

这里发生了一个很有意思的变化。

原来这项工作可能需要3到5个人参与，AI介入以后，一部分重复劳动可以由系统完成，实际需要投入的人力明显减少。

企业并没有简单地把剩下的人裁掉，这家企业本身处在上升阶段，老板希望做的是把人的生产力释放出来。

原来业务人员很大一部分时间耗在看资料、整理需求、反复核对这些事情上，这部分时间省下来之后，他们可以回到本来的业务工作，去联系更多客户、谈更多项目、接更多订单。

企业随后也会相应调整这些岗位的KPI和职责，让考核更偏向真正的业务价值。

所以本案例中的降本增效，核心是原来5个人的大量时间被低价值重复劳动占用，现在把其中一部分生产力释放出来，让人去做更需要判断、沟通和创造价值的事情。

这才是AI真正进入业务流程之后应该产生的变化。

项目图示

原案例图示（PDF 第 171 页）

原案例图示（PDF 第 172 页）

原案例图示（PDF 第 174 页）

五、关键落地难点

这个项目真正困难的地方，项目实践表明不完全是技术。

立项之前，能不能做、当前模型能力到什么程度、有什么风险，项目团队一般会先判断。

真正进入项目以后，遇到的坎主要有三个，图纸识别能不能达到报价要求、企业的数据质量、以及组织里人的接受度。

第一个挑战，是图纸识别在真实场景里达不到报价的要求。

客户图纸远比想象中杂，有PDF、CAD，还有各种扫描件，清晰度参差不齐。

模型在干净样例上效果不错，一旦碰到手写标注、特殊符号、非标准图框，抽取字段就经常出错。

报价是要对外的，一个尺寸抽错会直接影响成本。

项目团队的办法是给识别加一道人工校准兜底，业务人员只审那些模型把握不大的字段，审完再把修正结果回填到模型和数据里，识别准确率随着真实数据越滚越高，人工要审的部分越来越少。

第二个挑战，是企业的数据远没有想象中标准。

很多中小制造企业的数据基础比较薄弱，进去以后可以看到，各种资料、历史报价、物料信息、供应商信息，很少能天然直接给AI使用，所以项目团队花了大量时间做数据清洗和结构化。

更麻烦的是，要从这些数据里重新还原企业真实的业务逻辑，这个物料为什么这样映射，这种情况为什么这样报价，老师傅做这个判断到底依据什么。

这些东西不解决，模型再强也没用。

所以FDE在这里做的事情，其实很像经验复盘，要从企业现有的数据和人的经验里，把那套真正运行多年的业务规则挖出来，再把它重新变成AI能用的东西。

第三个挑战，比数据更难，是人。

这是企业AI项目需要重点关注的一点。

技术是相对静态的，人的反应是动态的。

比如一个岗位原来要3到5个人完成，现在老板说上AI以后可能只要1到2个人，员工第一反应常常是担心自己是不是要被优化、系统上线以后还有没有位置、是不是要被调去不想去的岗位，很少会先想到“这个系统真先进”。

这种抵触非常真实。

而作为乙方，项目团队其实没有权力去安排甲方员工，甚至从员工视角看，项目团队做的事情本身就威胁到他的岗位，他天然会对项目团队有抵触。

所以这个问题靠FDE团队解决不了，企业AI转型必须是一把手工程，老板必须真正认可，并且愿意自上而下推动。

这个项目里，项目团队会在立项前就和老板、项目相关方讨论生产力释放之后怎么办，方向是让省下来的时间转向更有价值的业务，简单裁人从来不是选项。

最终这家企业确实重新调整了相关人员的工作安排和KPI。

这项实践进一步验证了：AI落地的最后一道关，往往是组织架构的调整和转型。

六、FDE 交付方法与企业启示

做了几个项目之后，FDE的一个坚定判断是，FDE真正的功课，是让AI变成企业业务的一部分，把它装进企业只是开始。

这里面有几条经验对FDE比较重要。

第一，判断场景，先看它卡住的是不是企业最稀缺的人。

选场景的起点应该是业务瓶颈，模型能力排在后面。

报价这个场景之所以值得做，正因为看图纸、拆需求这些重复劳动占满了老师傅和技术骨干的时间，而他们对工艺、材料和可行性的判断，恰恰是企业最难复制的能力。

至于怎么筛，前面提过的三个条件，知识密集、有历史数据、瓶颈明确，缺一不可；用普通自动化就能解决的事，也不必硬套AI。

第二，别只盯着一个AI功能，要看完整业务链路。

如果项目团队只做图纸识别，这个项目的价值其实很有限。

识别只是入口，价值来自识别之后那条已经拆开的链路能不能整体跑通。

所以FDE要看的是端到端的业务流程，一个孤立的模型节点撑不起业务价值。

第三，数据治理本身就是项目的一部分。

很多人觉得企业把数据准备好之后，项目团队再来做AI，现实里往往相反，尤其是中小企业，进去之后很可能会发现数据本身就是乱的。

所以数据清洗、结构化、业务规则还原、经验沉淀，本身就是FDE必须参与的工作，把它当成前置准备工作会低估它的分量。

第四，拿阶段性结果跟客户对话，小范围验证之后再推广。

B端客户很多时候并不知道自己到底需要什么，所以项目采用边干边改，快速做出一个阶段性成果让客户看到，再通过真实反馈不断修正。

这种方式看起来不够完美，其实更符合真实业务。

落地上也一样，先找关键人和业务骨干用真实订单试，再让一个小组试，等结果稳定以后再扩大到部门，这样既降低技术风险，也降低组织层面的阻力。

第五，AI转型必须是一把手工程。

企业AI落地不是交付一个软件就结束了，当AI真正开始改变业务流程，它一定会继续影响岗位职责、KPI、部门协作甚至组织架构，这些事情不是一个乙方FDE能独立推动的，老板必须站出来。

所以更可持续的FDE合作模式，是成为企业长期的转型合作伙伴，做完一个版本、上线一个系统只是起点。

今天解决报价，下一步可能解决生产，再下一步可能进入供应链、销售或其他业务环节，一个场景一个场景地往前走，最后把整个业务闭环逐步重新设计。

最终项目团队要实现的，是一种新的组织状态，AI去承担那些可以标准化、可以重复、可以被数据化的工作，人重新回到判断、沟通、创造和业务增长上，这套系统只是载体。

项目实践表明这才是FDE真正应该推动的事情，把AI交付给企业只是过程，帮助企业重新设计人与AI一起工作的方式才是目的。

七、可复用的交付资产

同类项目若要复制这条路径，可以优先沉淀以下交付物：

• 场景访谈记录与 As-Is／To-Be 流程图
• 业务对象、关键字段、角色责任和异常分支清单
• 知识地图、文档清洗规则、切片规范和高频问题测试集
• 图像类型清单、标注样本集、识别错误集和人工复核规则
• Agent 工作流定义、工具调用清单、提示词版本和任务评测集
• 系统集成图、字段映射、权限配置、失败重试与回写日志
• 覆盖普通、复杂和异常任务的验收样本与业务指标口径

来源与作者

Datawhale《FDE案例100》，受访者：Stephen／崔逸枫（鲸语智能创始人）；PDF 第 169-180 页，书内页码 168-179。本文为访谈资料的第三人称整理，不是本站新采访。