1. FDE 模式到底是什么从一个被误读的岗位说起第一次听到 FDE 这个词是在一个做企业级 AI 落地的群里。有人发了一张招聘截图岗位写着“FDE 解决方案部署工程师高级”薪资区间比同级别的后端开发高出将近一半。底下立刻有人问这是不是就是售前换了个名字也有人猜是“驻场开发”。我当时也没想明白直到后来自己参与了一个 Agent 项目的交付才真正理解 FDE 这个角色为什么会在 AI 落地这波浪潮里被单独拎出来。FDE全称 Forward Deployed Engineer直译过来是“前线部署工程师”。这个岗位最早在数据平台类公司里成型核心逻辑只有一句话把工程能力直接搬到客户现场让产品能力和业务场景在同一个工位上完成对接。它不是一个纯技术岗也不是一个纯业务岗而是卡在中间那个最容易出问题、也最需要人来兜底的位置。为什么这个位置在 AI Agent 时代突然变得重要因为 Agent 项目的交付和传统软件交付有本质区别。传统 SaaS 交付配置完账号、导完数据、跑通流程就算完事。但 Agent 项目交付的是“能力”——它要理解客户的业务语言、要接入客户的数据源、要适配客户内部那套可能已经跑了十年的审批流。这些东西没法在远程会议室里靠 PPT 讲清楚必须有人蹲在现场看着真实数据流进来看着业务人员怎么用然后当场改 prompt、调工具链、重新编排 Agent 的执行逻辑。我参与的那个项目是做合同审核辅助的 Agent。客户是一家做供应链金融的公司合同类型有十几种每种的风险点都不一样。最开始我们在办公室用通用合同样本调了一版准确率能到八成大家觉得差不多了。结果一到现场客户的法务直接甩过来一份带手写批注的扫描件说“这种你们能处理吗”。那一刻我就明白了FDE 存在的意义不是把标准产品卖出去而是把标准产品在真实场景里“养”到能用。这个模式的核心可以拆成三个关键词前线、共创、双向。前线意味着工作地点在客户侧不是远程支持共创意味着方案不是提前定死的而是和客户一起长出来的双向意味着 FDE 不只是把公司能力输出给客户同时要把客户场景里的真实需求、边界条件、失败案例带回产品团队反过来推动产品迭代。这三个词缺一个FDE 就退化成普通的实施顾问或者驻场开发。适合关注这个模式的人其实比想象中多。如果你是在做 AI Agent 开发想理解自己的代码最终在什么环境里跑FDE 的视角能帮你少写很多“实验室里很美、现场一跑就崩”的逻辑。如果你是在企业里负责数字化落地想搞清楚为什么买了那么多 AI 工具最后都用不起来FDE 的工作方式能给你一套可参考的推进节奏。如果你正在考虑职业转型想知道 FDE 工程师学习路线怎么走、FDE 的轮岗晋升社区分享机制是怎么回事那这篇内容会把我知道的、踩过的、验证过的都摊开来讲。2. 为什么传统交付模式在 Agent 项目上跑不通2.1 传统交付的“三拍”困境我见过太多 AI 项目死在交付环节。总结下来有一个很形象的规律叫“三拍”立项时拍脑袋交付时拍胸脯上线后拍大腿。这个规律在传统软件时代还能靠标准化产品勉强兜住但到了 Agent 项目上几乎必然翻车。传统软件交付的逻辑是“需求冻结—开发—测试—上线”一条直线走到底。这套逻辑成立的前提是需求相对稳定、边界相对清晰。但 Agent 项目面对的场景恰恰相反业务人员自己都说不清楚他们想要什么因为 Agent 能做的事情超出了他们原有的想象边界。你问客户“你希望这个 Agent 帮你做什么”他可能回答“帮我处理合同”但“处理”这两个字背后可能是提取关键条款、可能是比对历史版本、可能是生成风险提示、可能是自动流转到下一审批人甚至可能是这四件事的组合。我在现场遇到过最典型的一幕客户业务负责人说“这个 Agent 能不能自动判断这份合同能不能签”。我说“判断依据是什么”。他说“就是看有没有风险”。我问“什么算风险”。他想了半天说“你让法务跟你说”。法务来了之后列了二十多条规则但补充了一句“这些规则也不是死的有些情况要具体看”。这就是 Agent 交付的真实起点——需求是一团模糊的、带条件的、依赖人判断的东西。2.2 Agent 项目的三个特殊性Agent 项目和传统软件项目相比有三个绕不开的特殊性这也是 FDE 模式必须存在的原因。第一输入是非结构化的。传统软件处理的是表单、字段、固定格式的文件。Agent 处理的是自然语言、扫描件、聊天记录、邮件正文。这意味着你没法用传统的接口文档来定义输入输出。同一个问题用户换一种问法Agent 的表现可能完全不同。我在做合同审核 Agent 的时候光是“甲方”这个词就遇到了七八种表达方式甲方、采购方、委托方、买方、需求方甚至还有用公司简称直接指代的。这些变体没法靠穷举解决必须靠现场不断收集、不断补充到 prompt 和工具链里。第二执行路径是动态的。传统软件的流程是写死的if-else 走到底。Agent 的执行路径依赖推理结果同一个任务可能走完全不同的工具调用链。这就带来一个很现实的问题你在办公室测试的时候跑通了不代表现场能跑通因为现场的数据分布和测试集不一样。我印象很深的一次测试环境里合同都是文本 PDF提取很顺利。到了现场客户发来一批扫描件OCR 出来的文字带着大量错别字和乱码Agent 直接懵了。这种问题只能在现场发现、现场解决。第三验收标准是模糊的。传统软件验收看功能清单打勾就行。Agent 的验收标准是什么准确率覆盖率用户满意度这些指标都很难在合同里写清楚。更麻烦的是业务人员对 Agent 的期望会随着使用不断变化。今天他觉得能提取条款就够了明天他看到隔壁部门用 Agent 自动生成了报告就会问“我们这个能不能也生成”。这种期望的漂移是常态不是例外。2.3 FDE 模式怎么接住这些特殊性FDE 模式对上述问题的应对方式不是试图在交付前把所有事情想清楚而是把“想清楚”这个过程本身搬到现场和客户一起完成。具体来说有三个动作。第一个动作是场景蹲点。FDE 工程师到现场的第一件事不是讲方案而是看业务人员怎么工作。我当时的做法是搬个椅子坐在法务旁边看他一天审多少份合同、每份看多久、卡在什么地方、遇到不确定的怎么处理。这个过程大概持续了三天收获比之前开十次需求会都大。因为我发现他真正花时间的地方不是“判断风险”而是“找历史类似合同做参照”。这个发现直接改变了 Agent 的设计方向——从“风险判断”转向“相似案例检索风险提示”。第二个动作是最小闭环验证。不要一上来就做全流程先找一个最小的、能跑通的场景让业务人员真实用起来。我们当时选的是“合同关键日期提取”因为这件事足够简单、足够高频、错了也不会有严重后果。跑通之后业务人员对 Agent 的信任度明显提升后面再推复杂功能就顺很多。这个顺序很重要先建立信任再扩展能力。第三个动作是双向反馈回路。FDE 在现场发现的每一个问题都要有渠道回流到产品团队。我们当时建了一个共享文档现场遇到的所有 bad case 都往里扔标注清楚场景、输入、期望输出、实际输出。产品团队每周过一遍决定哪些改 prompt、哪些改工具、哪些进产品需求池。这个回路如果不建FDE 就变成了纯人力外包现场经验全部浪费。3. FDE 工程师的核心能力拆解与学习路线3.1 技术能力不是最深但必须最全FDE 工程师的技术能力要求和一个纯算法工程师或纯后端工程师完全不同。你不需要在某个单点做到极致但需要在多个环节都能上手。我把它总结成“三层能力模型”。底层是工程基础。包括基本的编程能力Python 为主、API 调用、数据处理、简单的后端服务搭建。这些是基本功不用多解释。但有一个容易被忽略的点调试能力。Agent 项目出问题的时候报错信息往往很模糊比如“agent execution terminated due to error”这种你根本不知道是哪一步挂了。这时候需要你有能力把整个执行链路拆开逐段排查。我常用的做法是在每个工具调用前后加日志把输入输出都打出来然后一段一段比对。中层是 Agent 相关技术栈。包括 prompt 工程、工具调用编排、RAG 检索增强、记忆机制、多 Agent 协作等。这些是 FDE 的核心技术区。以 prompt 工程为例FDE 需要的不是写一个漂亮的 prompt而是写一个在现场能快速调整的 prompt。我的习惯是把 prompt 拆成多个模块角色定义、任务描述、输出格式、边界条件、示例。现场发现哪块有问题就改哪块不用整体重写。另外工具调用的编排也很关键。Agent 什么时候该调用哪个工具、调用失败怎么重试、多个工具的结果怎么合并这些逻辑直接决定 Agent 在现场能不能用。上层是领域理解能力。这个最容易被低估。FDE 不需要成为行业专家但需要能在短时间内理解客户的业务语言和核心流程。我自己的方法是画流程图——把客户描述的业务流程画成一张图然后拿着图去跟客户确认。这个过程能暴露很多口头描述里遗漏的细节。比如客户说“合同审批要经过法务”但画图的时候才发现法务审批还分“形式审查”和“实质审查”两个环节Agent 需要在这两个环节提供不同的辅助。3.2 业务能力翻译官和推进器FDE 的业务能力可以概括为两个角色翻译官和推进器。翻译官的意思是你要能把业务语言翻译成技术语言也能把技术限制翻译成业务能理解的话。客户说“我希望 Agent 能理解合同的意图”你得翻译成“我们需要定义意图的分类体系、标注样本、设计分类 prompt、设定置信度阈值”。反过来技术团队说“这个功能需要 fine-tune 模型周期大概六周”你得翻译成“这个功能短期内上不了但我们先用 prompt 工程做一个简化版能覆盖百分之七十的场景剩下的慢慢补”。推进器的意思是你要能推动事情往前走。Agent 项目最容易陷入的泥潭是“无限讨论、永不落地”。业务方觉得技术不成熟技术方觉得业务需求不清晰两边互相等。FDE 的作用就是打破这个僵局用一个最小闭环先跑起来用实际效果来推动下一步决策。我在现场最常说的话是“我们先做一个能用的版本用一周然后根据实际使用情况再调”。这句话听起来简单但能有效降低双方的决策压力。3.3 学习路线从哪开始怎么进阶如果你现在想往 FDE 方向走我建议的学习路线是这样的。第一阶段打基础1-2 个月。重点是把 Agent 开发的基本链路跑通。找一个开源的 Agent 框架照着文档搭一个能用的 demo。这个阶段不用追求复杂能实现“用户输入—Agent 推理—调用工具—返回结果”这个闭环就行。推荐从简单的任务开始比如“根据用户问题查询天气并给出建议”或者“读取一份文档并回答相关问题”。这个阶段的目标是建立手感知道 Agent 大概是怎么运转的。第二阶段做项目2-3 个月。找一个真实场景完整地做一遍。这个场景最好是你自己熟悉的领域这样你可以把精力放在技术实现上而不是理解业务上。比如你在做电商可以做一个“商品评论分析 Agent”你在做教育可以做一个“作业批改辅助 Agent”。这个阶段的目标是积累完整的项目经验包括需求拆解、prompt 设计、工具开发、测试调优。做完之后你会对 Agent 的能力边界有更实际的认知。第三阶段进现场持续。如果有机会参与真实的客户项目一定要去。现场能教给你的东西是任何课程和文档都给不了的。如果暂时没有这样的机会可以模拟现场环境——找几个不懂技术的朋友让他们用你做的 Agent你在旁边观察他们怎么用、在哪里卡住、有什么抱怨。这种观察能帮你建立“用户视角”这是 FDE 最核心的能力之一。关于 FDE 证书和 FDE 解决方案工程师高级报名这类信息我的建议是把它当作锦上添花不要当作入行的必要条件。这个岗位目前还没有形成统一的认证标准不同公司对 FDE 的定义和要求差异很大。真正重要的是你有没有实际交付过 Agent 项目、有没有在现场解决过真实问题。这些经历比任何证书都有说服力。4. 现场实操一个 Agent 项目的完整交付记录4.1 项目背景与目标设定这个项目是我去年参与的一个供应链金融合同审核 Agent。客户是一家做应收账款融资的公司每天要处理大量来自不同核心企业的合同。这些合同的格式、条款、风险点各不相同法务团队只有三个人审核压力很大。客户的目标很明确用 Agent 辅助法务做初审把明显有问题的合同筛出来把常规合同快速放行让法务把精力集中在真正需要人工判断的复杂合同上。项目启动的时候客户给了一个期望指标初审准确率不低于百分之九十单份合同处理时间不超过三分钟。这个指标看起来很合理但实际做起来才发现难点不在准确率本身而在于“什么算准确”这件事没有共识。法务团队内部对同一条款的判断标准都不完全一致更别说让 Agent 去对齐了。4.2 现场蹲点与需求澄清我到现场的第一周没有写任何代码主要做三件事看、问、记。看的是法务的实际工作流程。我发现他们审合同的时候有一个固定动作先翻到最后一页看签署页确认双方主体信息然后回到前面看付款条款和违约责任最后看有没有附加协议。这个顺序很关键因为它反映了法务的风险优先级。Agent 的设计也应该遵循这个顺序而不是从头到尾线性处理。问的是他们判断风险的依据。我整理了一份问题清单包括“什么样的条款你会直接拒”“什么样的条款你会标记但放行”“什么样的条款你会要求补充材料”。这些问题帮助我建立了一个初步的风险分类框架。但我也发现法务在回答这些问题的时候会给出很多“看情况”的答案。这时候不能强行要求他们给出明确规则而是要把这些“看情况”的场景记录下来作为后续 Agent 需要处理的边界条件。记的是所有提到的合同类型和风险点。我建了一个表格左边是合同类型右边是对应的风险点和处理建议。这个表格后来成了 Agent 知识库的基础。4.3 最小闭环的设计与实现蹲点结束后我没有直接做全流程的审核 Agent而是选了一个最小场景合同关键信息提取。具体来说就是从合同中提取出甲方名称、乙方名称、合同金额、付款期限、签署日期这五个字段。选择这个场景的理由有三个。第一它足够简单技术实现难度低能快速跑通。第二它是后续所有审核逻辑的基础提取不准后面的判断都是空中楼阁。第三它容易验证提取结果对不对法务一眼就能看出来不需要复杂的评估标准。技术实现上我用了最朴素的方案PDF 解析加 LLM 提取。PDF 解析用的是常规的文本提取库遇到扫描件就加一层 OCR。提取 prompt 的设计是这样的extract_prompt 你是一个合同信息提取助手。请从以下合同文本中提取指定字段。 需要提取的字段 - 甲方名称 - 乙方名称 - 合同金额 - 付款期限 - 签署日期 提取规则 1. 如果字段在文本中明确出现直接提取原文表述 2. 如果字段有多个候选值选择最靠近合同标题的那个 3. 如果字段未出现返回“未找到” 4. 金额和日期保持原文格式不要做转换 合同文本 {contract_text} 请以 JSON 格式输出提取结果。 这个 prompt 看起来很简单但实际调的时候改了很多版。最开始没有加“选择最靠近合同标题的那个”这条规则结果遇到有补充协议的合同Agent 会把补充协议里的金额也提取出来导致输出两个值。加上这条规则之后大部分情况都能正确处理了。4.4 从最小闭环到完整流程最小闭环跑通之后我开始逐步扩展能力。扩展的顺序遵循一个原则先做加法再做乘法。加法是指增加独立的审核规则。比如“合同金额超过一百万需要标记”“付款期限超过九十天需要标记”“违约责任条款缺失需要标记”。每一条规则都是一个独立的判断逻辑可以单独测试、单独调优。这个阶段我加了大概二十条规则覆盖了法务提到的大部分常规风险点。乘法是指把多个规则组合起来形成更复杂的判断。比如“合同金额超过一百万且付款期限超过九十天”这个组合风险等级比单独任何一个都高。这个阶段的难点在于规则之间的优先级和组合逻辑需要和法务反复确认。我的做法是先把组合逻辑写出来然后拿真实合同去测试看 Agent 的判断和法务的判断是否一致。不一致的地方就拿出来讨论是规则有问题还是法务的判断有特殊情况。整个扩展过程持续了大概六周。最终上线的版本包含了信息提取、规则审核、风险分级、审核意见生成四个模块。法务的使用方式是上传合同Agent 在三十秒内给出初审结果法务在这个结果的基础上做复核和修改。上线第一个月法务的平均审核时间从原来的二十五分钟降到了十二分钟左右。4.5 现场调优的典型场景现场调优和办公室调优最大的区别是现场的问题往往不是技术问题而是“技术没问题但就是用不起来”的问题。举一个例子。Agent 上线初期法务反馈说“提取的甲方名称有时候不对”。我查了日志发现 Agent 提取的是合同正文里第一次出现的甲方名称但法务期望的是签署页上的甲方名称。这两个名称大部分时候是一样的但偶尔会有细微差异比如正文里写的是“某某科技有限公司”签署页盖章的是“某某科技集团有限公司”。从技术角度看Agent 没做错但从业务角度看法务需要的是签署页上的那个名称因为那才是具有法律效力的主体。这个问题怎么解决不是改 prompt 让 Agent 去猜而是直接调整提取逻辑优先从签署页提取签署页找不到再回退到正文。这个调整只花了十分钟但它解决的是一个真实的业务痛点。类似这样的调整在现场几乎每天都会遇到。FDE 的价值就体现在这里——你能第一时间发现问题、理解问题、解决问题而不是等用户提工单、等排期、等版本更新。5. 双向赋能现场经验怎么反哺产品5.1 建立反馈回路的三个关键动作FDE 模式如果只做“把产品带到现场”这一个方向那就浪费了一半的价值。真正让这个模式成立的是双向流动现场经验要能回流到产品团队推动产品迭代。我们当时建了三个机制来保证这个回流。第一个是每日站会同步。每天下班前现场的 FDE 和产品团队开一个十五分钟的短会同步当天遇到的典型问题。这个会的规则是只讲具体案例不讲抽象感受。不说“今天用户反馈体验不好”而是说“今天用户上传了一份带密码的 PDFAgent 直接报错了期望是能提示用户先解密”。这种具体的描述能让产品团队快速定位问题。第二个是 bad case 库。所有现场遇到的失败案例都记录到一个共享文档里格式统一场景描述、输入样本、期望输出、实际输出、影响程度、临时解决方案。这个库每周由产品团队过一遍决定哪些进迭代、哪些改文档、哪些暂时不处理。我印象最深的是一个关于日期格式的 bad case合同里的日期写的是“二零二四年三月十五日”Agent 提取出来之后没有转换成标准格式导致后续的日期比较逻辑出错。这个问题在测试环境从来没出现过因为测试样本里都是阿拉伯数字日期。这个 case 直接推动了产品团队在提取模块里增加了一个日期归一化的处理步骤。第三个是现场周报。每周写一份简短的周报不是流水账而是聚焦三个问题本周发现了什么新场景、遇到了什么新问题、对产品有什么建议。这份周报会发给产品、研发、售前三个团队。它的作用不是汇报工作而是让后方团队保持对前线的感知。5.2 从现场需求到产品功能的转化案例有一个案例我经常拿出来讲因为它很典型地展示了 FDE 模式的双向价值。现场法务在用了两周 Agent 之后提了一个需求“能不能让 Agent 在审核意见里引用具体的合同条款原文”。这个需求听起来很简单但背后反映的是一个深层问题法务不信任 Agent 的判断他们需要看到判断依据。如果 Agent 说“付款期限过长”法务会问“哪里看出来的”。如果 Agent 能直接引用条款原文法务的复核效率会大幅提升。我把这个需求带回了产品团队。产品团队一开始的理解是“在输出里加一个引用字段”。但我在现场观察到的情况是法务需要的不是简单的引用而是引用加定位——他们希望点击引用能直接跳转到合同 PDF 的对应位置。这个需求就从一个简单的字段增加变成了一个涉及 PDF 解析、坐标映射、前端交互的完整功能。这个功能后来成了产品的标准能力之一不仅用在这个客户上后面几个客户也都提了类似需求。如果没有 FDE 在现场的观察和翻译产品团队可能只会做一个简单的引用字段然后发现客户还是不满意但不知道为什么。5.3 轮岗与社区分享机制的实际运作关于 FDE 的轮岗和社区分享机制我了解到的做法是FDE 工程师通常会在现场项目上待三到六个月然后回到产品团队待一到两个月做两件事。一是把现场经验整理成文档和案例二是参与产品迭代的讨论和设计。这个轮岗节奏的目的是防止 FDE 长期脱离产品也防止产品团队长期脱离现场。社区分享机制则是定期组织 FDE 之间的经验交流。形式不固定有时候是线上分享有时候是文档沉淀。我参与过的一次分享是关于“怎么在客户现场快速建立信任”分享者讲了一个很实用的技巧第一周不要讲方案只问问题。他说他每次到新客户现场第一周只做一件事——问业务人员“你现在最花时间的事情是什么”“你觉得最没意义但又不得不做的事情是什么”“如果有一个助手你最希望它帮你做什么”。这三个问题能快速定位到最有价值的场景也能让业务人员感觉到你是来解决问题的不是来卖产品的。6. 常见问题与避坑指南6.1 现场交付的五个典型坑坑一需求蔓延。现场最大的诱惑是“顺便把这个也做了”。业务人员看到 Agent 能干活就会不断提新需求。如果不控制项目范围会无限扩大最后什么都做不完。我的应对方法是所有新需求都记录但不立即做。每周和客户开一次需求优先级会由客户自己决定哪些先做、哪些后做。这个动作把决策压力还给客户也避免了 FDE 自己拍脑袋决定做什么。坑二过度承诺。现场气氛好的时候很容易说出“这个没问题”“下周就能上”这样的话。但 Agent 项目的不确定性很高很多问题在真正做之前不知道会遇到什么。我的原则是承诺范围不承诺时间。可以说“这个功能我们会做”但不说“这个功能周三之前能做完”。给自己留出缓冲空间也给客户一个合理的预期。坑三忽视数据质量。Agent 的表现高度依赖输入数据的质量。现场的数据往往比测试环境脏得多扫描件模糊、格式混乱、字段缺失、编码错误。如果不提前做数据质量评估后面会花大量时间在数据清洗上。我的做法是在项目启动阶段就做一次数据抽样检查看看真实数据的分布和质量然后把这个信息同步给客户和产品团队让大家对难度有共识。坑四只关注技术不关注使用习惯。Agent 做得再好如果业务人员不用就是零。我在现场见过一个功能技术上很完美但业务人员就是不用因为“要多点两下”。后来把入口从二级菜单提到一级菜单使用率立刻上去了。这个教训是在现场使用体验的优先级不低于功能正确性。坑五不记录、不沉淀。现场每天产生大量信息和经验如果不记录项目结束就全丢了。我要求自己每天花十五分钟写现场日志记录当天的问题、解决方法和观察。这些日志后来成了产品迭代的重要输入也成了我自己复盘和成长的素材。6.2 常见问题速查表问题现象可能原因排查方向临时解决方案Agent 执行中断报错信息模糊工具调用失败或超时检查每个工具调用的日志确认哪一步失败增加重试机制设置超时阈值提取结果不稳定同一份合同多次运行结果不同prompt 存在歧义或模型温度设置过高检查 prompt 中的模糊表述降低温度参数固定温度参数增加输出格式约束扫描件处理效果差OCR 识别率低或文本噪声大检查 OCR 输出质量评估是否需要预处理增加图像预处理步骤或提示用户上传清晰版本业务人员不使用 Agent入口太深或操作步骤太多观察业务人员的实际操作路径简化入口减少操作步骤Agent 判断与法务判断不一致规则定义不清晰或存在例外情况收集不一致的案例分析规律将例外情况加入规则库或标记为人工复核6.3 几条个人经验第一条经验是在现场速度比完美重要。业务人员不会等你把功能做到一百分再用他们会在你做到六十分的时候就开始用然后用他们的反馈帮你做到八十分。所以不要憋大招快速上线、快速迭代。第二条经验是学会说“我不知道”。现场会遇到很多你答不上来的问题这时候硬答不如诚实说“这个我需要确认一下”。客户对诚实的人容忍度很高对不懂装懂的人容忍度很低。第三条经验是把客户变成你的队友。FDE 不是单方面输出而是和客户一起解决问题。我在现场最有效的一个做法是遇到复杂问题时直接拉业务人员一起讨论让他们参与方案设计。这样不仅方案更贴合实际而且他们对最终结果的接受度也更高。第四条经验是保护好自己。现场交付的节奏很快压力很大容易陷入疲劳。我的做法是每天留出固定的休息时间哪怕只是半小时的散步。状态好的时候做的判断比疲劳时做的判断靠谱得多。7. 这个模式后续还能怎么扩展FDE 模式目前主要在 AI Agent 项目里被讨论但它的底层逻辑——把工程能力前置到场景现场通过双向反馈实现产品和场景的共同进化——其实适用于很多领域。我最近在观察几个方向觉得挺有意思。一个是AI 测试开发。测试工作和 FDE 有相似之处都需要理解业务场景、都需要在现场发现问题、都需要把问题反馈给开发团队。如果把 FDE 的思路引入测试让测试人员更早介入需求阶段、更深入理解业务逻辑可能会改变现在“开发完再测”的被动模式。另一个是专利相关辅助。我了解到有一些团队在用 AI 辅助做专利检索和分析这个场景和合同审核很像输入是非结构化的文档判断依赖领域知识输出需要人工复核。FDE 模式在这里的适配度很高因为专利分析的需求同样模糊、同样需要现场澄清、同样需要双向反馈。还有一个方向是企业内部的能力建设。很多公司买了 AI 工具但用不起来缺的不是工具而是那个“把工具和场景对接起来”的人。如果每个业务部门都有一个类似 FDE 的角色专门负责理解本部门的场景、对接技术团队、推动工具落地AI 的渗透率可能会高很多。这些方向目前都还在早期没有形成标准做法。但我觉得 FDE 模式的核心思路——前线共创、双向赋能——会越来越被认可。因为 AI 落地的难点从来不在技术本身而在技术和场景之间的那道鸿沟。谁能把这道鸿沟填上谁就能真正把 AI 用起来。我在实际项目里最深的体会是FDE 不是一个岗位名称而是一种工作方式。它的本质是把耳朵贴到地面上听真实的声音然后快速做出反应。这个能力在任何时代都有价值只是在 AI 时代变得格外稀缺。如果你正在做 Agent 项目不管你的 title 是什么我都建议你用 FDE 的视角去工作——去现场、去观察、去和真实用户一起打磨。这个过程会很累但收获也会很大。