SqlAI 提出「数据智能工程师」这一新兴角色

返回博客 Data Intelligence Engineer 的黎明 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 字，完整内容请点「打开原文」。）