数据智能工程师的崛起：AI 如何重塑数据团队角色

我问了我们的首席数据工程师（也是 MotherDuck 联合创始人）Nick Ursa，AI 如何改变了他的工作。他的回答是：“这是我职业生涯中第一次没有积压任务。”

你可能会以为这会让他有大把空闲时间，但他比以往任何时候都更忙。虽然积压没了，但答案仍然必须正确，而且仍然需要人来决定做多少质量控制。过去他的工作是确保自己计算出的数字是正确的，现在他的工作是确保 LLM 或 agent 得出的数字是正确的。

这和在工单队列里干活是两回事。在 11 月 4 日的 Data Outpost 上，我为这个新角色提出了一个名字：数据智能工程师（Data Intelligence Engineer）。我认为它现在是 AI 赋能的数据团队中新兴的角色，我想分享一下原因。

数据团队的职责是什么？

数据团队只有一项工作：让业务能够做出好的决策。他们能基于对正在发生的事情更准确的了解，越快做出这些决策，决策就越好。

困难之处一直在于一个问题变成答案所经过的路径。它像接力一样传递。一位营销负责人周一上班时注意到上周流失率出现了激增。为什么会这样？他们向数据团队提交工单请求调查。一名分析师接手工单，在深入排查时发现某个数据源没有导出一些关键数据。他们提交工单请数据工程师查看。这需要修改其中一条数据管道，于是数据工程师进行修改、测试、运行回填、测试回填，然后解决工单。接着球又回到分析师手中，他可以构建所需的仪表盘。等到它上线时，那位营销人员早已记不起当初为什么要问了。几周后流失率自己恢复了。

这并不是在指责谁没有高效或紧迫地工作；这个接力中的每个人都没有做错任何事。但每一次交接都意味着等待，上下文会丢失，而根据问题答案有效采取行动的能力的半衰期在慢慢衰减。

顺便说一句，我们应该注意到，有一整代 AI 赋能的工具其实并没有真正帮上忙；copilot 时代让一些周转变快了，但问题在于交接太多，无法足够快地采取行动。

这一次有所不同

在 2025 年 12 月之前，反对将 AI 用于分析的理由很容易成立。LLM 写的 SQL 很糟糕。业务逻辑无从得知。合理的结论是这永远行不通。事实上，我过去常谈论数据团队或多或少不受软件其他领域正在发生的颠覆的影响。

然后，突然间，地动山摇。新模型在 SQL 方面变得更强。业务逻辑原来是 agent 借助一些有用的上下文就能弄明白的东西。而且 agent 变成了多轮交互，这意味着它们不必第一次就做对。它们可以尝试一个查询，看看返回了什么，然后再试一次，就像人类分析师会做的那样。把这些放在一起，它……就……成了。

自助式 BI 已经被谈论了几十年，这次有什么不同？嗯，作为一个存在性证明，这里有个例子：我在 Data Outpost 上做的演示不是用 PowerPoint 或 Google Slides 创建的，而是我用 MotherDuck 和 Claude 构建的一个 应用。我使用了来自四个不同数据源的实时数据集，构建了许多交互式和动画可视化。我做的任何事情几乎任何人都能做到；我没有看过一行代码或 SQL。

需要强调的是，这不仅仅是自动化构建仪表板的一种方式。BI 通常是相当静态的，也许有几个下钻功能。但有了 AI，你可以构建更丰富的可视化。更重要的是，如果你能用提示词构建仪表板，你还可以更进一步，构建一个完整的应用。

让业务利益相关者能够自己用数据回答问题，其好处远不止缩短数据团队的积压工作；这实际上能让他们做出更好的决策。通过减少所需的时间和涉及的交接次数，他们可以提出更多问题。他们可以在脑海中还保留所有上下文时提出后续问题。这意味着他们可以更快地做出自信的决策。

这些工作中哪些可以变成一个提示词？

AI 正在极大地改变信息工作者所做的工作。软件工程师经常发现自己的时间花在照看 Claude 会话和给代理编写的代码盖章上。数据团队的传统角色呢？他们的哪些工作——说得有点挑衅性——可以变成一个提示词？

尽管答案可能令人不安，但相当多的工作可以通过提示词完成。在不久的将来，编写 SQL 查询、创建仪表板和构建 dbt 管道将不再需要专业知识。代理在这些任务上可能已经比人类做得更好，而且它们只会变得更好。我们的数据工程师 Nick 在一个周末内将我们从 Airflow 的一个版本迁移到另一个版本，几乎没有监督，而这曾经需要一周时间。

不过，编写代码或 SQL 或构建仪表板从来都不是工作的全部。对准确数据的需求以及理解数据的能力不会消失。而且必须有人负责，能够签字确认并说“是的，这是对的”。这需要人类参与其中。再次引用 Nick 的话：“数据工程，无论使用什么工具或由谁来做，都是一种问责职能。”

仍然需要人类的地方

一旦代理开始编写代码，数据领域还剩下什么？事实证明还有很多。人类需要确保其他头衔中没有“数据”二字的利益相关者能够用数据解决问题。这意味着他们需要确保一个干净的数据模型，带有适当的上下文和注释，一个清晰的本体论以确保术语和概念在整个过程中一致应用，并且他们还需要确保事情继续正常运作。

这些不是模型能从数据或历史中直觉推断出来的东西。模型懂 SQL。它不知道你的公司如何计算收入，也不知道几个看起来相似的表哪个才是真正的那个（它是 revenue_cpx_new_revised_v2_use_this_one ）。模型不知道当销售团队谈论收入时，他们指的是可佣金收入，而财务团队使用的是不同的东西。

上下文是一种难以维护的拐杖。更好的做法是一开始就构建一个干净的数据模型。这与软件领域有一个很好的类比；我倾向于认为，任何时候用户不得不阅读手册，都是用户体验的失败；更清晰的设计本应让他们想做的事情变得显而易见。上下文只是给智能体看的手册；如果你能让数据模型足够简单清晰，就能为它们节省大量时间和精力（以及 token）。

认识数据智能工程师

在 AI 时代，数据人员需要完成的工作与其他数据团队成员的典型职责并不真正匹配。我认为它足够不同，值得拥有一个新头衔，我在此将其命名为“数据智能工程师”

数据智能工程师通过创建和指挥软件智能体，自动化数据工程师的工作（数据摄取）和分析工程师的工作（转换与建模）。他们将自己对系统的知识编码为共享上下文，供其他智能体用来回答关于组织的问题。这些内容包括哪些字段可以连接，以及公司里的人说“ARR”时指的是什么。

评估是他们的另一项重要职责；这些是系统测试，用于验证当你提出有已知答案的问题时，答案是否正确。一套好的评估套件可以让人确信，用户向系统提出的那类问题会由智能体正确回答。评估也是一种了解何时出现故障的方式。

数据智能工程师的目标是实现自助服务。也就是说，组织中的任何人都应该能够打开 Claude 或 ChatGPT 或其他智能体，正确回答关于业务的问题，利用这一点构建应用和可视化，并最终借助数据做出高质量决策。当数据智能工程师把工作做好时，每个提出问题的人都能获得与公司里最聪明的分析师共事的体验。

日常工作中，这意味着他们将构建框架、构建数据模型、整理上下文、防止事物被破坏、在它们仍然被破坏时进行修复、运行评估，并对业务所依赖的界面负责。我们把这一切写成了职位描述，因为我们相信事情正朝着这个方向发展，是时候给它一个名字了。

如果你是数据工程师、分析工程师或分析师，你会认出其中的一部分。这些角色早已相互融合，并演变成某种新的东西。无论你的头衔是什么，这都是你要扮演的角色。

这不会造成混乱吗？

这是个合理的问题。更多人参与构建意味着更多出错的机会，而且监督更少。有可能因为依据错误的数据行事而犯下极其愚蠢的错误。至于读者是否认为极其愚蠢的错误是什么新鲜事，我留给他们自己判断。可怕的是，现在数据团队可能要为此负责。

有两件事有帮助。第一是，你离问题越近，就越能发现错误。与流失率数字朝夕相处的人会在它看起来不对劲时注意到。根据经验，我们发现结果实际上会改善，因为业务负责人对自己领域有切身的直觉；他们知道什么时候不对劲，而且往往甚至能在源数据中发现问题。

另一件有帮助的事情是，你不需要以同样的警惕程度去关注所有事情。我们朋友 Nick 的另一句值得引用的话是：“智能体需要的监督程度应与其影响范围成正比。”也就是说，如果某样东西将用于重要的报告或决策，你就应该格外关注。如果你只是在决定午餐订多少个三明治，那么即使因为 Claude 觉得哈瓦那辣椒芥末酱格外美味而多订了一些，大概也不会引发什么骚乱。

你可以把这想象成三层监督圈。最外层是“蛮荒西部”。任何人都可以构建，他们最好是在合理的基础上构建，但数据团队不插手。下一层是“精选集”。这是一组在某种程度上对业务很重要的仪表板、可视化、应用和指标。当这些仪表板出现故障时，数据团队应尽最大努力修复它们。最后是内圈，即“核心”。这里包含组织的关键指标，是必须确保正确的事情。数据团队必须确保这些指标在任何时候都高质量且可预测。董事会级别的数字就属于核心层。

这一切与 MotherDuck 有什么关系？

在 MotherDuck 上，我们构建机制来赋能你的 AI 数据团队。Flights 是可通过 vibe-coding 构建的管道，能将数据拉入你的仓库并将其转换为合理的模型。Context 存在于 Guides 中，即描述你的数据模型和业务的 markdown 文件。Guide 初始为私有，但管理员可以将其提升为适用于整个组织，以便每个人和智能体都基于相同的定义工作。我们将智能体可以创建的数据可视化称为“Dives”。每个人和智能体都有自己的 Duckling，即一个专用的 DuckDB 实例。所有这些都可以从 SQL 访问，因此一个人或智能体可以跨数据摄取、转换、上下文和应用来处理一个问题，而无需在工具之间交接。

唯一的出路就是穿过

我们正处于一个混乱的时刻。混乱孕育最大的机遇，而如果你愿意拿起这些工具，它们会赋予你一些真正的超能力。我们都在共同学习如何做到这一点。

数据团队不会消失。仍然需要有人拥有数据模型、策划上下文、保持系统正常运行，并对结果负责。No-backlog-Nick 要做的事情比以往任何时候都多，但这份工作正在改变，而且不会回到过去。

那么，在你们公司，是谁在做这些事，你们怎么称呼他们？

PS - 如果你想看我在演讲中使用的幻灯片，请查看 Dive Gallery