FDE 怎么干：3 大职责、4 大流程、5 大陷阱-AI领导力 - 刘言午

作者：刘言午 | AI 领导力导师
> 发布时间：2026-06-18 | 系列：AI 时代新型岗位研究 03
> 阅读时长：约 14 分钟

写在前面

前两篇文章我们讲了 FDE 的起源和全球标杆案例。今天这一篇，我想跟你聊点更”接地气”的事：

FDE 到底每天在做什么？怎么才能做好 FDE？新手 FDE 最容易踩哪些坑？

我调研了 Palantir、OpenAI、Anthropic、Cohere 等公司的 FDE 工作流程，结合 30+ 位在岗 FDE 的访谈，整理出了这一份”实战指南”。

全文分 3 大块：FDE 的 3 大核心职责、4 大工作流程、5 大常见陷阱。

一、FDE 的 3 大核心职责

如果要用一句话概括 FDE 的职责，那就是：用技术能力把客户业务问题解决掉，从头到尾。

但这句话太抽象了。具体拆开看，FDE 的职责可以分为 3 大块。

1.1 职责 1：技术落地的”首席架构师”

FDE 首先要承担”首席架构师”的角色，负责整个 AI 项目的技术方案设计。

具体来说包括：

业务需求转技术方案：把客户模糊的业务需求转化为可执行的技术方案
模型选型：根据业务场景、数据量、性能要求、成本约束选择合适的模型
架构设计：设计端到端的系统架构，包括数据接入、模型调用、业务集成、前端展示
技术决策：在客户现场做关键的技术决策，包括要不要微调、要不要用 RAG、用什么向量数据库等

FDE 的方案设计不是”写一份 PPT”那么简单，而是要带着客户业务场景的具体约束做设计。一个医院和一个银行的方案可能看起来都是”大模型 + RAG”，但具体实现差异巨大。

1.2 职责 2：客户成功的”长期合伙人”

FDE 第二个重要角色是”客户成功的合伙人”。

传统软件销售有一个很大的问题：销售签单、交付做完后，客户的实际使用效果往往不达预期。SaaS 公司为了解决这个问题，专门设置了 Customer Success Manager（CSM）这个岗位。

FDE 比 CSM 更进一步：FDE 不是只管”用起来”，而是直接”用到位”。这意味着：

价值实现：客户花了 1000 万买的 AI 项目，FDE 要帮客户把这 1000 万的 ROI 算清楚，让客户真正赚到钱
使用培训：教客户的业务团队怎么用 AI 工具，建立内部”AI 种子用户”
效果监控：建立量化的效果监控体系，比如客户满意度提升 20%、客服效率提升 50%
持续迭代：根据客户使用反馈，持续优化 AI 系统的表现

FDE 的”客户成功”不是一次性的，而是持续 6-12 个月甚至更长。

1.3 职责 3：产品迭代的”前线传感器”

FDE 第三个角色是”产品迭代的传感器”。

FDE 在客户一线工作，能听到客户最真实的声音。这些声音包括：

客户对模型能力的吐槽（”这个模型回答医疗问题不专业”）
客户对功能的需求（”我们需要一个批量处理功能”）
客户对竞品的反馈（”友商 X 的某个功能比我们好用”）
客户对价格的反馈（”这个功能不值这个价”）

这些信息是产品团队最宝贵的”前线情报”。Palantir 的 Shyam Sankar 在内部反复强调：“FDE 团队的眼睛看到的东西，是产品团队的耳朵听不到的。”

FDE 的前线反馈机制通常有 3 种形式：

周报机制：FDE 每周写一份”前线洞察周报”反馈给产品团队
季度复盘：每季度 FDE 团队和 PM 团队一起做产品复盘
客户案例库：把典型客户场景沉淀为产品案例，反哺新客户

二、FDE 的 4 大工作流程

讲完 3 大职责后，我们来看 FDE 的日常工作流程。

FDE 的一个完整项目周期通常是 3-6 个月，分为 4 个阶段。

2.1 阶段 1：业务洞察（1-2 周）

目标：理解客户业务，识别真实痛点

核心动作：

与客户业务团队（CEO、COO、CTO、业务负责人）做深度访谈
观察客户的日常工作流，记录痛点
调研客户的现有技术栈和数据资产
写”业务洞察报告”，明确 3-5 个核心痛点

关键产出：

业务洞察报告（10-20 页 PPT）
痛点优先级排序
AI 落地的潜在场景清单

常见错误：

❌ 只听客户”说”的，没去现场”看”的
❌ 客户说”我们想用 AI”就直接开始做方案
❌ 忽视客户的非技术约束（预算、合规、组织阻力）

正确做法：

✅ 至少 1-2 次现场驻点观察
✅ 用”5 Why”方法追问客户真实需求
✅ 把”AI 能做的”和”客户真正需要的”区分开

2.2 阶段 2：方案设计（1-2 周）

目标：基于业务洞察，设计可落地的技术方案

核心动作：

业务场景拆解：把大场景拆成 3-5 个可独立交付的小场景
模型选型与微调策略设计
系统架构设计（数据流、模型流、控制流）
评估指标设计（怎么算”成功”）
风险评估与应对方案

关键产出：

技术方案文档（30-50 页）
评估指标体系
项目计划（甘特图）

常见错误：

❌ 方案过于复杂（什么都想一次做完）
❌ 忽视数据质量评估（”先做起来再说”）
❌ 评估指标不清晰（”效果好”不算指标）

正确做法：

✅ MVP 思维：先做最小可用版本
✅ 提前做数据评估：数据质量决定项目成败
✅ 指标量化：把”效果好”变成”召回率 > 90%、准确率 > 95%”

2.3 阶段 3：原型交付（2-4 周）

目标：交付可运行的原型，让客户”看到”价值

核心动作：

数据接入与清洗
模型调用与微调
系统集成与开发
原型部署与演示
客户反馈收集与迭代

关键产出：

可演示的原型（通常 1-2 周内完成）
演示视频
初步的效果报告

Palantir 标准：

48 小时内出可演示的原型
哪怕是”丑但能用”的代码，也比”漂亮但跑不起来”的方案强

OpenAI 标准：

1-2 周内出可演示的应用
用 GPT-4 的能力做”功能爆点”，让客户直观感受 AI 能力

常见错误：

❌ 追求代码完美，错过交付窗口
❌ 忽视客户体验，演示效果差
❌ 没有”演示剧本”，客户不知道看什么

正确做法：

✅ 用最短路径跑通核心流程
✅ 准备 2-3 个客户场景的真实数据做演示
✅ 写”演示剧本”，让客户跟着剧本看价值

2.4 阶段 4：落地上线（4-12 周）

目标：把原型转化为生产环境，交付真正的业务价值

核心动作：

性能优化与压力测试
安全审计与合规适配
生产环境部署
运维体系搭建
客户团队培训
效果监控与持续迭代

关键产出：

生产环境系统
运维手册
培训材料
效果监控仪表盘
持续迭代计划

常见错误：

❌ 忽视性能优化（”在 Demo 上能跑就行”）
❌ 忽视安全合规（医疗、金融客户对安全极其敏感）
❌ 忽视客户培训（客户用不起来，AI 系统就是死的）

正确做法：

✅ 性能基准测试（QPS、延迟、并发）
✅ 安全合规检查清单（GDPR、HIPAA、PCI DSS 等）
✅ “种子用户”培训计划（先培养 5-10 个内部积极分子）

三、FDE 的 5 大常见陷阱

在和 30+ 位 FDE 的访谈中，我整理出了他们最常踩的 5 个坑。

3.1 陷阱 1：技术至上，忽视业务

典型表现：

用了最先进的技术（”我们用了 RAG + LangChain + 多 Agent 框架”）
但客户用不起来
客户吐槽”你们的技术很牛，但解决不了我的问题”

根因：
FDE 太执着于技术先进性，忘了客户的真实业务问题。

破解方法：

业务洞察阶段花足够时间（至少 1-2 周）
多问”为什么”，少说”我能做”
客户业务专家的话要”听懂”而不是”听到”

3.2 陷阱 2：完美主义，错失交付

典型表现：

想要 100% 完美的方案才交付
项目从 2 周拖到 2 个月
错过客户的业务窗口期

根因：
FDE 的工程师文化导致”代码洁癖”，追求完美。

破解方法：

“丑但能跑” > “漂亮但跑不起来”
MVP 思维：先交付 80% 的价值
内部设”代码冻结点”，到点必须交付

3.3 陷阱 3：单兵作战，忽视团队

典型表现：

FDE 一个人扛下整个项目
累死累活，项目还是延期
客户关系紧张

根因：
FDE 的”特种兵”角色容易让人以为”一个人就能搞定一切”。

破解方法：

明确分工：谁做架构、谁做开发、谁做客户沟通
借力产品团队：通用问题复用产品能力
借力客户团队：让客户业务人员深度参与

3.4 陷阱 4：交付即结束，忽视运营

典型表现：

项目上线后 FDE 撤场
客户实际使用率低，AI 系统闲置
客户不满”项目验收后就不管了”

根因：
FDE 把”交付”等同于”项目结束”，没有看到长期价值。

破解方法：

交付后至少 3-6 个月的”陪跑期”
建立量化的效果监控体系
主动收集客户反馈，持续迭代

3.5 陷阱 5：技术黑盒，客户不信任

典型表现：

客户问”这个模型为什么这么回答”
FDE 说”这是 AI 模型的预测，无法解释”
客户不信任，弃用系统

根因：
FDE 习惯用”技术语言”解释”业务问题”，客户听不懂。

破解方法：

用业务语言讲技术（”模型判断这封邮件是垃圾邮件，因为…”）
建立可解释性机制（输出置信度、参考文档、决策依据）
主动暴露 AI 局限（”这个场景 AI 还不能 100% 准确，需要人工复核”）

四、FDE 的 5 类核心交付物

FDE 的工作成果通常包括 5 类交付物：

类别	具体内容	形式
1. 业务洞察	客户痛点、业务流程、潜在 AI 场景	业务洞察报告
2. 技术方案	架构设计、模型选型、风险评估	技术方案文档
3. 原型系统	可演示的最小可用产品	代码 + 部署环境
4. 生产系统	性能稳定、安全合规、可监控的生产环境	代码 + 部署 + 监控
5. 持续运营	客户使用培训、效果监控、迭代优化	培训材料 + 监控仪表盘 + 迭代计划

这 5 类交付物贯穿 FDE 的整个项目周期，构成完整的”价值交付链”。

五、FDE 的一天：典型工作时间表

我采访了一位在字节跳动做 FDE 的工程师，给大家还原 FDE 的典型一天：

时间	事项
09:00 – 09:30	早会同步：和客户业务团队对齐当日工作
09:30 – 12:00	客户业务现场：观察业务人员工作，挖掘新需求
12:00 – 13:30	午餐：和客户业务人员吃饭（非正式沟通）
13:30 – 16:00	内部开发：基于上午洞察，迭代原型代码
16:00 – 17:00	客户演示：给业务团队演示新功能
17:00 – 18:00	客户成功：和客户领导层同步项目进展
18:00 – 20:00	内部协作：和产品团队对齐前线反馈
20:00 – 22:00	文档与复盘：写前线洞察周报、复盘当天