---
title: "verify-data：一个端到端的数据验数 Agent Skill"
description: "10类标准化SQL模板、基准表自动发现与降级策略、17步条件触发流程、5大场景识别。效率提升2-4小时→30分钟，评审级报告自动产出"
source_url: "https://mp.weixin.qq.com/s/CX7H8LUm9PokC19NDDd_WQ"
feed_name: "阿里云开发者"
author: "晓莄"
published: 2026-05-27
created: 2026-05-27
type: raw
tags: [agent-skill, data-validation, verify-data, agent, data-engineering, alibaba]
sha256: f236772f0c8909736c0abec25813d5cb1e78389f16b1d4fc26f58c062fdc663a
---

# verify-data：一个端到端的数据验数 Agent Skill

## 前置说明

Agent Skill 是一种给 AI Agent 定义的可复用能力包——可以理解为"Agent 的 SOP"。一个 Skill 定义了 Agent 在特定场景下应该做什么、怎么做、有哪些约束和红线。当用户用自然语言触发后，Agent 会按照 Skill 定义的流程自动执行，而不是靠模型临时发挥。

verify-data 就是这样一个 Skill：它把数据验数的全部流程——从信息收集、SQL 生成、执行到报告产出——编码成了一套可复用、可迭代的 Agent 能力。

## 数据层术语

| 术语 | 含义 |
|-----|------|
| ADS | Application Data Store，应用数据层，面向业务场景的宽表/CUBE表 |
| DWS | Data Warehouse Summary，汇总数据层，按主题域轻度聚合 |
| DWD | Data Warehouse Detail，明细数据层，清洗后的事实明细表 |
| DIM | Dimension，维度表，描述业务实体属性的参照表 |
| CUBE表 | 使用GROUPING SETS/CUBE语法做多维聚合的宽表 |
| 基准表 | 已验证可信的参照表，用来和研发表做数据对比 |
| 验数 | 数据验证，即通过SQL比对确认数据准确性的过程 |
| 血缘 | Data Lineage，数据表之间的上下游依赖关系 |

## 一、背景与痛点

在业务数据团队，每张表上线前或迭代后，都需要回答业务方的一个核心问题：**"数据准不准？"**

"验数"是指数据表上线前的人工review环节——评审人员需要看到完整的验证证据，确认数据逻辑正确、口径一致、无异常后才允许发布上线。这是数据质量的最后一道防线。

传统手工验数的典型痛点：

1. **覆盖度不够**：大多数开发者只跑了总量对比SQL，漏掉了维度逐项对比、汇总行一致性、CUBE完整性检查、关联膨胀检测等关键验证项。一张表如果有5个维度组合、7个指标，只跑一条总量对比等于只检查了冰山一角。

2. **基准表选错**：凭感觉选一张"名字差不多"的表做基准，结果两张表口径完全不同（比如基准表按买家维度去重，研发表按访客维度去重），验了半天结论无效。

3. **代码理解偏差**：没看懂研发代码的JOIN膨胀逻辑，验数SQL复刻了同样的bug。最典型的情况是研发表里有个LEFT JOIN会导致行数膨胀，但验数SQL也跟着做了同样的JOIN，结果两边数据"一致"，但都是错的。

4. **结论无依据**：业务方问"数据准不准"，回答"我跑了几条SQL，应该没问题"。这种主观判断缺乏评审级的证据链，业务方不信，评审也过不去。

5. **沉淀成本高**：每张表的验数SQL散落各处，换个分区、换个人又要从头来。验数过程没有形成可复用的资产。

## 二、verify-data 是什么

verify-data 是一个端到端的数据验数 Agent Skill。你只需要给它一张研发表名，它就能自动发现基准表、生成验数SQL、在计算引擎上执行、分析结果、组装评审级报告并发布到协作文档。整个过程通过自然语言对话完成，不需要手写一行SQL（除非你想主动干预）。

### 核心优势

| 维度 | 传统手工 | verify-data |
|-----|---------|------------|
| 效率 | 2-4小时 | 30分钟 |
| 覆盖度 | 冰山一角 | 全面体检 |
| 结论依据 | "我觉得没问题" | 评审级报告 |
| 资产沉淀 | SQL散落各处 | 自动归档 |

**10类标准化SQL模板**：确保验证覆盖度，特别是SQL 9（关联膨胀检测）和SQL 10（日期维度关联校验），这两项是数据评审最高频退回原因，手工验数时极易忽略。

**基准表自动发现**：通过血缘+维度/指标精排的两阶段策略自动选基准表，支持多基准表联合覆盖；找不到基准表时有4种降级策略兜底，确保任何表都能给出有意义的结论。

**17步条件触发流程**：主流程7-9步，加上条件触发的子步骤后实际可达17步。其中Step 3.6、3.7、4.8是被容易忽略但非常重要的强制/自动触发步骤。

### 5大场景识别

Agent会根据用户输入自动识别验数场景：

| 场景 | 名称 | 触发条件 |
|-----|------|---------|
| S1 | 新模型上线 | 单研发表，无基准表 |
| S2 | 迭代验数 | 双表对比（DEV vs PROD）或含迭代关键词 |
| S3 | 日常监控 | "最近数据异常"类描述 |
| S4 | 业务质疑 | "xx指标对不对"类问题 |
| S5 | 未知 | 模糊描述，需要进一步澄清 |

### 效率提升

从2-4小时到30分钟。传统手工验数的流程是：手写5-6条SQL → 逐条执行 → 肉眼比对结果 → 写验数文档 → 发给评审。verify-data将这一切压缩到30分钟以内：一句话触发后，Agent自动完成取数、跑SQL、写报告、推送通知，数据开发者只需要"看结论、做决策"。

### 证据链

产出结构化的评审级报告：7节标准格式、三档结论判定（PASS/WARNING/FAIL）、完整可执行的SQL附录、自动归档到协作文档，可直接交给评审人员。

### 资产沉淀

每份报告自动归档，SQL和报告成对保存在本地目录下，19条踩坑记录沉淀在Skill定义中，Agent不会重复犯已知错误。

### 风险管控

4条不可逾越的红线从机制上防止Agent在边缘场景犯错，这些不是"建议"而是"强制"，到了关键节点如果不满足条件就不会继续。

## 三、技术架构

verify-data的核心是一个条件触发流程。技术架构包括用户交互层、核心引擎层、外部依赖和输出产物。

## 四、核心流程（约17步）

主流程约7-9步，但加上条件触发的子步骤后实际可达17步。条件步骤不是每次都会执行，而是由对应的触发条件自动决定是否激活。