技能使用指南

数据上下文提取器Skill 用法详解

数据上下文提取器Skilldata-context-extractor
8 个章节 约 14 分钟阅读 AI 智能生成

数据上下文提取器Skill：把分析师脑中的“数据潜规则”变成可复用的 AI 分析技能

  • 它是什么：这是一个“元技能”——不直接做数据分析，而是从分析师身上提取公司特有的数据知识，生成一个专属的数据分析技能。
  • 两种模式：引导模式从零创建数据上下文技能；迭代模式为已有技能补充新领域（营销、财务、产品等）的上下文。
  • 解决的问题：AI 能写 SQL，但不懂你公司的“用户”指什么、ARR 怎么算、哪些行必须过滤掉——这些隐性知识只在老分析师的脑子里。
  • 输出物：一套结构化的技能包（SKILL.md + 实体/指标/领域表参考文件），可交付、可迭代、可复用。
  • 适合谁用：数据团队负责人、分析师、数据平台/数仓工程师，尤其是正在把 AI 接入公司数仓做分析的组织。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能中文名：数据上下文提取器Skill 技能英文名：data-context-extractor 技能ID：11425

这个技能解决的是一类非常真实的痛点：大模型写 SQL 的能力已经不错，但每次都要你在提示词里重新交代一遍——“我们说的‘用户’其实指账户”“ARR 要用 monthly_revenue × 12”“查订单表一定要过滤 is_test = true”。这些知识零散地存在于资深分析师的经验里，新人问一次答一次，AI 更是每次都要从头教。

数据上下文提取器Skill 把这件重复劳动产品化了：它像一个“数据知识访谈员”，通过几个关键问题的追问，把隐性知识结构化沉淀下来，最终生成一个可以反复加载的、公司专属的数据分析技能。

安装思路与步骤（具体命令、入口地址与授权方式以官方说明为准）：

  1. 确认前提：你需要一个可用的 AI 会话环境（支持技能加载的客户端/平台），以及目标数据仓库的连接能力——技能本身在工作流中依赖 ~~data warehouse 类工具进行模式探索，并会检查当前会话中可用的 MCP 工具。
  2. 获取技能：从官方技能市场或技能管理入口检索技能英文名 data-context-extractor 或技能ID 11425，按官方提供的安装方式添加（一键安装/导入技能包，实际入口与命令以官方说明为准）。
  3. 建立数据连接：按官方文档配置你的数据仓库连接（BigQuery、Snowflake、PostgreSQL/Redshift、Databricks 等），确保模式查询权限可用。
  4. 验证是否生效：在会话中直接说出触发语句，例如“创建一个数据上下文技能”“为我们的仓库设置数据分析”“帮我为我们的数据库创建一个技能”。若技能被正确加载，它会进入引导模式，首先反问你：“您使用什么数据仓库？”——看到这句追问，就说明技能已经生效。
  5. 日常使用：把这套流程固定成团队规范——每接入一个新仓库、每新增一个业务领域，就跑一次提取，让技能包随业务一起长大。

该技能的主要功能和特点

  • 双模式设计，覆盖“从 0 到 1”和“从 1 到 N”：引导模式负责创建全新技能；迭代模式负责给已有技能追加/更新参考文件，避免每次推倒重来。
  • 先探索模式，再问人：技能会先识别数据库类型，列出数据集/模式，确认“分析师最常查询的 3-5 张表”，提取这些表的结构详情，然后才进入访谈环节——问题因此更具体、更有针对性。
  • 五类核心追问，直击隐性知识：实体澄清（“说‘用户’时具体指什么？有不同类型吗？”）、主要标识符（主键 vs 业务键、UUID vs 整型、遗留 ID）、关键指标（精确公式与来源表列）、数据卫生（永远要加的 WHERE 条件、is_test/is_internal/is_fraud 标志）、常见陷阱（列名混淆、时区、NULL 处理、历史表与当前状态表）。
  • 输出结构化、可导航的技能包：生成 SKILL.md 加 参考/实体.md、参考/指标.md、参考/表/[领域].md，可选 参考/仪表板.json，并在 SKILL.md 中维护“知识库导航”。
  • 内置质量标准：参考文件按固定字段输出——表文档含位置、描述、主键、更新频率、关键列、关系、2-3 个示例查询；指标文档含定义、公式、源表、注意事项；实体文档含定义、主表、ID 字段、关系、常见过滤器。
  • 交付前有质量检查表：校验前缀完整性、实体澄清是否清晰、术语是否定义、标准过滤器是否文档化、每个领域是否有 2-3 个示例查询、SQL 方言是否正确、参考文件是否被导航链接。

和普通工具比强在哪：传统数据字典是“人写文档给人看”，往往写完就过期；NL2SQL 工具是“人问问题机器猜”。这个技能的差异点在于——它把访谈过程本身产品化，让知识的采集、结构化、交付、迭代形成闭环，而且交付物是 AI 可直接加载的上下文，不只是给人看的文档。

如何使用该技能？

路径一：引导模式（从零创建）

  1. 触发：说“创建一个数据上下文技能”或“为 [公司] 生成一个数据技能”。
  2. 回答数据库类型：技能会问“您使用什么数据仓库？”，常见选项为 BigQuery、Snowflake、PostgreSQL/Redshift、Databricks。
  3. 配合模式探索：技能会列出数据集/模式并询问最重要的表。例如 BigQuery 下它会用 SELECT schema_name FROM INFORMATION_SCHEMA.SCHEMATA 列数据集， SELECT table_name FROM \project.dataset.INFORMATION_SCHEMA.TABLES`列表； Snowflake 下则用SHOW SCHEMAS IN DATABASE my_database、SHOW TABLES IN SCHEMA my_schema`。
  4. 接受访谈（不要一次全答完，跟着节奏走）：按实体 → 标识符 → 指标 → 数据卫生 → 陷阱的顺序回答。示例输入：
    • “我们说的‘客户’指 account，一个 account 下可以有多个 user，用 account_id 关联。”
    • “最常问的是 ARR，公式是 monthly_revenue × 12，来自 subscriptions 表。”
    • “查任何表都要加 is_test = false 和 is_internal = false。”
  5. 确认生成：技能按模板生成目录结构与参考文件。
  6. 打包交付：技能创建完所有文件后会打包为 zip，并向你展示“捕获了什么”的摘要——这份摘要本身就是给团队评审的知识清单。

路径二：迭代模式（补充已有技能）

  1. 触发：说“添加关于 [领域] 的上下文”“用 [指标/表/术语] 更新数据技能”“改进 [领域] 参考”。
  2. 上传/定位现有技能：提供 zip 或文件夹，技能会阅读现有 SKILL.md 与参考文件。
  3. 指出差距：回答“哪些查询失败或产生了错误结果？”——这比“你想加什么”更容易问出真问题。
  4. 领域定向发现：技能探索相关表，追问该领域的关键指标、特殊过滤器和陷阱。
  5. 更新并重新打包：新增 参考/[领域].md，同步更新 SKILL.md 的“知识库导航”，重新打包交付。

输入/输出示例： 输入：“添加关于营销领域的上下文。我们的广告花费在 ad_spend 表，按天和渠道粒度，需要过滤 channel = 'organic' 才算付费投放。” 输出：新增 参考/营销.md，内含 ad_spend 的表位置、主键、更新频率、关键列、与其他表的关联、2-3 个示例查询，并同步进导航。

同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
数据上下文提取器Skill（本技能） 数据知识的“访谈式采集器” 双模式创建/迭代数据技能，自动探索模式并生成结构化参考文件 需可用的 AI 会话环境 + 数仓连接；安装方式以官方说明为准 让 AI 真正理解公司数仓语义、指标口径与查询习惯 优势：产出即 AI 可加载的上下文，含质量检查表；不足：依赖专家配合访谈，知识质量取决于回答质量
手工编写数据字典 / Wiki 文档 文档型知识沉淀 人工撰写表说明、指标定义 门槛低但工作量极大 团队内部查阅、合规审计 优势：灵活；不足：易过期、难维护，且不能直接被 AI 消费
BI 语义层（如 LookML、dbt 语义层一类方案） 指标与维度的建模层 定义指标、维度、权限与口径 需要建模工程投入，学习曲线较陡 报表与 BI 口径统一 优势：口径强约束；不足：面向报表消费，对“临时探索式 SQL 分析”的覆盖有限
通用 NL2SQL 工具 自然语言转 SQL 直接生成查询语句 接入快 快速取数、轻量查询 优势：上手快；不足：不理解公司专属语义与数据卫生规则，容易生成“技术正确、业务错误”的 SQL

选择建议：如果你的痛点是“AI 老是算错指标”，优先本技能；如果痛点是“报表口径混乱”，语义层更对症；两者可以并存——先用本技能把隐性知识挖出来，再反哺建模。

该技能的典型应用场景与实际体验情况

场景一：新分析师入职，带教成本高 角色：数据团队负责人。痛点：每个新人要花两三周才搞懂“公司里的用户到底指什么”。用法：跑一次引导模式，把老分析师的经验固化成技能包，新人加载后直接提问即可获得口径解释。体验：访谈环节是价值最高的部分——很多“我们以为大家都知道”的规则，第一次被写下来。

场景二：AI 写 SQL“技术对、业务错” 角色：业务分析师。痛点：AI 生成的查询忘了过滤测试账号，导致周报数据虚高。用法：在技能中把数据卫生规则显式文档化（is_test、is_internal、is_fraud、status = 'deleted' 等）。体验：一次性投入，长期生效；注意规则要说清“标志列名 + 取值”，否则 AI 无法落地。

场景三：业务扩张，新增营销/财务领域 角色：数据平台工程师。痛点：已有技能只覆盖交易域，营销域的问题答不准。用法：用迭代模式，直接说“添加关于营销领域的上下文”，技能会定向探索相关表并追问。体验：迭代模式明显比重新创建省力，因为已有实体与指标定义可复用。

场景四：指标口径反复扯皮 角色：增长团队。痛点：三个人算出的留存率三个数。用法：在“关键指标”环节逼出精确公式、来源表列和时间窗口惯例（过去 7 天还是自然月）。体验：这一步最容易被敷衍，但只要坚持写清“公式 + 源表 + 注意事项”，争议会大幅减少。

上手难度与注意事项：整体上手门槛不高，本质是“回答问题的能力”。真正的风险在于——如果你在访谈里含糊其辞，技能就会把含糊固化成文档。建议每轮生成后组织一次团队评审，用质量检查表逐条打勾；另外 SQL 方言一定要确认清楚（BigQuery 与 Snowflake 的写法差异会直接写进参考文件）。

该技能能为用户带来的价值

  • 把个人经验变成组织资产：隐性知识从“老分析师脑子里”迁移到“可加载的技能包”中，人员流动不再意味着知识流失。
  • 显著缩短新人爬坡期：原本需要反复口头带教的口径、陷阱、过滤器，一次文档化后全员复用，新人从“问人”变成“问技能”。
  • 提升 AI 分析的准确率：把指标公式、标准 WHERE 条件、常见陷阱写进上下文，直接减少“技术正确、业务错误”的返工——这类返工往往是最消耗信任的。
  • 降低门槛：不需要搭建完整的语义层工程，也能让 AI 具备公司级数据常识；对中小数据团队尤其友好。
  • 长期复利：迭代模式让知识库随业务生长，每新增一个领域只需增量投入，越用越准，形成正循环。

常见问题 FAQ

Q1：怎么安装？安装后怎么确认生效？ A：通过官方技能市场/技能管理入口检索技能英文名 data-context-extractor 或技能ID 11425 添加，具体命令与入口以官方说明为准。验证方式很简单：在会话里说“创建一个数据上下文技能”，如果技能反问“您使用什么数据仓库？”，说明已成功加载。

Q2：收费吗？ A：技能本身的计费与授权策略取决于官方发布渠道，以官方说明为准。需要留意的是，技能运行时会调用数据仓库查询工具，这部分消耗按你的数仓/云平台规则计算。

Q3：适合谁用？我是个人分析师，没有团队也能用吗？ A：非常适合。只要有明确的数据仓库和稳定的分析场景，个人分析师同样可以用引导模式给自己建一个“第二大脑”。团队规模越大、人员流动越频繁，收益越明显。完全不懂 SQL 的纯业务同学则不适合作为主要使用者。

Q4：它和直接写提示词告诉 AI“我们的表结构”有什么区别？ A：提示词是一次性的、零散的、容易遗漏的；本技能的产出是结构化的技能包（SKILL.md + 实体/指标/领域参考文件 + 导航），带质量检查表，可迭代、可打包、可交付给同事复用。差别类似“临时口头交代”与“正式交付的文档资产”。

Q5：和 BI 语义层、NL2SQL 工具怎么选？ A：不冲突，定位不同。BI 语义层面向报表口径强约束，NL2SQL 面向快速取数，本技能面向“让 AI 理解公司专属语义”。如果你最痛的是 AI 反复算错指标、忘记过滤测试数据，优先本技能；如果最痛的是报表口径混乱，先做语义层。两者并行时，本技能产出的实体与指标定义可以直接作为建模输入。