第 3 章 两种 FDE 形态
第 1 章给了 FDE 的时间形状，第 2 章给了判断形状。这一章给的是能力形状——同一个 FDE 角色，做不同项目时具体动用的肌肉是不一样的。
理解这件事的好处是：当你下一个项目里发现自己在做完全没碰过的事，不需要焦虑”我是不是不适合 FDE”——你只是切换到了另一种形态，几周可以上手。心法没变，铁律没变，换的只是肌肉。
3.1 两种形态
行业里”FDE”这个角色实际上覆盖两种主要形态。区分它们的不是公司——是项目当下要解决什么问题。
数据驱动型：客户有大量数据但用不起来，FDE 的工作是把数据接通、建模、推到决策层。Palantir 是这种形态的发源地，他们的 FDE 一周大头在写 ETL、设计数据本体（ontology）、对接客户数据库、跑数据校验。交付物是一套数据管道加上几个能让业务直接用数字回答问题的仪表盘或 API。
LLM 驱动型：客户某个工作流里大量重复劳动可以被自动化，FDE 的工作是把 LLM 应用嵌进客户的工作流。OpenAI、Anthropic 这类公司的客户工程团队是典型，AI 应用方向的初创公司也基本走这条路。一周大头在调 prompt、跑评估、改检索、调试 agent 工具调用。交付物是一个或几个能让客户工作流的某个动作中位时间显著下降的 LLM 应用。
两种形态在 FDE 这个职业上是同一个心法、不同的肌肉。心法是”驻在客户那边、对结果负责而不是对代码负责、用工程判断帮客户做技术决策”。肌肉是技术栈和工具链不同。
下面这张表把差别落地：
| 数据驱动型 | LLM 驱动型 | |
|---|---|---|
| 核心问题 | 客户的数据怎么用上 | 客户的工作流怎么自动化 |
| 主要交付物 | 数据本体 + 数据管道 + 仪表盘 | LLM 应用 + Prompt + 评估集 + 工具集 |
| 典型一周时间分布 | 50% 数据探索 / 30% 管道工程 / 20% 业务对接 | 40% Discovery 和业务理解 / 30% Prompt 和评估 / 30% 集成和部署 |
| 要懂的硬技能 | SQL, Spark, ETL, dbt, 数仓建模 | LLM API, Prompt 工程, RAG, Agent 框架 |
| 要懂的软技能 | 和数据团队 / DBA 协作，懂数据治理 | 和业务 PM / 一线员工协作，懂业务流程 |
| 成功的样子 | 客户做决策时能直接用数据回答问题 | 客户工作流里某个动作的中位时间显著下降 |
| 最致命的失败 | 数据建模做对了但没人用 | demo 惊艳但用不起来 |
读这张表的时候要注意：两种形态的工具栈差异比看起来大。一个数据驱动型 FDE 入门到能独立交付通常需要 1-2 年——光数仓建模和 schema 演化的坑就够踩一年。一个 LLM 驱动型 FDE 入门到能独立交付通常 6-12 个月——技术栈本身年轻，行业沉淀不多。
但两种形态的判断方式高度相似——第 1 章四阶段、第 2 章三铁律，两种形态都适用。区别只在每个阶段做的具体活儿。
3.2 决定形态的不是公司，是项目
很多人误以为”我在 X 公司就是 X 形态”。这个判断是错的。
真正决定的是项目当下卡在哪儿。同一个 FDE，在同一家公司、同一个客户、同一个项目里，不同阶段都可能切换形态。
举两个真实但概括过的例子：
例 1：金融客户做理赔自动化
- 第 1-4 周读他们的理赔流，发现关键卡点在”医生病历 → 理赔金额”这一步——非结构化的医生手写文字要变成结构化字段。这是 LLM 驱动型：你用 OCR + LLM 做信息抽取。
- 第 5 周一个具体的切换瞬间：你在站会上演示了 LLM 抽取的字段，准确率 85%。客户的理赔系统工程师当场说”这些字段进不了我们的规则引擎，因为我们的科室编码用的是 ICD-10，你抽出来的是文字”。那一刻你意识到——抽取的工程已经够了，下游集成不是 prompt 问题，是 schema 问题。当周你切换形态：开始建 mapping 表，写一个 dbt 模型把 LLM 输出 normalize 到 ICD-10 编码。这是 数据驱动型。
- 第 9-12 周规则化的判断要重新封装成”业务能解释”的 agent，加可追溯的决策路径。这一步又回到 LLM 驱动型。
同一个项目，三个阶段，三种形态来回切。识别”该切了”的能力，比”两边都精通”更重要。
例 2：制造业客户做设备预测性维护
整个项目核心是时序数据 + 预测模型——纯 数据驱动型主线。但客户希望系统生成的告警工单是自然语言可读的、维修工程师可以用问答方式查历史故障——这部分是 LLM 驱动型支线，占整个项目大约 30% 的工作量。
不是非此即彼。很多 FDE 项目是数据驱动主线 + LLM 支线，或者反过来。
怎么判断当前阶段属于哪种形态
两个问题，按顺序问：
- 客户当下的核心瓶颈是”数据用不上”还是”工作流没自动化”？
- 数据用不上（数据散在各系统、查不到、不同口径打架）→ 数据驱动型
- 工作流没自动化（重复劳动、信息检索慢、决策依赖个人经验）→ 看下一题
- 要被自动化的工作流主要操作的是结构化数据还是自然语言？
- 结构化数据（报表、订单、字段填充）→ 偏数据驱动型
- 自然语言或文档（客服问答、合同审阅、知识库检索）→ LLM 驱动型
这两题的答案会随项目阶段变化。每两周重新问一次。
3.3 同一个项目里什么时候切换形态
切换的时机判断比形态判断本身更难。三个最常出现的信号，看到了就该切：
信号一：发现”数据本来就有，只是没人能查”
不要急着写 ETL 或建数据中台。客户说”我们的合同条款搜不到”——可能是数据格式问题（PDF 没解析），可能是检索问题（搜索引擎没建索引）。先看一下，可能 RAG 一上来就解决，根本不需要数据驱动型的重投入。
这是数据驱动思维最容易做错的地方——看到客户喊”数据问题”，下意识反应是建管道、做治理。但有时候客户的真实问题只是”现有数据没接到自然语言入口”，LLM 驱动型方案 2 周能解决，数据驱动型方案 3 个月才能交付第一版。
信号二：发现”LLM 输出基本对，但下游接不进系统”
切回数据驱动型。Agent 抽取的字段进不了 ERP，因为客户那边编码不统一、字段语义有歧义、缺少必填项。这时候你需要数据治理思维——建 mapping 表、加校验规则、写异常处理。
这是 LLM 驱动型 FDE 最容易卡住的地方——LLM 把 80% 的工作做对了，但剩下 20% 的”接到下游系统”需要的是数据工程能力，不是 prompt 调优能力。这一段如果切换不及时，项目会卡在”demo 漂亮，生产用不了”的状态。
信号三：客户决策需要数字，但现有数据不够
切回数据驱动型主线。客户问”这个 Agent 到底节省了多少时间”——你发现没埋点。这时候你必须先做埋点和 ETL，否则连 outcome 都说不清楚（违反第二章 Sell the outcome 那条铁律）。
LLM 驱动的项目最常欠缺的是这件事：LLM 应用上线后没有业务指标。系统在跑，但没人能说清它的业务价值。这是 Handoff 阶段最常见的滑坡。
3.4 两种形态下三条铁律的具体落法
铁律没变，落法不一样。下面这张表把每条铁律在两种形态下的具体动作翻译出来：
| 铁律（第 2 章命名） | 数据驱动型 | LLM 驱动型 |
|---|---|---|
| Sell the outcome | Outcome 例子：月度报表准点率 60%→95%。数字来自数据系统本身能算。沟通对象：数据团队 + BI + 业务 | Outcome 例子：客服首响中位时间 4h→30min。数字常常需要新加埋点 / trace。沟通对象：业务团队 + 一线员工 |
| Eval-driven | 评估对象：数据正确性、口径一致、SLA。工具：dbt tests、Great Expectations、自写 SQL 校验。频率：每个 ETL run | 评估对象：答案质量、相关性、安全性。工具：DeepEval、Promptfoo、平台内置评估器（如 Bedrock Evaluations）。频率：每个 PR + 每天回归 |
| Fix forward（在客户那边修） | 现场修：一段 SQL / 一个 dbt 模型 / 一个调度。Hot fix 通道：Airflow / dbt Cloud 直接发。权限：数据库写权限（受限） | 现场修：一段 prompt / 一个 retriever 配置 / 一个 tool 定义。Hot fix 通道：配置中心 / Lambda / 边车 prompt 仓。权限：应用配置写权限（多用） |
读这张表注意一件事：两种形态的”现场修能力配置”差异很大。数据驱动型的写权限通常很受限——客户 DBA 不会随便给 FDE 数据库 DDL 权限。LLM 驱动型的应用层配置通常更开放——配置中心、prompt 仓库这种地方权限通常更好谈。
这意味着理论上 LLM 驱动型 FDE 的 Fix Forward 更容易做到，数据驱动型 FDE 的 Fix Forward 更需要前期争取权限。但实际上要看客户合规等级——金融、医疗、政企客户的应用层配置中心也会被严格管控，权限优势会被拉平。如果你做的是这类客户的数据驱动型项目，第一周拿 staging 写权限的优先级要更高，否则你的 Fix Forward 几乎不可能落地。
3.5 工具栈对照
两边各列一个清单。你可以判断自己当前缺的肌肉：
数据驱动型 FDE 的肌肉
- 入门：SQL、Python pandas、JSON / Avro、PostgreSQL
- 中级：dbt、Airflow / Prefect、Spark / PySpark、Snowflake / BigQuery / Redshift、Kerberos / IAM
- 高级：数据建模（Kimball / Inmon）、Apache Iceberg / Delta Lake、ontology 设计、schema 演化、实时管道（Kafka, Kinesis）、数据血缘、隐私合规
LLM 驱动型 FDE 的肌肉
- 入门：LLM API 调用、Prompt 工程、Function Calling、JSON Schema
- 中级：LangChain / LlamaIndex、RAG、向量库（Pinecone, Weaviate, OpenSearch, pgvector）、评估框架、Trace 工具、MCP 协议
- 高级：Agent 框架、Agent 工具沙箱和权限、流式和结构化输出、轻量微调（LoRA）、推理优化（vLLM, TGI）、托管平台部署（Bedrock、SageMaker、Vertex AI）
FDE 不需要两套全精通。但两边都要”懂到能问对问题”。比如你是 LLM 驱动型 FDE，遇到下游接不进 ERP 的问题，你不需要会写 dbt 模型——你需要知道客户这种问题应该叫数据团队来对，并且能跟他们用同一组词汇沟通（”字段映射”、”主键约束”、”幂等性”、”血缘”）。
反过来同理，数据驱动型 FDE 不需要会调 prompt——但要知道什么时候应该说”这块用 LLM 比堆规则引擎便宜”。
在 AWS 平台上两种形态的工具对照
如果你的项目跑在 AWS 上，下面是两种形态在 AWS 上常用的服务对照：
| 数据驱动型常用 | LLM 驱动型常用 | |
|---|---|---|
| 存储 | S3、Lake Formation | S3（KB 文档） |
| 数据 | Glue ETL、Glue Catalog | OpenSearch / Bedrock Knowledge Bases |
| 计算 | EMR、Athena、Redshift | Bedrock 模型调用 |
| 编排 | Step Functions、MWAA | Bedrock Agents、Step Functions |
| 治理 | Lake Formation 权限模型 | IAM + KMS |
| 监控 | CloudWatch + 数据血缘 | CloudWatch + Bedrock Guardrails + Bedrock Evaluations |
一个项目同一周里既动 Glue ETL 又动 Bedrock Agent 是常态。本书后续章节里数据驱动型的展开主要在第 9 章，LLM 驱动型的展开覆盖第 6-15 章。两种形态都需要的基础（VPC、SSO、合规）在第 11 章。
3.6 怎么判断当前项目应该侧重哪一边
每两周用下面这张表自检一次。哪一行的左侧描述更符合你当前项目，就更偏数据驱动；哪一行右侧更符合，就更偏 LLM 驱动。多数项目是两边混合，重点是看哪边占比更高。
| 项目特征 | 倾向 |
|---|---|
| 客户最大痛点是”数据散乱、找不到、口径不一” | 数据驱动型偏多 |
| 客户最大痛点是”重复劳动多、找信息慢、依赖个人经验” | LLM 驱动型偏多 |
| 客户合规要求严，先治理再用数据 | 数据驱动型偏多 |
| 客户业务高速增长，文档跟不上 | LLM 驱动型偏多 |
| 客户已经有数据团队 | 你做 LLM 驱动主线（数据团队接数据驱动那部分） |
| 客户没有数据团队 | 你做数据驱动主线 |
| 客户希望”3 个月内见效” | LLM 驱动型偏多（更快出第一版） |
| 客户希望”接下来 3 年的基础设施” | 数据驱动型偏多（基础更扎实） |
读这张表注意：单题不决定形态，要看多题的合力。如果一个项目”客户希望 3 个月见效”+”客户合规要求严”——前者推 LLM 驱动型，后者推数据驱动型——你需要找到一个可以两者兼顾的子问题，先做出来，再扩。
收尾
Part I 三章给出了完整的 FDE 工程坐标系：
- 第 1 章：时间形状——一天和一个项目的样子
- 第 2 章：判断形状——三条铁律决定每个具体取舍怎么做
- 第 3 章：能力形状——两种形态什么时候切换
读完这三章你应该能回答：我现在这个项目在四阶段的哪一段、当前最该防三条铁律的哪一条、属于哪种形态。这三个问题的答案变化时，你的工作重点也应该跟着变化。
Part II 进入第一个具体动作——Discovery。从你接到一个新项目开始，第一周到底问什么、看什么、写什么。这是 FDE 工作里最容易被低估、回报率最高的阶段。