OpenClaw × Aloudata CAN：两个 Skill 让 AI 学会查数和归因 ​

全网都在教小龙虾点外卖，我们让它算清了 GMV 为什么跌。这篇文章是配套的上手指南——从安装到提问到进阶调教，手把手带你跑通。

OpenClaw GitHub: https://github.com/OpenClawAI/openclaw

我们把小龙虾接上了 Aloudata CAN 语义层。六轮对话，从「上月销售额多少」一路追到「江西电商渠道销售额环比下降 67%，主因是购买用户数从 28 断崖式跌到 8」，最后还自动生成了一份带因子拆解、城市下钻的 HTML 归因报告。

这篇文章主要回答看完 Demo 之后你大概率会问的三个问题：

1. 我自己能跑起来吗？——能，十分钟以内。
2. 它到底是怎么做到的？——两个 Skill + Aloudata CAN 语义层 API，不是魔法。
3. 我能改它、甚至自己写新的 Skill 吗？——能，而且这才是最有价值的部分。

01 | 十分钟跑起来 ​

你需要准备什么 ​

• 已安装的 OpenClaw（能正常对话）
• Aloudata CAN Demo 环境 API Key（文末申请）

安装步骤 ​

第一步：装 Skill

两个 Skill 已经发布到 ClawHub，用你自己习惯的方式来安装：

• metric-query: https://clawhub.ai/jackyujun/metric-query
• metric-attribution: https://clawhub.ai/jackyujun/metric-attribution

安装过程中如果出现安全提示，点击「仍然安装」即可（这是因为 Skill 需要 API Key 但未在配置中声明，不影响正常使用）。

第二步：配置 API Key

Skill 通过 Aloudata CAN Gateway 访问数据，Gateway 需要 API Key 做认证。把你的 Key 写到 OpenClaw 的环境变量文件 ~/.openclaw/env 里：

CAN_API_KEY=cgk-你的Key

写好后，重启 OpenClaw，然后开一个新 session。旧 session 不会自动拿到新的环境变量。

Skill 调用 Gateway 时会通过 X-API-Key 请求头自动带上这个 Key。Key 不会出现在 Skill 文件或对话记录中。

第三步：开始问问题

就这么简单。试试：「上月销售额是多少？」

你会连到什么数据 ​

Demo 环境是一个零售场景的数据集：

数据涵盖多个月份，足够你做各种同环比和归因分析。你可以直接问小龙虾「有哪些指标和维度？」，它会给你列明。

不用担心「问错了」——语义层已经定义好了所有指标的口径和计算逻辑，你用自然语言问，它翻译成结构化查询，不存在「写错 SQL」的可能。

02 | 两个 Skill，各管一件事 ​

很多人看完 Demo 以为这是一个大而全的「AI 分析师」Agent，其实不是。我们拆成了两个 Skill，各司其职：

metric-query：问数的 Skill ​

这个 Skill 只做一件事——把你的自然语言翻译成语义层的指标查询 API 请求。

你说「上月各渠道的销售额和环比」，它做的事情是：

注意第 1 和第 2 步——它不是凭记忆猜指标名和维度名的。每次查询前，它都会先去 Aloudata CAN 语义层的 Gateway 搜索，确认指标和维度确实存在。这就是为什么它不会「幻觉」出一个不存在的指标。

这个 Skill 支持的查询能力覆盖：

metric-attribution：归因的 Skill ​

这个 Skill 是一个诊断流程的编排器。当你问「为什么跌了」，它不是调一次 API 就完事，而是按照一套诊断逻辑走多个步骤：

Step 1 → 确认波动事实：变了多少？跟什么比？
Step 2 → 因子拆解：哪个业务环节出了问题？（如 销售额 = 用户数 × 客单价）
Step 3 → 维度归因：问题集中在哪个渠道、哪个地区、哪个品类？
Step 4 → 外部事件关联：有没有天气、促销、政策等外部因素？
Step 5 → 综合诊断报告：把所有发现串成一条因果链

每一步都会调用 metric-query 的查询能力取数据，然后在本地做归因计算（包括 Shapley 值分解），最后汇总成报告。

视频里那份深色主题的 HTML 归因报告，就是 Step 5 的产出。

为什么要拆成两个 Skill？ ​

因为查数和归因是两个频率完全不同的操作。

拆开之后，简单问题不走复杂流程，复杂问题有专门的方法论。这个原则不只适用于数据分析，适用于所有 Skill 设计。

03 | 怎么问，效果最好 ​

装好 Skill 之后，你会发现「怎么问」直接决定了回答的质量。这里是我们测试过程中总结的提问技巧：

查数：说清楚四件事 ​

小龙虾内部会把你的问题拆解成四个维度，你说得越清楚，它翻译得越准：

好的提问：

上月各一级渠道的销售额环比及占比情况如何？按占比从高到低排序。

效果一般的提问：

数据怎么样？

太模糊了，小龙虾不知道你要看什么指标、什么时间、什么维度，只能"虾"猜。

归因：给它一个业务公式 ​

如果你要做归因分析，最有效的做法是直接把业务公式告诉它。视频里那句话就是一个好例子：

江西环比下降这么多（销售额=购买用户数×客单价），生成一个归因诊断报告

括号里的公式告诉了小龙虾：销售额可以拆成两个因子来分析。有了这个公式，它才能判断「是用户少了还是价格低了」。

如果你不给公式，它也能做维度归因（按渠道、地区等维度看贡献度），但少了因子拆解那一层，分析深度会打折扣。

追问：跟着它的建议走 ​

你可能注意到小龙虾经常主动建议下一步——「要不要帮你看看是哪个渠道拖的后腿？」「要不要继续下钻江西？」

这不是客套话，而是它根据当前数据情况判断的合理分析方向。如果你不确定接下来问什么，跟着它的建议走通常不会错。当然你也完全可以无视它的建议，按自己的思路追问。

一些容易踩的坑 ​

04 | 它背后到底调了什么 API ​

如果你是工程师，可能想了解得更深一些。这一节拆解 Skill 背后的 API 体系。

Gateway：所有请求的入口 ​

两个 Skill 的所有请求都走一个 Gateway：https://gateway.can.aloudata.com

Gateway 内置了认证，你不需要在每次请求中手动传 token。Gateway 暴露了两类 API：

搜索类（用来找指标和维度）：

查询类（用来取数据）：

整个流程就是两步：先搜后查。每次查询前都先通过搜索 API 确认指标名和维度名的正确性，避免幻觉。

一条查询长什么样 ​

以「上月各渠道销售额及环比」为例，小龙虾构造的 JSON 请求体大概长这样：

{
    "metrics": [
        "retail_amt",
        "retail_amt__sameperiod__mom__value",
        "retail_amt__sameperiod__mom__growthvalue",
        "retail_amt__sameperiod__mom__growth"
    ],
    "dimensions": ["first_channel"],
    "timeConstraint": "DateTrunc(['metric_time'], \"MONTH\") = DATEADD(DateTrunc(NOW(), \"MONTH\"), -1, \"MONTH\")",
    "orders": [{"retail_amt__sameperiod__mom__growthvalue": "asc"}]
}

核心概念解释：

快速计算的命名规则 ​

语义层的快速计算用双下划线拼接在指标名后面，像搭积木一样：

指标名__对比基准__对比方式__计算类型

有一个重要限制：每个指标只能做一次快速计算，不能链式叠加。Skill 约束了小龙虾不能写类似 retail_amt__sameperiod__mom__growth__rankDense__desc__xxx（先算环比再排名）这样的代码。如果需要多步计算，会用临时指标定义（metricDefinitions）分步来做。

05 | 怎么调教和改造 ​

如果你不只是想用现成的 Skill，而是想根据自己的业务场景调整，这一节告诉你怎么做。

看懂 Skill 的结构 ​

Skill 本质上就是一份 Markdown 文档，里面包含了：

你可以把它理解成一份写给 LLM 的「操作手册」——LLM 读了这份手册，就知道怎么正确地调用 Aloudata CAN 语义层 API。

可以改什么 ​

怎么写一个全新的 Skill ​

如果你想针对自己的业务场景写一个新的 Skill——比如「毛利监控 Skill」「库存预警 Skill」——关键是想清楚三件事：

Skill 是纯文本文件，不需要写代码，不需要编译部署。改完之后重新加载就能生效。

06 | 已知的不完美 ​

这个 Demo 我们没花多少时间，也没太过精心编排，Demo 和小龙虾都会有些小瑕疵，在这里坦诚说说：

07 | 最后总结 ​

最深的感受 ​

小龙虾（OpenClaw）解决的是 Agent 的「执行力」问题——它能操作你的电脑、调用各种工具。但当我们让它去做数据分析的时候，我们发现它缺的不是手脚，而是业务常识。

「销售额」这个词，在你公司的口径里到底含不含退款？「客单价」是按订单算还是按客户算？「环比」是跟上月比还是跟上周比？

这些问题，LLM 不知道，也不该猜。语义层的价值就在于它把这些业务常识编码成了结构化的定义——指标怎么算、维度怎么分、口径怎么对——然后通过 API 暴露给 Agent。Agent 不需要懂你的业务，它只需要会调 API，语义层保证返回的数据是对的。

这就是为什么我们选择做 Skill 而不是做 Prompt。Prompt 是「教 LLM 怎么猜」，Skill + 语义层 API 是「让 LLM 不用猜」。

开始试试 ​