界面截取自翼仓真实运行环境，客户名称与账号信息已做脱敏处理，成交类数据已模糊
不是没有数据，是数据不能直接用
平台后台给你的是「订单记录」，业务需要的是「昨天的成交、退货和 ROI」。中间这一步，过去全靠人拼。
六个后台，六套口径
同一个「成交额」，天猫含运费、京东不含、抖音扣完达人佣金。跨平台汇总时，第一件事永远是开会吵口径。
取数要排队
业务想看一个数，先提需求、再等开发写 SQL、然后核对字段。三天后报表出来，活动已经结束了。
大模型很聪明，但读不到你的表
把 AI 接进业务，卡住的多半不是模型，而是没人愿意把库存、成本、毛利这些表以可控的方式开放出来。
权限一放就乱，一收就瘫
数据全开放，离职当天就是风险；收得太紧，店长连自己店铺的毛利都看不到，报表最后又回到微信群里传 Excel。
四层结构，从后台页面到一句问答
接入、明细、聚合、服务，每一层只做一件事。上层不关心数据从哪个平台来，下层不关心谁在用。
聚合层按天增量构建，宽表字段可追溯到底层明细；自定义指标不改底层结构，只改视图。
我们替你把数据，准备到能用为止
通用数仓给的是工具，翼仓给的是已经按电商业务摆好的表。
多平台统一接入
店铺授权、平台账号、采集设备三种方式并存。有接口的走接口，没接口的用采集设备补齐，老系统也能进仓。
主题宽表开箱即用
店铺、SKU、订单、分类、型号、周度六类聚合宽表按天生成，销售、流量、推广、客服、目标数据并排在一行里。
口径与成本治理
SKU 成本配置、类目映射、店铺目标、数据校验规则统一维护。口径写在系统里，而不是某个人的 Excel 备注里。
RAG 知识库
文档、分块、知识条目、客服蒸馏候选都进同一套库，问答有出处、有度量快照，AI 答错能追到原文。
API / MCP 双通道
业务系统用 REST 拿数据，AI 客户端用 MCP 拿数据。同一套权限、同一套口径，不需要各维护一份。
登录、操作、异常全留痕
登录日志、操作日志、异常日志、数据变更差异分开记录。谁在什么时候导出了哪张表，查得到。
一张宽表，
把「卖了多少」拆成十二个问题
平台后台按动作记录，宽表按经营视角组织。销售域、商品域、流量域、推广域、目标数据、类销数据并排在一行， 同一张表既能看趋势，也能下钻到型号。
- 按天增量：每日自动构建，历史可回溯，补数不用重跑全量。
- 域字段分组：销售 / 商品 / 流量 / 推广各自成组，取数时按需选择，不用在几十个字段里翻。
- 组织可归属：每行带事业群、事业部与店铺归属，同一张表按组织切分后可直接下发给不同团队。
业务系统要数据，一行请求就够
不自建一套取数逻辑，也不再让人每周导一次表。接口按数据集授权，密钥绑定到具体账号与租户，随时可吊销。
- 数据集授权：接口能取哪几张表、哪些字段，写在密钥的授权范围里。
- 身份可绑定：每个密钥绑定一个账号与租户，调用即留痕，离职回收一步到位。
- 结果可缓存：宽表只增不改，同一区间重复查询走缓存，报表刷新不再拖垮业务库。
- 限流与配额：按密钥设置频次与单次返回行数上限，防止一个脚本把数据全拖走。
同一把密钥在 REST 与 MCP 通用，撤销后两条通道同时失效。
# 取 11 月各店铺的经营指标 curl -X POST https://dw.jcbbi.com/api/v1/metrics/query \ -H "Authorization: Bearer $WV_KEY" \ -H "Content-Type: application/json" \ -d '{ "dataset": "shop_daily_wide", "metrics": ["gmv", "refund_amt", "ad_cost", "roi"], "dimensions": ["shop_id", "stat_date"], "filters": { "stat_date": ["2026-11-01", "2026-11-13"] } }' # 返回 { "code": 200, "rows": [ { "shop_id": "S-1024", "stat_date": "2026-11-12", "gmv": 1284600.00, "refund_amt": 32100.00, "ad_cost": 214300.00, "roi": 5.99 } ] }
示例域名为占位写法，实际接口地址、数据集名称与字段以部署环境为准。
让 AI 直接查数，而不是猜数
翼仓内置 MCP 服务：Claude、Cursor、自建 Agent 接上就能用自然语言取数。AI 走的仍是同一套权限，越权字段直接报错，不是「悄悄给个大概」。
- 五个工具够用：列表、取字段、查指标、受限查询、检索知识库，不把整库暴露给模型。
- 口径随结果返回：每次查询附带指标定义与统计区间，AI 转述时不会把「成交额」说成「支付金额」。
- 只读、不写回：MCP 通道对业务数据只读，AI 无法修改订单、价格与库存。
- 同样留痕：AI 的每次取数与人工一样记入操作日志，可按密钥、按账号回溯。
{
"mcpServers": {
"wingvault": {
"type": "http",
"url": "https://dw.jcbbi.com/mcp",
"headers": {
"Authorization": "Bearer ${WV_MCP_KEY}"
}
}
}
}
# 可用工具
list_datasets 列出当前账号可见的数据集
get_dataset_schema 取某数据集的字段与口径说明
query_metrics 按指标 + 维度 + 时间查询
run_sql 受限 SQL（只读、行数上限）
search_knowledge RAG 知识库检索，返回出处
一句提问就该有答案：
「这个月每个店铺的 ROI 是多少，哪三个掉得最多？」→ AI 调用 query_metrics，返回排序结果与口径说明。
权限收到字段，
才敢把数据放开用
很多系统能管到「能不能进页面」，翼仓还要管「能看到哪些行、哪些列、能不能导出、能不能走接口」。 四层收口之后，数据可以放心地交给一线用。
- 租户隔离：集团、子公司、服务商各自独立，跨租户不可见。
- 数据范围：全部 / 本部门及以下 / 本部门 / 仅本人 / 自定义，五种范围按角色设定。
- 菜单与按钮：授权菜单、授权数据、按钮级控制分开配置，不靠前端藏按钮。
- 字段与接口黑名单：成本、毛利、客户手机号可单独拉黑；接口级黑名单挡住整条调用路径。
| 角色 | 可见范围 | 金额字段 | 导出 | 接口 |
|---|---|---|---|---|
| 总经理 | 全部数据 | 可见 | 允许 | 只读 |
| 事业部负责人 | 本部门及以下 | 可见 | 允许 | 只读 |
| 店长 | 本店 | 脱敏 | 禁止 | 只读 |
| 运营 | 本店 | 脱敏 | 禁止 | 禁止 |
| 外包客服 | 指定店铺 | 隐藏 | 禁止 | 禁止 |
AI 想用得准，先把数据喂对
数据进仓、口径统一、权限收口之后，接 AI 只剩三步。
接上通道
生成 MCP 密钥，把服务地址写进 AI 客户端配置。不需要模型侧写取数代码。
问业务问题
「上周哪个型号的退款率最高」「近 30 天推广花费跑得最快的渠道是哪个」。
拿到能核对的答案
结果附带指标定义、统计区间与数据来源，业务敢用，财务能复核。
沉淀成固定问法
高频问题固化为数据集模板与知识条目，新人上手直接复用，不用重新摸索。
三种交付方式，数据放在你认可的地方
云端托管
开箱即用，按店铺数与数据量订阅。适合希望快速上线、不想运维服务器的团队。
私有化部署
整套系统部署在你的服务器或专有云内，数据不出内网，接口与 MCP 走内部地址。
混合模式
明细留在本地，聚合宽表上传云端供 AI 使用。敏感字段不出门，模型照样能算。
先做数据体检
梳理店铺、平台、类目与现有报表，先看哪几张表值钱。
再定口径
把成交、退款、花费、ROI 的定义写进系统，一次说清。
然后跑通第一条链路
从一个看板或一个接口开始，让数据真正被用起来。
最后接 AI
等宽表和权限稳了，再接 MCP，AI 才不是玩具。