Genie One 企业级推广分步 playbook

一位区域销售总监想知道为什么本季度东北地区的销售管道看起来疲软。她不需要仪表盘；她需要在下次会议之前得到一个答案。于是她做了她一直做的事情：她给那位知道可信数据在哪里的分析师发消息，而这位分析师已经积压了三个请求。她将在周四得到答案，这意味着她将在没有答案的情况下做出决定。

Genie One 正是为了弥合这一差距而构建的，让你用通俗语言提出问题，获得基于受治理数据并有来源引用的答案，并在几分钟内启动随之而来的多步骤工作。

描绘这一愿景很容易。更难的部分是让财务、运营和销售部门默认将 Genie 作为他们首选的 AI 同事。而工具能否扎根与工具能否失败的差别几乎从来不在模型；而在于工具是否了解你的业务，以及推广是否真正触及需要它的人。

为什么 AI 推广会停滞

当组织试图一次做太多事情时，AI 转型工作可能会停滞：第一周就涉及十几个数据域，四个团队对"活跃客户"有四种不同的定义，语义层没有指定负责人，也没有验证答案是否正确的机制。

而当用户确实看到错误答案时，他们会很快失去信任。

解决办法是对你的推广进行排序。从一组狭窄的问题开始，用少数早期采用者赢得信任，根据他们的反馈采取行动，然后有意识地扩展到更多业务线。遵循这些步骤有助于用户养成使用新工具的习惯，让他们看到价值并更有可能采用。

如何向业务用户推广 Genie

面向业务用户的 Genie 推广包含四个组成部分，随着采用的增长，每个部分承载不同的权重：

Genie One是主要的业务用户体验：一位精通数据的 AI 同事，人们在这里提问、接收有引用的答案并采取行动。

Genie Agents是范围明确的、特定领域的智能体。一个范围限定于合同分析的智能体可以从 PDF 中提取续约日期，将其与你的收入表关联，并标记有风险的账户，全部一次完成。

Genie Ontology将业务术语、指标和关系映射到一个活的图中，按权威性对来源进行加权。你通过指标视图、Pages 和 Domains 来治理最重要的地面真值概念。Genie 推断其余部分，覆盖你永远无法手工完成记录的角落。

Unity Catalog是治理基础。它在查询时强制执行权限、掩码、血缘和审计，因此用户和智能体只能访问授权数据。Genie Ontology 还将权限执行扩展到第三方应用程序和数据，从而实现真正统一的治理层。

第 0 阶段：基础工作，在试点之前

目标：证明你的数据和洞察可以通过 Genie 变得可访问。

在这里投入一周时间将为你的团队长期成功使用 Genie 奠定基础。以下是团队应遵循的一般步骤：

1. 从一个团队和一组明确的问题开始。选择一个有反复出现、当前令人痛苦的需求的团队。比如说它是销售运营，问题集是销售管道健康状况：漏斗里有什么、什么移动了、什么有风险。
2. Domains是按业务目的组织资产的方式。设置一个 Sales Ops 域，机会表、销售管道仪表盘和 Genie Agents 都放在人们寻找它们的地方。先做这一步，因为 Pages 必须属于一个域，否则你就会被卡住。
3. Metric views覆盖人们争论的 10 到 20 个数字。预订量、销售管道覆盖率、赢单率、阶段转化率。你编写一次度量，人们在查询时仍然可以按销售代表、地区或季度进行切分，这意味着每个人都从相同的定义中提取数据，而不是从他们的仪表盘恰好硬编码的任何内容中提取。
4. Pages是你解释这些数字背后概念的地方。一个关于"合格机会"的 Page 包含定义、人们称它的其他名称，以及它引用的资产。Genie One 会在猜测之前找到它，并在答案中引用该 Page，以便任何人都可以检查你的工作。

分配负责人。每个目录资产、本体片段和智能体都应追溯到一个负责任的人，无论那是个人还是拥有真实受理路径的团队。集中式语义团队在这方面做得很好。出问题的是那种纸面上存在但当定义漂移时没有修复途径的所有权。建立治理和可观测性。在账户级别为试点用户配置权限。在工作区级别授予用户 Consumer access entitlement，并通过组授予资产权限，例如对你指标视图背后的 Unity Catalog 对象的 SELECT 权限，以及一个 SQL 仓库的 CAN USE 权限。确认列掩码。启用审计日志。打开 Ontology Snippets，并打开 Unity Gateway controls以获得使用情况和成本可见性。最好在影响范围是五个用户而不是五百个用户时做这件事。定义什么是"好"。记录团队提出的 25 到 50 个真实问题，并附上已知正确答案。对于销售运营："我第三季度的覆盖率是多少"、"哪些交易滑出了本季度"、"EMEA 的赢单率与去年相比如何"。如果你自己都无法回答这些问题，你也无法给 Genie 的答案评分。在试点之前以及语义发生任何更改之后，根据你的问题集对 Genie 进行评分。这里的失误才是有用的部分，因为它们表明所定义语义中可能存在缺口。Genie 返回了一个看起来不对的覆盖率？这通常不是模型的问题。从来没有人把销售管道覆盖率定义为指标视图，所以 Genie 用一些合理但错误的东西填补了空白。每一次失误都是指向下一件值得治理的事情的指针。

第 1 阶段：首个团队试点

目标：证明 Genie Agents 在一个领域内向一个小而积极参与的群体提供可信的答案。

• 招募 5 到 10 名试点用户，他们将提供坦率的反馈。
• 每周运行一次评估。记录每一个错误答案和每一个“我不知道”，然后解决根本原因——通常是缺失的定义、有歧义的列或本体中的缺口。
• 准确率稳定在一个你愿意据此做出真实决策的水平上。
• 试点用户无需被要求就会优先选择 Genie，而不是他们旧有的工作流程。
• 待修复的定义问题积压正在减少，而不是增加。

第一阶段奏效的最明显迹象是行为上的：试点用户通过转发 Genie 的回复来回答同事的问题，而不是提交请求。

第二阶段：扩展到相邻团队

目标：证明智能体可以扩展到你的首个试点之外。

• 增加两到三个相邻领域，每个领域都有自己的语义、负责人和评估集。复用第一阶段的模板。
• 将共享定义提升到本体中，使“收入”和“活跃客户”在每个智能体中含义一致。将团队特有的定义保留在各自的领域中。
• 添加一个轻量级评审工作流。只有在负责人通过评估门槛以及涵盖权限、掩码和敏感列的治理检查后，才扩展到新团队。保持轻量。
• 留意漂移。为每个页面指定负责人和评审节奏，并审查指标视图的变更，而不是事后才发现它们。一个偏离其源查询的定义不会只产生一个错误答案；它会在所有引用该定义的地方传播错误答案。
• 建立一个社区。一个专门的 Slack 频道、每月办公时间，以及一份关于如何提出有效问题的简短指南。采用会通过同事反馈说它有效而传播，而公共频道是让这一点变得可见的最有效方式。

第三阶段：组织范围的 AI 同事

目标：让 Genie One 成为你团队中默认的 AI 同事。

• 推出账户级别的 Genie One 访问权限，让人们获得一个跨领域的 AI 同事，并在适当的情况下具有跨工作区的覆盖范围。开启自动身份管理，并针对你已在身份提供程序中维护的组进行授权，这样用户首次登录时就会出现。
• 添加工作区指令，让每次聊天对话都有关于聊天应如何回应的指南。
• 联邦式所有权。中央平台团队拥有本体、标准和护栏；领域团队拥有他们的智能体和定义。把所有东西集中起来会形成排队；什么都不标准化则会产生相互矛盾的智能体，侵蚀信任。
• 治理 Genie One 可以触及的范围。Unity Gateway将治理扩展到数据之外，延伸到 Genie One 使用的工具。MCP 服务器成为你可以在其上授权的安全对象，工具过滤缩小 Genie 可以调用的范围，服务策略检查传入和返回的内容。
• 在人们工作的地方与他们相遇。为使用 iOS 和 Android 应用 的用户启用访问，让他们可以在移动中与 Genie 聊天；如果他们更喜欢在 Slack、Teams、Excel 或 Google Sheets 中工作，你可以将 Genie 嵌入这些工具，让他们在上下文中提问。或者，如果他们已完全标准化使用另一个智能体，可以使用 Genie MCP App 来确保他们继续受益于 Genie 本体。

一个现实的时间线

• 第 0 阶段：1 到 2 周
• 第 1 阶段试点：4 到 6 周
• 第 2 阶段扩展：下一季度
• 第 3 阶段组织范围：再之后的一到两个季度

当证据表明你已准备好时，就进入下一阶段；如果试点需要更多时间来理清定义，那么利用额外时间来确保更顺利的推广是合理的。

从一个团队开始

做对这件事的团队通常不是那些拥有最干净数据或最大平台组织的团队。他们从一个团队、一个有治理的领域，以及一组他们愿意接受评判的问题开始，把它做通，并从中赢得扩展的空间。

查看 Genie 文档，今天就着手设置你的第一个 Genie Agent。