企业官网建设流程全解析

1. FDE 模式到底在解决什么问题

第一次听到 FDE 这个词，是在一个做企业数字化交付的朋友群里。有人甩了张截图，说“我们团队现在不叫实施顾问了，改叫 FDE”，底下立马有人接话“这不就是售前加售后合体吗”。当时我也没太当回事，直到后来连续接触了几个 AI Agent 落地项目，才发现 FDE 这个角色被反复提起，背后其实藏着一套挺实在的交付逻辑。

FDE，全称 Forward Deployed Engineer，直译过来就是“前线部署工程师”。这个叫法最早在数据智能和 AI 基础设施领域流行起来，核心意思很直白：工程师不坐在后方等需求，而是直接扎到客户现场，跟业务方一起把问题定义清楚，再当场把方案搭出来。它跟传统实施工程师最大的区别在于，传统实施是“产品已经定型，你去装、去配、去培训”，而 FDE 是“需求还没完全定型，你带着工程能力去现场共创”。

为什么这两年 FDE 突然被频繁讨论？因为 AI Agent 这类东西的落地方式和传统软件完全不一样。传统软件卖的是功能清单，客户知道自己要什么，你按单交付就行。但 Agent 不一样，客户往往只知道“我想让 AI 帮我处理这块业务”，具体怎么拆任务、怎么设计工具调用、怎么控制幻觉、怎么跟现有系统对接，这些在签合同的时候根本说不清楚。这时候如果还按老流程走——销售签单、产品经理写 PRD、研发排期、测试验收——等做出来黄花菜都凉了，需求早变了。

FDE 模式解决的就是这个“需求模糊期”的交付问题。它把工程能力前置到销售和方案阶段，让懂技术的人直接跟客户业务方对话，边聊边画原型，边验证边调整。我见过一个比较极端的例子：一个做供应链金融的团队，FDE 在客户现场待了两周，每天跟风控、运营、IT 三个部门的人泡在一起，最后交付的 Agent 工作流跟最初销售承诺的完全不是一回事，但客户满意度反而更高，因为真正解决了他们“合同审核要来回切换五个系统”的痛点。

这套模式适合谁来参考？如果你在做 AI Agent 相关的项目交付，不管是乙方实施团队还是甲方内部创新部门，FDE 的思路都值得借鉴。哪怕你不叫这个 title，把“工程能力前置、现场共创、快速验证”这三个原则用起来，交付成功率会明显不一样。接下来我会从模式设计、核心能力、实操流程、常见坑几个角度，把 FDE 这套东西拆开讲清楚。

2. FDE 模式的核心设计与角色定位

2.1 为什么传统交付流程在 Agent 项目上容易翻车

传统软件交付的经典链路是：销售签单 → 需求调研 → 方案设计 → 开发排期 → 测试验收 → 上线运维。这条链路在标准化产品上跑了很多年，没什么大问题。但放到 AI Agent 项目上，它有三个致命伤。

第一个是需求传递失真。销售跟客户聊的时候，客户说“我想要一个能自动处理客诉的 AI”，销售理解成“做一个工单分类机器人”，产品经理写成“基于 NLP 的工单意图识别模块”，研发做出来一个分类准确率 92% 的模型。结果上线后客户说“我要的是它能直接回复客户，不是只给我打个标签”。每一层传递都丢信息，最后交付的东西跟客户脑子里的东西差了一大截。

第二个是验证周期太长。Agent 的效果高度依赖具体业务数据和场景细节，你不把真实数据跑一遍，根本不知道行不行。但传统流程里，研发在后方开发，客户在现场等着，中间隔了好几周甚至几个月。等第一版出来给客户看，客户说“这个场景我们上个月已经改了”，或者“这个数据格式跟我们实际的不一样”，返工成本极高。

第三个是责任边界模糊。Agent 项目里，效果不好到底是模型问题、数据问题、流程设计问题还是客户使用方式问题？传统交付模式下，乙方说“我按需求文档做的”，甲方说“这不是我要的效果”，扯皮扯不清楚。FDE 模式通过现场共创，把这些问题在过程中就暴露和解决掉，而不是等到验收时才爆发。

2.2 FDE 的角色定位：不是售前，也不是售后

很多人第一次接触 FDE，会把它理解成“售前工程师”或者“解决方案架构师”的变体。实际上 FDE 的定位更偏“带着工程能力的业务共创者”。我画个表对比一下几个容易混淆的角色。

FDE 最特殊的地方在于，他既要能跟客户业务方聊明白“你们这个审批流程到底卡在哪”，又要能当场打开编辑器写一段工具调用代码验证想法。这种“上下兼容”的能力组合，在传统分工体系里是缺失的。售前不懂代码，研发不懂业务，中间就出现了一个真空地带，FDE 就是来填这个真空的。

2.3 双向赋能：FDE 模式对甲乙双方的价值

“双向赋能”这个词听起来有点虚，但放到 FDE 场景里其实很具体。

对客户方来说，FDE 带来的最大价值是降低试错成本。Agent 项目最怕的是“做了半年发现方向错了”。FDE 在现场用真实数据快速搭原型，一两周就能让客户看到“这个方向行不行”。行就继续深入，不行就换方向，试错成本从几个月压缩到几天。另外，FDE 在共创过程中会把一些工程思维和方法论传递给客户的业务团队，比如怎么定义任务边界、怎么设计人机协作流程，这些知识会留在客户组织里。

对交付方来说，FDE 模式的价值是提高交付成功率和客户粘性。传统项目交付完，客户觉得“也就那样”，续约率低。FDE 在现场跟客户一起把问题解决掉，客户会觉得“这帮人真懂我的业务”，后续扩展新场景时第一个想到你。而且 FDE 在現場积累的业务理解，会反哺到产品团队，让产品迭代更有方向。我认识一个做 AI 客服 Agent 的团队，他们的 FDE 在客户现场发现“客户最需要的不是自动回复，而是自动生成回复建议给人工审核”，这个洞察直接改变了产品路线图。

3. FDE 核心能力拆解与实操要点

3.1 业务翻译能力：把模糊需求变成可执行任务

FDE 第一项核心能力是“业务翻译”。客户说“我想让 AI 帮我处理合同”，这句话信息量几乎为零。FDE 要做的是通过追问和观察，把它拆成可执行的任务链。

我通常会用一套“五问拆解法”：

1. 触发条件是什么：合同从哪里来？邮件、系统推送还是人工上传？
2. 输入是什么格式：PDF、Word 还是扫描件？有没有固定模板？
3. 处理动作有哪些：提取关键字段、比对条款、生成摘要还是直接审批？
4. 输出给谁用：结果给法务看、给业务看还是直接进系统？
5. 异常怎么处理：识别不了怎么办？有歧义怎么办？谁来兜底？

这五个问题问完，一个模糊的“处理合同”就变成了“从邮箱监听新邮件 → 下载 PDF 附件 → 提取甲乙方、金额、付款条款 → 与标准模板比对差异 → 生成差异报告 → 推送给法务企业微信 → 法务确认后回写合同系统”这样一条清晰的任务链。

注意：FDE 在翻译需求时，不要追求一次问全。客户往往说不清楚，你需要先搭一个粗糙的原型给他看，他看到具体的东西才能给出有效反馈。先做出来再问，比一直问不做效率高得多。

3.2 快速原型能力：用 Agent 框架搭出可验证的 Demo

FDE 的第二项能力是快速把想法变成可运行的原型。这里涉及 Agent 框架选型和 Skill 编排。

目前主流的 Agent 开发框架有几种路线。一种是代码优先的，比如用 Python 写 Agent 逻辑，灵活但开发速度慢；一种是配置优先的，通过可视化编排工具拖拽节点，上手快但复杂逻辑受限；还有一种是混合模式，核心逻辑用代码写，外围用配置。FDE 在现场通常时间紧，我建议优先选配置优先或混合模式，先把流程跑通，后面再优化。

Skill 的设计是原型阶段的关键。一个 Skill 就是一个可复用的能力单元，比如“提取 PDF 文本”“调用企业微信 API”“查询合同数据库”。FDE 在现场要快速判断哪些 Skill 可以直接用现成的，哪些需要现场写。我的经验是，通用能力用现成的，业务特有逻辑现场写。比如文件解析、HTTP 请求这些通用 Skill 直接用，但“根据公司合同模板比对差异”这种就要现场写一个。

# 一个简单的 Skill 示例：提取合同关键字段 # 实际项目中会根据具体业务调整 prompt 和校验逻辑 def extract_contract_fields(text): prompt = """ 从以下合同文本中提取： - 甲方名称 - 乙方名称 - 合同金额 - 付款方式 - 签约日期 以 JSON 格式返回，找不到的字段填 null。 """ result = llm_call(prompt + text) return validate_json(result)

这个 Skill 看起来简单，但现场写的时候有几个细节要注意。一是输出格式要严格约束，不约束的话模型返回的 JSON 可能带 markdown 代码块标记，后面解析会报错。二是要有校验和重试，模型偶尔会漏字段或格式错误，加一层校验和重试能显著提高稳定性。三是prompt 里要给出字段的边界定义，比如“合同金额”是含税还是不含税，不写清楚模型会猜。

3.3 现场沟通能力：跟业务方泡在一起的本事

FDE 第三项能力是沟通，但这个沟通跟销售式的沟通不一样。销售沟通是为了签单，FDE 沟通是为了把业务逻辑挖干净。

我自己的做法是“跟班观察 + 即时追问”。不要只坐在会议室里问，要坐到业务人员旁边看他实际操作。他打开哪个系统、点哪个按钮、复制什么数据、粘贴到哪里，这些动作里藏着大量他没说出来的信息。看到不懂的就当场问“这一步为什么要复制到 Excel 里”“这个字段你一般怎么判断”，往往能挖出关键的业务规则。

还有一个技巧是用他们的行话。每个行业都有自己的黑话，比如金融行业说“头寸”“敞口”，物流行业说“落货”“分拨”。FDE 如果能用客户的行话交流，客户会觉得“你懂我”，信任建立得快很多。我刚入行的时候不懂这个，用技术术语跟业务方聊，对方一脸茫然，后来我强迫自己学他们的说法，沟通效率翻倍。

实操心得：现场沟通时带一个笔记本，把客户说的关键规则、例外情况、人名系统名都记下来。不要依赖记忆，Agent 项目细节太多，漏一个例外条件后面就可能出大问题。

4. FDE 项目实操全流程拆解

4.1 进场准备：前三天要搞定的事

FDE 进场不是到了就开始写代码，前三天要做几件关键的事。

第一天：对齐目标和边界。跟客户的项目发起人聊清楚，这次共创要解决的核心问题是什么，成功标准是什么，哪些不在范围内。这一步很重要，不然后面容易范围蔓延。我见过一个项目，本来只做合同审核，结果客户业务方不断加需求，最后变成了要做整个法务系统，FDE 累死也做不完。

第二天：摸清数据和系统。要拿到真实的数据样本，了解数据存在哪里、什么格式、质量如何。同时要搞清楚 Agent 需要对接哪些系统，有没有 API，权限怎么开。这一步经常卡住，因为客户 IT 部门走流程慢，所以要提前启动。

第三天：搭建开发环境和最小原型。把 Agent 框架跑起来，用真实数据跑通一个最简单的流程。哪怕只是“读取文件 → 调用模型 → 输出结果”这样一条线，先跑通再说。跑通之后拿给客户看，客户马上就能给出反馈。

4.2 共创迭代：两周一个循环的节奏

FDE 项目的核心节奏是“两周一个共创循环”。每个循环包含：需求细化 → 原型开发 → 现场演示 → 反馈收集 → 调整优化。

第一个循环通常最粗糙，可能只覆盖主流程的 60%，但一定要让客户看到东西。客户看到具体的东西之后，反馈会非常具体，比如“这个字段提取错了”“这个审批节点应该跳过”“这个提示语太生硬”。这些反馈比任何需求文档都有价值。

第二个循环开始补异常处理和边界情况。Agent 项目最花时间的不是主流程，而是各种异常。比如合同扫描件模糊怎么办、系统返回超时怎么办、模型输出格式不对怎么办。这些要在第二个循环里集中处理。

第三个循环做集成和优化。把 Agent 跟客户的实际系统对接，优化响应速度和准确率，准备上线。

注意：每个循环结束都要有明确的“可演示成果”，不要闷头开发两周然后说“还没做完”。FDE 的价值就在于持续可见的进展，客户看到进展才会有信心继续投入。

4.3 交付与交接：让客户能自己跑起来

FDE 项目最终要交付的不只是一个能跑的 Agent，还包括客户团队能自己维护和扩展的能力。

交付物通常包括：Agent 工作流配置文件、Skill 代码库、部署文档、操作手册、常见问题排查指南。但光有文档不够，FDE 要走之前要做几场培训，让客户的 IT 人员和业务人员都能上手。

我自己的做法是“影子运行”一周。FDE 还在现场，但让客户团队自己操作，FDE 在旁边看着，有问题当场解决。这一周下来，客户团队基本就能独立跑了。另外要留一个“扩展指南”，告诉客户如果想加新场景，应该改哪里、怎么测试、注意什么。这样客户后续自己就能迭代，不用每次都找原厂。

5. 常见问题与排查技巧实录

5.1 Agent 执行报错怎么快速定位

Agent 项目最常见的报错是“agent execution terminated due to error”，这个报错信息极其模糊，可能是模型调用失败、工具调用超时、输出格式解析错误、权限不足等任何原因。我的排查顺序是：

1. 看日志：Agent 框架一般会记录每一步的输入输出，先看报错发生在哪一步。
2. 单独测 Skill：把出错的 Skill 单独拿出来跑，排除是 Skill 本身的问题还是编排的问题。
3. 检查输入：很多时候是输入数据格式跟预期不符，比如 PDF 解析出来是空字符串。
4. 检查权限：调用外部 API 时 token 过期或权限不足也会报这个错。
5. 加超时和重试：如果是偶发的超时，加超时和重试机制通常能解决。

5.2 客户说“效果不好”时怎么接

客户说“效果不好”是最常见的反馈，但这句话本身没有可操作性。FDE 要做的是把它拆成具体问题。

我会问三个问题：哪些 case 不好？不好在哪里？期望是什么？让客户举出具体例子，然后一起看这个例子的输入输出，定位是哪个环节出了问题。是提取错了、判断错了还是格式不对？定位到具体环节之后，解决起来就快了。

还有一种情况是客户期望本身不合理。比如客户期望 Agent 100% 准确，这在当前技术条件下不现实。这时候 FDE 要管理期望，说明“我们会做到 90% 以上，剩下的 10% 需要人工兜底”，并且设计好人机协作流程。把“AI 全自动”变成“AI 辅助人工”，客户接受度会高很多。

5.3 FDE 自己的避坑清单

做了几个 FDE 项目之后，我总结了几条自己的避坑经验：

• 不要承诺做不到的事：现场气氛热烈的时候容易上头，客户说什么都答应。但 Agent 的能力边界要心里有数，做不到的当场说清楚，比后面翻车好。
• 不要跳过数据摸底：我吃过亏，进场第三天就开始写代码，写到一半发现客户数据格式跟预想的完全不一样，返工重来。数据摸底再花时间也值得。
• 不要一个人扛：FDE 在现场压力很大，技术、沟通、项目管理都要管。背后要有一个支持团队，遇到搞不定的技术问题能快速求助。
• 不要忽略文档：现场节奏快，容易只顾着写代码不写文档。但 FDE 走了之后客户要维护，文档不全后面全是坑。每天花半小时整理当天的工作，后面省很多事。
• 不要忘记轮岗和社区分享：FDE 长期在外，容易跟公司内部脱节。定期回公司做分享，把现场经验沉淀成可复用的 Skill 和方案，对自己和团队都有价值。

6. FDE 工程师的成长路径与学习建议

6.1 从哪个方向切入比较现实

如果你现在做的是传统实施、售前或者开发，想转 FDE，我建议从自己最熟悉的领域切入。做金融实施的，先做金融行业的 FDE；做电商开发的，先做电商 Agent 的 FDE。行业知识是 FDE 的核心壁垒，不要轻易丢掉。

技术方面，需要补的主要是 Agent 框架的使用、Prompt 工程、基础的数据处理能力。不需要成为算法专家，但要能理解模型的能力边界，知道什么能做、什么做不了、大概怎么做。吴恩达的 Agent 教程、主流 Agent 框架的官方文档，都是不错的起点。

6.2 现场快速学习的技巧

FDE 经常要面对自己不熟悉的行业，快速学习能力很重要。我的方法是“三遍法”：第一遍让客户讲一遍业务流程，我只听不打断；第二遍我复述一遍，让客户纠正；第三遍我画成流程图，让客户确认。三遍下来，基本就能把业务逻辑搞清楚。

另外要善用 AI 辅助。遇到不懂的行业术语，当场用 AI 查；写 Skill 的时候，让 AI 帮忙生成初版代码再改。FDE 的核心竞争力不是什么都懂，而是快速搞懂并落地的能力。

6.3 长期发展的几个方向

FDE 做久了，有几个发展方向。一是行业专家型 FDE，深耕某个行业，成为这个行业 Agent 落地的首选人选。二是平台型 FDE，把现场经验沉淀成可复用的 Skill 库和方案模板，提高整体交付效率。三是转产品或解决方案，把一线洞察带回产品团队，影响产品方向。

不管走哪个方向，FDE 阶段积累的“现场感”都是宝贵资产。知道客户真正需要什么、知道方案落地会卡在哪里，这种判断力是坐在办公室里学不到的。

我在实际项目里最大的体会是，FDE 这个角色本质上是在填一个“技术与业务之间的翻译层”。AI Agent 的能力越来越强，但客户不会因为技术强就买单，他们买单是因为问题被解决了。FDE 就是那个把技术能力翻译成业务价值的人。这个角色累，但成就感也强，每次看到客户说“这个东西真省了我好多事”，就觉得值了。