Q1：作为FDE，你应用AI的具体场景是什么？在这个场景下遇到的具体问题长什么样？
我们这次选的是制造业里一个常见、却经常被低估的场景，非标产品的售前方案和报价。
这家企业大概有两三百人，营业规模在一二十亿元左右，业务属于典型的柔性制造，多品种、小批量，大量订单都是非标需求。
它和标准品企业不一样，标准品有固定SKU和价格，客户选完产品基本就知道多少钱；非标制造往往需要客户先发一张图纸，企业内部再去判断这个东西要做成什么样、用什么材料、关键尺寸是多少、结构和性能有什么要求、能不能生产、该用什么工艺、成本大概多少。
所以我一直觉得，这个场景只叫“报价”其实并不准确。更准确地说，它是一条完整的链路，图纸解析、需求拆解、研发协同、生产方案、成本核算、报价。
举个具体的例子。客户可能要加工一个轴承零部件，发来的不一定是一份标准数据，可能是PDF、CAD文件，也可能是其他不同形式的资料，里面写着材料、尺寸、关键部位要求、结构要求等信息。
过去企业需要有人把这些东西打开一项项看，再依靠专业经验，把客户的语言转成企业内部能够生产的语言。
单独看，任何一个动作都不算复杂，真正麻烦的是整条链路非常依赖人。
首先，它占用核心技术骨干。真正懂工艺、懂材料、懂制造可行性的人，在制造企业里通常比较稀缺，但大量非标订单进来以后，他们不得不花很多时间做售前方案、看图纸、拆需求、估成本。
其次，报价准确率直接影响利润。价格报高了，订单可能丢掉；价格报低了，单子虽然拿到，生产时才发现成本覆盖不住，利润空间被挤掉。
第三，还有一个经常被忽略的问题是响应速度。客户的询价不会一直等你，如果某个技术骨干正好在忙，报价卡在那里几天，这个售前节点就可能直接卡死，最后订单流失。
我们选这个场景，并没有从“AI现在能识别图纸”出发。
判断顺序正好反过来，一个场景值不值得做AI改造，我通常先看三件事：有没有大量知识型工作，比如分析、判断、设计和经验复用；有没有一定规模的历史数据可以使用；现有流程里有没有非常明确的效率瓶颈。
如果只是简单的自动化流程或者需求价值不高的场景，我觉得根本没必要上AI。
图1：工单识别
图2：AI工艺单智能解析与BOM生成、接单风险预估（纺织行业）
图3：研发协同平台
图4：AI图纸智能解析与工艺路线生成、阶梯报价（机加工行业）
Q2：在你参与之前，这个问题过去是怎么解决的？
在AI介入之前，客户图纸过来以后，业务人员、技术人员或者企业里的老师傅打开文件，根据自己的经验理解客户要求，再把信息整理出来，然后去查企业自己的物料、供应商和历史价格。本质上，这是一个纯人工的信息理解、结构化和匹配过程。
之前没有成熟的多模态能力，很难让系统直接理解不同格式的图纸，也很难把大量非结构化资料自动转成结构化信息。企业自己的知识同样不够标准，一个零部件为什么这样报价，很多时候都写在老师傅脑子里，他清楚某个材料应该找哪个供应商，某种工艺大概需要多少成本，什么情况下该给客户留一点余量。
企业过去也试过用系统把这件事接起来，早期上过ERP和报价模板，想用固定字段把报价流程管起来。这类系统擅长的是“你把字段填进去，我按规则往下跑”，最难的第一步，也就是把客户五花八门的输入理解成标准数据，始终没人解决。所以系统最后只能覆盖标准件和固定SKU，非标部分照样回到人，模板反而多填一遍表。
问题真正爆发，是在业务规模和复杂度上升以后。订单越来越多，非标需求越来越多，人的处理能力却不会同比增长。一个关键技术员一天能看的图纸、能处理的询价是有限的，需求一来多，整个售前链路就开始排队。经验长期握在少数人手里，也意味着企业很难把这种能力复制出去。
所以我们真正想解决的，是一个新问题：当业务规模继续扩大时，能不能不再靠增加更多人、更多老师傅来撑住报价能力。报价能力，是影响一个制造业供应链企业生死存亡的核心能力，关系到这个企业的响应速度、服务能力以及利润空间。
Q3：后来你使用AI解决这个问题的整体思路和关键步骤是什么？
图5：客户沟通记录
做这个项目，我没有拿着一个模型去问客户“这个模型能帮你干什么”，工作顺序一直是反过来的，先理解业务，再拆流程，再判断哪些环节该用AI。
我们先去复现传统人工操作的业务流和数据流，通过还原实际SOP，结合AI大模型与Agent编排能力，去梳理输出企业AI再造后的新业务流程。
FDE在这里更像一个连接器，一头听懂企业在说什么，一头清楚当前大模型、Agent和各种AI工具能做到什么，再把两边拼成一个能落地的方案。
第一步，是把“报价”重新拆成一条业务链路。
前期我们深入做了需求调研和业务调研。进场之后我先去了车间，看一个订单从图纸到交付到底经过哪些环节，又翻了一批历史报价单，找业务人员和老师傅分别聊，问他们拿到一张图纸后第一件事做什么，谁看图纸，谁做需求拆解，谁定物料，谁判工艺，谁核成本，谁最后报价，不同角色之间怎么交接。只有把这些都搞清楚，才能知道AI应该放在哪个位置。
第二步，是先解决非结构化信息的入口。
客户发来的图纸格式不统一，有的PDF、有的CAD，所以第一步要利用多模态能力，把图纸里的材料、尺寸、结构要求等关键信息抽取出来。但我们的目标不止于“识别图纸”，识别之后必须结构化，因为只有结构化以后，这些数据才能继续进入后面的业务流程。
第三步，是让AI进入企业自己的业务规则。
这一步很关键。AI提取出客户需求之后，不能直接凭模型自己的知识报价格，企业内部有自己的物料库、供应商体系和长期形成的报价逻辑，所以报价必须基于这家企业自己的条件。我们会把结构化后的客户需求，与企业自己的物料、供应商、历史数据和报价规则做匹配，再通过垂类Agent把这些环节串起来。这样出来的结果，才是企业真正可以拿去用的报价。
这个设计也是调整出来的。一开始我们想得比较直接，觉得模型看懂图纸、抽取字段，后面按规则一算就能出价。真正到现场跑起来才发现，端到端直接出价，出来的数字经常对不上真实成本。所以我们改了方案，让模型先只负责把图纸信息结构化，报价环节再回到企业自己的物料和规则库里做匹配，每一单都经过人工校准才对外输出。
第四步，是把老师傅的经验变成企业的数据资产。
企业原来的很多工艺知识都存在人脑里。AI介入之后，我们开始把这些知识逐步标准化、流程化，哪些物料怎么映射，某类需求通常走什么工艺路线，报价时有哪些判断逻辑，都可以逐步沉淀下来。同时我们设计了人工校准和回填机制，AI第一次给出的结果不一定完全正确，业务人员会修改，修改完之后就把这次修改重新沉淀到数据、向量数据库或者相关模型里。
这样就形成一个数据飞轮，AI生成、人工校准、数据回填、下一次结果更好。
第五步，是不等所有需求都搞清楚再开发。
前期调研不可避免，我们也会深入现场、开很多次会，但我一般不会等所有信息都完全掌握之后，再关起门来做几个月。我的方式是边干边改，客户给我一部分输入，我就先给他阶段性产出，可能是Demo、一个流程，也可能是某个功能，让他先看是不是这个意思、这个东西到底能不能解决他的问题，客户反馈之后我们继续调整。整个过程中可能来回几次，甚至十几次。
B端项目有一个很现实的问题，有时客户自己都不知道自己真正需要什么，FDE不能只记录需求，还要不断拿阶段性结果去帮客户澄清需求。
第六步，是先让关键人试用，再逐步推广。
产品做到可以运行之后，我们不会马上让所有人用，先找关键人试，让最懂业务的人拿真实订单跑，发现问题再修改；接下来再让一个业务小组试运行，这个阶段仍然不断收集问题。这个项目里试运行周期大概是1到2个月，我们围绕几个真实订单不断验证，同时继续调整需求。等到结果基本可用，再做部署、数据集成、启动会和全员培训，最后逐步扩大到整个部门。
整个推广路径就是关键人试用、业务小组试点、真实订单验证、反馈调整、部门推广。
我认为这种方式比一次性开发完成再宣布上线可靠得多。
Q4：相比传统方式，使用AI后的实际效果如何？
这个项目刚上线的时候，并没有立刻达到理想状态，前两个月一直处在磨合和微调阶段。因为我们最终看的，是这个结果能不能真正被企业拿去报价，模型能不能输出一个结果反而是次要的。
目前来看，整体效果已经比较明显，至少能减少50%以上的相关工作量。但如果只把“节省50%工作量”当成全部价值，还是低估了这个项目。
我们内部评估效果，会看几个层面。第一是响应速度，原来人工完成一套报价要多久，现在通过这套流程要多久；第二是报价结果本身的可用性和准确率；第三是前面图纸解析的准确率；最后还是要回到第四层，它到底给企业运营带来了多少价值。
这里发生了一个很有意思的变化。原来这项工作可能需要3到5个人参与，AI介入以后，一部分重复劳动可以由系统完成，实际需要投入的人力明显减少。企业并没有简单地把剩下的人裁掉，这家企业本身处在上升阶段，老板希望做的是把人的生产力释放出来。
原来业务人员很大一部分时间耗在看资料、整理需求、反复核对这些事情上，这部分时间省下来之后，他们可以回到本来的业务工作，去联系更多客户、谈更多项目、接更多订单。企业随后也会相应调整这些岗位的KPI和职责，让考核更偏向真正的业务价值。
所以我理解的降本增效，核心是原来5个人的大量时间被低价值重复劳动占用，现在把其中一部分生产力释放出来，让人去做更需要判断、沟通和创造价值的事情。这才是AI真正进入业务流程之后应该产生的变化。
Q5：在部署AI过程中，是否遇到了新问题或挑战？你是怎么解决的？
这个项目真正困难的地方，我觉得不完全是技术。立项之前，能不能做、当前模型能力到什么程度、有什么风险，我们一般会先判断。真正进入项目以后，遇到的坎主要有三个，图纸识别能不能达到报价要求、企业的数据质量、以及组织里人的接受度。
第一个挑战，是图纸识别在真实场景里达不到报价的要求。
客户图纸远比想象中杂，有PDF、CAD，还有各种扫描件，清晰度参差不齐。模型在干净样例上效果不错，一旦碰到手写标注、特殊符号、非标准图框，抽取字段就经常出错。报价是要对外的，一个尺寸抽错会直接影响成本。我们的办法是给识别加一道人工校准兜底，业务人员只审那些模型把握不大的字段，审完再把修正结果回填到模型和数据里，识别准确率随着真实数据越滚越高，人工要审的部分越来越少。
第二个挑战，是企业的数据远没有想象中标准。
很多中小制造企业的数据基础比较薄弱，进去以后你会发现，各种资料、历史报价、物料信息、供应商信息，很少能天然直接给AI使用，所以我们花了大量时间做数据清洗和结构化。更麻烦的是，要从这些数据里重新还原企业真实的业务逻辑，这个物料为什么这样映射，这种情况为什么这样报价，老师傅做这个判断到底依据什么。这些东西不解决，模型再强也没用。
所以FDE在这里做的事情，其实很像经验复盘，要从企业现有的数据和人的经验里，把那套真正运行多年的业务规则挖出来，再把它重新变成AI能用的东西。
第三个挑战，比数据更难，是人。
这是我现在做企业AI项目感受最深的一点。技术是相对静态的，人的反应是动态的。比如一个岗位原来要3到5个人完成，现在老板说上AI以后可能只要1到2个人，员工第一反应常常是担心自己是不是要被优化、系统上线以后还有没有位置、是不是要被调去不想去的岗位，很少会先想到“这个系统真先进”。这种抵触非常真实。
而作为乙方，我们其实没有权力去安排甲方员工，甚至从员工视角看，我们做的事情本身就威胁到他的岗位，他天然会对我们有抵触。所以这个问题靠FDE自己解决不了，企业AI转型必须是一把手工程，老板必须真正认可，并且愿意自上而下推动。
这个项目里，我们会在立项前就和老板、项目相关方讨论生产力释放之后怎么办，方向是让省下来的时间转向更有价值的业务，简单裁人从来不是选项。最终这家企业确实重新调整了相关人员的工作安排和KPI。这件事让我更加确信，AI落地的最后一道关，往往是组织架构的调整和转型。
Q6：根据你的经验，我们怎么才能更好地把AI部署到实际业务中？
做了几个项目之后，我的一个坚定判断是，FDE真正的功课，是让AI变成企业业务的一部分，把它装进企业只是开始。这里面有几条经验对我比较重要。
第一，判断场景，先看它卡住的是不是企业最稀缺的人。
选场景的起点应该是业务瓶颈，模型能力排在后面。报价这个场景之所以值得做，正因为看图纸、拆需求这些重复劳动占满了老师傅和技术骨干的时间，而他们对工艺、材料和可行性的判断，恰恰是企业最难复制的能力。
至于怎么筛，前面提过的三个条件，知识密集、有历史数据、瓶颈明确，缺一不可；用普通自动化就能解决的事，也不必硬套AI。
第二，别只盯着一个AI功能，要看完整业务链路。
如果我们只做图纸识别，这个项目的价值其实很有限。识别只是入口，价值来自识别之后那条已经拆开的链路能不能整体跑通。所以FDE要看的是端到端的业务流程，一个孤立的模型节点撑不起业务价值。
第三，数据治理本身就是项目的一部分。
很多人觉得企业把数据准备好之后，我们再来做AI，现实里往往相反，尤其是中小企业，进去之后很可能会发现数据本身就是乱的。所以数据清洗、结构化、业务规则还原、经验沉淀，本身就是FDE必须参与的工作，把它当成前置准备工作会低估它的分量。
第四，拿阶段性结果跟客户对话，小范围验证之后再推广。
B端客户很多时候并不知道自己到底需要什么，所以我习惯边干边改，快速做出一个阶段性成果让客户看到，再通过真实反馈不断修正。这种方式看起来不够完美，其实更符合真实业务。
落地上也一样，先找关键人和业务骨干用真实订单试，再让一个小组试，等结果稳定以后再扩大到部门，这样既降低技术风险，也降低组织层面的阻力。
第五，AI转型必须是一把手工程。
企业AI落地不是交付一个软件就结束了，当AI真正开始改变业务流程，它一定会继续影响岗位职责、KPI、部门协作甚至组织架构，这些事情不是一个乙方FDE能独立推动的，老板必须站出来。
所以我理想中的FDE合作模式，是成为企业长期的转型合作伙伴，做完一个版本、上线一个系统只是起点。今天解决报价，下一步可能解决生产，再下一步可能进入供应链、销售或其他业务环节，一个场景一个场景地往前走，最后把整个业务闭环逐步重新设计。
最终我们要实现的，是一种新的组织状态，AI去承担那些可以标准化、可以重复、可以被数据化的工作，人重新回到判断、沟通、创造和业务增长上，这套系统只是载体。
我觉得这才是FDE真正应该推动的事情，把AI交付给企业只是过程，帮助企业重新设计人与AI一起工作的方式才是目的。