企业官网建设流程全解析

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

第一次听到 FDE 这个词，是在一个做企业级 AI 落地的群里。有人甩了张截图，说“我们团队现在不叫解决方案工程师了，改叫 FDE”，底下立刻有人接话“这不就是售前换了个马甲”。我当时也这么想，直到自己带着两个人扎进一个制造业客户的现场，蹲了整整三周，才明白 FDE 和传统售前、传统交付根本不是一回事。

FDE 是 Forward Deployed Engineer 的缩写，直译过来叫“前线部署工程师”。这个角色最早在数据智能类公司里成型，核心特征就一条：工程师直接坐到客户业务现场，和业务方一起把问题定义清楚，再当场把方案写出来。它跟传统交付最大的区别在于，交付是“需求已经定好了，你来实现”，而 FDE 是“需求还没定，你来和我一起定，定完你顺手实现掉”。

为什么这两年 FDE 突然被频繁提起？因为 AI Agent 这类东西的落地方式和传统软件完全不同。传统软件你可以写一份详细的需求文档，把字段、流程、权限全部列清楚，然后开发照着做。但 Agent 不一样，它的效果高度依赖业务上下文——客户内部的话术习惯、数据分布、审批链路、甚至某个老师傅的隐性经验，这些东西写不进需求文档，只能靠人在现场一点点摸出来。你远程问客户“你们的工单分类逻辑是什么”，客户会说“就是按类型分啊”；你坐到他对面看他操作，才会发现他实际分了十七种，而且有五种是历史遗留没人敢删的。

这就是 FDE 模式存在的根本理由：AI 落地的瓶颈不在模型能力，而在业务上下文的理解和转化。模型再强，你不知道客户那句“帮我查一下上次那个事”里的“那个事”指什么，Agent 就是废的。FDE 的价值就是把这个“翻译”过程前置到现场，用工程师的专业能力直接消化业务模糊性，而不是把它层层转述给后方研发。

适合关注这个模式的人其实挺广的。如果你是在做 AI Agent 开发，你会关心 FDE 怎么把现场需求转成可执行的 Skill 和工具链；如果你在做企业数字化，你会关心这种模式能不能降低项目烂尾率；如果你是个想转型的工程师，你会关心 FDE 这条学习路线到底要补哪些能力。我下面就把这三周现场踩出来的东西，按我自己的理解拆开讲。

2. 核心思路拆解：为什么是“共创”而不是“调研”

2.1 传统交付模式的三个死结

在讲 FDE 怎么做之前，得先说清楚传统模式为什么在 AI 项目上容易翻车。我经历过一个典型项目，客户要做智能客服，需求文档写了八十页，开发做了四个月，上线第一天就被业务方打回来，理由是“答得不对”。哪里不对？客户说“用户问‘我的件到哪了’，它只会念物流单号，但我们的用户其实想知道‘今天能不能到’”。这个问题在需求文档里根本不存在，因为写文档的人不知道用户的真实关注点。

第一个死结是需求转译损耗。业务方脑子里的需求，经过产品经理转述、经过文档固化、经过开发理解，到代码里已经变形了。AI 项目尤其严重，因为很多需求是“感觉型”的——“回答要自然一点”“语气要像我们客服”——这种描述转译三次基本就没了。

第二个死结是反馈周期太长。传统模式是开发完再给客户看，客户说不对，回去改，再给看。一轮下来两周。但 Agent 的调优需要高频反馈，可能今天调了提示词，明天就要看效果。周期一长，调优就变成了猜谜。

第三个死结是隐性知识无法传递。客户内部有很多“只可意会”的东西，比如某个审批为什么必须走某个节点，是因为三年前出过一次事故。这种事没人会写进文档，但 Agent 如果不知道，就会给出“理论上正确但实际会被骂”的建议。

2.2 FDE 的“双向赋能”到底赋什么

FDE 模式的核心动作是“共创”，但共创这个词太虚了，我把它拆成两个方向的具体动作。

从业务到技术的方向，FDE 要做的是把业务语言实时翻译成技术语言。客户说“这个回答太生硬了”，FDE 不能只回一句“好的我调一下”，而要当场判断：是提示词里的语气指令不够具体，还是检索到的知识片段本身太书面，还是模型选型偏保守。这个判断需要在现场做，因为你需要立刻追问“你觉得哪个回答算不生硬”，然后拿到真实样本。

从技术到业务的方向，FDE 要把技术约束翻译成业务能理解的取舍。比如客户想要 Agent 记住所有历史对话，FDE 要解释清楚：全量记忆会导致响应变慢和成本上升，我们可以做分层记忆，最近三轮全量保留，更早的做摘要。客户听懂了，才会接受这个方案，而不是觉得你在偷工减料。

这两个方向的动作，在传统模式里是割裂的——业务翻译归产品，技术取舍归研发，中间隔着好几层。FDE 把它们压到一个人身上，在现场同时完成。这就是“双向赋能”的实际含义：不是谁给谁赋能，而是同一个人在两个语言体系之间实时切换，让信息损耗降到最低。

2.3 为什么这个模式在 Agent 项目上特别有效

Agent 项目和传统软件有一个本质区别：它的行为是概率性的，不是确定性的。传统软件你输入 A 一定得到 B，测试用例可以穷举。Agent 你输入 A，可能得到 B、C、D，取决于上下文、模型版本、甚至温度参数。这意味着你没法用“写完代码再测试”的方式来做，必须边做边看边调。

FDE 在现场的价值就体现在这里。我举个实际例子。客户有个场景是让 Agent 从一堆合同里提取关键条款。远程开发的做法是写一个提取函数，定义好字段，跑测试集，准确率 85%，交付。但现场 FDE 会发现，客户实际使用时会先问“这份合同有没有风险条款”，然后再问“具体是什么风险”。这是一个两段式交互，第一段是筛选，第二段是细读。如果 Agent 不知道这个交互模式，它会把所有条款都吐出来，用户觉得信息过载。

FDE 在现场看到这个交互，当场就可以调整：第一轮只返回风险条款的标题列表，第二轮再展开详情。这个调整不需要写新代码，只需要改 Skill 的编排逻辑。改完立刻让客户试，客户说“对，就是这样”。整个过程可能就二十分钟。如果走传统流程，这个交互模式的发现可能要等到上线后。

3. 核心细节解析：FDE 现场到底在做什么

3.1 现场第一件事：建立“业务词典”

我到客户现场的第一天，没有碰电脑，而是拿了个本子坐在业务员旁边看他打电话。看了半天，记了三十多个他们内部用的词。比如“走件”不是寄快递，是走审批流程；“老件”不是旧文件，是历史遗留的疑难工单；“过一下”不是检查，是提交审批。这些词如果不在现场泡着，你永远不知道。

这个本子后来变成了 Agent 的“业务词典”，我把它写进了系统提示词里。效果立竿见影：之前 Agent 听到“帮我走个件”会问“请问您要寄什么”，现在它会直接问“请问是哪个工单要走审批”。客户觉得“这 AI 懂我们”，信任感一下就建立了。

注意：业务词典不是一次性的，要持续更新。我建议每天收工前花十分钟，把当天听到的新词、新说法补进去。这个动作看起来笨，但它是 Agent 效果提升最快的手段，没有之一。

3.2 Skill 的现场定义方法

FDE 模式里，Skill 不是提前写好的，而是现场“长”出来的。我的做法是：先让业务员用自然语言描述他想让 Agent 做什么，我记下来，然后当场拆成 Skill 的输入、处理、输出三段。

举个例子。业务员说：“我想让 AI 帮我把这堆工单按紧急程度排个序。”这句话拆开就是：

• 输入：一堆工单文本
• 处理：判断每个工单的紧急程度
• 输出：排序后的工单列表

但现场拆的时候会发现很多细节。比如“紧急程度”怎么定义？业务员说“看客户催没催”。那“催”怎么识别？是看工单里有没有“催”字，还是看客户有没有重复提交？这些细节在远程根本问不出来，只有现场追问才能拿到。

我当时的做法是，每拆一个 Skill，就让业务员当场给五个真实样本，我手动跑一遍逻辑，确认理解一致。这个“五样本确认法”帮我省了大量返工。因为很多时候你以为你懂了，跑一遍样本才发现完全不是那么回事。

3.3 Agent 编排的现场调整

Agent 的编排逻辑，也就是多个 Skill 怎么串起来，这个在现场调是最有效的。因为编排的合理性取决于业务的实际流程，而业务流程里有很多“不成文的规矩”。

比如客户有个场景是“收到投诉工单后，先判断是否涉及退款，如果涉及就转财务，如果不涉及就转客服”。这个逻辑听起来很简单，但现场会发现：涉及退款的工单里，如果金额小于 50 块，其实不用转财务，客服可以直接处理。这个“50 块以下”的规则没人写在文档里，是业务员自己掌握的。FDE 在现场把这个规则加到编排里，Agent 的转派准确率立刻上去了。

我一般会用一张纸画 Agent 的编排图，每调整一次就重新画一遍，贴在工位旁边。这样业务方路过也能看到，他们会主动说“哎你这个地方不对，应该是先判断再转派”。这种非正式的反馈，比正式评审会有效得多。

3.4 数据回流与迭代机制

FDE 在现场还有一个重要动作：建立数据回流通道。Agent 每次回答，业务员觉得好还是不好，要有一个极低成本的反馈方式。我试过几种，最有效的是在 Agent 输出后面加两个按钮：“有用”和“没用”。业务员点一下就行，不用打字。

这些反馈数据每天收工后导出，我花半小时过一遍。点“没用”的，看是哪里出了问题，是知识库缺内容，还是 Skill 逻辑不对，还是提示词需要调。第二天早上把调整后的版本推上去，让业务员继续用。这个“日迭代”节奏是 FDE 模式的核心竞争力，传统模式根本做不到。

提示：反馈按钮的位置很关键。我一开始放在回答的最下面，业务员经常看不到。后来改到回答的右上角，点击率翻了三倍。这种细节只有现场才能发现。

4. 实操过程：一个完整 FDE 周期的记录

4.1 进场准备：三天内要搞清楚的五件事

FDE 进场不是拎包就去的，前三天要快速搞清楚五件事，否则后面全是坑。

第一件，业务方的真实 KPI 是什么。客户说“我们要提升效率”，这是废话。你要追问：是响应时间要缩短，还是处理量要提升，还是投诉率要下降？不同的 KPI 对应完全不同的 Agent 设计。我遇到过一个客户，嘴上说“要快”，实际 KPI 是“准确率”，因为快但错会被罚钱。如果按“快”来设计，就南辕北辙了。

第二件，现有系统能提供什么数据。Agent 的效果高度依赖数据质量。你要搞清楚：工单数据在哪个系统，能不能实时拉取，字段全不全，有没有历史脏数据。我一般会要一个测试账号，自己登进去翻一遍，比问谁都准。

第三件，关键用户是谁。不是所有业务员都会用你的 Agent，你要找到那两三个愿意尝鲜、愿意反馈的人。把他们服务好，他们会帮你传播。其他人看到效果好，自然会跟上来。

第四件，审批链路有多长。Agent 如果要触发某个动作，比如发邮件、改状态，需要经过谁审批？这个链路如果不提前摸清，Agent 做出来也上不了线。

第五件，客户的技术栈底线。有些客户数据不能出内网，有些客户只能用特定云服务，有些客户对开源协议有要求。这些约束要在第一天就问清楚，否则方案设计到一半发现跑不了，全白干。

4.2 第一周：从零到可演示

第一周的目标不是做完整产品，而是做一个能演示的最小闭环。我的做法是选一个最痛、最窄、最容易看到效果的场景，快速做出来。

选场景有三个标准：高频（每天至少发生十次）、痛点明确（业务员一提就皱眉）、边界清晰（输入输出容易定义）。我这次选的场景是“工单自动分类”，因为客户每天有三百多张工单要手动分到十七个类别，业务员怨声载道。

实现路径是这样的：先把十七个类别的定义和样例收集齐，每个类别至少二十个样本。然后用这些样本写一个分类 Skill，输入是工单文本，输出是类别标签。Skill 本身不复杂，难的是类别定义的边界。比如“咨询”和“投诉”怎么分？业务员说“看语气”，但语气这东西没法写进代码。我最后的做法是让业务员标了一百条边界样本，从中总结出可操作的规则，比如“出现‘为什么还没’算投诉，出现‘请问’算咨询”。

第一周末尾，我做了个简单的前端页面，业务员可以把工单粘进去，点一下出分类结果。演示的时候，我让业务员随机抽了二十条真实工单，Agent 分对了十七条。业务员说“比我想的好”，这句话就是第一周的验收标准。

4.3 第二周：从演示到可用

演示能跑通，不代表能用。第二周要解决的是稳定性和覆盖度。

稳定性方面，我遇到的最大问题是长工单截断。有些工单描述写了上千字，模型处理不了那么长。我的解决方案是做一个预处理 Skill，先把工单拆成“标题+正文+历史记录”三段，只把标题和正文的前五百字送给分类模型。这个阈值是试出来的：五百字能覆盖 95% 的关键信息，再长边际收益很低。

覆盖度方面，第一周只覆盖了最常见的五类工单，第二周要把剩下十二类补上。补的方式不是重新写 Skill，而是用 Few-shot 的方式，在提示词里给每类加三个样例。这样不用改代码，只改配置，迭代速度很快。

这一周我还做了一件事：把 Agent 的置信度暴露出来。分类结果后面加一个“确定/不确定”的标记，不确定的工单自动转人工。这个设计让业务员放心很多，因为他们知道 Agent 不会瞎分。置信度阈值我设的是 0.7，低于这个值就转人工。这个值可以调，我建议初期设高一点，宁可多转人工，也不要让业务员觉得 Agent 在乱来。

4.4 第三周：从可用到好用

第三周的目标是让业务员主动用，而不是你催着用。这周的关键动作是嵌入工作流。

之前 Agent 是一个独立页面，业务员要切过去用。第三周我把它嵌到了他们现有的工单系统里，选中工单文本，右键就有“AI 分类”选项。这个改动看起来小，但使用率提升了四倍。因为业务员不用离开当前界面，操作成本几乎为零。

另一个动作是个性化。每个业务员负责的工单类型不同，我让 Agent 记住每个人的偏好。比如张三主要处理退款，Agent 就会在分类时优先考虑退款相关类别。这个个性化是通过在提示词里加一段用户画像实现的，成本很低，但业务员觉得“这 AI 认识我”。

第三周末尾，我做了个统计：Agent 的分类准确率到了 91%，业务员平均每天节省四十分钟。客户的项目负责人说“这个可以推广到其他组了”。这句话意味着 FDE 周期的第一阶段结束，可以进入推广期。

4.5 关键参数与配置参考

下面这张表是我这次项目里实际用到的核心参数，供参考。注意这些值不是通用的，要根据具体场景调。

注意：置信度阈值不要一次调太低。我试过直接设 0.5，结果 Agent 把很多模棱两可的工单也硬分了，业务员反而更不信任。宁可多转人工，也不要让 Agent 显得“自作聪明”。

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

5.1 Agent 回答“太官方”怎么办

这是最高频的问题。业务员说“它说话像机器人”，你去看输出，确实每句都是“您好，关于您的问题，我们将尽快处理”。问题出在提示词里的语气指令太抽象。你写“语气要自然”，模型不知道什么叫自然。

我的解法是给具体样例。在提示词里加三组对照：官方版和自然版的对比。比如官方版“您的请求已收到”，自然版“收到啦，我看看”。模型看到样例，就知道往哪个方向调。这个改动通常一次就能见效。

5.2 Skill 之间“打架”怎么排查

多个 Skill 串联时，经常出现 A 的输出不是 B 想要的输入。排查方法是把中间结果打出来。我在每个 Skill 后面加了一个调试开关，打开后会把输入输出写到日志里。这样一眼就能看出是哪个环节断了。

常见原因有三个：一是字段名不一致，A 输出叫“category”，B 输入要“type”；二是格式不一致，A 输出是字符串，B 要的是列表；三是语义不一致，A 说的“紧急”是时间紧，B 理解的“紧急”是重要性高。前两个改代码就行，第三个要回去对齐业务定义。

5.3 业务员不用怎么办

我遇到过 Agent 做出来了，业务员还是手动做。原因不是不好用，而是他们不习惯。人的习惯很难改，你不能指望他们主动切到一个新工具。

解法是嵌入现有流程，前面说过。另一个解法是找种子用户。每个组里总有一两个愿意尝鲜的人，把他们服务到极致，让他们在组里说好话。其他人看到同事在用，而且用得挺爽，自然会跟。我这次就是先搞定了一个叫小李的业务员，他用了三天后在晨会上说“这个比我手动快多了”，一周内全组都开始用。

5.4 模型成本超预期怎么控

Agent 跑起来之后，token 消耗可能远超预期。我这次第一个月就超了预算 40%。排查下来，主要浪费在三个地方：一是提示词太长，每次调用都带一大堆没用的上下文；二是重复调用，同一个工单被分类了三次；三是缓存没做，相同的问题反复问模型。

控制手段：提示词精简到只保留必要信息，我这次从 2000 token 压到了 800；加去重逻辑，相同输入直接返回缓存结果；对高频问题做本地缓存，命中率能到 30%。这三招下来，成本降了六成。

5.5 常见问题速查表

5.6 几个我踩过的坑

第一个坑是过早追求完美。我第一周就想把十七类全做准，结果每类都不精。后来收窄到五类，做透了再扩，反而更快。

第二个坑是忽略业务员的情绪。有个业务员一直不用，我以为是不习惯，后来聊天才知道他觉得“AI 是来替代我的”。我花了一个小时跟他解释，Agent 是帮他省掉重复劳动，让他有时间做更有价值的事。他听懂了之后，成了最积极的使用者。技术问题好解，人的问题要花时间。

第三个坑是没有留退路。有次我推了个新版本，分类逻辑改了，结果效果反而差了。业务员那天怨声载道。后来我学乖了，每次推新版本都保留旧版本，效果不好一键回滚。这个机制必须有，否则一次翻车就可能失去信任。

6. FDE 工程师的能力清单与学习路线

6.1 技术能力：不用全栈，但要能打通链路

FDE 不需要是算法专家，但需要能看懂模型的能力边界。你要知道什么任务适合用提示词解决，什么任务需要微调，什么任务根本不该用模型。我见过有人拿模型做精确计算，结果错得离谱，这就是能力边界没搞清楚。

具体来说，这几项能力是必须的：提示词工程，能写出稳定可控的指令；API 调用，能把模型接进现有系统；数据处理，能清洗和构造训练/测试样本；基础前端，能做个简单界面让业务员用。不需要精通，但要能自己动手，不能什么都等别人。

6.2 业务能力：比技术能力更重要

FDE 的核心竞争力其实是业务理解力。你要能快速进入一个陌生行业，听懂行话，看出痛点。这个能力没法速成，但可以刻意练习。我的方法是每进一个新行业，先花一天看他们的内部文档和聊天记录，把高频词记下来，不懂就问。不要装懂，业务员一眼就能看出来。

另一个练习是追问三层。业务员说“我要提升效率”，你问“哪方面的效率”，他答“处理工单”，你再问“处理工单的哪个环节最慢”，他答“分类”。到这一层，你才知道该做什么。大部分人只问到第一层就停了。

6.3 沟通能力：翻译官的角色

FDE 一天里可能有一半时间在说话。跟业务员说人话，跟研发说技术话，跟管理层说价值话。这三种话的切换要自然。

我的经验是，跟业务员沟通时不要用技术词。你说“我调一下提示词”，他听不懂。你说“我让它学几个例子”，他就懂了。跟研发沟通时要给具体约束，不要说“效果不好”，要说“召回率低了，需要补负样本”。跟管理层沟通时要算账，不要说“提升了体验”，要说“每天省四十分钟，一个月省二十个工时”。

6.4 学习路线建议

如果你现在想往 FDE 方向转，我建议按这个顺序补：

第一阶段，把 Agent 开发的基础打通。找一个开源框架，自己搭一个能跑的 Agent，理解 Skill、编排、记忆这些概念。不用追求效果，先跑通。

第二阶段，找一个真实场景练手。可以是自己工作中的重复劳动，也可以是帮朋友做个小工具。关键是要有真实用户，能收到真实反馈。没有反馈的练习，效果有限。

第三阶段，去现场泡一次。如果有机会，跟着有经验的 FDE 去客户现场待一周。看他们怎么问问题，怎么拆需求，怎么处理突发状况。这种现场学习，比看十篇文章都管用。

第四阶段，建立自己的工具箱。把常用的提示词模板、Skill 模板、排查清单整理成自己的库。下次遇到类似场景，直接调用，效率翻倍。

提示：FDE 这个角色目前没有标准认证，所谓的“课程”大多是把公开资料重新包装。真正有价值的学习方式是跟着项目走，在实战中积累。不要花大价钱买课，把钱和时间花在真实项目上。

7. 这个模式后续可以怎么扩展

我在这次项目结束后，跟几个同行聊了聊，发现 FDE 模式还有一些值得探索的方向。

一个是远程 FDE。不是所有客户都愿意让你驻场，有些客户觉得驻场成本太高。远程 FDE 的做法是高频视频会议加屏幕共享，业务员操作你看，你调完立刻让他试。效果比纯远程开发好，但比驻场差一些。适合预算有限的中小客户。

另一个是FDE 知识库的沉淀。每个 FDE 在现场都会积累大量行业 know-how，这些如果只留在个人脑子里，就浪费了。我现在的做法是每做完一个项目，写一份“行业词典+Skill 模板+踩坑记录”，存到团队共享库里。下一个 FDE 进类似行业，直接调用，起步快很多。

还有一个是FDE 与 ADP 的结合。ADP 是 Agent 开发平台，如果平台能把 FDE 在现场常用的 Skill 模板、调试工具、反馈机制都内置进去，FDE 的效率会大幅提升。目前这块还在早期，但我看好这个方向。

最后分享一个小技巧。每次进新现场，我会带一包好一点的茶叶或者咖啡，放在业务员的工位上。不是为了讨好谁，而是创造一个非正式交流的场景。很多关键信息不是在正式会议上得到的，而是在茶水间闲聊时听到的。业务员觉得你是个好相处的人，才会跟你说真话。这个投入很小，但回报很大。