Show HN：Zingle —— 面向数据团队的 AI 代码审查工具（SQL/dbt/Airflow/Spark）
Zingle 会在代码合入生产环境之前，自动检查 GitHub PR 中的 SQL、dbt、Airflow 和 Spark 变更，提前发现成本回退（cost regressions）、逻辑问题、数据质量缺口以及下游链路破坏。
这是演示视频：https://youtu.be/dS0NnBjG2p4
你可以在 https://getzingle.com 免费试用，最多覆盖 100 个 PR。
这个工具源于我们自己的经历：当时我们为一个企业客户管理每周 60+ 个 dbt PR。资深数据工程师能用来审查 PR 的时间非常有限，而随着 AI 辅助编程普及，每天产生的代码量又大幅增加。团队只能在两个都很昂贵的选项之间做选择：要么让 PR 以极低的审查标准合入，承担仓库成本飙升或管道崩溃的风险；要么拉长审查周期，拖慢整个开发节奏。
两条路最后都代价不菲，要么烧真金白银，要么浪费工程时间。有一次为了赶代码量，我们合入了一个 PR，结果触发了一个大模型的重复全量刷新（full refresh），最终变成了一张 5 万美元的 Snowflake 账单。
我们意识到：软件工程师有各种 AI 代码审查工具，但数据团队没有——而数据团队的 PR 承载着完全不同的风险。
一个 SQL 或 dbt 改动，不只是“对不对”的问题。审查者需要理解计费行为、表的大小、血缘关系、数据基数、治理规则，以及这个改动会和真实数据产生怎样的交互。一个 SQL diff 在代码评审里可能看起来没问题，可一旦放到大规模数据上跑，就会出错或者变得极其昂贵。
Zingle 在每个 PR 上会做以下事情：
- 预测该改动对仓库成本的影响
- 检测全量刷新、缺失谓词、爆炸性连接（exploding joins）和行数增长风险
- 在安全沙箱中运行新的 SQL，并分析真实的数据差异（data diffs）
- 追踪血缘关系，判断哪些仪表盘或模型会在下游失效，并通知相关负责人
- 标记缺失的数据质量检查（空值、唯一性、业务测试）以及冗余测试
- 强制执行治理规则（PII 规则、文档、所有权、merge-key 要求）
客户的数据不会离开仓库。我们不存储 SQL、数据、元数据或查询内容。
Zingle 到目前为止发现过的实际问题：
- 一次会消耗数万美元的重复全量刷新
-
事实表中引入了重复行，导致收入数据失真
-
缺失过滤条件：如果没发现，表会膨胀一倍、管道越跑越慢
- 列重命名：差一点弄坏 14 个下游仪表板
- 低基数维度引发的连接爆炸
- 没有文档的模型，却在支撑财务指标
- 增量模型缺少 merge-key 去重逻辑
在现有用户中，Zingle 已经帮他们省下了超过 200 万美元的仓库成本和管道故障损失。
用户反馈的实际效果：
- 仓库成本下降 37%
- 数据事故减少 75%
- SQL 正确性信心：65% → 95%
- 模型测试覆盖率：45% → 90%
- 治理覆盖率：50% → 95%
- 代码评审周期：4 天 → 1.5 天
- 平均故障解决时间：10 小时 → 3 小时
关于我们：我们是 Anant（UIUC 人工智能博士，发表过多篇 AI 论文）和 Atishay（前高盛数据工程负责人，8 年数据工程经验，之前做过 text-to-SQL）。本科时是同学。
我们觉得，大多数数据团队都相信自己已经有了一套成熟的实践规范，但事实上这个领域仍在演进——治理、测试、血缘、可观测性都还没有标准答案。试错代价很高：糟糕的代码评审浪费资深工程师的时间，漏掉的问题则直接让团队损失金钱。