你平时怎么用AI写代码？AI写的SQL你敢直接上线吗？

# 数仓开发规范（给 AI 编码助手读的项目说明）
## 分层与命名
- 只允许读取 dwd/dws/dim 层；禁止直接读 ods 层做统计
- 表命名：{层}_{主题}_{内容}_{周期}，如 dws_trade_order_d
## 必须遵守
- 所有大表查询必须带分区条件 dt
- 禁止 SELECT *；Join 前先确认两边粒度，防止行数放大
- 时间统一用站点当地时间切日：使用 site_local_date 字段，不要自己转换时区
- 去重统计用户用 user_id，不要用 device_id
- 金额字段单位为分，输出时转换为元
## 常用表
- dws_trade_order_d：一个订单一行，主键 order_id，已剔除测试账号
- dim_user：一个用户一行，主键 user_id，拉链表，取当前用 is_current=1

-- AI 生成的典型问题：订单 Join 明细后直接汇总订单金额
SELECT o.dt, SUM(o.order_amount) AS gmv          -- ✘ 一个订单多条明细，金额被放大
FROM dws_trade_order_d o
JOIN dwd_order_item_d i ON o.order_id = i.order_id
WHERE o.dt = '2026-10-10' AND i.category = '耳机'
GROUP BY o.dt;
 
-- 修正：先在明细粒度过滤，再按订单去重后汇总
SELECT o.dt, SUM(o.order_amount) AS gmv
FROM dws_trade_order_d o
WHERE o.dt = '2026-10-10'
  AND EXISTS (SELECT 1 FROM dwd_order_item_d i     -- 用 EXISTS 避免行数放大
              WHERE i.order_id = o.order_id
                AND i.dt = '2026-10-10' AND i.category = '耳机')
GROUP BY o.dt;

这段 SQL 是很好的面试素材：语法完全正确，跑得也很快，结果却是错的。这正是 AI 生成代码最危险的地方——它的错误不会以报错的形式出现。

展开四：验证流程——让流程兜底

评审清单靠人，人会疲劳。所以还要有自动化的验证：

• 数据测试：主键唯一、非空、取值范围、参照完整性，每个新表和改动都要有。

• 数据对比：改造类需求，新旧逻辑在同一批数据上双跑，对比行数、主键、核心指标汇总。

• 基准值核对：新指标和已知可信来源（财务报表、看板）核对。

• 执行计划检查：扫描分区数、Shuffle 数据量是否在合理范围。

• 小步提交：AI 生成的大段代码拆成小的改动分别评审，避免一次几百行看不过来。

# 数据测试示例（类 dbt 写法）：AI 生成的模型必须通过才能合并
models:
  - name: dws_user_repurchase_d
    tests:
      - row_count_change: {max_ratio: 0.3}      # 行数日环比波动超 30% 告警
    columns:
      - name: user_id
        tests: [not_null, unique]               # 粒度：一个用户一行
      - name: repurchase_rate
        tests:
          - accepted_range: {min: 0, max: 1}    # 比率必须在 0-1 之间

实战经验：SQL 代码质量治理

我在某短剧出海公司做过 SQL 代码质量治理。SQL 风格各异、同一个口径多种写法，是很多数据团队的通病，Join 放大、漏分区这类问题也由此而来。这类治理的核心无非三件事：统一编码规范、建立评审清单、给核心表补数据测试。

这套机制在 AI 编码普及之后反而更重要了。AI 写代码的速度远超人工评审的速度，如果没有规范、清单和自动化测试，代码质量只会更难控制。所以我的观点是：AI 编码时代，团队的工程规范和测试体系不是可有可无，而是必需品。

追问链

追问一：你觉得用了 AI 之后，你的开发效率提升了多少？

这道追问要诚实回答，并且说出度量方式。比如“写新 SQL 的初稿时间明显缩短，但评审和测试的时间没有减少，甚至因为要更仔细地审 AI 的代码而有所增加，整体看需求交付周期缩短了一些”。不要报一个夸张的数字（比如“效率提升 10 倍”），面试官会追问怎么算的。具体怎么量化见第 20 题。

追问二：有没有遇到过 AI 生成的代码出问题的情况？

最好准备一个真实的例子：AI 生成的 SQL 哪里错了、你是怎么发现的、后来怎么避免的。比如“AI 把订单表和明细表 Join 后直接汇总订单金额，数字偏大，是在核对看板时发现的；之后我把‘Join 前确认粒度’写进了项目说明文件和评审清单”。有发现、有改进，说明你有把关能力和闭环意识。

追问三：团队里有人完全依赖 AI、不审代码，你怎么看？

我会从机制上解决，而不是指责个人。代码合并必须经过评审和自动化测试，这条规则对人写的代码和 AI 写的代码一视同仁。同时把 AI 常见的错误模式整理成清单分享给团队，让大家知道该重点看哪里。责任在提交代码的人，不管代码是谁写的。

加分说法 vs 减分说法

✔ 加分说法	✘ 减分说法
大量使用，说得出具体场景	我不太用 AI，自己写更放心
给 AI 完整上下文：表结构、口径、规范	AI 写的基本都对，直接用
能列出 AI 生成 SQL 的典型错误	说效率提升了 10 倍但说不出怎么算
AI 代码和人写代码走同一套评审测试	只说用了某某工具，说不出怎么用
AI 提速，人负责正确性，流程兜底	出了问题怪 AI

怎么挂到你的项目上

话术模板：“我日常写 SQL 初稿、读老代码、写测试都会用 AI，用之前会给它团队的规范文件和表结构。但 AI 写的 SQL 我不会直接上线，会重点检查 Join 粒度、NULL、时区切日、去重口径和分区过滤，并且通过数据测试和双跑对比。我之前做过 SQL 代码质量治理，深知没有规范和测试兜底，写得越快问题越多。”

如果你有被 AI 坑过的真实例子，一定要讲出来，这比任何方法论都有说服力。

总结

这道题的标准姿态是大量使用、严格把关、流程兜底。能说出具体使用场景、能列出 AI 生成 SQL 的典型错误、能讲清楚验证流程，就证明你既拥抱了 AI，又保持了专业判断。记住那句话：AI 的错误不会以报错的形式出现。

下一篇聊很多人最关心的问题：没做过大模型项目，怎么讲自己在 Agent 方向的经验？

你用 AI 写代码，被坑过最惨的一次是什么？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长