企业 AI · FDE · 业务责任
请了FDE，企业AI还是落不了地：公司内部少了一个关键角色
外部工程师能接系统、写代码，却不能替企业定义结果、开放权限、承担风险。
最近 FDE 很火。
企业觉得 AI 项目推不动，第一反应是找一个既懂模型、又能进现场写代码的人。最好他还能梳理需求、协调部门、解决数据问题，最后对上线结果负责。
听起来很合理。
但工程师进场以后，常常先撞上另一堵墙：业务部门说不清要改善哪个结果，数据负责人不敢开放权限，流程里的例外全靠老员工临时判断，出了问题也没人愿意签字。
FDE 会写接口，不能替客户决定谁有权退款；会搭 Agent，也不能替法务承诺一份合同可以自动放行。
这时再强的工程能力，都容易耗在找人、开会和猜需求上。
Syed Hassan 在 X 上提出了一个自创角色，叫 Business Deployed Operator，简称 BDO。可以把它理解成"业务部署操盘手"：站在企业内部，负责把管理层的 AI 目标，变成工程团队能够交付、业务团队敢于使用的具体任务。
这个名称未必会流行，但它指出的问题很准。
企业请 FDE 之前，内部得先有人把路清出来。
FDE最怕的，不是技术难，是问题一直在变
一个 FDE 最适合处理什么？
问题已经收窄，业务目标可以衡量，关键资料能够获取，相关负责人愿意配合。工程师进入现场后，把模型接入数据和工具，处理异常，再推到生产环境。
可现实里的需求经常只有一句话：
"给销售做一个 Agent。"
销售到底卡在找线索、判断客户、准备方案，还是跟进不及时？没有人说得清。于是 FDE 一边写代码，一边采访业务；刚确定方案，另一个部门又补充一套口径；做到验收，老板才第一次看到成品，然后问："它为什么不能顺便把合同也审了？"
项目做得越久，边界越大。工程师的时间越来越贵，企业却觉得结果离自己越来越远。
这不完全是 FDE 的问题。他只是被迫兼任了客户内部本该有人承担的工作。
公司内部需要一个"翻译官"，但翻译的不是术语
BDO 不是负责把"RAG"解释成"知识库"，也不是在业务和技术之间传话。
他要翻译的是企业的运行方式。
老板说"客服成本太高"，他需要追问是哪类工单、多少人工介入、错误会造成什么后果；业务说"这类客户可以特殊处理"，他要把"这类"和"特殊"拆成系统能够识别的条件；安全团队说"数据不能乱用"，他要确认哪些字段受限、谁能授权、日志保留多久。
翻译完成后，一句模糊愿望应该变成一张可执行的任务单：
• 谁在什么环节遇到问题；
• 系统依据哪些数据和规则作判断；
• AI 提建议、执行动作，还是只做提醒；
• 哪些情况必须转人工；
• 谁验收结果，出错后谁接管。
这张任务单，才是 FDE 开始工作的地方。
这个人通常已经在公司里，只是没有这个头衔
Syed Hassan 认为，BDO 往往来自财务、运营、供应链、法务、销售或市场。他对日常工作足够熟，也愿意理解新技术。
更重要的是，他所处的位置不能太高，也不能太远。
只在管理层附近的人，知道公司想去哪，却未必看过员工如何绕过旧系统完成一笔业务。只在一线的人熟悉细节，却可能没有权限召集数据、安全和 IT 一起作决定。
合适的人通常具备几种迹象：
• 在本部门做过几年，知道制度之外还有哪些例外；
• 参与过 ERP、流程改造或跨部门项目，懂得系统上线不等于工作改变；
• 遇到新工具愿意自己试，也知道什么时候不能冒险；
• 业务负责人信任他，一线员工也愿意告诉他真实做法；
• 能讨论效率，也能讨论权限、审计和责任。
他未必会写代码。只要能判断问题、调动相关人员，并对业务结果负责，就比一个只会转发需求的"接口人"有用。
为什么传统项目经理和业务分析师还不够
过去做 ERP，企业会先梳理流程，再把相对稳定的规则写进系统。相同输入通常得到相同结果，需求可以在较长周期里逐步确认。
AI 系统没这么听话。同一个问题可能产生不同回答，模型会遇到没见过的输入，工具调用也可能中途失败。许多问题只有上线试用后才会暴露。
因此，BDO 不能只在立项阶段写需求，交给技术后就退出。他需要跟着系统进入真实工作：看哪些建议被员工修改，哪些任务总要人工接管，用户为什么不愿意用，问题来自模型、数据、权限，还是流程本身。
这项工作更接近持续经营，而不是一次性交接。
一个合格的BDO，至少要盯住五件事
先把目标改写成一个业务判断
不要用"提升智能化水平"立项。写清楚哪个岗位在什么时点，需要更快或更准地作出哪项判断。
让FDE接触真实任务
会议纪要和需求文档只能提供一部分信息。FDE 需要看到真实工单、审批记录、异常样本，以及员工在系统外做的补救动作。
守住数据和权限边界
外部 FDE 可能接触企业数据、流程和商业经验。BDO 要和安全、法务、数据负责人一起定义可访问范围、脱敏方式、审计记录和退出机制。速度不能靠放弃控制换来。
把人的修改变成反馈
员工改了 AI 的结果，不能只在聊天里说一句"不好用"。要留下当时的输入、系统输出、修改内容和原因，才能判断下一步该改模型、资料还是流程。
用经营结果验收
Agent 能回答问题，只能说明它会运行。处理时间有没有缩短，人工接管有没有下降，错误后果是否可控，员工是否持续使用，这些才是企业该看的结果。
请FDE之前，先开一次这样的会
不用急着发招聘信息，也不用马上创造 BDO 岗位。
先把管理层、业务负责人、IT、数据与安全人员叫到一起，用一个准备做的 AI 场景回答下面六个问题：
1. 我们要改善哪项具体业务结果？ 2. 谁最了解这项工作的真实流程和例外？ 3. 哪些数据可以使用，谁有权批准？ 4. AI 可以做到哪一步，哪里必须由人决定？ 5. 系统出错时，谁负责发现、暂停和修正？ 6. 谁会在接下来的几个月持续跟进使用结果？
如果第六个问题没人愿意回答，FDE 进场后大概率只能自己找答案。
而外部工程师最不该替企业决定的，恰恰是业务目标、权限和责任。
FDE负责把系统做出来，企业内部的人负责让它活下来
FDE 的价值很清楚。他们理解新的模型和工具，也能把原型推到真实环境。
但企业 AI 不是请来一个高手，就能绕过内部治理。目标没人定义，权限没人协调，反馈没人整理，最后的业务结果也没人承担，FDE 只会变成一个昂贵的救火队员。
所谓 BDO，不一定是一张新名片。
它更像一份不能空缺的责任：企业内部必须有人站在业务和工程之间，把模糊愿望拆成可交付任务，把现场变化带回系统，并在 FDE 离开后继续对结果负责。
先找到这个人，再请 FDE。
否则，企业买到的可能是一段很强的工程能力，却没有一个能让它落地的位置。
资料来源： Syed Hassan（@Syed_hassan17），X 文章 Forward Deployed Engineers (FDE) alone will not save your Enterprise AI programme，发布于 2026 年 7 月 17 日。BDO 为原作者自创称呼，并非通行岗位名称；本文将其译作"业务部署操盘手"，在原文观点上进行了中文语境重构。
完