数据积压消失，Data Intelligence Engineer 登场
The Dawn of the Data Intelligence Engineer
随着 AI 能力的飞跃，数据团队的工单积压首次消失了，但这并不意味着工作的结束，而是角色的根本转变。过去，数据工程师忙于处理 SQL 查询和管道修复；现在，LLM 和 Agent 能自主完成这些任务。真正的挑战在于确保 AI 生成的答案准确无误，并建立清晰的上下文。这就催生了一个新的角色：Data Intelligence Engineer。他们不再直接写代码，而是构建数据模型、设计评估体系（Evals）并维护系统上下文，让业务人员能通过自然语言直接获得可靠洞察。正如 MotherDuck 的 Nick Ursa 所言，数据工程本质上是一个问责职能，无论工具如何变化，人类仍需为最终结果负责。
数据工程，无论使用何种工具或由谁执行，本质上都是一个问责职能。
HN 评论区
73- agenticfish
数据领域被拆分成这么多不同的职位头衔，真是让人抓狂。我日常得和数据工程师、数据分析师、分析工程师、数据科学家、机器学习科学家以及机器学习工程师打交道。每个人都把自己的角色看得很窄，所以要想做成一件事，往往得拉进一堆人。很多时候，干脆自己干反而更省事。
我理解适度的专业化是有用的，但我更希望看到更多 T 型数据人才。
- aleda145
我觉得，简单地把这块领域贴上“狂野西部”的标签，然后让用户为所欲为，存在巨大风险。
一直以来，你都可以为了迎合你想讲的任何故事而“按摩”数据。以前你得去找数据分析师，说服他们放弃原则。现在，你只需让一个 agent 去搞定。
那么，你如何确保这些洞察能在公司其他部门共享（且值得信赖）呢？
我认为，暴露指标层（metrics layer）可能是这里的解决方案。
挺讽刺的是，行业努力推动数据民主化这么久，现在却手忙脚乱地限制访问，生怕用户做出错误决策。
- zodwick
虽然总体上我同意大部分观点，但其中一些感觉像是“无马马车”（指过时的技术或思维）。
比如：
>它不知道你公司如何统计营收，也不知道哪几张长得差不多的表里哪张是真的（是 revenue_cpx_new_revised_v2_use_this_one）
这个假设主要只适用于不干净的数据（而这大多是人类懒惰和积压任务堵塞的结果）。随着 AI 开始构建更多上游管道，这就不再是个问题了。
即便是现有的管道，我也预期修复会向上游移动：当 agent 在查询时遇到歧义，有用的输出不是修改上下文，而是一个修复问题的 PR。
- moezd
那不过是增强了 agent 的数据工程师罢了。
- epgui
我这边用的是 Opus 5.5 和 Fable 5.2，但我不敢说生成的代码普遍质量很高。