---
title: "FDE + AI：一个人如何扛起一整个数据项目的交付"
author: deletexiumu
pubDatetime: 2026-04-03T01:00:00+08:00
featured: false
draft: false
tags:
  - Claude Code
  - AI Agent
  - 数据治理
  - 效率
description: "十年项目交付经验沉淀：Forward Deployed Engineer 如何用 Claude Code 实现从数据探查、建仓、建模到全栈交付的端到端闭环，附 AI 使用能力四层模型（L1-L4）。"
---

做项目交付十年了。从最早的传统 BI 到后来的大数据平台，再到现在的 AI + 数据，交付的技术栈在变，但有一件事从来没变过：同一个项目里，永远有好几件事同时找你。数仓建模评审还没结束，数据质量那边催着要字段空值率报告，业务方又丢过来一个临时取数需求，中间巡检脚本还报了个告警要处理。

做过驻场交付的人都知道，这就是日常——你扎在一个客户现场，但这个客户的事从来不是一件一件排队来的，而是好几条线同时压过来，每条线都要"刚好够用"地交出去。

这篇文章是我这十年交付经验的一次沉淀。文中提到的探查工具、巡检脚本、问数 Skill 等都已脱敏后整理在文末附件中，可以直接参考使用。

过去几个月，我开始把 Claude Code 当成数据交付的 copilot。不是用它写代码——准确说，写代码只是最表层的事。真正改变工作节奏的，是它**缩短了每个环节的启动时间**。从"不知道怎么开始"到"有一个能跑的草稿"，这个距离被大幅压缩了。

## FDE 的工作到底长什么样

FDE（Forward Deployed Engineer），源自 Palantir 的 Forward Deployed Software Engineer（FDSE）角色。核心定位是**为一个客户启用多种能力**——嵌入客户现场，端到端负责从数据接入到产生业务价值的全过程。和传统软件工程师的区别在于：SWE 的核心是**开发一种能力，服务多个客户复用**；FDE 的核心是**面对一个客户，启用多种能力去解决他的问题**，更像小团队里的 startup CTO。如今 OpenAI、Salesforce 等公司也广泛采用了这个角色。

在数据平台项目中，FDE 的工作范围大致覆盖这条链路：

**数据探查 → 数据接入与建仓 → 数仓建模 → 取数服务 → 业务应用交付**

全链路巡检作为伴随任务贯穿全程——不是主链路的某个阶段，而是从第一天开始就伴随运行的"第二双眼睛"。

![FDE 工作范围全景图](/blog/fde-ai-data-project-delivery/fde-workflow.jpg)

这条链路的痛点很明确：

**上下文切换成本高。** 一天内你可能在 Hive SQL、Python 脚本、Shell 运维、Word 文档之间反复跳。每次切换都要重新加载上下文，这种认知开销是隐性的，但累积起来非常消耗。

**重复劳动多。** 每个新项目的数据字典、巡检脚本、取数模板都要从头搭建。模式相似，但细节不同，没法简单复制。

**交付周期受限于非核心工作。** 真正的建模和业务判断可能只占 30% 时间，剩下 70% 花在配环境、查元数据、写文档上。

而 FDE 被衡量的标准是业务成果，不是代码行数。接下来的五个场景和一个伴随任务来自我最近参与的几个数据项目——它们合起来覆盖了 FDE 数据交付的完整链路，展示 AI 如何改变了我在每个环节的工作方式。

## 五个主链路场景 + 一个伴随任务

### 场景一：数据探查——三天的活压到两小时

新项目入场第一件事——摸清数据家底。客户给了一份 339 张 Hive 表、10,145 个字段的数据字典 Excel，需要为每个字段补充空值率、去重数、值域分布、样例值等探查信息。

人工逐表 `DESCRIBE` 然后手写探查 SQL？339 张表，不现实。

我把需求描述给 Claude Code："我需要一个配置驱动的批量探查工具，输入数据字典 Excel，输出带探查结果的增强版 Excel。环境是华为 FusionInsight MRS，Kerberos 认证，Hive + TEZ 引擎。"

它产出了 Dataprobe——一个完整的探查工具。一个 YAML 配置文件驱动整个流程：连接信息、Kerberos 认证、并发策略、脱敏规则全部收敛在配置里。核心能力包括：多维指标采集（空值率/去重数/值域分布/样例值）、复杂类型自动适配（array/map/struct 类型自动降级，只采集 null 统计）、敏感字段自动识别与脱敏、表级并发 + 字段级信号量双层限流、断点续跑。

```yaml
# 一个 YAML 驱动整个探查流程（脱敏示例）
datasources:
  hive_prod:
    type: "hive_jdbc"
    host: "xxx.xxx.xx.x"
    port: 21066
kerberos:
  enabled: true
  principal: "user@HADOOP.EXAMPLE.COM"
  keytab: "/path/to/user.keytab"
concurrency:
  max_workers: 10
  field_level:
    per_table_max_parallelism: 3
sensitive:
  enabled: true
  rules:
    - type: "PHONE"
      pattern: "(mobile|phone|tel|手机|电话)"
    - type: "IDCARD"
      pattern: "(idcard|id_card|cert|sfz|身份证)"
```

初始版本当天完成，同一天内从 v1.0（Beeline 版）迭代到 v2.0（纯 Python JDBC 版）再到 v2.1（复杂类型 + 元数据增强）。后续扩展到全量 20,697 个字段的探查，其中生产表白名单 431 张表的 4,346 个待回填字段通过断点续跑脚本完成。

需要说明的是：探查工具本身的执行时间并没有缩短（该跑多久还是多久），真正压缩的是**开发探查工具的时间**——从需求描述到一个完整可用的探查工具，传统做法大概要 3 天，AI 辅助下 2 小时就有了一个能跑的版本。

### 场景二：临床数仓——AI 能提取字段，但不知道 HIS 的"方言"

场景一侧重技术层面的数据物理特征。场景二进入业务层面——在某三甲医院的临床数据中心（CDR，集中存储患者就诊、检验、用药等全量数据的系统）项目中，FDE 需要完成从理解业务到数据接入到质量验证的全链路。这一步才是 FDE 区别于普通数据工程师的核心能力。

**业务理解阶段：** AI 读取 Word 版接口文档（几十个接口、上百个字段），自动提取字段信息、推断语义关系，生成 ODS 层建表语句。ODS（原始数据层）有 10 张表，全部是 TEXT 列的 HIS（医院信息系统）原始 dump——184 例患者、48,992 条检验明细、28,784 条生命体征记录。

**数据接入阶段：** 将 10 张原始表按临床域重组为 7 张 DWD（明细数据层）表（患者域、就诊域、检验域、检查域、生命体征域、诊疗域、诊断域）。用标准化编码映射表将 HIS 系统的本地编码对齐到行业标准（LOINC），同时处理 TEXT 到数值的安全类型转换。

**然后问题来了。**

AI 按教科书术语建了一份检验映射表，26 条映射规则。拿去跑真实数据——13 条无法命中任何记录。

原因是，这家 HIS 系统的检验项目命名完全不按教科书来。AI 知道教科书上的标准检验项目名称，但不知道这家 HIS 里同一个检验项用的是完全不同的本地别名。更麻烦的是，实际数据里检验项目名前面带着 △、★、* 等装饰符号，而且同一个检验概念分散在三个不同名称的检验项下（△检验A、*检验A、★检验A）。

**这些映射只能通过查看真实数据得到。** 最终从 26 条扩充到约 86 条映射，全部是 FDE 查看实际 HIS 数据后手工修正的。

映射之外，还有更深层的判断——这些判断不是技术问题，而是业务和产品问题。

NLP 抽取了 12,529 条非结构化数据，AI 倾向于建独立的 NLP 域表——干净但割裂。我的判断是融入现有五域，因为 NLP 数据本质来源于病历文书，应归入对应临床域，否则下游关联会非常痛苦。另一个例子：系统的时间窗口规则将一部分检验标记为"缺失"——因为采集时间不在预设窗口内。AI 会把这当 bug 修——但我的判断是不改，因为系统定位是特定阶段评估，对前瞻性使用场景这个行为是正确的。**这些都不是技术判断，是产品判断。**

这个项目中绝大部分代码提交由 AI 完成——但人类的提交是决策性的：架构选型、业务判断、数据质量修正。按个人经验估算：ODS 层建表 + 质量验证从一周压缩到一天半，AI 处理机械工作，FDE 聚焦业务判断。

### 场景三：数仓建模——三个 AI 吵完架，我来拍板

数仓 DWS（汇总数据层）需要设计增量识别机制。这不是简单的"写个 SQL"——DWS 宽表每日全量覆盖产出当日分区（INSERT OVERWRITE），`update_time` 每日全部刷新，下游 ADS（应用数据层）无法识别"真正变化"的增量数据。亿级数据量下每日全表扫描，成本扛不住。

需要在性能、准确性、可维护性之间做架构权衡。

我让 Claude Code 读取现有表结构和业务规则，它提出了全字段 Hash + Delta Keyset 方案——简单说就是给每行数据算一个指纹，每天比对指纹变化来识别增量。具体做法是给 DWS 表加一个影子表（只存主键 + SHA-256 hash + 时间戳），每日用 FULL OUTER JOIN 比对新旧 hash，输出 I/U/D 三种变更类型到 delta keyset 表，ADS 层直接用 keyset 回表取增量。

方案出来后，我分别调了 Codex（GPT-5.4）和 Gemini 做独立审查。三个模型各有侧重：

- **Codex 发现了三个代码级 Bug：** 影子表 location 推导用 replace() 可能误匹配、复杂类型标准化存在碰撞歧义、Mapper 中有未使用的死代码
- **Gemini 识别了三个架构级风险：** ARRAY<STRUCT> 类型强转可能 ClassCastException、null 转空字符串的业务歧义、HiveMetaStoreClient 权限边界

审查后补充了关键改进：Kerberos 票据预检（`klist -s`）、beeline 冷启动误判防御、null-safe hash 对比（`NOT (a <=> b)` 替代 `a != b`）、月分区兼容逻辑。

但最终决策是我做的。比如"用影子表还是 ALTER TABLE ADD COLUMNS"这个选择——1000+ 个 SQL 文件不可能逐一修改，所以选影子表，确保现有 DWS SQL 零改动。再比如"FULL OUTER JOIN 还是 NOT EXISTS + UNION ALL"——选 FULL OUTER JOIN 一条 SQL 搞定 I/U/D，但必须用子查询预过滤分区，因为 FULL OUTER JOIN 时 Hive 两侧都是 preserved table，WHERE/ON 的分区条件无法下推。这个坑恰好是 Codex/Gemini 审查时强调的。

```sql
-- Delta Keyset 核心 SQL（脱敏）
SELECT
    COALESCE(t_new.pk_id, t_old.pk_id) AS pk_id,
    CASE
        WHEN t_old.pk_id IS NULL THEN 'I'
        WHEN t_new.pk_id IS NULL THEN 'D'
        ELSE 'U'
    END AS op
FROM
    (SELECT pk_id, hash_key FROM dws_hash WHERE dt = '${DT}') t_new
FULL OUTER JOIN
    (SELECT pk_id, hash_key FROM dws_hash WHERE dt = '${DT_PREV}') t_old
ON t_new.pk_id = t_old.pk_id
WHERE t_old.pk_id IS NULL
    OR t_new.pk_id IS NULL
    OR NOT (t_new.hash_key <=> t_old.hash_key);
```

模型给方案，FDE 给决策。了解客户的数据量级、更新频率、下游依赖链的是人，不是 AI。个人体感：方案设计从 2 天压缩到半天，且经过多模型交叉验证，鲁棒性比单人评审更高。

### 场景四：智能问数——让 AI 当数据开发，不只是翻译 SQL

数仓建好后，业务方频繁提取数需求，每次都要我人工写 SQL。我变成了"人肉 SQL 翻译器"。

我构建了 Smart Data Query——一个 Agent + Skill 分离架构的问数系统。Agent 负责执行工作流（搜索数仓目录 → 选表 → 生成 SQL → 静态自检 → 交付），Skill 负责存储可进化的知识规范（SQL 输出标准、Hive 方言护栏、验收清单）。

几个设计决策值得展开说：

**选表比写 SQL 更难。** 数仓有上千张表，选错表后面全白费。所以我用纯 Python 写了一个零依赖的目录检索引擎：从 DDL 文件构建两层 catalog（轻量索引粗筛 + 按需加载详情），多维度加权打分（表名权重 5、COMMENT 权重 4、列名权重 3），中英文混合 tokenizer，低信息量 token（id/name/code/dt）自动降权。

**内置静态检查器替代 DBA 审查。** 不连库即可检查分区下推遗漏、SELECT *、JOIN 放大风险、Hive 方言不兼容、ORDER BY 非法引用。第一天就踩了 5 个 Hive 方言坑，全部编码成自动化规则。

**从纠正中自动学习。** 每次问答自动记录 JSONL 日志，包含用户反馈标签（good/bad）和结构化问题分类。累计若干条已标注样本自动触发规则更新——bad case 中的高频问题（如 `wrong_layer`、`missing_time_range`）自动沉淀为业务问卷的补问清单和 Skill 的技术护栏。

实际迭代过程中，同一个取数需求经常要三轮：第一轮选错分层，第二轮用了静态分区参数，第三轮改为动态 `MAX(dt)` + CTE 结构才被接受。但这三轮迭代比一轮完美需求评审更高效——业务方不需要知道什么是 ADS/DWS/DWT，先看结果再调整。

### 场景五：全栈交付——一个人撑起一个产品的完整生命周期

前面场景二中的临床数仓，是这个业务系统的数据底座。现在把视角拉远——整个系统需要从零交付给客户：后端 Python FastAPI + 推理引擎 + 前端 Next.js。FDE 不只是"部署工程师"，而是主导整个产品从设计到上线的全过程。

**产品设计：** 不是接收 PRD，而是自己写——51K 字的架构设计文档，定义了 19 个需求、6 条设计原则。关键决策如"推理引擎只定义结构关系，不硬编码判定阈值，所有可执行逻辑收敛到配置文件"——需要同时理解业务领域（规则更新频率远高于知识结构变更）和 AI 技术边界（LLM 不可信赖做确定性推理）。

**开发：** 用 GSD（Get Shit Done）工作流管理 29 个 Phase，每个 Phase 经历标准流程——讨论 → 调研 → Codex 对抗审查 → 计划 → 并行执行 → 验证。v1.0 MVP 用 11 天完成 16 个 Phase、35 个 Plan，平均每个 Plan 执行时间约 6 分钟。技术栈横跨推理引擎、Java gRPC、Python FastAPI、TypeScript Next.js、dbt SQL、Docker Swarm。

每个 Phase 开始时，我在 CONTEXT.md 中明确标注 `Locked Decisions`（我拍板的）和 `Claude's Discretion`（AI 自由发挥的）。这种"给 AI 画框"的方式很重要——AI 在约束内编码效率极高，但决定做哪些 Phase、以什么顺序做，是 FDE 的判断。

**部署：** 15 台服务器的 Swarm 集群，全部 CentOS 7.9。1 天完成 v2.0 部署（JWT 认证 + Docker 镜像 + Swarm 多副本 + Nginx 反代），但过程不是一帆风顺的：

- 内网 HTTP insecure mirror 与 Docker BuildKit 不兼容——果断关掉 BuildKit，不纠结"最佳实践"
- gRPC HTTP/2 长连接无法用 Swarm VIP 做 per-request 负载均衡——改用 `endpoint_mode: dnsrr` + 客户端 round_robin
- Docker Secrets 文件尾部换行符导致密码认证静默失败——entrypoint 里加 `tr -d '\r\n'`

以及 CentOS 7.9 内核兼容性、IPv6 localhost 解析等若干环境问题。

这些问题 AI 无法预判。AI 在 Phase 18 的验证报告中主动标注了 3 项 `human_needed` 验证（内网 Registry 可达性、CentOS 内核验证、HEALTHCHECK 状态）——它知道哪些事情自己做不了，这种诚实比盲目自信更有价值。

20 天，数百次提交，29 个 Phase，595 个测试。从 51K 字的架构文档到生产环境的集群部署，一个人完成。按个人经验估算：同样的交付如果是传统模式（前端 + 后端 + 运维各一人），大概需要三人协作三到四周。

### 伴随任务：全链路巡检——贯穿全程的第二双眼睛

巡检不是交付完才做的事。从数据接入开始就需要监控任务成功率，建模阶段监控小文件和存储膨胀，上线后监控全链路的基础设施和接口健康度。

我用三个 Claude Code Skill 搭建了全链路巡检体系：每日巡检（YARN 任务状态 + Kafka 消费 lag）、全链路巡检（ES/CK/HDFS/Hive/接口测试三层联动分析）、周报生成（汇总所有组件数据 + 飞书 Wiki 上传）。

几个设计细节：

**Deadline 驱动的告警与归因。** 08:30 前数据加工任务必须完成，脚本不仅检查是否超时，还追溯上游原因——"某关键任务 MISSING，可能因上游超时：某依赖任务在 08:47 才完成"。

**grep 加速的日志扫描。** 3.3GB 的基础设施日志，Python 逐行读要分钟级，用 grep 预筛选 + Python 后处理约 10 秒完成。支持 6 种组件、15+ 种错误模式分类。

**三层联动分析。** JMeter 接口失败 → 通过接口注册表映射到后端服务 → 在同时间窗口搜索基础设施日志 → 生成因果链。从"接口报 500"到"CK 节点内存溢出"的根因定位，自动完成。

**周报从手工到一键。** 数据采集（SSH 下载原始 JSON）→ 标准化分析（pandas 聚合 + 环比计算）→ 报告渲染（460 行 Markdown + 4 张图表 + Excel 附件）→ 飞书上传。脚本保证数据准确性，AI 只在 `AI_REVIEW` 标记处补充跨组件关联分析。

个人体感：周报编写从每周 4 小时降到 15 分钟，巡检覆盖面从"人能记住的几个指标"扩展到"脚本跑完所有指标"。

## FDE 用 AI 的正确姿势

从上面六个场景中，我总结出四个层次的 AI 使用能力。这个分层参考了 Brex 的员工 AI 能力四级体系（User → Advocate → Builder → Native），同时结合了 Gartner AI 成熟度模型的工程实践视角。它不只适用于 FDE——任何需要用 AI 做事的人，都可以在这四层里找到自己的位置：

![AI 使用能力四层模型](/blog/fde-ai-data-project-delivery/ai-levels.jpg)

**L1 使用者（User）—— 会问 AI 问题。** 用 ChatGPT 或 Claude 提问，获取信息、学习概念、解答疑惑。大多数人停在这一层。这一层的价值是"搜索引擎的升级版"，能回答问题但不直接产出交付物。

| 典型行为 | 衡量指标 | 人机边界 |
|---------|---------|---------|
| 提问、查资料、学概念 | 问答频率 | AI 给建议，人做所有事 |

**L2 生成者（Builder）—— 用 AI 产出东西。** 写 SQL、写脚本、写配置文件、生成文档。数据探查工具的初始版本、巡检脚本的编写、前端页面的搭建，都属于这一层。AI 在这一层的价值是"从零到初稿"的加速——产出物是可交付的，不只是知识。

| 典型产出 | 衡量指标 | 人机边界 |
|---------|---------|---------|
| SQL / 脚本 / 配置 / 文档 | AI 生成代码占比 | 人工 review 100% |

**L3 编排者（Orchestrator）—— 把 AI 串成工作流。** 把多个步骤串成端到端链路。巡检的"采集 → 分析 → 渲染 → 上传"闭环、问数的"搜索 → 选表 → 生成 → 自检 → 反馈"闭环，都属于这一层。需要用 Skill/MCP/Agent 等编排能力把 AI 的单次输出组装成可复用的工作流。从"用 AI 做一件事"到"让 AI 自动跑一条链路"，这是质变。

| 典型产出 | 衡量指标 | 人机边界 |
|---------|---------|---------|
| 端到端自动化链路 | 自动化流程数量 | 关键节点设审批门禁 |

**L4 协作者（Collaborator）—— AI 参与决策。** 多模型共识决策、方案对比审查、人机决策边界划定。数仓建模场景中 Claude + Codex + Gemini 的三方审查，全栈交付中用 Locked Decisions / Claude's Discretion 划定人机决策边界，都属于这一层。AI 不再只是"执行者"，而是"对话者"——你让不同模型从不同角度挑战方案，明确哪些决策权归人、哪些归 AI，然后作为最终决策者综合判断。

| 典型产出 | 衡量指标 | 人机边界 |
|---------|---------|---------|
| 多模型审查报告 / 决策矩阵 | 决策准确率 + 时间节省 | Locked Decisions（人拍板）vs AI's Discretion（AI 自由发挥） |

四个层次逐步叠加：L1 是起点，L2 开始产出交付物，L3 让产出可复用，L4 让决策更稳健。本文的六个场景覆盖了 L2 到 L4——但每个人都可以从 L1 开始，逐步升级。

几条关键经验：

**给 AI 越多上下文，产出质量越高。** 数仓项目的 CLAUDE.md（7.4K 字）把架构约束、设计原则、命名规范全部注入 AI 的工作上下文。临床项目的 CONTEXT.md 明确标注哪些决策已锁定、哪些 AI 可自由发挥。上下文工程的投入回报比远高于调参。

**人工审核不能省。** AI 输出是"初稿"不是"终稿"。检验映射表的故事说明了这一点——AI 按教科书建的映射表一半无法匹配真实数据。每个场景中 FDE 的不可替代性都指向同一个点：对真实业务环境的理解。

**工具链比单次对话重要。** 问数系统的 Skill 规则可以从反馈中自动进化，巡检系统的三个 Skill 覆盖了从每日到每周的完整运维链路。Skill 复用远比每次重新向 AI 解释需求高效。

## FDE 的下一步

做交付这些年，多线并行已经是常态。不同的是，现在有了 AI 加持，这种节奏不再让人疲于奔命。AI 处理机械劳动，FDE 聚焦业务判断和架构决策。

我不认为 AI 会替代 FDE。恰恰相反，AI 放大了 FDE 的杠杆——一个人能扛的交付面更宽了，每个环节的启动成本更低了，但做出正确判断的能力依然是人的事。

如果你也是 FDE 或数据工程师，建议从巡检自动化开始尝试。它是最容易上手的场景（脚本逻辑相对固定、反馈循环快），同时也是每天都能省出时间的场景。等你体会到 L2 生成者的效率提升后，自然会开始想：能不能把这些脚本串成工作流（L3 编排者）？能不能让多个模型来审查我的方案（L4 协作者）？

---

## 附件：文中提到的工具和 Skill

以下资源均已脱敏处理，可直接参考或在此基础上定制：

| 场景 | 资源 | 说明 |
|------|------|------|
| 数据探查 | [Dataprobe 探查工具](/blog/fde-ai-data-project-delivery/attachments/dataprobe.zip) | 配置驱动的 Hive 批量元数据采集，支持 Kerberos、断点续跑、敏感字段自动脱敏 |
| 智能问数 | [Smart Data Query Skill](/blog/fde-ai-data-project-delivery/attachments/smart-data-query.zip) | Agent + Skill 架构的自然语言转 SQL 系统，含目录检索引擎和静态检查器 |
| 全链路巡检 | [巡检 Skill 套件](/blog/fde-ai-data-project-delivery/attachments/inspection-skills.zip) | 每日巡检 + 全链路巡检脚本（不含平台相关巡检脚本） |
| 数仓建模 | [DWS 增量识别方案](/blog/fde-ai-data-project-delivery/attachments/dws-hash-key.zip) | Hash 比对 + Delta Keyset 的完整 SQL 和 Shell 编排脚本 |

---

## 相关阅读

- [数据治理时代，Agent 能帮我们干哪些脏活累活？](/posts/data-governance-agent/) — 本文的"前传"，聚焦数据治理场景的 AI Agent 落地思路
- [取数同事离职后，业务还能稳吗？一个自我进化的智能问数 Skill](/posts/smart-data-query/) — 场景四"智能问数"的深入版，详细拆解 Agent + Skill 架构
- [从 AI 问答到 AI 值夜班：我的真实工作流拆解](/posts/ai-workflow-from-qa-to-nightshift/) — 另一个视角看 AI 工作流全景，与本文的 L1-L4 模型互补

---

*本文效率数据基于个人经验估算，非精确测量。所有项目信息已做脱敏处理，隐去关键识别信息。*