夜雨聆风刚好，今年3月，我在上海创智学院参加了一期培训，是上海经信委组织的第一期FDE（前沿部署工程师）专题培训班，为期四周。正是这四周的经历，让我对这个“先有鸡还是先有蛋”的问题，有了一些新的观察和思考。
FDE：技术与业务之间的“翻译官”
FDE的全称是Forward Deployed Engineer。这个词借用了军事术语——部署在前线执行任务的特种单位。
如果说大模型是一辆马力强劲的越野车，那么大多数企业的实际业务场景，就是一条坑坑洼洼、杂草丛生的乡间土路——数据格式混乱，系统五花八门，员工用了二十年的老习惯一个都改不了。车再好，开不上路也是白搭。FDE干的事，就是先在现场铺出一条碎石路，让车跑起来；等跑通了，再把这条路修成高速公路。
FDE的难得之处在于，他们是技术与业务之间真正的“双语者”：能看懂模型架构，也能读懂工厂里的PLC控制协议；能写代码，也能听懂客户用行业黑话描述的需求。培训期间，一位在商汤科技工作的同学告诉我，他们给某物流企业做AI优化项目，光是“听懂”对方的需求就花了两周——物流行业的术语和互联网行业完全是两套语言。
语言的壁垒，往往比技术的壁垒更难跨越。
两条路径，各有各的难
回到朋友的问题：让业务人员学AI，还是让AI人才学业务？两条路都在走，但都不容易。
路径一：让业务人员学AI。这是目前最普遍的路径。兴业银行要求全行“人人学AI、懂AI、用AI”；中钢国际为五大核心岗位定制AI培训，累计覆盖4000余人次。这条路的好处很明显：懂业务的人学AI，能更快找到高价值的落地场景。太保科技的一个案例很有说服力：由60名理赔专家、医学专家及AI工程师组成的跨界团队，通过“人在回路”策略，让医学专家实时修正AI输出，最终将理赔差错率控制在0.32‰，仅为行业平均的七分之一。
但问题也很现实。一线专业人员长期从事本领域的工作，数字知识基础薄弱，一开始容易产生畏难情绪。从“会用工具”到“能结合场景创造价值”，中间还有一道很深的沟。
路径二：让AI人才学业务。这就是FDE培养的路径。上海的做法是把“懂技术”的存量工程师，转化为“懂业务”的复合型人才。太保科技的“海豚IC”项目就是这种思路的产物，团队中有理赔专家、医学专家和AI工程师，最终单人日均处理案件量达200件，效率为行业均值2倍。
但这个路径的门槛同样不低。传统算法工程师往往对产线、供应链、合规体系知之甚少，让他们理解业务逻辑，有时比让业务人员学代码更难。
科技公司怎么选？
我查阅了阿里、字节、百度、蚂蚁等科技公司的公开做法，发现它们没有选边站，而是同时在走三条路。
阿里的做法是组织重构。4月8日，吴泳铭发布内部信，在集团层面设立技术委员会，同时将通义实验室升级为通义大模型事业部。这不是让业务学技术或技术学业务，而是把懂技术的人和懂业务的人放在同一个指挥体系里，让他们必须协作。
字节跳动的路径是“顶尖人才驱动”。张一鸣与上海交大ACM班创始人俞勇合作创办知春创新中心，从人才培养的源头切入。字节的逻辑更接近路径二的极致版——招募最顶尖的人，让他们来解决业务问题。
百度和蚂蚁则大力布局数字员工。百度推出全球首批AI数字员工，涵盖营销、还款、汽车销售等核心业务；蚂蚁推出专家级“AI数字员工团队”，覆盖客服、营销、巡检等五大领域，其核心创新是“人机融合”全托管模式——AI处理标准化工作，复杂问题由专家网络无缝补位，在电商客户实践中带来了约10%的GMV增长。
阿里国际的思路是培养“桥梁型通才”。阿里副总裁张凯夫直言，未来AI型组织里，“桥梁型通才至关重要”。这类人既懂技术，又懂业务洞察，是AI组织的核心资源。
总结一下：科技公司没有押注单一选项，而是让组织重构、数字员工、复合型人才培养三条路并行。
数字员工是“中间路线吗？
数字员工作为“第三条道路”是不是在回避核心矛盾，和稀泥呢？我认真想了想这个问题。
首先要澄清一个误解：数字员工不是让人“不用学”了。蚂蚁集团“数字蚂力”的案例很说明问题。他们推出的AI数字客服团队，背后是“服务设计、知识运营、效果评测等多个专家智能体组成的协同团队”。让AI客服跑起来的，是一群懂客服业务、懂AI能力边界、懂如何调教和评估AI的人。这些人不是“什么都不用学”，而是学习的对象变了——从学“怎么自己干活”，变成学“怎么让AI干活”。
其次，数字员工的本质，不是“和稀泥”，而是“封装复杂性”。百度智能云在介绍其数字员工时，用了三个词：“懂业务、给结果、可进化”。它已经被训练得懂某个业务场景了，你不需要再给它讲一遍业务逻辑；它直接对最终结果负责；它还能在使用中持续优化。这就像Excel——会用Excel的人不一定懂它的底层算法，但不妨碍用它解决复杂问题。数字员工扮演的是同样的角色：把AI的复杂能力封装成业务人员可直接使用的工具。这不是在回避矛盾，而是在降低技术与业务之间的摩擦成本。
第三，第三条路的意义在于“让协作更顺畅”。纯粹的技术专家在真实业务场景中可能失灵，纯粹的业务专家面对AI技术也可能无从下手。如果让这两类人直接对话，往往需要大量的翻译和磨合时间。FDE的存在就是为了缩短这个过程，而数字员工走得更远——把“翻译能力”直接封装进AI工具里。业务人员使用数字员工时，不需要懂技术；技术人员开发数字员工时，也不需要懂所有业务细节。两类人只需要在“数字员工”这个界面层交汇，而不是在每一个具体问题上纠缠。
因需而动，而不是非此即彼
如果说“让业务学技术”和“让技术学业务”是在“改变人”，那么数字员工这条路是在 “改变工具”。前者解决的是能力问题，后者解决的是协作效率问题。两条路并行，而不是互相替代。
真正的问题不是“选哪条路”，而是“你的企业现在最缺什么”：
如果你缺的是能把技术和业务串联起来的人，那就需要FDE或“桥梁型通才”；
如果你缺的是让业务团队快速上手AI的工具，那就需要数字员工；
如果两者都缺，那就需要同时推进——就像阿里、百度、蚂蚁正在做的。
结尾
培训结束那天，恰逢2026全球开发者先锋大会（GDPS）在上海开幕。我没有参加结业典礼，而是直接去了会场。大会今年的主题是“宁智勿庸，创领未来”——宁可务实，不沉迷炫技；唯有在产业土壤中扎根，才能真正开创未来。
会场里，4.5万名开发者从全国各地赶来。最热闹的展位，不是模型参数最大的那家，而是愿意坐下来听客户讲三分钟痛点、再开口说话的那家。
那一刻我突然觉得，FDE培训和这场大会，其实是同一件事的两面。一个在培养“能现场解题的人”，一个在搭建“让问题与解法相遇的平台”。一个务实，一个宏大。
回到最初朋友的问题：业务学技术，还是技术学业务？
我的回答是：与其纠结谁该学谁，不如先问——你的企业里，有没有人能负责“翻译”？
如果没有，那就先培养翻译官，或者制造翻译工具。FDE是翻译官，数字员工是翻译工具。两者不矛盾，可以并行。
当技术与业务之间的壁垒被打破，AI才能真正在产业里落地。而打破壁垒的方式，没有标准答案，只有适合你的答案。
