企业官网建设流程全解析

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

第一次听到 FDE 这个词，是在一个做企业级 AI 落地的群里。有人甩了一张组织架构图，说他们公司新设了“前线交付工程师”岗位，缩写就是 FDE。底下立刻有人接话：“不就是售前加实施的缝合怪吗？”另一个人回：“你干过就知道了，纯售前搞不定，纯实施也搞不定。”

这句话基本概括了 FDE 模式的核心矛盾。传统软件交付的分工是：销售签单，产品经理写需求，研发做功能，实施去客户现场部署，售后接锅。这条链路在标准化 SaaS 时代跑得通，因为产品是固定的，客户适应产品就行。但到了 AI Agent 和 Skill 编排这类项目上，这套分工直接崩了——客户自己都不知道想要什么，你怎么写需求文档？

FDE 模式要解决的就是这个断层。它把“懂业务场景的人”直接推到前线，让他同时具备三种能力：能跟客户聊清楚真实痛点，能动手搭出可运行的 Agent 原型，能把原型转化成可交付的 Skill 配置。这个人不完全是工程师，也不完全是销售，更接近“带着技术工具箱的业务翻译”。

我观察下来，FDE 模式在三种场景下特别成立。第一种是 AI Agent 项目，客户说“我要一个智能客服”，但实际需求可能是工单自动分类加知识库检索加人工兜底，这三件事的技术路径完全不同。第二种是 Skill 编码类项目，比如把某个行业的专家经验拆成可复用的 Skill 模块，这需要既懂行业又懂 Skill 编排逻辑的人在现场反复调试。第三种是 ADP（Agent Development Platform）平台的落地，平台方提供能力，但客户的具体业务流程需要有人现场做适配。

注意：FDE 不是万能药。如果项目需求已经非常明确，比如就是接一个支付接口，那用 FDE 就是浪费人力。FDE 的价值在于需求模糊、场景复杂、需要快速验证的早期阶段。

2. FDE 工程师的能力模型拆解

2.1 技术侧：Agent 开发与 Skill 编排是基本功

FDE 工程师不需要写底层推理引擎，但必须能熟练使用主流 Agent 框架。我试过用几种不同的框架搭同一个任务型 Agent，差异非常明显。有的框架在工具调用上很顺手，但记忆管理一塌糊涂；有的框架记忆做得好，但 Skill 注册流程繁琐到让人想砸键盘。

实际工作中，FDE 最常做的技术动作是这三类：

• Agent 流程编排：把客户的业务逻辑拆成“感知-决策-执行”的循环，确定哪些步骤用大模型推理，哪些步骤用规则引擎兜底。比如一个合同审核 Agent，条款抽取用模型，金额校验用正则，风险等级判断用规则表。
• Skill 封装与注册：把可复用的能力打包成 Skill。这里有个坑，很多新手会把整个业务流程塞进一个 Skill，结果调试时根本定位不到问题。正确的做法是按“单一职责”拆分，一个 Skill 只做一件事，比如“查询订单状态”是一个 Skill，“计算退款金额”是另一个 Skill。
• ADP 平台配置：不同 ADP 平台的配置逻辑差异很大。有的平台用 YAML 定义 Agent 行为，有的用可视化拖拽，有的直接写代码。FDE 需要快速摸清平台的“脾气”，知道哪些配置项是坑，哪些默认值必须改。

2.2 业务侧：比客户更懂他的业务

这句话听起来很狂，但实际就是这样。客户内部的业务专家往往只熟悉自己那一亩三分地，跨部门的流程断点他们看不见。FDE 的价值在于，他见过多个同类客户的场景，知道“这个需求在别的公司是怎么解决的”。

举个例子，我参与过一个零售客户的库存预警 Agent 项目。客户一开始的需求是“库存低于阈值时发通知”。聊了半小时后发现，他们真正的问题是采购部门和生产部门对“安全库存”的定义不一致，导致预警频繁误报。这个问题不是技术能解决的，但 FDE 必须识别出来，并推动客户内部对齐定义，否则 Agent 做得再好也是废的。

2.3 沟通侧：用客户听得懂的话讲技术

FDE 不需要给客户讲 Transformer 架构，但需要把技术约束翻译成业务语言。比如“这个 Skill 的响应延迟在 2 秒左右”，客户可能没感觉，但你说“用户点击查询后，大概喝完一口水的时间能看到结果”，他就懂了。

我个人的经验是，跟客户沟通时永远准备两个版本的解释：一个给业务负责人听，讲投入产出和风险；一个给一线操作人员听，讲具体怎么用、出错了怎么办。这两个版本的内容差异极大，但缺一不可。

3. 从零搭建一个 FDE 式交付流程

3.1 现场调研：前三天只做一件事——看

很多 FDE 新手一到客户现场就开始问需求、记笔记，然后回去写方案。这个顺序错了。我的做法是前三天不主动问任何需求，只做三件事：看一线人员怎么操作、看系统日志里哪些环节报错最多、看跨部门沟通时哪些信息靠人工传递。

这三件事做完，基本能画出客户的“真实业务流”，而不是他们以为的业务流。我试过在一个物流客户那里，他们说自己“已经实现了数字化”，结果现场一看，调度员还在用 Excel 手动排班，因为系统里的排班功能“不好用”。这个“不好用”背后是三个具体的交互缺陷，改掉之后 Agent 的接入才有意义。

3.2 快速原型：48 小时出可演示版本

FDE 的核心竞争力之一是速度。客户对 AI 的耐心通常只有一周，如果一周内看不到可交互的东西，项目基本就凉了。我的做法是 48 小时内出一个“能跑通主流程”的原型，哪怕背后全是硬编码。

具体操作步骤：

1. 第一天上午：确定一个最小闭环场景。比如“用户输入问题 -> Agent 检索知识库 -> 返回答案并附来源”。其他所有功能全部砍掉。
2. 第一天下午：用 ADP 平台或 Agent 框架搭出流程。知识库先用几条假数据，确保检索链路通。
3. 第二天上午：接入真实数据的一小部分，比如 20 条知识库条目，测试检索准确率。
4. 第二天下午：录一个 3 分钟的操作视频，发给客户关键决策人。

这个原型的目的是“对齐预期”，不是“交付”。客户看到能跑的东西后，提出的反馈会比纯文字需求具体十倍。

3.3 Skill 拆分与编码：颗粒度决定成败

Skill 的拆分颗粒度是 FDE 最容易踩的坑。拆得太粗，一个 Skill 几百行逻辑，改一处崩三处；拆得太细，Skill 之间调用关系复杂到没人看得懂。

我的经验法则是：一个 Skill 的输入输出能用一句话说清楚，且不超过 5 个参数。比如“根据订单号查询物流状态”是一个合格的 Skill，“处理售后请求”就是一个不合格的 Skill，因为它包含了查询、判断、计算、通知等多个动作。

在 Skill 编码阶段，有几个实操要点：

• 参数校验必须前置：不要指望调用方传对参数。每个 Skill 入口处做类型检查和范围检查，错误信息要具体到“订单号格式不对，应该是 12 位数字”。
• 超时和重试要显式配置：默认超时往往太长或太短。根据 Skill 的实际耗时设置，比如查询类 3 秒，计算类 5 秒，写入类 10 秒。
• 日志要带上下文 ID：每个 Skill 调用时传入一个 trace_id，这样排查问题时能把整条链路串起来。

3.4 交付与赋能：让客户自己的人能接手

FDE 模式最怕的是“人一走，系统就没人会维护”。所以交付阶段的核心任务是“赋能”，而不是“交接文档”。

我的做法是：在项目最后两周，让客户方的 1-2 名技术人员全程参与调试和配置。FDE 不直接改配置，而是口述操作步骤，让客户的人自己动手。遇到报错时，FDE 不直接解决，而是引导对方看日志、定位问题。这个过程很慢，但两周后客户的人基本能独立处理 80% 的日常问题。

提示：赋能阶段一定要留出“故意制造故障”的环节。比如手动改错一个参数，让客户的人练习排查。这种演练比任何文档都有效。

4. 实操中遇到的典型问题与排查实录

4.1 Agent 响应不稳定，时好时坏

这是最常见的问题。同一个输入，有时候 Agent 返回正确结果，有时候胡言乱语。排查思路按以下顺序：

我遇到过一次典型情况：Agent 在测试环境稳定，在生产环境偶尔出错。最后发现是生产环境的并发请求导致某个共享缓存被污染。解决办法是给每个会话分配独立的缓存空间，而不是全局共享。

4.2 Skill 注册后不生效

这个问题通常有三个原因。第一，Skill 的触发条件写得太窄，比如只匹配了“查询订单”但用户说的是“帮我看看我的单子到哪了”。第二，Skill 的优先级被其他 Skill 覆盖，需要调整注册顺序。第三，ADP 平台的缓存没刷新，重启服务后恢复。

排查时先用平台的调试工具手动触发 Skill，看是否能正常执行。如果能执行但 Agent 不调用，就是触发条件或优先级问题；如果手动也执行不了，就是 Skill 本身的配置或代码问题。

4.3 客户业务人员抵触使用

技术问题好解决，人的问题难。我见过一个项目，Agent 做得很好，但一线人员就是不用，因为“用起来比原来还麻烦”。后来发现是交互入口太深，原来点两下能完成的操作，现在要点五下。

解决办法很简单：把 Agent 的入口放到业务人员最常用的界面上，比如企业微信或钉钉的聊天窗口。不要让他们切换系统。这个改动只花了一天，但使用率从 10% 涨到了 70%。

4.4 并发压力下的性能瓶颈

AI Agent 项目在演示阶段通常只有几个人用，一旦推广到全公司，并发问题就暴露了。我经历过一次从 10 并发到 200 并发的压力测试，响应时间从 1.5 秒飙升到 15 秒。

优化手段按优先级排序：

1. Skill 结果缓存：对于查询类 Skill，相同参数的请求在 5 分钟内直接返回缓存结果。
2. 模型调用批处理：把多个独立的推理请求合并成一个批次，减少网络往返。
3. 异步化非关键路径：日志记录、通知发送等操作改为异步，不阻塞主流程。
4. 限流与降级：设置合理的限流阈值，超过后返回兜底话术而不是直接报错。

5. FDE 模式的边界与个人体会

FDE 模式不是所有团队都适合。如果公司没有足够的项目密度，FDE 会变成“到处救火但哪里都做不深”的角色。我见过一个 FDE 同时跟五个项目，结果每个项目都只做了原型就撤了，客户满意度反而下降。

比较健康的节奏是一个 FDE 同时深度参与两个项目，每个项目周期控制在 4-6 周。超过这个范围，要么是需求太复杂需要拆阶段，要么是客户配合度有问题需要重新评估。

另外，FDE 的知识沉淀非常重要。每做完一个项目，必须把可复用的 Skill、配置模板、排查经验整理成内部文档。否则下一个项目又要从头踩坑。我自己的习惯是每周五下午花两小时整理本周的“踩坑记录”，这个习惯坚持了半年后，新项目的启动时间缩短了将近一半。

这个模式后续还可以往“行业 Skill 市场”的方向扩展。当 FDE 积累足够多的行业 Skill 后，可以打包成标准化的 Skill 套件，新项目直接复用 60% 的基础能力，FDE 只需要专注在 40% 的客户特有逻辑上。这样交付速度会再上一个台阶。