夜雨聆风| Data+AI · 数据治理与AI实战 |
上周跟一个朋友聊，他在鞋服企业做数据开发，跟我吐槽了一句话，让我印象特别深刻。他说现在靠 AI 写 SQL 效率直接翻三倍，可在老板眼里这本就是分内事，反倒揪着 ETL 偶尔报错的问题追着问。当时听完特别有共鸣： 现在团队几乎人人都在用 AI 辅助开发，但大家拉开差距的根本，从来不是手里装了多少工具，而是工具用在了业务流程的哪个关键节点 AI工具用了一圈下来，发现一件事：用得好的和用得不好的，差距已经在拉大。但不是因为"用了多少个工具"，而是"用在了哪几个环节"。 我把近一年真正常用的5个工具筛了一遍，每个都附真实场景和踩过的坑。5分钟读完，希望对你能有一些帮助 |
| 1 | Cursor：写SQL/DDL，快但别全信 |
干什么的：AI编辑器，隔壁程序员都在用，数据开发装一个，写SQL和DDL比手动快三倍，但这有个前提，我后面说。 具体场景：我们DWD层表有400多张，每次加字段或者改口径，以前要翻文档、找原来DDL、手改。现在把相关表的DDL全选，跟Cursor说"在dwd_order_detail里加一个字段叫discount_type，从ods_order的discount列透传，口径跟dwd_price一致"，它出的DDL直接能用，我基本只改字段注释即可 真实收益：以前改一张表DDL平均花25分钟（翻文档+手写+检查），现在8分钟。这个数字不夸张，但累积起来半年就是一天工时 踩过的坑：Cursor生成的DDL，JOIN逻辑偶尔会"自作主张"帮你优化——比如你本来要LEFT JOIN，它觉得INNER JOIN性能更好，直接给你改了。我有一次没注意，上线后报表数据少了30%，查了半天才发现是JOIN条件被动了。现在我的规矩是：Cursor出DDL，我一定会手动核对JOIN和WHERE条件 |
| 2 | Claude Code：终端审SQL，改代码不用切窗口 |
干什么的：Claude官方出的终端AI Agent，直接在命令行里审SQL、改代码、解释报错。不用开浏览器、不用切窗口，终端里直接对话 具体场景：我们离线 ETL 全都是夜间调度跑，每晚都有运维盯报错。我现在处理报错的方式基本是：直接在终端敲一行指令：claude "解释这个报错，并且给出修改建议"，把整段报错日志丢进去就行。举个最常见的例子，它会精准定位：第 87 行分区格式不对，得用 yyyy-mm-dd，顺带把改好的 SQL 片段直接输出，脚本可用率基本是100% 真实收益：以前值班处理ETL报错，平均1个花15-20分钟。现在终端里直接弄，5-8分钟处理完一个 踩过的坑：Claude Code对国内直连不太友好，要配代理。另外它有时候会"过度理解"——你只想让它解释报错，它顺带把你的SQL重构了一遍，改了逻辑。我现在用法是：只让它"解释"和"给建议"，改代码我自己来 |
| 3 | TRAE（CN版）：字节家AI IDE，中文场景稳 |
干什么的：字节出的AI IDE，类似Cursor但国内服务稳，中文理解好。CN版走国内直连，不用配代理，企业内网环境能用。国际版在国内访问偶尔抽风，数据团队选CN版省心 具体场景：我们表名很多带中文、字段名拼音混写、注释都是中文，这类"中国式代码库"，TRAE理解得比Cursor准。有一次我让它"找出dwd层所有跟'会员'有关的表，并且列出每个表的主键和分区字段"，它准确找出了17张表，而Cursor只找出了11张（漏了字段注释里提到"会员"的表） 真实收益：跟Cursor比，少改30%的注释和字段名。对新员工更友好。以前新人接手数仓，要先花一周理表关系，现在让TRAE"画出dwd_order相关表的血缘关系"，10分钟出结果，新人理解速度快了一倍 踩过的坑：大文件（2000行以上）读不全，会丢上下文；偶尔"过度主动"：你只想让它改一个字段注释，它把整张表的DDL重写了。我现在用法：大文件先切分，让它处理单个段落；改代码前先让它"只列出要改的地方"，确认后再执行 |
| 4 | DataWorks DataAgent：数仓原生，SQL任务生成/解释 |
干什么的：阿里云DataWorks内置的AI Copilot，原生理解数仓上下文（ODPS表结构、分区、权限），不是通用AI工具随便接的。鞋服企业如果用阿里云数仓，这个工具是直接能用的 具体场景：业务方给我一个需求："要一张表，统计每个门店最近30天的销售额、客单价、连带率，并且跟去年同期对比"。以前我要自己设计DWD->DWS->ADS的链路，现在把需求直接贴进DataWorks DataAgent，它先给出推荐的表结构和字段口径，我再微调，然后直接生成ODPS SQL。我试下来，生成的SQL大约70%不用改，剩下30%是口径要跟业务再确认 真实收益：以前接一个中等复杂的需求（要3-5张表JOIN），设计表结构+写SQL平均花2小时。现在1小时以内搞定。按每周接3个新需求算，一个月省下来约8-10小时 踩过的坑：DataAgent生成的SQL，分区裁剪有时候会漏——比如你明明有dt分区，它生成的SQL没加WHERE dt='xxx'，全表扫，慢且费钱。我现在规矩是：它生成的SQL，我一定会手动加分区条件，并且Explain一下看执行计划 |
| 5 | 阿里悟空：AI工作平台，跨工具Agent调度 |
干什么的：阿里钉钉团队2026年3月发布的企业级AI工作平台。它不是IDE，是"管理/调度AI工具"的平台——你告诉悟空目标，它自己决定调哪个工具、用什么技能、怎么分解任务 具体场景：我们每周要给业务方出一份数据质量报告，以前要：①跑质量规则SQL → ②整理异常清单 → ③写报告文档 → ④发邮件。现在我把这个流程配置成悟空的"工作流"，每周一早上它自动跑SQL、整理异常、生成报告文档草稿、发邮件给我确认。我只改一下措辞就发出去了 真实收益：以前每周出报告花1.5小时，现在15分钟确认一下就行。但这个工具的价值不在"省时间"，而在"让你的AI工具协同起来"——Cursor写代码、Claude Code审代码、DataWorks跑任务，悟空负责把这三个串起来，自动完成一个完整的工作流 踩过的坑：悟空现在还在推广期，企业版要申请，不是想用就能用。另外"工作流"配置有一定学习成本——我花了约半天时间才把第一个流程配置通。如果你的团队规模小（3人以下），暂时不值得专门上悟空，前面4个工具已经够用了 |
| ⚡ | 用好AI工具的前提：你的数据治理得过关 |
前面5个工具，都是"让你把已经想清楚的事做得更快"。但如果你的数据治理本身是一团乱麻，AI工具只会让你"更快地产出错误结果"。
举一个具体例子： 你让DataWorks DataAgent"生成一张门店销售宽表"，如果你的ODS层数据本身口径不一致（有的表dt格式是yyyy-mm-dd，有的是yyyymmdd；有的金额字段是amt，有的是amount......），AI生成的SQL会直接继承这些错误，而且它不会提醒你，因为它也不知道正确的口径是什么
所以个人建议是： AI工具应当在"数据治理底子打好了"之后再用，好数据才能驱动真智能 ① ODS层数据口径统一（日期格式、金额单位、编码规则全统一） ② DWD层字段命名规范（业务含义清晰，不靠注释理解） ③ 有起码的数据质量规则（空值、异常值、重复数据有监控） 这三点没做好之前，AI工具能帮你做的事非常有限——这也是为什么很多公司"上了AI工具但没效果"的真实原因吧
