作者 / 来源：中智凯灵 / AiDD

很多企业的 AI 项目，最初并不是死在模型能力上，而是死在角色分工里。

业务方说不清完整需求，只能描述一个模糊目标；产品和BA 还在等一份稳定的需求文档；工程团队希望先明确边界、接口和验收标准；模型能力却在快速变化，今天做不到的事，过两周可能已经被新工具改写。项目一开始看起来都很积极，但推进几轮后，很容易变成另一种熟悉的状态：需求还在涌现，设计不断返工，演示可以跑，验收却说不清。

这不是某一个团队的问题，而是 AI 项目本身改变了交付条件。

传统软件项目的默认前提，是需求相对可描述、逻辑相对可确定、测试相对可枚举。AI 项目则不同：业务意图经常在现场互动中逐渐清晰，模型输出带有概率性，数据和知识质量会直接影响结果，工具调用还会牵动权限、审计和责任边界。

于是，一个很现实的问题出现了：如果企业还按“业务提需求、产品写方案、研发排期、测试验收、运维接手”的方式推进 AI 项目，谁来把这些不确定性接住？

这也是 FDE 重新被讨论的原因。

FDE，Forward Deployed Engineer，常被直译为“前线部署工程师”。但在企业 AI 落地语境里，它不应该被理解成“驻场开发”的新名字。驻场开发强调人在客户现场完成既定任务，FDE 真正解决的问题，是在任务尚未完全稳定时，连接业务现场、AI 工程、评估反馈和持续运营。

换句话说，FDE 的关键不是“人在现场”，而是“责任在业务结果上”。

图 1：AI 项目改变了交付条件，FDE 出现在业务、模型、数据和流程不确定性叠加的位置

▍FDE 首先不是等需求的人，而是重新定义问题的人

很多 AI 项目一开始会被一个技术能力牵着走。

模型能读文档，于是做知识库；Agent 能调工具，于是做流程助手；多模态能识别图片，于是做视觉质检。这些方向都可能成立，但它们本身还不是业务问题。

真正的问题通常藏在现场：哪个岗位每天被什么事情卡住？现在靠什么人工经验解决？出错时损失在哪里？AI 如果介入，应该改变哪个业务结果？这些问题说不清，项目越快，偏差也可能越大。

这正是 FDE 与普通驻场开发最容易被混淆、也最需要分清的地方。驻场开发通常在需求已经被拆解后进入，负责把功能做出来；FDE 往往要在需求还不稳定时进入，和业务方一起把模糊目标翻译成 AI 可处理、可验证、可迭代的问题。

比如一个企业说“我们想做一个智能客服 Agent”，FDE 不能只问“要接哪些系统、什么时候上线”。它更应该追问：客服场景中哪类问题最耗时？答案是否存在明确知识来源？哪些问题必须转人工？错误回答的成本是什么？上线后用什么指标判断效果？业务方每周能提供多少真实样本和 Bad Case？

这些追问不是流程洁癖，而是 AI 项目的入口。没有问题重定义，后面的模型选型、知识库、工具调用和评估体系都可能建立在一个虚假的场景上。

FDE 的第一项价值，就是让项目更早知道自己到底在解决什么问题。

图 2：驻场开发通常接收既定任务，FDE 要在任务尚未稳定时参与定义问题

▍FDE 也不是“调 Prompt 的人”，而是搭建 AI 能力骨架的人

AI 项目的早期演示，往往会把复杂性藏起来。

一个网页、一个对话框、一个看起来流畅的 Agent，就足以证明“方向似乎可行”。但企业真正需要的不是一个能展示的智能体，而是一项能持续运行的 AI 能力。

这两者差别很大。

智能体产品可以有界面、有按钮、有回答；AI 能力还必须有知识来源、数据管道、工具调用、流程门控、权限边界、评估样本、反馈机制、版本记录和运营仪表盘。前者能让人看见 AI，后者才能让企业放心使用 AI。

所以，FDE 的第二个角色，是架构操盘手。它要设计 RAG 管道、Agent 逻辑、Workflow、MCP 或工具调用、系统集成和基本前后端，让 AI 能力先以最小可运行形态进入真实流程。

这里的难点不只是“会不会全栈开发”。

传统全栈开发面对的是相对确定的需求、接口和页面；FDE面对的是一个会受数据质量、上下文长度、模型版本、Prompt 结构、工具权限和业务反馈共同影响的系统。它必须判断：哪些地方适合让模型自主规划，哪些地方必须用 Workflow 固定下来；哪些动作可以自动执行，哪些动作必须留人工确认；哪些能力应该放在当前项目里做，哪些应该沉淀到技术中台里复用。

从这个角度看，FDE 更像是在搭建一套 AI 能力骨架。模型是其中一部分，但不是全部。真正决定落地效果的，是模型如何被企业知识喂养、被业务流程约束、被工具系统放大、被评估机制持续校正。

如果没有这套骨架，项目很容易变成“强模型 + 薄应用”：演示顺滑，但一进真实流程就开始松动。

图 3：FDE 要把模糊业务意图转成场景、样本、流程、指标和边界

▍FDE 的核心难题，是管理概率性输出

传统软件项目里，测试和验收有一个很强的默认前提：输入相同，输出就应该相同。

AI 项目打破了这个前提。

同一个用户问题，模型可能因为上下文、检索结果、工具调用路径、模型版本变化而给出不同答案。结果可能“看起来对”，但事实错了；也可能结构完整，却遗漏了关键业务限制；还可能在标准样本上表现很好，一碰到真实用户的表达方式就开始漂移。

这也是很多企业 AI 项目从 Demo 进入试用后最先遇到的尴尬：大家都觉得方向有价值，却说不清它到底稳定到什么程度。

FDE 因此必须承担第三个角色：AI 驯化师。

这里的“驯化”不是把 Prompt 写得更花，而是持续管理模型行为。它包括整理上下文、选择样本、构建知识库、设计工具调用、建立评估集、收集 Bad Case、调整边界条件，并把线上反馈重新放回系统。AI 能力不是一次开发完成的，它需要在真实输入里被训练、被校正、被约束。

在 AiDD 上海站多场分享里，这个变化已经非常明显。Agent 从“能不能跑”走向“能不能评估”，企业真正补的不是一个测试表，而是一套持续判断 AI 是否可靠的能力。

对 FDE 来说，管理概率性输出是一项长期工作。它既不是一次性调参，也不是上线前突击测试，而是把“AI 有没有做好”变成一套可以被业务、技术和管理层共同理解的证据链。

这条证据链至少要回答四类问题：样本是否真实，指标是否清楚，错误是否回流，风险是否有兜底。没有这四件事，AI 项目的验收只能停留在主观体验；有了这四件事，团队才知道下一轮应该补数据、改流程、调模型，还是缩小场景。

图 4：FDE 交付的不是单个 Agent界面，而是一套可运行的 AI 能力骨架

▍FDE 不能把上线当终点，而要把运营放进交付

很多传统项目在上线之后，会把主要责任交给运维或业务使用方。AI 项目这样做很危险。

因为 AI 能力上线以后，真正的问题才开始出现：用户会提出训练样本里没有的问题，业务规则会更新，知识库会过期，模型供应商会升级，成本可能随使用量上升，工具权限也可能暴露新的风险。

一个智能体如果没有运营机制，很快就会从“有用”滑向“不敢用”。

所以，FDE 的交付对象不应该只是某个版本，而是一条演进路径。从场景探索与 PoC，到迭代交付与用户试用，再到持续优化与可配置化，最后进入自主运营与持续监控。每一步都对应不同的问题：先证明方向是否值得做，再证明小范围是否能用，然后证明能否被业务持续调校，最后证明组织能否接手运营。

这意味着，FDE 要把业务反馈、评估报告、版本记录、监控仪表盘和持续优化节奏一起交出去。

如果没有这条路径，AI 项目就很容易停在演示工程：它证明“能做”，但没有证明“能跑下去”。有了这条路径，企业才能判断一项 AI 能力是否真的进入了业务循环。

更重要的是，运营不能等上线后才补。谁提供样本，谁判断答案对错，谁维护知识库，谁审批高风险动作，谁看成本和效果，谁决定继续扩展或暂停，这些责任应该从 PoC 阶段就被写进项目节奏。

FDE 的价值，不是替企业永远守着一个系统，而是帮助企业把AI 能力从项目组手里交到组织机制里。

图 5：FDE 用样本、评估、反馈和护栏持续管理概率性输出

▍FDE 是小队作战的接口，不是单兵英雄

FDE 这个角色容易被误读成“一个特别强的全能工程师”。

但在企业 AI 落地里，真正重要的不是神化单个人，而是形成一种新的小队作战方式。

一个成熟的 AI 项目，至少需要几类能力共同出现：业务侧有人能定义目标、提供样本、判断结果；工程侧有人能搭建智能体、接入系统、部署服务；数据侧有人能整理知识、清洗样本、维护质量；中台侧有人能提供模型、向量库、权限、监控和工具组件。

FDE 位于这些能力之间，扮演接口角色。

它必须能听懂业务方说的痛点，也能向工程团队解释为什么某个边界不能轻易自动化；它必须知道模型能力的变化，也要知道组织能承受多快的迭代节奏；它既要推动 Demo，也要在 Go/No-Go 决策关口提醒团队：哪些项目值得继续，哪些项目应该缩小范围、补数据、换场景或及时暂停。

这也是“敏捷 AI 工程”与传统敏捷开发的差别。

传统敏捷强调快速迭代，AI 项目还要在迭代中持续发现问题本身是否成立。FDE 的价值，不只是让团队做得更快，而是让团队更早知道什么值得做、怎样做、做到什么程度可以继续投入。

从这个意义上说，FDE 不是替代产品经理、架构师、开发、测试或运维，而是把这些能力重新组织到 AI 项目的节奏里。它让业务问题更早被定义，让技术方案更快进入真实数据，让评估和反馈不再拖到最后，让上线后的持续运营有明确责任。

图 6：生产级 AI 能力不是一次性交付，而是从 PoC 到自主运营的四阶段演进

▍为什么企业现在需要 FDE？

企业过去采购软件，本质上是在买一套相对稳定的能力；今天建设 AI 智能体，更多是在建设一项会持续变化的能力。

这个变化会影响预算、项目管理、人才结构和交付方式。

从“买系统”到“建能力”，IT 投资重心会从采购软件许可，转向模型选型、数据治理、场景验证和人才培养；从“大项目制”到“小步快跑”，团队需要用更短周期持续交付可验证能力；从“确定性规划”到“探索性投资”，组织要允许试错，并设置 Fail Fast 决策关口。

这三点背后，其实都指向同一个判断：AI 不是 IT 部门的工具升级，而是企业战略资源配置方式的变化。

当 AI 能力仍处在探索期，企业最怕的不是试错，而是不知道自己错在哪里；最怕的不是项目暂停，而是把一个不成立的场景拖成长期投入；最怕的不是模型能力不完美，而是业务、数据、工程和运营之间没有人能把问题接住。

FDE 的价值就在这里。它让企业 AI 项目从“做一个东西”转向“建设一项能力”：从真实问题出发，用真实样本验证，用工程骨架承载，用评估反馈校正，用运营机制持续进化。

这也解释了为什么 FDE 不能被简单理解为更贵的咨询、更强的外包，或者更会用 AI 工具的工程师。

咨询可以给判断，但未必能把判断放进系统；外包可以交功能，但未必对业务结果负责；普通工程师可以实现需求，但未必参与重新定义需求。FDE 的特殊性在于，它把三件事放在一起：业务认知工程化、AI 能力生产化、项目经验资产化。

图 7：FDE 位于业务、数据、工程和中台之间，承担 AI 小队的交付接口

▍结语：FDE 的新，不在名字，而在交付对象变了

FDE 之所以不是驻场开发，不是因为它听起来更新，也不是因为它多会几个 AI 工具。

它真正的新，在于交付对象变了。

传统软件项目的交付对象，是一组相对稳定的功能；AI 项目的交付对象，是一项不断面对真实输入、真实反馈、真实风险并持续演进的能力。前者更强调按需求实现，后者更强调在不确定性中定义问题、验证路径、控制风险和沉淀经验。

所以，一个成熟的 FDE，至少要同时具备四种能力：像业务咨询师一样进入现场，像架构操盘手一样搭建系统，像 AI 驯化师一样管理概率性输出，像运营负责人一样推动长期演进。

这不是一个轻松的角色，也不是一个只靠培训几天就能完全获得的标签。它更像是企业 AI 落地过程中逐步长出来的新型工程能力：既要懂业务，也要懂技术；既要能快速做出MVP，也要能判断这个 MVP 是否值得继续；既要能接住模型能力的变化，也要能把变化变成组织可复用的资产。

如果说传统软件项目交付的是“系统”，那么 AI 项目更应该交付“会进化的能力”。

FDE，就是把这件事落到现场的人。

图 8：FDE 的本质，是把业务意图转成可运行、可验证、可运营的 AI 能力

FDE 的故事，上海站只是开篇。

当企业从“试一试 AI”进入“把 AI 放进真实业务”，更需要讨论的就不只是模型能力，而是角色、流程、评估、反馈和持续运营如何被重新组织起来。

2026 年 AiDD 北京站，将在上海站的基础上继续关注 AI 研发、Agent 工程化、企业智能体和组织级落地。8 月 23-24 日的 FDE 深度工作坊，也会把这些问题带到更具体的业务场景里：如何识别场景，如何设计PoC，如何搭建知识库和智能体，如何建立评估与反馈闭环，并把 AI 项目推向真实使用。

AI 项目能不能落地，最终不只看企业有没有模型、有没有工具、有没有预算。更关键的是，有没有一类人和一套机制，能把不确定性接住，并把它转化为持续进化的能力。

北京，我们继续聊。