企业AI助手最容易死在演示之后

很多企业 AI 项目死在演示之后。第一次看 Genie One 回答业务问题，画面通常不错：自然语言提问，答案带引用，底层是受治理的数据。第二次、第三次，用户还会不会打开，才是问题。

Databricks 博客作者 Josh Rosenberg 在 这篇 Genie One 企业落地 playbook 里，把这个过程拆成了几个阶段。原文来自 Databricks 推文：链接。它讨论的是 Genie One，一个面向业务用户的数据智能 AI 同事：用户用自然语言提问，拿到基于受治理数据、带来源引用的答案，再继续推进多步工作。

开头那个场景很具体。区域销售总监想知道东北区 pipeline 为什么变软。她不需要仪表盘，她需要一个答案。她给唯一知道可信数据在哪的分析师发消息，对方已经积压三个请求。答案周四到，决策已经做完了。Genie One 想补的就是这段延迟。

但演示容易，默认使用很难。Databricks 的判断是，模型通常不是决定因素。决定因素是工具懂不懂业务，以及推广有没有触达真正需要它的人。

演示之后的坎

AI 推广常见的翻车方式很一致：第一周铺十几个数据域，四个团队对“活跃客户”有四种定义，语义层没有明确 owner，也没有机制验证答案对不对。用户第一次看到错误答案，信任就掉了。

所以方案是排序。先窄问题集，先一小批早期用户，按反馈改语义，再扩到更多业务线。这个说法不新，但顺序清楚。

四块积木

Databricks 把 Genie 的企业落地拆成四部分：

• Genie One：业务用户的主入口，提问、拿带引用的答案、执行后续动作。
• Genie Agents：限定领域的 agent。比如合同分析 agent 可以从 PDF 里抽续约日期，关联收入表，再标出风险账户。
• Genie Ontology：把业务术语、指标和关系映射成一张活的图，按来源权威性加权。团队通过 metric views、Pages、Domains 治理关键概念，其余部分由 Genie 推断。
• Unity Catalog：治理底座，在查询时执行权限、掩码、血缘和审计。Genie Ontology 还把权限执行扩展到第三方应用和数据。

先把问题集写出来

Phase 0 大约 1 到 2 周，目标是证明数据和洞察能通过 Genie 变得可访问。动作包括：
选一个团队和一组明确问题。销售运营的 pipeline 健康度就是典型：漏斗里有什么、什么移动了、什么有风险。
定义语义层。顺序是 Domains、Metric views、Pages。Domains 先建，因为 Pages 必须属于某个 domain。Metric views 覆盖 10 到 20 个大家经常争论的数字，比如 bookings、pipeline coverage、win rate、stage conversion。定义写一次，查询时仍可按销售、区域、季度切。Pages 解释数字背后的概念，比如“合格商机”的定义、别名、依赖资产。Genie One 会优先查 Page，并在答案里引用，方便别人核对。
分配 owner。每个 catalog 资产、ontology 片段、agent 都要能追到负责的人或团队，而且要有修复路径。纸面 ownership 没用。
做治理和可观测性。给试点用户账号级权限，工作区级 Consumer access entitlement，按组授予 Unity Catalog 对象权限，比如 metric views 背后的 SELECT，再给一个 SQL warehouse 的 CAN USE。确认列掩码，开审计日志，开 Ontology Snippets，开 Unity Gateway 的用量和成本控制。五个人时做这些，比五百人时做容易。
定义什么叫好。记录 25 到 50 个团队真实问题，并写下已知正确答案。自己都答不出来的问题，也没法给 Genie 判卷。试点前用问题集打分，语义层每次改动后再打分。答错的地方往往指向语义缺口，不一定是模型问题。pipeline coverage 看起来不对，可能只是没人把它定义成 metric view，Genie 用了一个合理但错误的补丁。

试点看行为，不看掌声

Phase 1 持续 4 到 6 周。找 5 到 10 个愿意说真话的试点用户。每周评估，记录错误答案和“我不知道”，追根因：缺定义、列名歧义、ontology 缺口。提前定退出标准：准确率达到你敢拿来做真实决策的线；试点用户不用催就会用 Genie 替代旧流程；定义修复 backlog 在缩小。最清楚的成功信号是行为：试点用户把 Genie 的回答转发给同事，而不是继续提分析请求。

扩张前先看定义会不会漂

Phase 2 在下一季度扩到 2 到 3 个相邻域。每个域有自己的语义、owner、评估集，复用 Phase 1 模板。共享定义提升到 ontology，团队特有定义留在自己的 domain。加一个轻量评审流程：新团队通过评估线，再通过权限、掩码、敏感列的治理检查。给每个 Page 定 owner 和评审节奏，review metric view 变更。定义漂移不会只产生一个错误答案，它会在所有引用处传播。社区也重要：Slack 频道、月度 office hours、一份如何提问的短指南。采用往往靠同事说它有用，公开频道让这件事可见。

全组织上线时，治理要能管到工具

Phase 3 是组织级。开账号级 Genie One 访问，需要时跨工作区。开自动身份管理，按身份提供方里的组授权，用户首次登录就到位。加 workspace instructions，给聊天设回复规范。所有权联邦化：中央平台团队管 ontology、标准、护栏；领域团队管自己的 agent 和定义。全集中会排队，全不管会出现互相矛盾的 agent。用 Unity Gateway 管 Genie One 能触达什么：MCP server 变成可授权对象，tool filtering 收窄可调用工具，service policies 检查输入输出。入口跟着人走：iOS、Android、Slack、Teams、Excel、Google Sheets，或者用 Genie MCP App 接入别的 agent。

时间表不激进

Phase 0 用 1 到 2 周。Phase 1 试点 4 到 6 周。Phase 2 扩张放在下一季度。Phase 3 组织级再往后 1 到 2 个季度。证据够了再进下一阶段；试点还在补定义，就多花时间。

这篇 playbook 最值得记的是那个行为信号：先让一个团队愿意把答案转发给同事。做到这一步，再谈全组织。