Google计划招数百名FDE，这些人要做AI做不了的什么？

01｜AI 首先接手数据整理工作

Google Data Cloud负责人Andi Gutmans推动的自动化，先从企业AI项目的数据准备入手。

同一个缩写在两个部门可能指不同业务，一张表的说明可能过期，另一张表是谁维护的，又得找人确认。模型接入之前，工程师需要先弄清字段含义、表之间的关系，以及哪些数据允许谁来用。

Google的Knowledge Catalog会汇集这些背景信息，再结合数据结构、使用记录等材料补充说明，让Agent按权限找到所需内容。现有资料展示的是数据准备工序的自动化，尚无证据表明它能包办FDE的整项客户交付。

英国电信公司Virgin Media O2有一个公开案例。该公司的数据环境包含超过两万项数据资产，团队使用生成式AI补充元数据，也就是描述数据本身的说明。例如，一串难懂的字段名，可以补充上它代表什么金额、使用什么币种、来自哪类业务记录。

过去需要人逐张表整理的说明，现在可以先让AI起草。AI起草后由内部领域专家继续修订和验证，让描述符合公司的业务实情。

Google在产品说明里交代了生成过程。系统先分析数据类型、数值分布和常见模式，再把这些统计信息与表结构一起交给Gemini，生成表、字段和业务术语的说明。随后，说明被存进统一目录，供搜索、数据治理和其他Agent使用。工程师核对过的一份解释，就能被后续任务反复引用。

这项能力在2025年12月已正式开放，也提供API，可以接进已有的数据处理流程。新数据进入时，团队可以同步生成说明，减少事后追补文档的工作。对FDE而言，接入API之后还需要安排更新，确定哪些变化触发重新生成，旧说明是否仍然适用，修订结果如何交给下一次查询使用。整理文档因此成了一项可以持续运行的工程任务。

02｜把客户专家的业务判断，变成系统能执行的规则

沿着AnyJob AI的数据产品图谱继续调查发现Virgin Media O2的数据战略、云与工程负责人Chandu Bhuman，以及Google数据与AI架构师Dženan Softić，出现在一篇共同署名的案例里。它讲的恰好是自动化之前，各个团队的明确分工。

他们采用“数据契约”。这里的契约是一份机器能读取的约定，写清数据结构、业务含义、质量要求，以及更新是否及时、内容是否完整。

这份约定明确了分工。中央团队提供共用的平台和工具，各部门负责自己的数据产品与质量。规则写好之后，系统可以持续检查数据是否符合要求，发现变化或异常就报警。

在Virgin Media O2，数据提供方会把约定写成YAML配置文件，提交到GitLab代码库。系统先检查文件是否符合规范，再依据里面的要求创建数据质量扫描任务。规则因此有了版本记录，团队可以查到某次检查依据的是哪一版约定。

制定阈值也有实际数据可参考。平台会持续统计空值出现频率、数值范围和数据类型分布，帮助各部门提出可执行的质量要求。检查结果进入BigQuery，使用者通过看板查看数据是否达标，再决定是否接入自己的业务。中央团队则通过授权视图汇总各部门结果，无须为此复制一遍数据。发生异常时，相关部门可以查看具体告警，核对问题出在哪项要求上。

至于检查标准，例如一张表晚到半小时有没有影响，一个空值能否接受，得由使用数据的部门结合业务确定。

这让FDE和客户专家之间的合作变得分工明确。工程师把要求写进系统，客户确认要求是否反映实际工作；发生例外时，双方再判断是改规则、修数据，还是暂停某项自动操作。

03｜把 AI 能力，接进客户的业务系统

AnyJob AI在执行者搜索中找到了Raghvender Arni。沿着他的职业网络继续调查，再核对哥伦比亚大学公布的简介，可以看到他长期带领面向企业客户的技术团队。

Arni也公开介绍了Google Cloud的FDE团队。与数据产品的发布相比较，两边承担的任务不同。产品团队把通用能力做好，交付团队还要把它接进一家具体公司的环境。

Google的FDE招聘要求提到了旧数据系统、API和安全边界。这些词背后都是现场问题。客户已经运行多年的系统怎么连接，权限开到哪一级，响应速度和准确率如何验收，项目上线后谁来维护。

Google此前发布的一则FDE IV招聘说明，把八年软件开发经验列为基本条件，还要求候选人有带领客户开展技术需求讨论，以及将AI方案从构想到正式上线的经历。团队需要有人在需求仍不完整时，就能组织客户讨论，确定哪些工作进入开发。

技术要求延伸到模型运行之后。职位说明提到每秒生成的Token数、单次请求成本、状态管理和细粒度追踪。工程师得知道一次任务运行到哪一步，哪里变慢，哪个环节增加了调用成本。这些记录能帮助团队重现客户遇到的问题，也为后续修改提供依据。客户交付中的技术深度，还包括把系统的运行过程查清楚。

招聘说明还要求工程师识别重复出现的问题，把它们转成可复用模块或正式产品需求。一个客户现场解决过的麻烦，应该帮助后面的客户少走一遍。

04｜让 AI 动手之前，先设好权限

Palantir已经把一款产品命名为AI FDE。它能通过对话参与数据转换、代码和业务对象的修改，用户可以指定模型、工具与上下文。文档同时安排了分支提案、预览与审查流程，修改要经过相应检查再进入正式环境。

Palantir官方AI FDE产品示意，图片来自产品文档。

8月20日，Andi在Stack Overflow的访谈里讲了一次自己的经历。一个Agent替他生成了一千个测试，他让另一个Agent检查，发现测试质量有问题，仍要由他判断和改进。他把自己的工作变化描述为少写一些代码，多做设计、组织和审查。

测试数量很容易增加。它们有没有覆盖会让客户损失钱、泄露数据或中断业务的情况，才是验收时需要回答的问题。

05｜招聘和采购都要重新看交付

类似变化也在国内的数据工具里发生。

阿里云DataWorks的Agent已覆盖数据集成、开发、治理等任务。用户用自然语言描述需求，可以让它生成配置、组织代码和工作流。文档对部分存在冲突的操作设置了再次确认步骤。

DataWorks还允许用户把指定的数据表、代码文件、本地文档和规则加入对话背景。处理复杂任务时，Agent列出待办步骤，结束后汇总已完成的操作和生成的资源，同时提供任务耗时与Token消耗记录。客户能够逐项核对软件究竟做了什么。

对企业来说，这会改变评估供应商的方法。如果数据整理、代码初稿和常规配置越来越多地由软件完成，单看投入多少工程师、写了多少代码，就很难比较交付质量。

采购评估可以据此增加一项实际测试，让供应商在同一批数据和同一套要求下完成任务，保留生成结果、修改记录与调用开销，再记录人工复核和返工耗时。工具显示的执行时间只是其中一部分。将这些记录放在一起，才能判断省下的开发时间是否抵消了新增检查工作，也能比较不同方案在持续运行时需要多少人工投入。

更具体的检查可以看业务目标有没有对应的验收样本，关键操作有没有权限与回退方案，客户团队能不能在交付后继续使用和维护系统。这些要求也对应着Google招聘说明里的评测、生产集成和客户采用。

招聘FDE同样如此。候选人会不会调用Agent，只回答了一部分问题。让他讲清一次真实项目中的错误、如何发现、怎样修改验收标准，会更接近这份工作的责任。