"AI 写 SQL 靠不靠谱"这个问题，问的对象可能错了。答案通常不取决于模型有多聪明，而取决于你的数据库有多整齐。模型拿到的是表名和字段名，如果字段叫 qty_1、flag_a，或者同一个"数量"在三个表里是三种含义，再强的模型也只能猜。反过来，表结构规范、中文注释清楚、口径统一的库，命中率会高得让人意外。

在具体场景上，它最擅长的那类问题其实很集中：趋势、排名、对比、分布。比如"最近三十天各仓库的库存变化趋势"、"本月各产品线的订单金额排名"、"近三个月主要供应商的采购单价对比"、"各物流商上周的平均配送时长"。共同点是问题指向明确、答案落在聚合结果上。这类查询过去要找 IT 排期，现在一句话就能出表格加图表。多轮追问还能接着收敛：先问"上月销售额前十的产品"，再问"其中哪些是新品"，再让"按月份画趋势"，上下文是连着的。

边界也确实存在，主要有三处。一是口径：业务概念的定义往往不在数据库里。"呆滞库存"按九十天算还是一百八十天算，"及时交付"从下单起算还是从出库起算——这些规则如果只存在于老员工的经验中，AI 查出来的数字就会和人算的对不上。二是规模：单次结果集通常有上限，比如一千条，所以它适合看趋势和排名，不适合导全量明细去做二次加工。三是跨系统：它能查的只是接进来的那个业务库，数据还散在 ERP、TMS 和各种 Excel 里没打通的话，问了也答不了。

打开网易新闻 查看精彩图片

想让它靠谱，有几件事得先做。字段要有中文注释，让模型读懂业务含义；关键口径要在系统里固化成规则，而不是靠人传话；生成的 SQL 要能看得见——以代码块的形式展示出来，既能核对逻辑，也能直接拿去复用，这一步其实是信任的基础，黑箱出数没人敢用。安全边界同样要前置：只允许 SELECT，自动屏蔽密码等敏感字段，查询设超时，操作留审计记录。这样即便问歪了，最坏的结果也只是查不到，而不是改坏了数据。

聚龄供应链在 AI 秘书的智能问数里走的就是这个思路：连接 MySQL 业务库，按表名和中文注释建轻量索引，按需加载字段详情；结果以表格、图表和文字解读三种方式呈现，SQL 原样展示，只允许 SELECT 查询。

说到底，AI 写 SQL 不是替企业省掉数据治理，而是把数据治理的账提前摆到了台面上。底子整齐的企业会先享受到这波红利；底子乱的，问得越多，露出来的问题越多——这本身也是一种价值。