在智能体人工智能时代重新思考数据分析团队

王建峰·2026年05月15日 19:50

领导者们，现在的问题不再是这场变革是否会发生，而是你们是先于变革做好准备，还是被动地应对变革。

我想从最高层开始——不是从分析师的职业焦虑开始，而是从这一刻对于负责数据职能的领导者来说究竟意味着什么开始。

大多数商业智能和分析团队的架构都基于一个已被悄然推翻的核心假设：组织智能的主要制约因素是人对 SQL 的访问权限。消除这一障碍——通过增加分析师人数、完善商业智能工具、覆盖仪表盘——企业就能更加数据驱动。

这一假设推动了长达十年的分析投资。它催生了庞大的商业智能团队，推动了Tableau和Power BI许可证的增长，并将“数据驱动”变成了高管层的口头禅。而且，它的确达到了目的。至少在一段时间内是这样。

智能体人工智能已经使它过时了。

如今，制约组织智能发展的不再是查询权限，而是连接原始数据和业务决策的知识层的质量。更紧迫的问题是速度——仪表盘本质上是被动的，只有在用户主动查找后才能提供洞察，而业务领导者越来越需要在事件发生时就能获得答案。智能体系统不会等待用户提问，它们会持续监控、推理并呈现信息。

那是一种截然不同的模式，需要一支截然不同的团队。

智能体人工智能对商业智能功能究竟有何作用

让我们说得更具体些，因为关于人工智能取代分析师的模糊说法对任何人都没有帮助。

智能体分析的最佳应用方式是增强而非取代组织现有的嵌入式商业智能和数据系统——它建立在已有的数据管道、语义模型和治理框架之上，使人工智能代理能够直接在公司现有环境中运行。关键在于“建立在……之上”。没有“直接部署人工智能”的捷径。基础设施必须先存在。语义层必须构建完成。业务逻辑必须编码完成。而且，必须有人来管理它。

正在消亡的是被动的、请求驱动的分析工作流程。智能体人工智能系统可以在几秒钟内完成分析，而分析师手动收集、查询和验证数据则需要两到四个小时。这种时间压缩并非意味着分析师变得无关紧要——相反，它使得分析师的机构知识，如果被正确编码到系统中，其价值将远超以往仅存在于他们头脑中的情况。

转变之处在于： 以前分析师的输出是一个查询语句，现在则是一个受控的定义，一百个用户无需提交任何工单即可同时进行查询。

智能体人工智能使数据分析民主化，让组织内的广大用户都能轻松获取数据——业务用户可以提出复杂的问题，并获得简洁明了、对话式的答案，而无需了解 SQL 或任何技术语言。这对领导者的影响显而易见。非技术背景的利益相关者现在有了一个可靠的替代方案，无需再向你的团队寻求帮助。如果你的团队没有构建确保答案准确性的智能层，其他人就会去做——更糟糕的是，人工智能可能会凭空捏造出一个听起来合理的答案。

领导者思维模式问题：关注结果还是关注原因

真正的问题在于此，我就直说了。

目前大多数数据领导者都处于观望状态。他们密切关注着通用商业智能（GenBI）市场的发展，等待观察哪些工具最终胜出，谨慎地开展试点项目，并告诉团队“人工智能将增强而非取代现有业务”。这种说法本身并没有错，但却是一种危险的被动姿态。这是一种等待外部事件明朗化后再确定方向的心态。

那些身居要职的领导者不会坐以待毙。他们做出了如下豪赌：他们组织中的语义层——即对业务指标实际含义进行编码、管理、机器可读的定义——是他们现在能够构建的最有价值的基础设施。而且，他们是在被迫之前就着手构建它。

这两种策略带来的结果差异将十分显著。将人工智能项目成果与可衡量的仪表盘挂钩的分析团队，将改变预算讨论的焦点——不再围绕工具成本，而是围绕可衡量的回报。这种转变将数据职能从成本中心提升为战略资产。率先展开这种讨论的领导者将主导讨论的走向。

身处事业之中意味着要做出那些在没有完全把握的情况下令人感到不舒服的决定：

在GenBI平台完全验证之前，将分析师的精力从报告撰写转移到语义层构建。
在自助查询模式全面投入运营之前，告知利益相关者被动式查询模式即将逐步停止运行。
在组织尚未完全理解原因之前，就通过智能基础设施重组团队角色和 OKR，降低每次洞察的成本。

这种不适感是走在时代前沿而不是落后于时代所要付出的代价。

重新思考组织设计：从服务台到智能基础设施

组织架构设计问题是大多数数据领导者遇到的瓶颈。当前的组织结构既熟悉又稳定，并且与利益相关者的关系紧密相连。要改变它，就必须正视组织结构本身存在问题这一事实。

如今大多数 BI 团队都是按照 领域相关的服务职能 构建的：

这种设计旨在优化对各个利益相关群体的响应速度。每位分析师都拥有一个队列、一组关系以及一套领域知识。问题在于，这三者——队列、关系和知识——都属于个人，而非系统。当分析师离职时，这些知识也随之流失。当队列增长时，系统会聘请另一位分析师。当利益相关方需要新的仪表盘时，则由工程师负责构建。

传统商业智能 (BI) 的局限性意味着只有经过培训的分析师才能获取洞察，或者需要 BI 团队的参与，而且报告反映的是历史数据，而非未来预测或可执行的建议。服务台模式在结构上无法改变这一点。它的规模与员工人数呈线性增长，并且只能生成特定时间点的快照，而非动态的智能层。

GenBI 时代的团队设计遵循不同的原则： 一次编码，处处可用。 但支撑这一理念的结构模型并非重新集中化的分析功能，而是联邦式结构。领域团队拥有各自的数据产品，而中央平台团队则拥有运行所有这些产品的基础设施。这就是应用于智能体人工智能时代的“数据网格”原则。

这个设计中有几点值得一提。

平台团队是赋能者，而非守门人。 其职责是提供基础设施、标准和工具，使领域团队能够独立构建和发布数据产品——包括语义引擎、GenBI 运行时、治理框架和数据目录。平台团队不拥有业务逻辑，业务逻辑属于各个领域。
每个领域团队都是一个全栈数据产品单元。 它包含语义知识（负责编码业务定义的专家）、构建能力（负责构建和维护转换层的分析工程师）以及对两者都负责的领域专业知识。如果商业团队对客户流失的定义有误，则由商业分析负责人负责，而不是由与业务背景相隔三层的集中式 BI 部门负责。
在这次转型中，分析工程师的角色最被低估。 在旧模式下，分析工程师是 dbt 开发人员——他们编写 SQL 转换、建模数据并构建分析师查询的干净表。在新模式下，他们是智能层本身的架构师。原因如下：一个成熟的 dbt 项目不仅仅是一个转换库，它是一个结构化、版本控制且文档齐全的知识库。每个 dbt 模型都有名称、描述、列级文档以及内置的业务逻辑测试。在 dbt 语义层中定义的每个指标（通过 dbt Metrics 或 MetricFlow）都是一个机器可读的业务定义，并附带一个血缘图。这正是 Vanna 和 Wren AI 生成准确、上下文相关的 SQL 所需的训练语料库。懂得如何将 dbt 项目作为 GenBI 训练源的分析工程师并非在做一份新工作——他们只是以更高的效率完成现有工作。他们不再构建分析师查询的模型，而是构建用于训练所有人都在查询的 AI 的模型。 dbt 存储库成为动态语义层，随着业务的发展不断更新，自动向智能层提供受管控的定义，而无需从头开始手动标注。
每个领域的分析主管都是一种新型角色。 他们并非负责协调分析师工作的经理，而是资深实践者，负责该领域语义层的产品开发，包括其覆盖范围、准确性、治理以及随着业务变化而不断演进。他们参与业务部门领导层的讨论，了解决策内容以及支持这些决策所需的定义。
跨域指标由统一的部门进行管理。 跨越多个领域的指标——例如公司总收入、综合客户获取成本、综合客户流失率——通过相关领域负责人参与的联合流程进行定义，并由平台团队的治理层批准。任何单一领域都无权单方面拥有这些指标。这是大多数数据网格实现方案设计不足的棘手治理问题，需要明确的设计而非假设。
从纸面上看，人员编制可能与现在差不多。但问责模式却截然不同。知识不再属于个人，而是属于版本化、文档化和管理化的领域数据产品。即使管理员离职，语义层依然保留。随着业务发展，领域负责人会更新定义。智能基础设施将成为组织资产，而非依靠机构记忆和Slack聊天记录维系的个人专业知识集合。

真正有效的技能提升计划

大多数组织中关于技能提升的讨论都缺乏正确的视角。领导者宣布启动“人工智能技能提升计划”，购买平台许可，并衡量在线课程的完成率。三个月后，分析师的行为却没有任何改变。

这种方法行不通，因为它把技能再培训视为学习问题。实际上，它是一个工作设计问题。

人们很容易急于在所有岗位上同时提升GenAI素养，但正确的方法是从业务成果入手，思考人工智能投资如何促进或加速这些成果的实现，然后再明确实现这些成果所需的技能。如果只注重技能而忽略成果导向的再培训，最终只会培养出证书收集者，而非真正具备实践能力的从业者。

以下是商业智能和分析职能部门进行转型时，有效的技能再培训的具体内容：

第一层级：面向所有分析师的人工智能素养（第 1-4 周）

团队中的每位分析师都需要对 GenBI 工具的运作方式有一个清晰的理解——不是如何配置，而是它们的准确性如何取决于底层语义层的质量。这是基础。如果没有这个基础，分析师就会把 GenBI 当作玩具，而不是他们负责构建和管理的系统。

实用形式：每周一次 90 分钟的工作坊——一部分讲解概念，一部分使用您的实际数据和 GenBI 平台进行实践操作。使用您自己的指标作为培训材料。标注您自己的查询。学习与实践密不可分。

第二层级：高级分析师的语义策展技能（第 5-12 周）

这才是真正技能提升的关键所在。高级分析师需要学习如何系统地将 SQL 知识转化为结构化的语义定义。具体技能包括：

编写精准的业务定义，消除歧义
识别并记录对指标的常见误解
对 GenBI 工具可作为训练数据接收的注释进行结构化处理
运行验证测试——使用利益相关者提出的相同问题查询 GenBI 层，比较输出结果，并进行迭代。

为期 12 周的课程可以将初级分析师培养成人工智能运维专家——对于拥有深厚领域知识的高级分析师来说，转型速度更快。他们的专业知识是原材料，课程教他们如何将其转化为实际应用。

第三层级：面向 GenBI 的分析工程（第 3-6 个月）

这是最直接、最具杠杆效应的技能提升发生的地方——也是大多数组织错失重大价值的地方。

已经使用 dbt 的分析工程师拥有一个尚未被广泛理解的优势。一个维护良好的 dbt 项目本身就是一个语义知识库。模型描述、列级文档、dbt 测试和 MetricFlow 指标定义都是结构化、机器可读且版本化的工件。Vanna 基于 RAG 的训练管道可以直接将 dbt 模型 YAML 文件作为文档源导入。Wren AI 的原生 dbt 集成意味着您可以连接现有的 dbt 项目，并完全跳过手动语义层设置——转换层本身就成为了训练语料库。

因此，分析工程师的技能提升并非从零开始学习新工具，而是学习如何编写以 GenBI 使用为导向的 dbt 文档：

模型描述应解释业务目的，而不仅仅是技术结构
列描述应定义业务含义，而不仅仅是数据类型
dbt 测试对每个指标的“正确”状态进行编码，并将失败结果作为语义层治理信号呈现出来。
MetricFlow 指标定义使业务计算更加明确、可重用且可供 AI 查询

一位分析工程师如果在整个数据库项目中系统地执行此操作，实际上就为 Vanna 或 Wren AI 预先构建了语义层。原本需要语义标注员花费数周时间才能从原始 SQL 数据中手动完成的标注工作已经完成——只需根据业务上下文编写合适的代码，即可用作 GenBI 训练数据。

此层级的学习工具：选取一个领域的数据库项目，审核文档完整性，重写模型和列描述以符合 GenBI 就绪标准，连接到 Vanna 或 Wren AI，并测量修改前后的查询准确率。差值即为概念验证。

什么因素加速了这三个层次的发展：

将技能提升与绩效目标直接挂钩。语义覆盖率、自助服务采用率和人工智能数据产品使用率是新的关键绩效指标 (KPI)。当职业发展取决于构建智能层而非处理查询时，分析师就能更快地适应新模式。

引入适当的激励措施可以激发员工的学习意愿，而让高管团队走在变革的前沿至关重要。如果数据副总裁仍然以仪表盘交付量和工单解决率来衡量团队绩效，那么无论技能提升计划的质量如何，最终都将以失败告终。

责任归属：当人工智能出错时，谁该负责？

这是大多数 GenBI 实施项目在出现问题之前都会回避的治理问题。但这个问题无法回避。

当业务用户向 GenBI 平台询问“我们上季度的转化率是多少？”却得到错误答案，并据此采取行动时，谁该为此负责？不是人工智能，也不是平台供应商。责任在于拥有生成该答案的语义定义的人。或者，如果没有人负责，那么责任就在于允许未经监管的人工智能输出结果传递给决策者的数据负责人。

这才是所有权真正发挥作用的地方，而不仅仅是激励作用。

语义层中的每个指标都需要一个负责人。该负责人负责：

业务定义的准确性
对支撑它的 SQL 进行验证
随着业务发展，需要定期审查该定义。
输出错误时的事件响应

这并非官僚主义，而是确保大规模部署 GenBI 系统可信度的最低限度治理结构。人工智能治理需要透明度、审批门槛和决策监控——这些措施确保人工智能代理以负责任的方式运行，与现有 BI 系统无缝集成，并交付可衡量的业务成果。

实际上，情况如下：

指标 注册表 ：一份动态文档（或者更准确地说，它本身就是一个受监管的数据产品），它将语义层中的每个指标映射到所有者、定义、上次验证日期以及负责签署定义的业务利益相关者。
语义 审查频率 ：每月或每季度，由审核员审查使用率最高的指标，根据当前的业务实际情况验证其定义，并标记偏离最初意图的指标。
查询 审计跟踪 ：GenBI 的每个输出都可追溯到生成它的语义定义——这不仅便于调试，还能满足受监管行业和财务职能部门所需的审计置信度。
在需要之前就构建好这一治理层的团队将赢得信任。而在事件发生后才构建的团队则需要花费数月时间才能恢复信誉。

衡量投资回报率：数据领导者需要的框架

大多数数据转型项目在第二年就夭折的原因并非技术故障，而是无法用首席财务官和首席执行官能够理解的方式阐明投资回报率。

“我们减少了分析师的工作量”不是一个商业案例。“我们在保持员工人数不变的情况下，将可决策范围扩大了5倍”才是。

以下是我用来衡量 GenBI 转型效果的 ROIC 框架：

一支中等规模的分析团队（8-12人）预计在12个月内总共需要投资30万欧元至60万欧元，其中包括过渡期间的生产力下降。

三个值流：

第一部分：分析师能力的恢复

追踪转移到自助服务的重复性查询百分比。如果您的团队目前每月处理 200 个临时请求，而自助服务吸收了其中 70%，那么您就释放了相当于 2-3 名分析师全职员工的产能。这些产能可以重新部署到语义层构建和 AI 产品开发中——从而实现收益的倍增，而不是仅仅通过裁员来获取。

第二部分：决策速度和质量

一项针对 500 家公司的 2025 年研究表明，智能人工智能系统可将任务完成时间缩短 34%，并将资源利用率提高 14%。对于那些洞察延迟会直接影响收入的业务职能——例如定价决策、营销活动优化和客户维系措施——这种时间缩短会带来可量化的损益影响。请与您的首席财务官合作，将决策延迟缩短一天所带来的收入与最具价值的应用场景挂钩。

第三部分：数据消费者规模

旧模型的扩展是线性的：增加一名分析师，活跃数据用户数量也会相应增加。新模型的扩展是指数级的：构建一个完善的语义层，就能吸引数百名活跃用户。将每周/每月活跃数据用户数 (WAU/MAU) 作为核心指标进行跟踪。如果您的团队目前服务于 50 位活跃数据用户，而 GenBI 层在 12 个月后服务于 250 位用户，那么您的每次洞察成本计算的分母就降低了 5 倍。这就是其商业价值所在。

ROIC 计算（示例）：

第一年投资：450,000 欧元；分析师产能回收：180,000 欧元（重新部署 3 名全职员工）；决策速度价值：200,000 欧元（保守估计，主要用例的延迟降低）；消费者规模价值：120,000 欧元（避免了未招聘分析师的成本）；第一年总回报：500,000 欧元；第一年投资回报率：11% ；第二年（复利增长）：持续投资：150,000 欧元（平台 + 维护）；回报（扩展层）：650,000 欧元；第二年投资回报率：330%+

第一年的投资回报率并不高——这对于基础设施投资而言属于正常现象。能够带来高投资回报率的团队从一开始就注重价值创造，而非为了学习而学习，并且着眼于整体转型，而非仅仅关注单一用例。第二年的回报体现了构建完善的语义层的复利效应。第一年标注的每个指标在第二年都无需任何维护成本。第二年新增的每个数据使用者也无需占用额外的分析师资源。

你应该和你的首席财务官谈谈：不是“我们需要为人工智能工具制定预算”，而是“我们正在构建一个智能基础设施，为更多决策者提供服务的边际成本接近于零”。

分析师现在需要做什么

如果你是以分析师而非领导者的身份读到这里——那么这一部分就是为你准备的。

我所描述的组织架构重塑并非假设，而是已经在一些快速发展的组织中实施。能够展现适应能力而非仅仅具备技术能力的专业人士正变得不可或缺——沟通能力、利益相关者管理能力和数据叙事能力正日益与硬技能一起出现在职位描述中。

能够在这种转型中脱颖而出的分析师都具备一个共同的特质：他们不把SQL知识视为可按需部署的个人技能，而是将其视为需要编码、管理和扩展的机构知识。这种转变的重点在于从“做事”转向“构建能够执行操作的系统”。

具体而言：

立即开始编码。 提取过去 90 天的查询记录。针对每个重复出现的指标，编写结构化的注释——包括业务问题、精确定义、常见误解以及经过验证的 SQL 语句。不要等到公司强制要求才开始。这是你的作品集，它能在正式设立语义注释员职位之前就展现你的相关技能。

学习工具，而不仅仅是概念。 在个人环境中搭建 Vanna 或 Wren AI 系统。向它输入你标注过的查询。测试它。找出它的问题所在。理解它在哪里失败以及失败的原因——因为这些失败总是源于文档的缺失，而弥补这些缺失正是语义策展人的核心工作。

重新定位你对利益相关者的价值。 如果分析师说“我来解答你们的数据问题”，那么他很容易受到攻击。但如果分析师说“我管理的系统能够可靠地解答你们的数据问题”，那么他就不会那么容易受到攻击。这种重新定位不仅仅是语言上的改变——它要求你真正去构建这个系统。但这种框架对于领导层如何看待你在转型过程中的角色至关重要。

要勇于承担责任。 指标所有权——即作为业务定义准确性的指定负责人——是一种新型的职业责任。它比编写仅供自己审核的查询语句更具风险性。要积极应对。那些承担情报层责任的分析师，将成为组织不可或缺的人才。