用途
当问题不只是“要写哪些检查”，而是质量项目应如何跨工具、团队和发布阶段运作时，使用本技能。它帮助智能体在多个质量框架之间设计规则归属、严重级别、证据与执行策略。
需要避免的假设：更多检查并不自动等于更高质量。运营模型与框架本身同样重要。
何时使用
- 选择或组合数据质量工具
- 设计规则组合与严重级别模型
- 对齐 dbt tests、Great Expectations、Deequ、Cuallee、Soda 或仓库原生检查
- 决定哪些内容阻断发布、哪些内容仅发出警告
- 提升数据质量控制的长期可维护性
工作流程
-
定义质量运营模型。明确：谁拥有规则、谁分诊失败、什么阻断发布、什么成为告警或趋势信号。
-
按用途对规则分组。典型分组包括：契约正确性；完整性与新鲜度；分布与异常检查；对账与财务控制；治理或受监管数据控制。
-
有意识地选择工具。决定每类规则应归属何处：dbt tests 用于仓库原生模型验证；Great Expectations、Deequ、Cuallee 或 Soda 用于可复用的基于框架的检查；仓库原生监控用于平台本地健康信号。
-
定义证据与路由。要求：可操作的输出；严重级别与归属；趋势可见性；与事件和发布工作流的链接。
-
控制规则组合的增长。审查重叠、过时、嘈杂或低价值的检查，使质量保持可信且可维护。
常见合理化借口
- “我们应该统一用一个工具做所有事。”——不同规则类型往往适合不同的执行面和运营模型。
- “如果规则失败，我们可以之后再决定影响。”——发布和事件行为必须在引入规则时就已定义。
- “规则越多质量越好。”——嘈杂或重复的检查会降低信任并拖慢分诊。
危险信号
- 规则归属和分诊路径不清晰
- 工具按偏好而非工作负载适配度选择
- 阻断与非阻断检查混在一起，没有严重级别逻辑
- 证据难以审查或难以随时间观察趋势
- 过时、重叠或低信号规则不断累积且无人检查
验证
- 质量运营模型清晰定义了归属与严重级别
- 规则分组映射到真实交付风险和发布阶段
- 工具选择契合执行面与维护需求
- 证据与路由可审查、可操作
- 规则组合的蔓延随时间得到控制