AI写SQL很爽，烂摊子谁来收？

AI把写SQL的成本打到接近零之后，真正稀缺的东西变了——不是生成能力，而是清理能力。

最近，IT168企业级频道发布头条文章《“氛围编程”与数据库工程的结合：清理AI生成的SQL》。标题里最值得咀嚼的不是“氛围编程”，而是“清理”这两个字。几乎同一时间，工信部与国家数据局联合印发通知，正式启动2026年“模数共振”行动，面向制造业20个重点行业推动AI赋能新型工业化。一头是技术侧的工程反思，一头是政策侧的规模化动员——这两件事撞在一起，指向同一个判断：AI生成SQL正在从尝鲜走向常态，而数据库工程的重心，正在从“写出来”滑向“清干净”。

🧑‍💻 写SQL这件事，第一次不靠手艺

数据行业私下流传一句话：以前分析师提个数要排队三天，现在排队的是数据团队——排队处理AI吐出来的SQL。

场景并不陌生。过去一条取数SQL，要靠数据分析师、BI工程师、DBA这条人力流水线：确认口径、核对表结构、估算扫描量、走变更流程。一个复杂的多表关联查询，老手要花半天时间斟酌。而今天，任何会打字的人对着对话框描述需求，几秒钟就能拿到一段语法漂亮、缩进工整、甚至自带注释的SQL。这就是“氛围编程”（vibe coding）落到数据侧的样子：描述意图，机器产出，人只负责“感觉对了”。

IT168这篇文章的信号意义在于：当一家面向企业级读者的主流技术媒体，把“氛围编程”和“数据库工程”放在同一个标题里，说明AI生成SQL已经不再是开发者社区的玩具话题，而是进入了企业生产链路的严肃议题。媒体开始讨论“如何清理”，恰恰说明清理的需求已经大到无法忽视。

产业逻辑也随之改变。SQL的生产函数第一次发生了结构性变化：生成环节的边际成本趋近于零，瓶颈整体后移到了质量控制环节。过去贵的是“写”，现在贵的是“审”。这不是效率工具的小修小补，而是数据工程分工的一次重新洗牌。

🧹 AI生成的SQL，烂得很有规律

“AI写的SQL，第一眼看全是惊喜，第二眼看全是惊吓。”——这是某数据平台团队负责人在内部分享时的原话，后来在小圈子里被反复引用。

一个典型的场景：分析师让AI“查一下最近30天各区域的销售额”，AI秒回一条80行的SQL，跑通了，数字也出来了。但三天后财务对账，发现口径对不上——AI把退款记录也算进了销售额，因为退款表里恰好有一个语义相近的“金额”字段。语法全对，业务全错。

这类问题呈现高度规律性，大体可以归为三类：

需要注意的是，这不是模型不够强的问题，而是概率生成的本性：模型按照“像SQL”的规律输出，而不是按照“对的SQL”输出。Schema越脏、语义层越缺、数据治理越薄弱的企业，AI生成SQL的错误率就越高。换句话说，AI生成SQL的质量，是一家企业数据治理水平的照妖镜。

这也解释了为什么“清理”会成为关键词——它不是一个临时动作，而是会被AI放大存量问题的持续负载。

⚙️ 清理不是擦屁股，是一条流水线

IT168标题里的另一个关键词是“结合”。真正的解法，不是让人回头逐行手改，而是把数据库工程的既有方法论接入AI生成链路，让清理本身工程化、流水线化。

这条流水线的核心思想，是把过去靠老师傅经验兜底的质量控制，拆成机器可执行的层层门禁：静态检查拦语法与规范，沙箱试跑拦执行风险，成本评估拦性能黑洞，版本化与评审拦口径漂移，上线监控拦长尾问题。生成越便宜，门禁越要便宜——否则人工审核会成为整条链路最贵的一环。

再往深处走，清理的前置化才是终局：与其事后过滤烂SQL，不如让AI在生成时就“无处可烂”。语义层把业务口径固化下来，约束和权限把危险操作挡在数据库内部，让模型的自由发挥空间被收窄到安全区。治理手段的定位可以用一张四象限图看清：

右上象限（自动化+事前预防）是产业竞争的制高点。谁能把“事前”做到自动化，谁就能吃到这一波红利。

而且要看到冰山下的部分——清理的成本远不止改代码：

🏭 “模数共振”一来，脏SQL要翻着倍长

如果说技术社区讨论清理SQL还是“先富的问题”，政策这一脚油门，会把它变成“千行百业的问题”。

近日，工信部、国家数据局联合印发通知，正式启动2026年“模数共振”行动：面向制造业领域20个重点行业，确定一批重点城市，探索场景、模型、智能体、数据集、案例等关键技术成果的产出路径，推动人工智能高水平赋能新型工业化。

拆开看这份清单，尤其值得注意“智能体”三个字。智能体落地工厂和供应链，意味着什么？意味着大量非专业开发者开始用自然语言直接调用数据：产线查询、能耗分析、质量追溯、设备报表——每一条自然语言指令背后，都是一次Text-to-SQL式的数据访问。互联网公司好歹还有数据团队兜底，而制造业的数据基础参差不齐、语义层普遍缺失，AI生成SQL的错误率只会更高，清理需求会被同比例放大。

政策的推演路径很清晰：“模数共振”明确把“数据集”列为关键成果之一，说明主管部门已经意识到模型质量与数据质量是绑定的。但数据集建设解决的是训练侧问题，推理侧的查询质量、执行成本、口径安全，最终仍要靠企业自己的数据库工程能力兜底。这中间的落差，就是未来一到两年最大的产业空白。

📊 谁能在清理层赚到钱

据多位接近数据平台团队的人士透露，不少公司2026年的技术预算里，“AI代码与查询治理”正从运维费用中拆出来单独立项——这是个强烈的信号：清理正在从成本项变成预算科目。

沿这条主线，三类玩家有明确机会：

• 数据库与湖仓厂商：把约束、权限、成本控制做成“内置护栏”，让AI生成的SQL一进库就被驯化，治理能力从附加品变成采购理由；
• 语义层与数据目录厂商：口径即约束，谁的语义层足够厚，谁的AI取数错误率就足够低；
• 可观测性与DevOps厂商：把SQL静态扫描、成本巡检、执行监控纳入CI/CD，卖的不是工具，是“AI产出的质量保险”。

对从业者而言，结论可能有些反直觉：未来两年，数据工程师最值钱的能力不是写SQL的速度，而是审SQL的判断力。写已被机器接管，审则刚刚开始定价——尤其在“模数共振”把AI推向20个制造业行业之后，懂数据库工程、又懂AI生成特性的人，会成为企业落地智能体时最先抢的稀缺资源。

小结：生成零成本时代，可靠才是新稀缺

AI把SQL的生产成本打到接近零，但 reliability（可靠性）不会免费。IT168的“清理”一文点破了工程侧的现实，“模数共振”则预告了需求侧的量级——当20个行业的智能体开始批量向数据库发问，清理层不再是锦上添花，而是整个数据基础设施的承重墙。2026年值得盯住的一个指标：企业技术预算里，“AI产出治理”的科目占比。它会比任何概念热度，更诚实地告诉你这场变革走到了哪一步。