连 SQL 都不想写了，Text-to-SQL 实战体验报告

连 SQL 都不想写了Text-to-SQL 实战体验报告昨天刚把五年前的老代码底层用 Cursor 搞了个大清理给屎山做了次“代码体检”无用变量砍了命名规范了嵌套层级扁平了代码可读性蹭蹭往上涨。那时我还挺得意心想“这次算是踏实地让 AI 配合代码干得有声有色”。结果刚喘口气同事、产品、运营又开始各种扔需求过来“这块数据给我查个报表这个接口改下条件把昨天的统计加个维度”。说实话立马觉得头大——代码层面清晰了数据库查询这关却依然是老大难。这时我开始琢磨AI 能不能像理解代码上下文那样直接帮我理解数据库结构和业务查询意图能不能少写点 SQL或者写得更准更快于是我就试水了最近火得不得了的 Text-to-SQL文本转 SQL工具想看看它能不能把“AI 理解代码”这个门槛顺着走到“AI 理解数据”。需求来了数据库结构还真挺复杂拿到需求的那天手边项目数据库是典型的五年老架构user表存用户基础信息字段有id,name,email,statusorder表订单表字段有id,user_id,total_price,created_at,statusproduct表商品表字段有id,name,category,price简单来说业务常用查询多半是“查询某用户的某时间段内订单情况”还要过滤订单状态、统计商品类别销量什么的。传统思路直接写 SQL像下面这样SELECTp.category,COUNT(*)ASsales_count,SUM(o.total_price)AStotal_revenueFROMorderoJOINproduct pONo.product_idp.idWHEREo.user_id123ANDo.created_atBETWEEN2024-01-01AND2024-03-31ANDo.statuscompletedGROUPBYp.category;但这句 SQL 不止我写不出有时候写了跑出来结果还感觉不对得反复改条件改 join改 group by效率堪忧。尤其产品那边常常给的需求描述很模糊“帮我查一下最近三个月某用户的订单数据要区分商品类别还有销售额”。这就触发了我试 Text-to-SQL 的念头要不直接跟 AI 说“我想要这个业务问题的 SQL”让它帮我整实操体验从表结构到提示语的打磨第一步我把三张表的结构和业务含义整理了一份给 AI表结构 user(id, name, email, status) - 用户信息表status表示用户状态active/inactive order(id, user_id, product_id, total_price, created_at, status) - 订单表status表示订单状态pending/completed/canceled product(id, name, category, price) - 商品表 业务需求示例 查询用户ID为123在2024年第一季度内所有已完成订单中按商品类别统计订单数量和销售额总和。然后我用一个 Text-to-SQL 工具开源或商业都行这里以开源的某工具为例输入这个描述给它的 prompt 加了点细节请根据以下表结构和业务需求帮我生成 SQL确保查询的是已完成订单时间范围严格限制在2024年第一季度按商品类别分组聚合订单数量和销售额。生成的 SQL 基本准确SELECTp.category,COUNT(*)ASorder_count,SUM(o.total_price)AStotal_revenueFROMorderoJOINproduct pONo.product_idp.idWHEREo.user_id123ANDo.created_at2024-01-01ANDo.created_at2024-03-31ANDo.statuscompletedGROUPBYp.category;我试着在测试库跑了一遍没啥问题。但我发现这玩意也不是完美生成的 SQL 有时会忽略user表信息或者误用字段。为了避免误查我总结了几个小技巧尽量把表和字段的业务含义写清楚尤其是主外键和状态字段的解释让 AI 理解哪些字段用来关联哪些字段用来过滤。提示里明确时间范围和状态条件避免生成漏加限制的 SQL防止结果过大或脏数据。先让 AI 生成 SQL再自己做一次简单核对不盲目直接用结果毕竟生成器可能搞错逻辑关系。多写点业务背景和示例场景比如“只查已完成订单”“统计每个商品类别的销售额”帮助它结合上下文。Text-to-SQL让 AI 理解数据递进式提升工作效率回头看昨天的 Cursor是让 AI 读懂代码的上下文好让它在代码结构脉络中帮我们“修剪”和“重构”今天的 Text-to-SQL则是让 AI 从数据库表结构、字段定义到业务查询意图逐步理解“数据背后的故事”。我体验下来不管是老项目还是临时跑数据Text-to-SQL 就像是帮你搭了一个“语义桥”减少了死磕 SQL 语法和逻辑细节的时间能让开发者从原本机械写代码、写查询跳到和 AI 一起“聊业务”“聊数据关系”效率立刻能蹭蹭往上涨。当然Text-to-SQL 不会取代 SQL 开发者但作为一个辅助工具尤其在多表关联、条件复杂的场景里能极大降低入门门槛和出错概率体验相当惊喜。下次我们把目光放宽不仅看 AI 怎么读懂单表、单查询更要探讨它究竟是如何理解多表关联和业务语义的。毕竟光会写“简单的查询”在真实业务里远远不够真正的难点往往在复杂业务逻辑的“语义层面”。这背后隐藏着什么样的原理和模型能力这就是接下来要聊的重点。