实践中的智能分析：Slack机器人、语义层以及购买服务与自主开发的选择。
科技公司的智能分析系统：能与数据对话的 Slack 机器人、需要扩展规模的语义层、收购 Omni 的决策，以及为何采用这些技术最为重要。
来源: My Experience Building Agentic Analytics at a Tech Company (And Shipping It to Stakeholders)
在各类供应商的推介中，代理分析技术随处可见：与数据对话、人工智能驱动的商业智能、语义层、第二代自助分析功能。几乎所有的分析产品都在竞相将人工智能应用到各个领域。关于这一趋势未来走向的观点屡见不鲜，但在真实企业中构建此类系统的案例却十分罕见，而对于一个更关键的问题——它能否经受住真实用户和实际需求的考验——的诚恳答案也同样少见。
以下便是这样一个案例，源自2025年底某中型订阅公司数据科学家的工作记录。它讲述了从零开始构建第一个用于与数据交互的Slack机器人、向实际用户推出该工具的过程、扩展语义层及其基础设施所带来的压力，以及团队在寻找企业级BI工具时所做的自行开发与购买之间的抉择。此后，同一位人士转行从事咨询工作，而他接触的几乎每家公司都在努力解决类似问题，这表明数据科学家确实存在广阔的发展机会。
在人工智能出现之前的关键决策
2025年初发生了一件当时看似与人工智能无关的事情。数据主管意识到有必要构建公司的第一个信息模型，于是聘请了一位经验丰富的数据工程顾问来牵头，同时每一步都会有两名数据科学家参与其中。
信息模型是定义数据结构、表格之间关联方式，尤其是各种指标含义的层级。可以将其视为公司内所有人在讨论数据时应当使用的共同语言。
技术层面相对简单，难点在于让所有人都认同这种语言标准。比如关于什么是活跃用户，不同团队会有不同答案：市场部有其一定义，产品部有另一定义，财务部又有第三种定义，而且每方都坚信自己的定义才是正确的。达成共识的过程既缓慢又繁琐，但这项工作却成了此后所有工作的基础。如果没有信息模型，直接在数据之上构建语义模型几乎肯定会弊大于利。
按需生成洞察
在信息模型逐渐完善的同期，这位数据科学家也经历了个人层面的转变。通过研究就业市场，他发现越来越多的企业需要人工智能相关技能，这促使他开始自学如何自动化处理日常工作中的某些任务：数据清洗工具、探索性分析工作流程，以及理解人工智能、数据及其背景之间的关联。
最初只是为了提升效率的尝试，后来逐渐发展成更重要的方向，即迈向“代理分析”（当时尚未使用这一术语）的进程——因为传统的分析方法已无法满足需求。由此诞生的最重要项目之一就是Slackbot。
其理念是打造一种介于仪表板与数据科学家之间的数据产品，用于处理那些本应容易回答、却又不值得专门构建新仪表板或重新设计现有仪表板的问题。并非所有问题都值得创建Jira工单。
没有人提出过这样的请求，也无需等待许可或批准。大部分内容都是独自开发的，作为原型，配有系统设计图以及给团队的简短演示。关键之举在于将其呈现为已经完成的产品，而非寻求启动批准的请求。这样既让团队几乎无需承担风险，也让开发者有机会展示具有实际价值的成果，足以赢得所需的支持。
逐步推广并了解人们的需求方式
首批用户是一个名为市场部的团队。这是有意为之：采用可控的逐步推广方式，而非全公司范围的上线，因为后者可能会导致难以掌控的问题出现。
预期的成果仅仅是实现更安全的发布而已。实际上，它揭示了许多非分析师提问的方式。营销人员会从业务问题的角度来提出问题，而非通过表格或指标定义，因此系统必须在这两者之间进行转换。分析师们往往会被自己的习惯所束缚。
从一开始就很清楚，这是一款数据产品而不仅仅是一个工具，因此文档、内部推广以及用户引导都亟需重视，因为这些因素决定了人们是否真的会使用所开发的产品。最初的几个月主要都在进行测试，而且测试量非常大。
接下来的发展
最终得到了一个最小可行产品，接下来需要决定该产品是否值得进一步投资，以及下一个版本需要做什么。以数据为基础构建系统并非最困难的部分。当问题转向如何让产品更实用时，讨论焦点便转向了机器人能够处理的数据范围，这就意味着需要扩展语义层。
团队随后问了自己一系列问题。第一层语义数据以YAML文件的形式存在Slackbot背后，那么它要如何扩展？多人如何共同协作处理？大家对于相关定义是否达成一致？
这些问题出现得恰逢其时，因为当时已经在考虑引入新的BI工具，毕竟现有的工具已显得不够现代化。讨论从改进Slackbot转向了是否需要真正的语义层，以及该语义层应是内置在BI工具中还是独立存在。
许多企业级BI产品，如Looker或Omni，都内置了语义层。对于这个团队而言，有一个明确要求：如果BI工具配备了语义层，那么该层不能被锁定，必须能够移植到其他工具中。正因如此，2025年9月发布的关于开放语义互操作性的声明——该声明承诺为语义层制定通用标准——才显得如此重要。
自行开发还是购买，以及为何其重要性不如表面看上去的那样
该公司最终选择了购买方案。选中的工具是Omni，它融合了Tableau、Looker的功能以及一些电子表格能力。2025年11月和12月期间对多个工具进行了评估，Omni于2026年初正式投入使用。
这听起来可能有些虎头蛇尾：一个关于从零开始构建Slack机器人的故事，最终却以购买现成产品收场。但许多数据科学家忽视了一个重要点：即便公司选择购买，之前积累的技能依然适用。构建那个机器人的过程为整合Omni提供了宝贵经验：提示词工程技巧、评估方法、MCP技术，以及对语义层功能的深入理解。
上下文工程就是一个很好的例子。它指的是在模型处理查询时控制其能够看到哪些信息：哪些表格、哪些指标定义、哪些业务规则。由于是从零开始构建整个系统，开发者清楚应该将什么信息呈现给模型，更重要的是，知道哪些信息应该排除。这种认知来自实际构建过程，而非阅读文档。
这些技能在面试中也会出现。自从进入咨询行业后，许多公司似乎更倾向于自行开发，主要是因为他们希望获得定制化的解决方案。因此，询问是否值得学习这些技能是个错误的问题。无论公司做出什么决定，都应学习这些技能，因为它们能帮助应对任何数据架构带来的挑战。
购买工具的不足之处
Omni是一款出自一家发展迅速的年轻公司的优秀产品，带来了极大的价值。最常出现的缺陷与MCP有关。
该公司仍有很大一部分工作依赖Google Sheets和Excel，而且这种情况短期内不会改变。他们的目标是将这些数据也连接起来，采用与其他数据相同的语义模型，这样某人在电子表格中的数字就能与其他地方的含义完全一致。通过MCP来实现这一点本是理想的，但实际并不可行。
该团队希望在语义模型与其后续使用环节之间拥有更多决策权：决定返回什么内容，以及允许哪些工具与之连接。如果拥有独立的语义层且其余部分都在内部开发，就能完全掌控API。这就是需要权衡的点，对许多公司而言，这将是决定性因素。在灵活性和完全控制权至关重要的情况下，仅购买产品可能不够；而在速度和即开即用的体验至关重要的情况下，像Omni这样的产品就能发挥巨大作用。
采用情况决定一切
这个话题值得专门写一篇文章。即便拥有世界上最先进的系统，如果人们不将其纳入工作流程并信任它，那也毫无价值，而这正是许多数据科学家所欠缺的。对于小型团队来说，抽出时间来使用这项技术确实困难重重，但他们依然十分重视产品的采用。他们所做的投资包括：
- 一套用于快速入职的视频系列，
- 几场面向全公司的演示，
- 为财务等关键团队举办的专门现场研讨会。
任何在内部推广人工智能工具的人，都应将其视为产品发布来对待。这意味着需要进行内部营销、培训，并在每个团队中培养支持该工具的推动者。否则，数月的辛勤工作最终只会变成另一个没人使用的工具。这项工作十分繁琐，也不会体现在任何仪表板上，但它却是让整个努力对职业发展产生意义的关键。
职业发展影响
Slack机器人、该工具的推广以及我在向智能分析转型过程中的领导角色，都带来了实实在在的成果：议价能力。这段经历为我争取晋升提供了支撑，最终我也获得了晋升。
这场争论的重点并非Slack机器人本身，而是关于如何发挥创造力、保持在行业前沿，进而利用这些优势创造出能提升公司实力的成果——在本案中，就是关于需求的洞察力。最令人印象深刻的一点是：没人要求这些成果，也无需有人指导相关工作。管理者会将此视为资深度的体现。
既能构建此类系统，又懂数据且了解业务的人实属罕见，各公司也都明白这一点。这也解释了后来转向咨询业务的原因——因为那些能从系统层面思考人工智能而非仅依靠临时性对话引导的数据科学家需求正在迅速增长。
核心要点
智能分析技术已经在实际应用中，而非未来才会出现的事物。各企业正在不断尝试、推广这些技术，并探索哪些方法有效。数据科学家应当积极参与其中。无论企业选择自行开发还是购买相关技术，这些技能都能得到应用：它们能提升当前岗位的价值，增强晋升机会，还能在面试中脱颖而出。
这一切都始于业余时间制作的原型、系统设计图以及为团队准备的简短演示。等待他人提出相关需求是错误的做法，主动规划自己的成长才是更好的途径。
相关阅读
- 实用指南：构建可用于生产环境的智能欺诈检测系统 — 详细介绍了构建可用于生产环境的智能欺诈检测系统的步骤，包括相关合同、检查项以及供团队直接使用的代码模板。
- AI智能体时代的初创公司Web技术栈：Next.js、MUI与Firebase — 在智能体负责编写大部分代码的情况下，哪些工具依然适用？本文介绍了Next.js、MUI、Firebase、Vercel、PostHog以及简化的智能体设置方案，并说明了每种工具的选用理由。