WorkBuddy Integrates with Aowei BI: Complete Enterprise Data Analysis Through Chat

当 AI 开始调用真正的企业 BI，"上传 Excel 让它写份报告"这件事就该翻篇了。

• 接入方式：MCP 连接器 —— 标准协议，无需改造 BI 权限体系

• 数据流向：数据不出域 —— 查询指令进系统，结果原地返回

• 分析口径：全局统一 —— 指标统一定义，结论可下钻复核

• 交付形态：对话即报告 —— 一句话提问，图文分析直接产出

配置好 MCP 连接器后，WorkBuddy 就能直接调用奥威BI 的数据能力。业务人员不需要下载数据、不需要打开 BI 门户，只需在对话框里说出业务问题——比如"分析去年公司经营风险"——就能拿到一份口径统一、数据可溯源的图文分析报告。

核心差别只有一个：数据在企业自己的系统里，分析能力也接在企业自己的系统上，而不是把数据复制到个人电脑里。

一、背景：为什么"上传 Excel 给 AI"注定做不好

过去一年，"用 AI 做数据分析"几乎成了企业数字化的新标配。落地到具体动作上，主流做法通常是这样：业务方从 ERP 或数据库里导出一份 Excel，丢给 AI，让它"分析一下"，然后拿到一份图表精美、结论像模像样的报告。

这套流程在演示时总是很惊艳，但它有三个绕不开的问题。

（一）数据是"切片"，不是"全貌"

一个部门导出的 Excel 只包含他关心的那几张表、那个时间范围。而经营分析从来不是单点问题——毛利率下滑可能来自价格政策、可能来自原材料成本、也可能来自产品结构变化。只看切片得出的结论，方向对了，路径却可能错。

（二）口径不统一

同一个"销售额"，财务口径按开票确认，运营口径按发货确认，BI 口径可能按回款确认。三个数字摆在三份报告里，谁也说不清哪个对。企业一旦开始争论"以哪个数为准"，AI 生成再多次也是消耗。

（三）数据出了门

客户名单、报价、成本结构、供应商信息，这些内容在 Excel 被复制出去的那一刻，就已经脱离了企业的权限体系、审计体系和保密边界。

于是就出现了视频号评论区里那种典型的尴尬：报告做得很漂亮，但决策不敢用。

"精美但错误"，往往不是模型不够聪明，而是喂进去的数据本身就不完整、不一致、不安全。

二、核心概念：MCP 连接器解决了什么

MCP（Model Context Protocol，模型上下文协议）是当前主流的 AI 工具连接外部能力的方式。它的作用很简单：给 AI 一个标准接口，让它能够安全地调用外部系统的数据和功能，而不是靠人工搬运文件去"喂"它。

把这个机制用在 WorkBuddy 和奥威BI 之间，得到的调用链路如下：

• ① 业务提问 · 业务人员：用业务语言描述问题，例如"分析去年公司经营风险"

• ② 意图理解 · WorkBuddy：组织分析逻辑，规划取数与计算路径

• ③ 数据调用 · MCP 连接器：通过标准接口发起查询，附带调用方身份与权限边界

• ④ 取数计算 · 奥威BI：按统一指标口径完成计算，并生成配套图表

• ⑤ 报告呈现 · WorkBuddy：组织成图文分析报告，输出结论与依据

说明：调用链路由 WorkBuddy 发起，奥威BI 在企业内网中完成取数与计算，数据不发生跨系统搬运。

这条链路里最关键的一点是：数据没有移动，动的只是"查询指令"。奥威BI 在企业内网中完成取数与计算，把结果按调用方的权限返回给 WorkBuddy 呈现。整个过程中，没有一份完整的经营数据落到任何人的个人电脑上。

相比之下，"上传 Excel"的模式是先把数据搬出去，再让 AI 猜；MCP 模式是让 AI 去企业数据所在的地方问。这是两种完全不同的安全模型。

三、落地实践：三步接入

整体接入路径分为三步：先确认 BI 侧的数据能力，再完成连接器配置，最后用业务语言直接提问。三个步骤依次递进，前一步不通，后一步也无法稳定运行。

（一）第一步：确认 BI 侧的接口能力

奥威BI 对接企业既有业务系统（典型的如金蝶云·星空、金蝶 K/3 WISE，以及用友等 ERP），把分散在各系统中的经营数据统一到 BI 侧。这一步是整个链路的数据地基：统一数据模型 + 统一指标口径，让"销售额""毛利率""库存周转"这类指标在全公司只有一种算法。

（二）第二步：在 WorkBuddy 中配置 MCP 连接器

在 WorkBuddy 的连接器管理中新增 MCP 服务，填入奥威BI 提供的服务地址与认证信息。连接器配置文件位于 ~/.workbuddy/mcp.json，配置完成后需要手动信任该 MCP 服务并启用。

注意：MCP 服务不会自动生效。写好配置之后，需要在连接器管理页面右上角的自定义连接器入口里，对新服务点击"信任"，这一步做完，WorkBuddy 才真正具备调用奥威BI 的能力。

（三）第三步：直接用业务语言提问

连接就绪之后，没有培训成本，也不需要学习 BI 产品的菜单结构。直接在对话框里输入一句话，例如：

"奥威BI，分析去年公司经营风险"

一段时间后，一份图文报告就出来了。

这里的关键在于提问方式。给 AI 的指令不需要是精确的查询语句，用业务语言即可——"去年经营风险""哪些客户在流失""哪个产品线毛利在掉"。奥威BI 负责把业务语言翻译成对统一指标体系的准确查询，WorkBuddy 负责组织分析逻辑并把结果讲成人能读懂的话。

四、关键价值：三个"不一样"

与"上传 Excel 给 AI"的做法相比，这套方案在数据安全、分析口径与能力边界三个方面存在本质差异。

（一）数据安全不一样

• 数据流向：上传 Excel 模式是把数据复制出企业系统；MCP 连接器模式是查询指令进企业系统，数据原地返回

• 数据落点：上传 Excel 模式落在个人电脑或第三方 AI 服务；MCP 连接器模式留在企业内网 BI 平台

• 权限控制：上传 Excel 模式依赖导出权限，导出后失控；MCP 连接器模式调用即鉴权，按角色返回

• 可审计性：上传 Excel 模式难以追溯谁看过哪份数据；MCP 连接器模式调用链路完整留痕

说明：权限边界由连接器认证信息与 BI 侧权限体系共同约束，AI 的可见范围与调用者的授权范围一致。

（二）分析口径不一样

在统一指标体系之下，AI 生成的每一个数字都可以被追溯到具体的计算规则和数据来源。这意味着 AI 的产出不再是"参考"，而是可以直接进入经营会议的数据依据。

这一点对企业极其重要。AI 分析的价值不在于"帮领导写出一份好看的 PPT"，而在于把过去要三天才能做完的归因分析，压缩到一次对话，并且结论经得起财务和业务的双重追问。

（三）能力边界不一样

Excel 模式里，AI 只能看到你给它的东西。MCP 模式下，AI 能调用的是企业完整的 BI 能力——不只是取数，还有指标计算、多维分析、图表生成、权限校验。这意味着分析深度不再受限于"你这次导了几张表"。

五、常见问题

以下是企业客户在评估阶段最常提出的几个问题。

Q：接了 MCP 之后，AI 会不会随便乱查数据？

不会。调用权限由连接器的认证信息和 BI 侧的权限体系共同约束，AI 能看到的范围与调用者的授权范围一致。

Q：我们数据还在金蝶 K/3 WISE 里，还没上 BI，能用吗？

可以。奥威BI 的价值恰恰在于承接这类存量系统——通过数据接口把金蝶云·星空、K/3 WISE 以及用友等 ERP 的数据统一接入并建模，之后 AI 通过 MCP 调用的就是已经治理好的数据。这是先补数据地基、再开放 AI 能力的正确顺序。

Q：AI 生成的结论如果错了怎么办？

这恰恰是统一口径的意义所在。因为每个数字都能下钻到明细数据，结论是可复核的——如果 AI 的归因不成立，展开明细就能立刻看到问题出在哪。可被证伪，比看起来正确重要得多。

Q：业务人员需要培训吗？

不需要额外培训 BI 操作。用自己的话提问，是每个业务人员本来就具备的能力。真正需要培训的是 BI 管理员——指标怎么定义、数据模型怎么建。

六、总结：什么场景该用这个方案

适合：

• 已经部署了奥威BI 或已有明确 BI 平台，希望让 AI 真正用上企业数据的企业

• 经营分析需求高频、跨部门数据分散在多个 ERP 系统的制造与流通企业

• 对数据安全、权限隔离有明确合规要求的行业

需要先打理的：

• 指标口径尚未统一的，先在 BI 侧完成数据建模与指标定义

• 数据仍在老系统且未做接口对接的，先完成 ERP 到 BI 的数据接入

一句话总结：把 AI 接进企业数据的能力链，而不是把企业数据接进 AI。前者让分析建立在企业自己的数据资产和权限体系之上，后者只是让 AI 拿着一份复印件说话。

WorkBuddy 终于能调用 BI 了。这句话背后真正的分量，不在于省了几步操作，而在于企业级数据分析的门槛，降到了"会说话"这个程度。