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 和产品团队开一个十五分钟的短会，同步当天遇到的典型问题。这个会的规则是：只讲具体案例，不讲抽象感受。不说“今天用户反馈体验不好”，而是说“今天用户上传了一份带密码的 PDF，Agent 直接报错了，期望是能提示用户先解密”。这种具体的描述能让产品团队快速定位问题。

第二个是 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 常见问题速查表

6.3 几条个人经验

第一条经验是：在现场，速度比完美重要。业务人员不会等你把功能做到一百分再用，他们会在你做到六十分的时候就开始用，然后用他们的反馈帮你做到八十分。所以不要憋大招，快速上线、快速迭代。

第二条经验是：学会说“我不知道”。现场会遇到很多你答不上来的问题，这时候硬答不如诚实说“这个我需要确认一下”。客户对诚实的人容忍度很高，对不懂装懂的人容忍度很低。

第三条经验是：把客户变成你的队友。FDE 不是单方面输出，而是和客户一起解决问题。我在现场最有效的一个做法是，遇到复杂问题时直接拉业务人员一起讨论，让他们参与方案设计。这样不仅方案更贴合实际，而且他们对最终结果的接受度也更高。

第四条经验是：保护好自己。现场交付的节奏很快，压力很大，容易陷入疲劳。我的做法是每天留出固定的休息时间，哪怕只是半小时的散步。状态好的时候做的判断，比疲劳时做的判断靠谱得多。

7. 这个模式后续还能怎么扩展

FDE 模式目前主要在 AI Agent 项目里被讨论，但它的底层逻辑——把工程能力前置到场景现场，通过双向反馈实现产品和场景的共同进化——其实适用于很多领域。我最近在观察几个方向，觉得挺有意思。

一个是AI 测试开发。测试工作和 FDE 有相似之处：都需要理解业务场景、都需要在现场发现问题、都需要把问题反馈给开发团队。如果把 FDE 的思路引入测试，让测试人员更早介入需求阶段、更深入理解业务逻辑，可能会改变现在“开发完再测”的被动模式。

另一个是专利相关辅助。我了解到有一些团队在用 AI 辅助做专利检索和分析，这个场景和合同审核很像：输入是非结构化的文档，判断依赖领域知识，输出需要人工复核。FDE 模式在这里的适配度很高，因为专利分析的需求同样模糊、同样需要现场澄清、同样需要双向反馈。

还有一个方向是企业内部的能力建设。很多公司买了 AI 工具但用不起来，缺的不是工具，而是那个“把工具和场景对接起来”的人。如果每个业务部门都有一个类似 FDE 的角色，专门负责理解本部门的场景、对接技术团队、推动工具落地，AI 的渗透率可能会高很多。

这些方向目前都还在早期，没有形成标准做法。但我觉得 FDE 模式的核心思路——前线共创、双向赋能——会越来越被认可。因为 AI 落地的难点从来不在技术本身，而在技术和场景之间的那道鸿沟。谁能把这道鸿沟填上，谁就能真正把 AI 用起来。

我在实际项目里最深的体会是：FDE 不是一个岗位名称，而是一种工作方式。它的本质是把耳朵贴到地面上，听真实的声音，然后快速做出反应。这个能力在任何时代都有价值，只是在 AI 时代变得格外稀缺。如果你正在做 Agent 项目，不管你的 title 是什么，我都建议你用 FDE 的视角去工作——去现场、去观察、去和真实用户一起打磨。这个过程会很累，但收获也会很大。