上个月我让 Claude 给我写一个 dbt model。SQL 看着干净，join 也合理。我直接上线了。
三周后才发现，它悄悄丢了 8% 的行。该用 LEFT JOIN 的地方用了 INNER JOIN。没人抓到。仪表盘看着没事，因为丢掉的那 8% 恰好没怎么影响头部指标。
这就是 AI 在数据工作里的问题。它不知道它不知道什么。而且无论对错，它都说得很有把握。
我每周都会中招的两个地方
ETL。 join 用错 key。过滤看着对，但默默丢掉了边缘 case。type conversion 把时间戳转成日期，时区丢了。window function 的 ORDER BY 写法”对”，但不是你想要的那个意思。代码跑得通，数字出得来，看着没问题。但就是不对。
建模。 特征工程里有 leakage。“交叉验证”写成了偷看未来的版本。回归把带空值的行默默扔掉也不告诉你。指标算在和标签不一样的粒度上。模型训好了，AUC 看着很漂亮，一上线就翻车，等你在生产里发现。
共同点：看着对不等于对。AI 把”看着对”练得非常强。一个写得很顺的错误答案，比一个写得别扭的错误答案更危险，因为你会跳过 review。
review 现在就是你整个工作
我跟团队里年轻的同事反复说同一句话：
AI 的上限取决于你 review 它的能力。
一个资深的人用 AI，产出快 10 倍。一个新人用 AI，bug 也多 10 倍。工具是一样的，结果是反的。差别不在 prompt，在眼力。
我 review AI 输出的时候，做的跟 review 一个没信用的实习生一样：
- 每一行都读，不是扫。用自己的话讲一遍它干了什么。
- 拿一个已知答案的 case 跑一遍，对得上吗？
- join 前后数一下 row count。bug 经常就藏在这儿。
- 找静默失败。 丢 key、丢 null、隐式转换。这些从来不报错，只吃你的数据。
- 问一句”它假设了什么”。AI 会做假设，但不会告诉你，你得挖出来。
这很费时间。这就是这份工作。
新的技能
大家在讲 prompt engineering 是要学的新技能。不是。要学的是更快地识别错误。一页生成的代码，你多快能看出里面的谎言？一个看着合理的数字，你多快能感觉到它不对劲？
这个技能其实不新。就是老技能 — 会读代码、懂自己的数据、有品味。AI 只是把筹码变大了。你现在一天产出更多代码，意味着一天错的机会也更多。
我每天还在用 AI，回不去了。但我不再把它的输出当作”答案”。我把它当作一个很快、很会讲、有时候完全不对的实习生的初稿。我的工作是那支红笔。
如果你没有在用这支红笔，AI 不是在帮你，它只是在帮你更快、更自信地犯错。