业务同事天天找我跑数上季度华南区退货率多少排个 Top10 客户出来。我嫌烦搭了个能用大白话查数据库的智能体让他们自己问。听着简单真要搭稳坑不少。重点不是把自然语言转成 SQL——那一步现在的模型基本能做——而是怎么让它别查错、别瞎编。整体怎么搭我在一个拖拽就能配流程的智能体平台上拉了这么一条链路用户用大白话提问。模型结合表结构把问题转成 SQL。把 SQL只读地跑到数据库。拿结果再让模型组织成人话回复。最关键的是第 2 步要把表结构喂给模型——表名、字段名、字段含义。不喂它就按自己的想象编字段名SELECT 退货率 FROM 订单表数据库里压根没这字段直接报错。让它查准的几个动作字段加注释。光给字段名cust_lv模型不懂我把cust_lv客户等级1普通2银卡3金卡一起喂进去它才不会把金卡客户翻译错。枚举值列出来。地区字段实际存的是华南/华东还是south/east差一个字就查空。我把可选值都列给它。限制只读。这条是底线。只给查询权限物理上杜绝它生成UPDATE/DELETE把生产库干掉。我一开始没限测试时它真的生成过一条 DELETE吓出汗。SQL 先回显。复杂查询我让它先把生成的 SQL 亮出来结果旁边标基于以下查询业务同事能核对我调试也方便。踩得最狠的坑聚合口径同事问销售额模型默认SUM(amount)但公司口径是要扣掉退款的。模型不知道这条业务规则算出来的数比真实值高一截同事拿去汇报差点出事。后来我把这类业务口径写进系统提示当成硬规则销售额一律 订单额 - 退款额。这种隐性口径模型再聪明也猜不到必须人喂。没搞定的部分多表 JOIN 一复杂它还是会偶尔关错表。我现在的兜底是把最高频的几个查询做成预设模板模型只填参数只有非标准的临时问题才让它现写 SQL。模板覆盖了大概七成日常需求剩下三成接受偶尔要我兜一下。搭完这个业务同事自助查数的比例明显上来了我清净了不少。转 SQL 和组织回复用的模型我挂讯飞 MaaS调现成 API没自部署省得为这点查询自己养模型。