我之前写过一篇文章，是专门去讲FDE这个岗位的。而这周末跟一个做FDE的朋友约了顿饭，聊了很久。
FDE，前线部署工程师，一个被 AI 落地困境重新激活的角色。他去过制造业工厂、知识产权公司、国央企，见过各种「接了 AI 但用不起来」的现场。
我想知道的是，那些说要做 AI 转型的企业，卡在哪了？FDE 这个角色到底在做什么？他们看到的现场和我们想象的有什么不一样？
聊完以后，我发现模型能力往往不是最先出现的障碍。真正费力的是把一句模糊的需求还原成业务流程，在数据、权限和组织限制里找到入口，再判断哪些经验值得交给 AI。
FDE 这个角色，恰好站在这些问题中间。
客户说出来的，往往只是现象
我问他 FDE 工作中有没有印象中特别深刻的客户案例？
朋友先讲了一个制造业客户的案例。
这是一家风力发电零部件厂商，给 GE、西门子等企业供货。业务从「来图加工」开始：客户发来询价邮件和 PDF 图纸，企业完成图纸识读、工艺核算和报价审核；中标以后，再进入下单评审和 ERP 建档。
市场部收到询价邮件后，先把客户和物料信息录进 Excel，再把表格交给采购部。采购判断内采还是外采，需要外采的再转给技术部核价。技术人员再把总成拆成组件、零件和原材料，按原材料、标准件、下料折弯、机加工、表面处理、焊接热处理、外协加工七个单元核算，最后把结果交给业务经理审核。
一张表格要过四个部门的手。中间可能丢信息、对错口径，这些核算公式散落在不同版本的 Excel 里。历史报价和相似件记录存放在个人电脑中，议价后的二次报价缺少统一版本，中标后还要把物料、BOM 和工艺路线重新录进金蝶。报价成功率、失单原因和任务进度，也没有形成连续的数据。
同一个零件由不同的人核算，结果也未必一致。历史报价和相似件经验存在人的记忆里，很难稳定复用。
他回忆起到现场的第一印象：
我们去到客户现场的时候，发现他们整套报价流程的工具就是一个 Excel 表格 加邮箱。信息分散、容易丢、没法追溯。但他们就这样干了好几年。
表面上，是一张 Excel 在四个部门之间流转。真正断开的，是从询价邮件、图纸、核价、审核，到中标建档和经营分析的整条链路。客户说「流程乱」，只能描述结果；FDE 要继续追问，究竟是哪一段信息没有被接住。
他强调，大量中小制造企业的内部流程都是这个状态，现有的流程全靠人工维护，没有系统兜底。企业知道 AI 能帮上忙，但你问他具体帮什么，他说不上来。
这类企业不是不知道有问题，是说不清楚问题长什么样。梳理每一个环节人在具体场景和真实的需求，这也恰恰是 FDE 的核心能力和难点。
SaaS 实施顾问、数字化转型团队、内部 IT 项目经理会遇到同样的处境：你以为客户需求不清晰，其实是他们的流程本身就是模糊的，说不清才是常态。
FDE 进到现场之后，还得跳出来看问题
对话里有一个很重要的澄清点，很多人听到 FDE 这个岗位，第一反应是，又是 AI 时代冒出来的新工种。
但其实这个角色 20 年前就有了。当时有个公司叫 Palantir，服务的是 CIA、NSA 这些美国情报机构。情报数据高度保密，需求又模糊，传统的软件交付方式根本走不通。Palantir 的做法简单粗暴，把工程师直接派进客户的办公室，一住就是半年起步。
到今天，这个岗位被企业 AI 落地的困境重新捡起来了。
我问他，FDE和其他角色有什么区别？ 他用排除法划了边界。FDE 不是售前，售前负责画架构图、讲产品能力，但不写生产代码。
他说：
FDE 这个角色，一定是把客户的业务真正融入到 AI 能解决的场景里面，同时要把公司各个业务模块、各个部门之间的系统全部打通。你不打通，就会形成部门之间的数据孤岛，那也没有形成真正的企业 AI 化。
他举了一个很具体的场景：企业有 ERP 资源管理系统，销售有 CRM 客户管理系统，运营有 OA，人事有招聘系统，财务有财务系统。每个部门各跑各的，数据流不过去，信息出不来。FDE 要做的事，是站在这些系统中间，先搞明白业务怎么流转，再判断 AI 在哪个节点能切进去，最后把这些孤岛连起来。
企业 AI 化不再是「买一个产品」的采购行为，而是企业有没有「重构一套流程」的系统工程。
如果非要用一句话定位这个角色，更接近懂 AI 的 CTO，而不是会用 AI 工具的人。既懂业务、又懂技术、又懂 AI，同时还愿意去现场跟客户聊需求。这种复合型的人，目前在国内确实稀缺。
当一个新角色很难一句话讲清时，先划清边界，再指向核心能力，比直接下定义更不容易被误解。做 SaaS 交付的实施顾问、帮甲方做选型的技术顾问、负责内部系统落地的信息化团队，只要工作核心是把 AI 或系统落进一家真实企业，拆清楚流程的能力都比写代码更关键。
转成 FDE 前，他是 AI 产品经理
我顺着这个岗位边界继续问他，转成 FDE 前是干什么的？
他回答得很直接：
转成 FDE 前，我是做 AI 产品经理的。当时主要做数字员工 SaaS 平台，为每一个数字员工搭建对应的 Agent 模板和 RAG 知识库，也会对标飞书 AI 在办公场景里的能力。
这里的「对标」不是把飞书的功能列表抄一遍。他们会拆飞书 AI 案例中的提示词优化方案和系统提示词，看它调用了哪些工具，怎样与用户交互，又是怎样调回答风格的。
他说：
我们还会参考飞书 AI 的办公场景，用企业自己的真实数据去训练和调优，让模型学会这家企业的语言和业务逻辑。它要能理解企业的组织架构，接入并调用飞书全套 API，再继续做工具调用强化、指令微调和知识库集成。
他当时做的，准确说是一组面向办公场景的数字员工：让每个 Agent 都能理解对应的企业知识和组织关系，也能调用工具完成具体工作。
做这些工作的时候，他越来越在意一个问题：产品需求到底是从哪里来的？
据他的描述：
这类平台的需求，很多来自老板拍脑袋，或者各个部门小伙伴讨论出来的想法，最多再去拆一些竞品。但产品更需要的，其实是从业务侧回来的需求。真实的人，在具体场景里提出的真实需求，这种需求才值得回到产品里。
这不是说老板、部门讨论和竞品分析没有价值，而是这些信息都隔着一层。它们能告诉产品经理「大家想做什么」，却不一定能回答：谁会在什么场景里使用，原来的工作怎样完成，真正卡住人的那一步在哪里，功能上线以后有没有改变结果。
他想把这一层补回来。
做产品也好，做 FDE 也好，都应该先去看真实的人、真实的场景和真实的需求。这是我后来想继续发展的方向，所以我转去做了 FDE。
AI 产品经理的经历并没有在转岗后失效。数字员工 Agent 的设计、RAG 知识库、提示词与工具调用调优，仍然帮助他理解模型怎样进入办公流程；真正变化的是，他不再只等需求回到产品里，而是走进业务现场，去看需求怎样发生，再为它能不能进入生产负责。
进入 FDE 以后，他的工作并不是只剩下驻场交付。用他自己的划分，这份岗位同时包含两类职责：
现在 FDE 的工作有两部分：一部分是这个岗位保留的售前解决方案事项，另一部分是 AI 时代新增的 FDE 事项。
FDE 的一天，很少只做一件事
我问他，FDE 每天在干什么？是不是大部分时间都在客户现场写代码？
他先纠正了我的这个想象。FDE 确实要去现场，也要理解技术，但这个岗位的一天很少只做一件事。
从客户前期的需求对接到最后的项目交付，整套全流程是 FDE 需要跟完的。针对多个客户、多个需求，以及重复出现的售前准备和方案，也要思考怎么用 AI 沉淀下来，做成流程和 SOP。
第一次接触客户，要先了解业务，问清楚数据从哪里来、团队现在用什么工具、最想改变什么结果；到了现场，要跟着一线员工走一遍真实流程，看他们怎样找邮件、传表格、改公式，又在哪里绕开系统。回到公司，还要把这些口语化的描述翻译成业务对象、数据字段、权限、规则和异常路径。
项目进入交付以后，FDE 还要和研发继续对齐：客户为什么这样提需求，哪些部分必须兼容，哪些共性需求值得回流产品，低置信度结果怎样转人工，方案怎样接进 ERP、企业微信等已有系统。做出一版以后，再拿真实业务去验证，继续找现场和方案之间还差哪一段。
所以，「FDE 每天在干什么」很难用一张固定日程表回答。按他的描述，工作会在客户沟通、现场观察、方案整理、研发对齐和真实业务验证之间切换。表面上一直在换事情，实际都指向同一个结果：让客户说出来的现象，最后变成团队能交付、客户能使用的业务闭环。
第一步：把客户说不清的需求捋出来
朋友说他们去了客户现场，到了才知道，客户说的「流程混乱」，其实就是一张 Excel 表格在四个部门之间来回传。市场部从邮箱下下来，填完传采购，采购转给技术核价，核完再丢给业务经理审核。每一步都是人工，每一步都可能丢。
很多人以为FDE接到的是标准化的需求文档，实际情况完全不是。FDE接到的原始需求，很少是标准化的、流程化的。FDE 的工作就是去到客户现场，弄清楚他们真实的工作流是什么样的，然后判断哪里能用 AI 接进来，哪里还是得靠人来审核，来把关。
最后做的，是把这条链路串起来。定时从邮箱抓取询价邮件，AI 意图识别邮件内容，自动判断并生成询价单，低置信度的地方转人工，高置信度的全自动推进；内部核价走公海池认领机制；历史件和物料库直接调取，不用重新录入。最后打通金蝶云星空和企业微信，让数据在系统之间自己流动。
他强调这一点：
很多人对 FDE 的想象是去到客户现场驻场，梳理完需求直接全栈开发。但实际上，客户能说出来的往往是现象，不是问题。他们说流程太乱，翻译过来是一张 Excel 表格在不同部门之间手工来回流转，是一张 PDF 图纸需要人工截取分几次上传到表格当中，是一套繁琐的流程。FDE 要做的，是把这句模糊的描述，翻译成可以被机器接管的系统逻辑。
B 端产品的真实处境和这个一模一样。客户说「我想要一个审批系统」，翻译过来很可能是「我现在审批要等三天，我受不了了」。你直接去做审批系统，你在解决症状。先去看他们怎么审批，才能找到真正的堵点在哪一环。进场不是去给答案，是去看清楚问题长什么样。
第二步：在限制条件里找办法
朋友讲了第二个例子，是在知识产权行业。
知识产权服务的市值有 3000 亿元，它的背后是专利许可、技术转让、品牌授权更大的产业价值。比如说华为，每年靠专利授权收取几十到上百亿；中船集团，每卖出一艘 LNG 船，就要向欧美专利方缴纳几千万美金的使用许可费；网上还有个说法：迪士尼的法务团队，会全球追杀任何一处未授权使用它 IP 的图片。知识产权不是辅助职能，它是企业无形资产里最有价值的那块。
做了才发现，FDE 在这个行业要打交道的，不只是研发团队。法务、知识产权部门、市场，甚至要直接跟老板谈。因为客户每一次知识产权决策，背后都是管理层的战略在驱动。新开一条技术线，专利布局怎么走、怎么防被人仿制，都是老板和法务在战略层面拍板的。
FDE 要能在这个链条的每一层把事说清楚，这不是技术问题，是沟通和组织的问题。
有一类客户对数据泄露、数据安全比较敏感，国央企、军工、航天。核心技术数据不能离开厂区，用豆包写个报告，数据都要考虑泄露风险。
很多技术人员遇到安全边界时，第一反应是说服客户放宽限制。他们的做法反过来，是把 AI 搬进去。
带着一台搭载本地微调模型的离线设备直接进厂，128GB 内存，不联外网，数据不出厂区。研发人员写交底书，过去要花一到两天，现在在本地离线环境或内网里跑完，不碰任何云端。
问题不是 AI 能不能用，而是数据能不能出去。遇到这种情况，不是劝客户降低安全标准，而是要带着解决办法进去。
云端大模型的能力和企业数据安全边界，天然冲突。很多技术人员遇到安全边界时，第一反应是说服客户放宽限制。这个做法反过来，约束是事实，方案要在约束内长出来。医疗行业的患者数据不能出院、金融系统的核心数据不能上公有云、政务系统要在国产化环境里跑，这些约束不会因为 AI 变强而消失。约束不是拒绝理由，是每次方案设计的起点。
FDE 的工作不只是让客户用上 AI，还要在他们的约束里，找到 AI 能进去的那条路。
第三步：做 FDE 最难的是什么？
我问他，做 FDE 这么久，觉得最难的事情是什么？
结果，他想了想，说：
假装抽烟。
我以为在开玩笑，但确实他本人不抽烟，也不喜欢烟。他说 FDE 外派到一家企业，刚进去的时候，现场的人基本都不认识。想了解业务，第一步不是马上问流程，而是先让别人认识你；想继续问到真正的细节，至少得先跟人搭上话。
现场不少技术同事会去抽烟角。为了跟他们聊到一块，他也会跟着去，点一根，假装吸一口，含在嘴里再吐掉。
烟不是重点，它只是给这场交流留出了一个气口。他不用一上来就拿着需求表追着人问，先跟着站一会儿，聊几句。等大家不再把他当成一个完全陌生的外派人员，真正的工作细节才会慢慢出来。
一些在正式会议里不容易展开的细节，反而会在这种时候被聊出来。大家熟悉以后，他才能继续问下去：平时真正的流程是怎么跑的，为什么一直这样做，哪些经验是干了很多年才留下来的。
这个故事听起来有点好笑，却刚好解释了 FDE 为什么不能只懂技术。
FDE 每进入一家企业，面对的都是一群陌生的人和一个陌生的行业。别人不认识你，就很难把真正的工作细节告诉你；拿不到这些一手信息，后面再完整的需求文档，也可能只是经过几次转述之后的结果。
所以对他来说，假装抽烟不是为了学会应酬，而是先跟对面的技术人员聊到一块，降低沟通成本，尽快摸到这个行业真正的 know-how。
他不是把自己关在工位上猜业务，而是先想办法让最懂现场的人愿意开口。别人干了很多年才形成的经验，他不用从头踩一遍坑，就能更快摸到门道。
后来再听他讲怎么研究竞品，我才发现，假装抽烟和约竞品演示，表面上完全是两回事，用的其实是同一种办法：不要关起门从头硬啃，先去找已经懂这件事的人，借别人的路径把行业的基本框架搭起来。
但拿到一手信息还不够。
现场的人愿意把经验告诉你以后，下一道题才真正开始：这些经验里，哪些是真正的行业规律，哪些只是多年没有改掉的习惯？哪些应该交给 AI 学，哪些反而不该被自动化？
他用报价系统举例，做的时候，中间有一个环节是让 AI 学客户的核价逻辑，不止 Excel 表格当中的公式，还有客户的工程师怎么算成本，哪些零件可以压价，哪些供应商可以绕开报价直接走历史价。这套东西是十几年沉淀下来的，他们要把它喂给模型。
喂着喂着会发现，里面有两种东西混在一起，一种是真实的行业规律，一种是因为流程设计不好、操作习惯懒，或者历史原因形成的变通方式。有个字段，客户说「这个填 0 就行，反正我们系统里都是手动改的」。这种习惯要不要让 AI 学？
我们的挑战不在技术，而在行业认知。这个行业有它原来的工作方式、人工经验、知识积累。但怎么从这些东西里，找到真正是 AI 该学的？哪些是因为人自身的局限积累下来的，不应该被 AI 继承的？怎么去伪存真，让 AI 学该学的，把不该学的摒弃掉，这个才是真正难的地方。
陌生行业又不会停下来等 FDE 学半年。他后来摸出另一个很直接的方法：把自己放在客户的位置，去约老牌 ERP 或行业产品做演示，让对方带着他从头走一遍系统。每到一个页面，他就继续往下问：为什么这里要审批，为什么物料要分层，为什么同类产品的处理方式不一样。
每一步、每一个点击、每一个 Tab，我都会问：这个背后的逻辑为什么这样设计？为什么和我之前看的产品不一样？他们是基于什么考量？这是我后来发现的，最小成本快速了解行业 know-how 的方法。
把这两件事放在一起看，就更容易理解他做 FDE 的方式。抽烟角里，他借的是现场研发和技术同事的一手经验；演示会上，他借的是成熟产品已经走过的路。前者让他知道这家公司实际上怎么干，后者让他知道这个行业通常怎么干。
这不是偷懒，也不是少做一步，而是不把时间浪费在别人已经走过的路上。FDE 不可能每到一个陌生行业，就先关起门研究半年再开始工作。知道该找谁、该看什么、该去哪里问，让自己尽快补到能做判断的位置，这种会借力、会找最省力入口的能力，本身就是 FDE 很核心的一部分。
产品界面只是表面，每一个长期存在的按钮背后，通常都有一段业务历史。竞品能告诉你这个行业通常怎样运行，客户现场再告诉你这家公司实际上怎样运行。两者之间的差异，往往就是 FDE 真正要处理的地方。
这个判断做不好，AI 学到的不是行业智慧，是行业的坏习惯。
他接着解释，一套流程里，客户二十年的操作经验是有价值的，他们知道哪个供应商不靠谱，哪类询价单意向低可以降优先级。但同时，他们也积累了大量绕过流程漏洞的习惯、因为系统难用而形成的手工补丁，还有一些本来就错了但没人改的默认做法。AI 照单全收，这样学出来的系统跑起来更像是给这些坏习惯加了个自动化外壳。
他认为，数据里有两种东西，一是沉淀下来的真实价值，二是一直延续到今天的低效习惯。AI会把两种都学走，你得先把它们区分开。
FDE 要能拿捏的不只是技术实现，而是四种判断：
业务理解，看懂这家企业真实的目标、流程和痛点；
AI 判断，分清哪些问题适合模型接，哪些不该交给机器；
工程融合，把系统、数据、权限、部署这些细节跑通；
组织推动，让方案不只是跑通，还能在客户的组织里真正活下去。
四件事里最容易被低估的是第二件。很多人觉得 AI 判断是技术问题，实际上它更多是业务问题，你得同时懂行业规律和模型能力，才能看清边界在哪里。任何一个组织，只要是想让 AI 学习内部经验，都会遇到同样的问题。驾驭 AI 之前，先搞清楚哪些人类的经验是否值得被继承。
第四步：找到实际切入的环节
朋友他举了一个前段时间他去江西，拜访一家年产值八亿多的工厂的场景。
工厂用的 ERP 是 19 年前开发的，界面风格跟 XP 一模一样。你说老板不知道 AI 吗？知道，也觉得有用，就是不知道怎么落进自己的公司。
他们分享完方案，这位 60 多岁的老板当场说，「我能不能先给你付个费？」现场就给自己雇了一个 AI 战略顾问。后来老板告诉他们，准备拿出 500 万预算，要把公司打造成这个行业的 AI 标杆。
企业不是不想做 AI，是不知道第一步从哪开始。技术供应商给的方案太宏大，业务部门提的需求太零散，中间缺一个能把「我想用 AI」翻译成「从这三个环节切入」的角色。
很多AI供应商一上来就推方案，技术供应商给的方案太宏大，业务部门提的需求太零散。
他的做法不一样，每次第一次见客户，会先说，我想先花几分钟了解一下你们的业务，这样我给的建议才靠谱。帮我回答五个问题：
现在的业务场景和业务流是怎样运行的？
获客和数据渠道有哪些，数据从哪里来？
团队平时怎样处理这些工作，用表格、系统，还是主要靠人盯？
用过哪些接近 AI 的工具，实际体验怎样？
最终希望 AI 帮业务实现什么结果？
前面三问还原现状，第四问了解已有认知和边界，第五问把注意力拉回结果。客户说完，他只做一件事，把客户刚才讲的业务流复述一遍，在每个环节标注，这里 AI 能切进来，这里暂时不能。需求是从客户自己脑子里梳理出来的，不是拍脑袋想出来的。
我们现在更侧重问客户：你到底要达到什么效果？围绕这个目标，再想各种解法，不管 AI 还是其他技术，来达成业务结果，都可以引进来。跟以前不一样的地方是：从第一性原理出发，围绕客户业务的效果考量，而不是接客户已经过滤好的中间需求。
客户说「我想要一个审批系统」，翻译过来很可能是「我现在审批要等三天，我受不了了」。你直接去做审批系统，你在解决症状。先问「你希望审批在多长时间完成」，你才是在解决问题。
产品需求评审里同样成立。开发团队提需求说「要做某个功能」，下一个问题不是「排多少期」，而是「如果不做这个功能，现在的问题会怎样」。
从功能往回推期望结果，需求的优先级会更好判断。AI 不是功能，是结果的实现路径。照着功能列表做出来的东西，不代表客户会觉得好用；先对齐结果再谈实现，项目返工的概率会低很多。
功能上线了，项目也不一定算交付
我问 FDE 的核心 KPI，也就是交付预期，应该怎么定？
这个问题在报价系统里尤其具体。他后来补充，图纸识读、核算公式、线上流程、物料数据、金蝶云星空 ERP 对接和经营看板六项交付现在都已经完成。ERP 已经打通，报价链路进入了实际生产流程，原来反复录入和跨部门倒手的环节被替代，生产效率也已经得到提升。但功能做完以后，项目是不是就算交付成功了？
他先把方向拉回客户想要的结果。
要明确挖掘出客户的目标和诉求，这个诉求一定要对应到业务结果。比如提升内部生产效率，或者实现一个更有竞争力的核心指标突破。最终是促成客户的业务成功，而不是单纯交付一个软件系统。
聊到这里，我把他的回答往「怎样验收一份 FDE 交付」上又收了一步。他说的「客户业务成功」适合做方向，但很难直接作为 FDE 唯一的考核数字。成交率还受到价格、市场、销售能力和客户预算影响；模型准确率又太局部，它无法证明一整条业务流程真的跑了起来。只看功能完成数更不够：就算六个模块全部上线，如果员工仍然回到 Excel 和微信群里处理，项目还是没有完成改变。
如果一定要提炼一个核心指标，我建议叫有效业务闭环率。
它衡量的不是系统能不能打开，而是在双方约定的范围里，有多少真实业务实例能够质量达标地走完该走的流程，成功进入下一业务节点，同时留下完整、可追溯的记录。发生异常时，任务要进入明确的人工路径，而不是在系统里悄悄丢掉。
真正计算时，分母是事前约定范围内、按规则去重后的全部真实业务实例，不管它最终有没有进入新系统；分子是沿实际业务分支走完流程、关键结果合格、记录可以追溯的实例。人工接管不自动等于失败。项目本来就把低置信度结果设计为转人工，只要它在正确节点被接住，并继续完成后续流程，仍然可以算一次闭环。但如果大量任务都被甩给人工，效率和使用护栏会直接把问题暴露出来。
放到报价系统里，一个业务实例就是一条有效询价任务。从邮件和图纸进入系统开始，完成意图识别、图纸字段提取、核价任务分配、公式与参数执行、报价审核和报价单输出；如果中标，再把对应数据推入 ERP。只有这条路径按实际分支跑完，关键结果正确，状态、版本和责任人能够找到，才算一次有效闭环。
但这个「闭环率」不能单独看，还要放四个护栏，防止最后得到一个很漂亮、业务却没改变的数字。
效率护栏，看重复录入、跨部门倒手和单次业务需要的人力有没有减少；
质量护栏，看关键字段错误有没有被自动放行，低置信度结果能不能正确回到人工；
使用护栏，看真实业务是不是进入系统，而不是员工登录过一次以后继续使用旧表格；
资产护栏，看公式、行业规则、失败案例和评测样本有没有沉淀下来，下一次交付能不能复用。
回头再看报价系统的六项交付，它们也能被翻译成一套通用预期：图纸识读代表 AI 判断可评价、可接管；核算公式系统化代表业务规则可配置、可追溯；全流程线上化代表业务能闭环；物料统一代表数据和经验可复用；ERP 对接代表方案进入真实生产系统；经营看板代表交付结果能够被看见、被管理。
不同项目的业务例子当然不同。报价系统是一条询价任务，知识产权场景可能是一份技术交底书，客服场景可能是一张工单。统一的不是大家都追同一个准确率，而是每一个项目都要先说清楚：什么叫完成，什么叫合格，失败以后谁接管，最后留下什么。
FDE 交付的不是一套能打开的软件，而是一条客户自己能够持续跑下去的业务链路。
FDE 不止是单兵作战
我最后问了一个问题，FDE 经常以外派或驻场的形式工作，团队协作会有什么问题？项目是不是主要靠自己一个人从 0 到 1？
朋友说，FDE 确实要有独立推进的能力，要能在现场先判断问题影响哪一段流程，再把需求拆成业务目标、实现边界和需要团队协作的事项。但独立推进不等于一个人完成所有工作。他提到的真正卡点，是团队里不断地「倒一手信息」也就是真实的客户需求。
团队协作主要是和研发、售前、销售。一个卡点是，你和客户沟通以后，沉淀下来的需求和会议里的一手信息没有对齐，总是会倒一手，就会出现信息不对等。共性需求回补到产品时，也会发现信息缺失。
报价公式就是一个例子。客户希望新系统尽量贴合原来 Excel 的公式逻辑，让老员工更快上手。研发如果只从产品整洁度和开发效率出发，可能觉得这是在复制低效流程；但客户在意的是系统的易用性，使用习惯不能突然被推翻。
反过来，如果 FDE 只转述一句「客户要求和 Excel 一样」，研发同样会被带偏。真正要传回团队的，是客户为什么这样要求，哪些部分必须兼容，哪些旧习惯应该借这次改造结束，以及最后用什么结果验收。
我把这段协作关系理解为：FDE 要独立扛住的是问题闭环，不是独占研发、产品、销售和项目经理的职责。FDE 负责保住客户现场的上下文和验收目标；研发负责生产实现与技术质量；销售和售前对齐商业承诺；客户内部也要有人提供数据、推动使用并共同验收。
所以，从 0 到 1 不是一个人把所有事情做完，而是第一次把模糊问题、技术方案和组织责任闭成一条线。如果项目结束以后，所有判断仍然只存在某个 FDE 的脑子里，那只是换了一种方式依赖人。如果一手信息也只留在 FDE 脑子里，系统接上了，组织还是原来的组织。
把 AI 接入流程里 ，不等于完成了 AI 化
聊到最后，我问他那些接了 AI 的企业，是不是就安全了？他的回答很直接，不一定。
电力革命刚开始的时候，英国纺织业占全世界产量的七成左右。电出来了，他们也用电，把电接到了原来蒸汽机的大轴上。整个生产组织、工厂布局、运营方式，还是蒸汽时代那套。同一时期，美国、日本、德国从零开始，用电力原生重构了整个生产组织。英国纺织业就这样被甩下去了。
不是因为没用电，是因为用电的方式错了。
AI 这次变革，不是一次技术浪潮，是一次完整的生产力革命，对社会的影响会超过互联网。接上电或者接上 AI，技术只占很小一部分。真正变化的是生产工序、组织方式、人才和商业模式。AI 的核心不只是技术变化，也是组织和业务的变化。
这个比喻区分了两件经常被混在一起的事：部署了新技术，和围绕新技术重新设计工作。
他也说见过很多企业，部署了 AI 工具，跑了几个项目，老板在大会上说「我们已经开始 AI 转型了」。但底层的业务流程没变，部门之间的数据还是没打通，员工还是用原来的方式工作，AI 只是又多了一个没人用的系统。
FDE 能做的，是帮企业把这个转型真正推进去一段。能不能跨越周期，最终取决于企业自己有没有把 AI 当成重构商业的机会，而不只是一次采购行为。接上 AI 只是开始。没有围绕它重构的企业，迟早还是会掉队。
和这位 FDE 朋友聊完，我对「企业 AI 化卡在哪」有了更具体的答案。
它会卡在客户只能描述现象，却没人还原流程；卡在模型能力很强，却进不了真实的数据边界；卡在企业积累了很多经验，却没人判断哪些值得继承；也会卡在系统已经上线，组织仍然按照旧方式运行。
FDE 站在客户现场和生产系统之间，承担的是业务理解、AI 判断、工程融合和组织推动。技术很重要，但技术不是全部，也往往不是第一步。
下一次再判断一个企业有没有真正开始 AI 化，我会先看三件事：业务流程有没有因此改变，人的判断有没有被重新分配，项目结束以后有没有留下可以继续复用的业务资产。
如果这些都没有，企业只是给原来的流程接上了 AI，还谈不上真正的 AI 化。
