企业官网建设流程全解析

1. FDE 到底在解决什么问题：从一个被反复追问的现场说起

第一次听到 FDE 这个词，是在一个做企业智能体落地的项目群里。有人问："我们买了平台、买了模型额度，为什么业务部门还是用不起来？"群里沉默了几秒，然后有人回了一句："因为缺一个既懂业务现场、又能动手改代码的人。"这句话基本就是 FDE（Forward Deployed Engineer，前线部署工程师）这个角色存在的全部理由。

传统交付链条是这样的：售前讲方案，产品做功能，研发写代码，实施做配置，最后交给客户。链条一长，信息就衰减。业务现场那句"我要的不是这个"往往传到研发那里已经变成了"客户希望优化交互体验"，需求被磨平了棱角，交付出来的东西自然对不上。FDE 模式的核心动作，是把一个工程能力过硬的人直接放到业务现场，让他同时承担需求翻译、方案设计、原型开发、效果调优这几件事，把"反馈—修改"的循环从几周压缩到几小时。

这篇内容适合三类人看：一是正在做 AI Agent、大模型应用落地的工程师，想知道自己离 FDE 还差什么；二是团队管理者，在纠结要不要设这个岗、怎么设；三是刚入行、看到"FDE 工程师学习路线""FDE 解决方案工程师"这类词但搞不清它和普通开发、普通售前的区别的人。我会把 FDE 的能力结构、和 Agent/Skill 这些技术概念的关系、轮岗与晋升机制、以及实际落地中踩过的坑，按我自己的理解完整拆一遍。

需要先说明一点：FDE 不是一个新发明的职位名称，它更像是一种工作方式的命名。不同公司叫法不同，有的叫解决方案工程师，有的叫交付架构师，有的干脆就叫"驻场开发"。名字不重要，重要的是它背后那套"前线共创、双向赋能"的逻辑——前线拿到真实场景，反哺产品；产品能力增强，又让前线交付更快。这个循环转起来，才是 FDE 模式真正值钱的地方。

2. FDE 的能力结构：为什么它既不是纯开发也不是纯售前

2.1 三种能力的交集，而不是三种能力的叠加

很多人对 FDE 的误解是"要求太高了，又要会写代码又要会沟通还要懂业务"。这个理解方向就错了。FDE 不是把三个岗位的活全干一遍，而是站在三者的交集上做事。

我画不出图，但可以这样描述：纯研发关注"这个功能怎么实现"，纯售前关注"这个方案怎么讲清楚"，纯业务关注"这个流程能不能跑通"。FDE 关注的是"这个场景里，用现有技术能力，最快能跑出什么可验证的结果"。注意关键词是"可验证"和"最快"。

这意味着 FDE 的编码能力不需要达到架构师级别，但必须能独立写出可运行的原型；沟通能力不需要达到金牌销售级别，但必须能把业务语言翻译成技术约束；业务理解不需要成为行业专家，但必须能识别出哪些需求是真痛点、哪些是伪需求。

这张表是我自己总结的，不一定严谨，但能说明问题。FDE 的成功标准是"场景跑通"，不是"功能上线"，也不是"合同签订"。这个标准决定了 FDE 的所有行为逻辑。

2.2 为什么"翻译能力"是 FDE 最稀缺的技能

我见过不少技术很强的人转 FDE 失败，卡点几乎都在翻译能力上。业务方说"这个报表能不能自动生成"，技术人第一反应是"数据源在哪、字段怎么映射、用什么模板引擎"。但 FDE 的第一反应应该是："你现在这个报表是给谁看的？多久看一次？生成之后要做什么决策？"

这两个反应的区别在于：前者在解一个技术题，后者在解一个业务题。技术题的答案往往有很多种，业务题的答案往往只有一两种是真正有用的。FDE 的价值就在于，他能判断出哪种技术方案对应的是真正有用的那个业务答案。

举个具体的例子。某团队做合同审核 Agent，业务方一开始提的需求是"帮我把合同里的风险条款标出来"。如果直接按这个需求做，就是做一个条款识别加分类的模型。但 FDE 到现场看了一圈发现，法务真正花时间的不是"找风险条款"，而是"找完之后要写一段解释说明给业务部门"。所以真正该做的是"识别风险条款 + 生成解释话术"，后者才是省时间的地方。

这个判断不是靠技术能力做出来的，是靠现场观察和追问做出来的。这就是为什么 FDE 必须"在前线"，远程开会问不出这种细节。

2.3 技术底子要扎实到什么程度

虽然 FDE 不追求架构师级别的深度，但技术底子必须扎实到能独立排错。我个人的判断标准是：给你一个 Agent 框架，你能在半天内跑通一个带工具调用的 demo；给你一份 API 文档，你能在一小时内写出可用的调用脚本；给你一个报错日志，你能定位到是模型输出格式问题还是工具参数问题。

这个标准听起来不高，但实际能达到的人不多。因为大部分工程师习惯了在成熟框架里做业务开发，一旦要自己搭环境、自己调 prompt、自己处理模型输出的不确定性，就会卡住。

FDE 面对的技术栈通常包括这几块：

• 大模型调用层：不只是调 API，还要理解 temperature、top_p 这些参数对输出稳定性的影响，知道什么时候该用结构化输出、什么时候该用自由文本。
• Agent 编排层：理解 Agent 和 Skill 的区别（后面会细讲），知道什么场景该用单 Agent、什么场景该用多 Agent 协作。
• 工具集成层：能把业务系统封装成 Agent 可调用的工具，处理好鉴权、限流、异常返回。
• 效果评估层：能设计一套简单的评估方法，判断这次改动是变好了还是变差了。

这四层里，最容易被人忽略的是第四层。很多 FDE 做完改动之后，凭感觉说"好像好了一点"，但没有量化依据。时间一长，改动越堆越多，效果反而下降，因为没人知道哪个改动是有效的。

3. Agent、Skill、ADP：FDE 必须理清的几个技术概念

3.1 Agent 和 Skill 的区别，以及为什么这个区分很重要

热词里出现了"agent skill""skill和agent的区别""skill插件""skill脚本"这些词，说明很多人在这两个概念上犯迷糊。我用一个类比来解释。

Agent 像一个员工，Skill 像这个员工会的一项技能。一个员工可以会多项技能，一项技能也可以被多个员工掌握。Agent 负责"决定做什么"，Skill 负责"具体怎么做"。

放到技术实现上：Agent 通常包含一个决策循环——观察当前状态、选择下一步动作、执行动作、观察结果、继续循环。Skill 则是被 Agent 调用的一个具体能力单元，比如"查询订单状态""生成摘要""调用某个 API"。

为什么这个区分重要？因为它决定了你的系统怎么扩展。如果你把每个业务动作都写成一个独立的 Agent，系统会变得极其臃肿，因为每个 Agent 都要维护自己的决策逻辑。正确的做法是把通用能力抽成 Skill，让 Agent 去编排这些 Skill。

我见过一个反例：某团队做客服系统，把"查订单""改地址""退款"分别做成了三个 Agent。结果用户说"我要改地址，顺便看下订单到哪了"，系统就懵了，因为没有一个 Agent 能同时处理这两件事。后来改成"一个客服 Agent + 三个 Skill"，问题立刻解决。

3.2 ADP 在 FDE 工作流里的位置

ADP 这个词在不同语境下含义不同，在 Agent 开发语境里，我理解它指的是 Agent 的开发平台或编排协议层。不管具体指什么，FDE 需要关心的是：ADP 这类东西解决的是"Agent 怎么被定义、被部署、被管理"的问题。

FDE 在前线做原型时，往往不会一上来就用重型平台，而是先用脚本把流程跑通。等场景验证有效了，再考虑迁移到平台上做标准化。这个顺序不能反。我见过太多团队一上来就搭平台，结果平台搭好了，场景还没验证，最后平台成了摆设。

提示：原型阶段用脚本，验证阶段用框架，规模化阶段用平台。跳过任何一步都会付出代价。

3.3 从"能跑"到"稳定跑"之间隔着什么

Agent 系统最容易被低估的难度，是从 demo 到生产之间的那段路。demo 阶段，你输入一句话，Agent 返回一个结果，看起来很美。生产阶段，你要面对的是：用户输入千奇百怪、工具调用偶尔超时、模型输出格式偶尔跑偏、并发上来之后响应变慢。

FDE 在前线最常处理的不是"能不能做"，而是"为什么昨天能跑今天跑不了"。这类问题的排查链路通常是：

1. 先看模型输出是否格式异常——最常见的原因是 prompt 里某个约束被模型忽略了。
2. 再看工具调用是否失败——常见原因是鉴权过期或参数类型不匹配。
3. 再看上下文是否超长——长对话场景下，历史消息把窗口撑爆了。
4. 最后看是否是并发问题——多个请求同时操作同一份状态。

这个排查顺序是有讲究的，从概率高的往概率低的排。我自己的经验是，前两类问题占了八成以上。

4. 前线共创怎么落地：一个可复现的工作循环

4.1 驻场第一周该做什么，不该做什么

很多 FDE 一到现场就开始写代码，这是大忌。第一周的正确动作是观察和记录，不是开发。

我自己的做法是：第一天跟着业务人员完整走一遍他们的工作流程，不做任何打断，只记录。第二天开始追问，针对记录里出现的每一个"手动操作""复制粘贴""来回切换系统"的点，问清楚为什么要这么做、多久做一次、做错了会怎样。第三天开始画流程图，把观察到的流程和系统实际支持的流程做对比，找出差距。第四天和业务方确认哪些差距是真正值得解决的。第五天再开始动手做第一个原型。

这个节奏看起来慢，但比上来就写代码快得多。因为上来就写，大概率写的是你以为的需求，不是真实的需求，返工的时间远超观察的时间。

4.2 原型该做到什么程度就可以拿出去

原型的目的是验证方向，不是交付产品。所以原型的标准是：能让业务方用真实数据跑一遍，并且给出"对"或"不对"的判断。

具体来说，原型需要满足三个条件：一是能处理真实数据，不能只用假数据演示；二是能覆盖主流程，不需要覆盖所有边界情况；三是能在一分钟内跑完，不能让业务方等太久。

我见过有人把原型做得非常精致，UI 漂亮、交互流畅，但用的是假数据。业务方看完说"挺好的"，然后就没有然后了。因为假数据跑出来的结果没有说服力，业务方无法判断这个东西在真实场景下有没有用。

反过来，原型丑一点没关系，只要真实数据跑出来的结果是对的，业务方立刻就能给出有价值的反馈。

4.3 双向赋能里的"反向"那一半

"双向赋能"这个词，大部分人只关注了"赋能业务"这一半，忽略了"赋能产品"那一半。但后者才是 FDE 模式对公司的真正价值。

FDE 在前线看到的场景，是产品团队坐在办公室里想象不出来的。哪些功能被反复需要、哪些设计被反复吐槽、哪些边界情况反复出问题，这些信息如果能系统性地回流到产品团队，产品的迭代方向会精准得多。

我见过做得好的团队，FDE 每周会写一份"前线观察"，不是写项目进度，而是写"这周我听到业务方抱怨了三次 XX 问题""有三个不同客户都问到了 YY 功能"。这种信息比任何用户调研都真实。

反过来，如果 FDE 只顾着在前线救火，不往回传信息，那这个模式就退化成了"高级外包"，价值大打折扣。

5. 轮岗、晋升与社区分享：FDE 的成长路径怎么设计

5.1 为什么 FDE 需要轮岗

热词里出现了"fde 的轮岗 晋升 社区分享机制"，说明这是很多人在关心的组织问题。轮岗对 FDE 来说不是福利，是必需。

原因很简单：FDE 的核心能力是"快速理解一个新场景"，而这个能力只有在不断接触新场景的过程中才能保持。如果一个人在一个行业待太久，他会变成这个行业的专家，但会失去跨场景迁移的能力。而 FDE 的价值恰恰在于迁移能力。

轮岗的节奏，我看到的比较合理的做法是：一个 FDE 在一个行业深耕 6 到 12 个月，把场景做透，然后轮换到相邻行业。相邻很重要，跨度太大前期学习成本太高，跨度太小又起不到锻炼作用。

5.2 晋升标准不该看交付数量

如果用"交付了多少个项目"来考核 FDE，会导向一个坏结果：FDE 会倾向于做简单、快速能交付的项目，避开那些难但价值高的场景。

更合理的考核维度应该包括：场景验证的成功率、原型到生产的转化率、回流到产品的有效需求数量、以及在前线沉淀下来的可复用 Skill 数量。

最后一项特别重要。一个 FDE 如果每做一个项目都能沉淀出几个可复用的 Skill，那他的价值是复利增长的。反过来，如果每个项目都是从零开始，那他的价值就是线性的。

5.3 社区分享机制为什么不能省

FDE 是分散在各个前线的，如果不做社区分享，每个人踩过的坑其他人还会再踩一遍。

分享的形式可以很轻，比如每周一次线上同步，每个人讲一个"这周遇到的最奇怪的问题"和"怎么解决的"。不需要准备 PPT，不需要正式汇报，就是口头讲。这种轻量分享的频次比质量更重要，因为频次高了，信息流动才快。

我自己的体会是，FDE 之间最有价值的分享不是"我做了什么"，而是"我以为是这样，结果发现是那样"。前者是成果展示，后者是认知修正，后者对听的人帮助大得多。

6. 实操中踩过的坑与排查链路

6.1 需求翻译错误的典型表现

最常见的坑是：业务方说"我要 A"，FDE 做出来 A，业务方说"这不是我要的"。问题出在"我要 A"这句话本身是模糊的。

我遇到过一个典型案例。业务方说"我要一个能自动分类工单的系统"。FDE 做出来一个基于文本分类的 Agent，准确率 85%。业务方说不行。追问之后才发现，业务方真正要的不是"分类准确"，而是"分类错误的时候能快速纠正"。因为工单分类错误的代价很高，分错了会导致处理延迟。

所以正确的方案不是提高分类准确率，而是做一个"分类 + 人工快速纠正"的流程。这个需求如果不在现场追问，是问不出来的。

排查这类问题的方法：当业务方说"不对"的时候，不要问"哪里不对"，要问"你原本打算拿这个结果做什么"。后一个问题才能挖出真实需求。

6.2 Agent 输出不稳定的排查顺序

Agent 输出不稳定是 FDE 最常处理的技术问题。我的排查顺序是这样的：

这个顺序是从改动成本低到高排的。前两步通常改 prompt 就能解决，成本最低。后两步可能要改代码，成本高。所以先查前面。

我自己的经验是，把 temperature 调到 0 能解决相当一部分"不稳定"问题，但会牺牲一些创造性。对于需要稳定输出的场景，这是值得的。

6.3 从原型到生产的环境差异

原型跑在本地，生产跑在服务器，这中间的差异能坑死人。

最常见的三个差异：一是网络环境，本地调 API 很快，生产环境可能有延迟；二是并发，本地一个人用，生产可能几十个人同时用；三是数据量，本地测试用几百条数据，生产可能是几百万条。

FDE 在原型阶段就要考虑这些差异，至少要做一次"模拟生产环境"的测试。比如用并发脚本压一下，用真实规模的数据跑一遍。这一步花的时间不多，但能避免上线后才发现问题。

7. 我对 FDE 模式的一点个人判断

做了几个项目之后，我越来越觉得 FDE 模式的核心不是"人"，而是"循环"。一个 FDE 再强，如果前线的信息不能回流到产品，产品的能力不能反哺到前线，那这个模式就是不可持续的。

判断一个团队适不适合搞 FDE，我会看三个信号：一是产品团队愿不愿意听前线的"坏消息"；二是 FDE 有没有时间做沉淀，而不是被项目排期填满；三是公司是否容忍原型阶段的"不完美"。这三个信号里任何一个缺失，FDE 都会退化成普通交付。

另外分享一个小技巧：FDE 在前线做原型时，尽量把每个 Skill 都写成独立可测试的单元。这样即使整个 Agent 流程还没跑通，单个 Skill 也能拿给业务方看，提前收集反馈。这个习惯能显著缩短反馈循环，是我自己踩了不少坑之后才养成的。