MotherDuck 数据工程师提出“数据智能工程师”新角色

返回博客 数据智能工程师的黎明 SqlAI 2026年11月11日 · 12分钟阅读 我问过 Nick Ursa——我们的首席数据工程师，也是 MotherDuck 的联合创始人——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 会话、给 agent 写的代码盖章放行上。那数据团队的传统角色呢？他们哪些工作——说得挑衅一点——可以变成一个提示？

答案可能让人不舒服，但相当多的事情可以通过提示完成。在并不遥远的未来，编写 SQL 查询、创建仪表盘、构建 dbt 管道将不再是需要专业知识才能做的事。agent 在这些任务上很可能已经比人更强，而且只会越来越强。我们的数据工程师 Nick 在一个周末就把我们从 Airflow 的一个版本迁移到另一个版本，几乎不需要监督，而这曾经要花一周。

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

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）