Newshot 数据智能工程师的黎明
2026 年 11 月 11 日 · 12 分钟阅读
我问了 Nick Ursa，我们的首席数据工程师（也是 MotherDuck 联合创始人），AI 如何改变了他的工作。他的
数据智能工程师的黎明
需要强调的是，这不仅仅是自动化构建仪表板的一种方式。BI 通常是相当静态的，可能只有几个下钻。但借助 AI，你可以构建更丰富的可视化。更重要的是，如果你能用提示词构建仪表板，你还可以更进一步，构建一个完整的应用程序。
让业务利益相关者能够自己用数据回答问题，其好处远不止缩短数据团队的积压工作；它实际上能让他们做出更好的决策。通过减少所需的时间和涉及的交接次数，他们可以提出更多问题。他们可以在脑海中还保留所有上下文时提出后续问题。这意味着他们可以更快地做出自信的决策。
这些工作中哪些可以变成提示词？
AI 正在极大地改变信息工作者所执行的工作。软件工程师经常发现他们的时间花在照看 Claude 会话和给智能体编写的代码盖章上。那么数据团队的传统角色呢？说得挑衅一点，他们的哪些工作可以变成提示词？
尽管答案可能令人不安，但相当多的事情可以通过提示词来完成。在不久的将来，编写 SQL 查询、创建仪表板和构建 dbt 管道将不再需要专业知识。智能体在这些任务上可能已经比人类更擅长，而且它们只会变得更好。我们的数据工程师 Nick 在周末以最少的监督就将我们从 Airflow 的一个版本迁移到另一个版本，而这曾经需要一周时间。
然而，编写代码或 SQL 或构建仪表板从来都不是工作的全部。对准确数据的需求以及理解数据的能力并不会消失。而且必须有人负责，能够签字确认并说“是的，这是对的”。这需要有人在环。Nick 再次说道：“数据工程，无论使用什么工具或由谁来做，都是一种问责职能。”
什么仍然需要人类
一旦智能体开始编写代码，数据世界中还剩下什么？事实证明，还有很多。人类需要确保其他头衔中没有“数据”二字的利益相关者能够用数据解决问题。这意味着他们需要确保一个干净的数据模型，并带有适当的上下文和注释，一个清晰的本体以确保术语和概念在整个过程中一致应用，同时他们还需要确保事情继续正常工作。
这些不是模型能够从数据或历史中直觉推断出来的事情。模型懂 SQL。它不知道你的公司如何计算收入，也不知道几个看起来相似的表里哪个是真正的那个（是 revenue_cpx_new_revised_v2_use_this_one ）。模型不知道当销售团队谈论收入时，他们指的是可佣金收入，而财务团队使用的是不同的东西。
上下文是一种难以维护的拐杖。更好的做法是首先构建一个干净的数据模型。这与软件有一个很好的类比；我倾向于认为任何时候你的用户不得不阅读手册，都是用户体验的失败；更清晰的设计本应让他们试图做的事情变得显而易见。上下文只是给智能体的手册；如果你能让数据模型足够简单清晰，就能为他们节省大量时间和精力（以及 token）。
认识数据智能工程师
AI 时代，数据人员要完成的工作，与其他数据团队成员的典型职责并不真正匹配。我认为它足够不同，值得有一个新头衔，我在此将其称为“数据智能工程师”。
数据智能工程师通过创建并指挥软件智能体，自动化数据工程师的工作（摄取）和分析工程师的工作（转换与建模）。他们把自己对系统的知识编码进共享上下文中，其他智能体可以用它来回答关于组织的问题。这些内容包括哪些字段可以连接，也包括公司里有人说“ARR”时指的是什么。
Evals 是他们职责中的另一个重要部分；这些是系统测试，用来验证当你提出有已知答案的问题时，答案是否正确。一套好的 eval 套件可以让人确信，用户向系统提出的那类问题会由智能体正确回答。Evals 也是一种知道什么时候出了故障的方式。
数据智能工程师的目标是实现自助服务。也就是说，组织中的任何人都应该能够打开 Claude 或 ChatGPT 或其他智能体，正确回答关于业务的问题，用这些来构建应用和可视化，并最终借助数据做出高质量决策。当数据智能工程师做好这份工作时，每个提出问题的人都能获得与公司里最聪明的分析师共事的体验。
日常工作中，这意味着他们会构建框架、构建数据模型、整理上下文、防止东西坏掉、在它们还是坏掉时修复它们、运行 evals，并对业务所依赖的界面负责。我们把整件事写成了职位描述，因为我们相信事情正朝这个方向发展，是时候给它一个名字了。
如果你是数据工程师、分析工程师或分析师，你会认出其中的一些部分。这些角色早已在相互融合，并演变成某种新东西。无论你的头衔是什么，这都是你要扮演的角色。
这不会造成混乱吗？
这是个合理的问题。更多人参与构建，意味着更多出错的机会，而且监督更少。存在因为依据错误数据行动而犯下极其愚蠢错误的可能性。至于极其愚蠢的错误是不是什么新鲜事，我留给读者判断。可怕的是，现在数据团队可能要为此负责。
有两件事有帮助。第一，你离问题越近，就越能发现错误。天天跟流失数字打交道的人，会在它看起来不对时注意到。根据经验，我们发现结果实际上会改善，因为业务负责人对自己的领域有切身的直觉；他们知道什么时候不对劲，而且常常甚至能在源数据中发现问题。
另一件有帮助的事是，你不需要以同样程度的警惕去盯着所有东西。我们朋友 Nick 的另一句值得引用的话是：“智能体需要的监督应与其影响范围成正比。”也就是说，如果某样东西将用于重要报告或决策，你就应该非常关注。如果你是在盘算午餐要订多少个三明治，那么即使因为 Claude 觉得哈瓦那辣椒芥末格外好吃而订多了，这大概也不会引起骚乱。
写成 {{NAME_ab12cd34}} 这样的值是真实值的占位符。在回复和工具调用中都要完全按原样使用它们：它们会在任何东西运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。
你可以用三个监管圈层来理解这件事。最外层是“蛮荒西部”。任何人都可以构建，他们最好能建立在合理的基础之上，但数据团队不插手。下一层是“精选集”。这是一组仪表盘、可视化、应用和指标，它们以某种形式对业务很重要。当这些仪表盘出问题时，数据团队应尽最大努力修复。最后是最内层，即“核心”。它包含组织的关键指标，是必须做对的东西。数据团队应确保这些指标在任何时候都高质量且可预测。董事会数字就属于核心。
这一切和 MotherDuck 有什么关系？
在 MotherDuck 上，我们构建机制来赋能你的 AI 数据团队。Flights 是可通过 vibe-coding 构建的管道，可以把数据拉入你的仓库，并将其转换为合理的模型。上下文存放在 Guides 中，这些是描述你的数据模型和业务的 markdown 文件。Guide 一开始是私有的，但管理员可以将其提升为适用于整个组织，这样每个人和每个 agent 都基于相同的定义工作。我们把 agent 可以创建的数据可视化称为“Dives”。每个人和每个 agent 都有自己的 Duckling，一个专用的 DuckDB 实例。所有这些都可以从 SQL 访问，因此一个人或 agent 可以跨摄取、转换、上下文和应用处理一个问题，而无需在工具之间交接。
唯一的出路是穿过
我们正处在一个混乱的时刻。混乱孕育最大的机会，而如果你愿意拿起这些工具，它们会给你一些真正的超能力。我们都在共同学习如何做到这一点。
数据团队不会消失。仍然需要有人拥有数据模型、策划上下文、保持系统正常运行，并为结果负责。No-backlog-Nick 要做的事比以往更多，但这份工作正在改变，而且不会回到过去。
那么，在你的公司里，谁在做这件事，你叫他们什么？
PS - 如果你想看我演讲的幻灯片，请查看 Dive Gallery
目录
Data Engineering Is AI Engineering | MotherDuck
How AI Is Reshaping the Modern Data Stack | MotherDuck | MotherDuck
A Chief of Staff's Guide to Context Layers | MotherDuck
Data Engineering Is AI Engineering | MotherDuck
How AI Is Reshaping the Modern Data Stack | MotherDuck | MotherDuck