SQLBot：用中文查业务数据，从一句提问接到 SQL 和图表

想知道订单来自哪些区域，往往要先找到表、请人写查询，再把结果做成图。SQLBot 把这几步放进同一段问答：选定数据源，用中文提问，系统生成 SQL、查询数据，再用图表展示；用户还能继续追问、查看查询语句和导出明细。它适合已有业务数据、希望减少临时取数往返的团队。

值得认识它的地方，是问答、图表和底层查询有可回看的联系。对业务使用者而言，入口可以是一句话；对负责核对口径的人而言，结果也有继续检查的位置。

看官方例子：同一个结果，可以继续查数据和问原因

官方仓库的中文界面示例，展示了对下单记录按区域汇总并返回饼图的任务。图中列出北区、南区和东区，图例还保留了 null；下方的分析文字也提到了区域缺失的记录。

来源：官方仓库的历史界面示例，原图日期为2025年7月29日。它展示图表与后续分析的衔接，不是本文运行的查询，也不代表当前所有按钮位置。打开原图查看图例与分析文字。

这份材料里，最值得留下的细节是缺失区域。一个饼图已经能让人看出分布，但 null 不应被当成第四个真实区域。继续分析之前，需要知道它来自未填写、关联失败，还是统计口径中的其他情况。AI 可以组织解释，字段的真实含义仍要回到数据和查询本身。

“前10”也只是展示上限，结果里只有几个分组，并不需要编满十个。这种对材料的判读，决定了图能否进入后续报告，不能只看回答是否完整、颜色是否漂亮。

当前智能问数手册说明，每次问数都会生成对应 SQL，可查看和复制；图表可以查看明细、导出 Excel，也可以根据数据结构切换图表类型。执行详情还记录处理过程、耗时与 Token 消耗，便于排查某次回答。

例如，先问“近一周各品类订单量趋势”，再追问“其中哪个品类增长明显”，是手册所支持的多轮分析方式。这里需要核对的是：时间范围是否仍为同一周，订单量到底按记录条数还是商品数量计算，后续回答是否沿用相同数据源。查询语句与明细入口，让这些问题有了可以检查的材料。

点击“数据分析”后，系统会基于当前图表数据调用模型组织趋势描述和业务解读。查询得到的数字与模型给出的原因推测，应分开阅读。数据可以显示某区域占比变化，变化为什么发生，通常还需要活动、业务规则等额外信息，不能只凭模型写出的原因就下结论。

SQLBot 使用大模型与 RAG 组织 Text-to-SQL 流程，并提供术语配置和SQL 示例库。两者适合解决企业问数里很常见的一类问题：同一个词，团队口头说法和数据库字段并不一致。

术语可以填写名称、解释和同义词；SQL 示例则把问题、对应 SQL、说明以及数据源一起保存。后续问题匹配到示例时，会把这些参考材料与问题一并交给模型。示例只在对应数据源范围内匹配，不能把另一套表结构的查询直接套过来。

比如团队说“有效订单”时，要先明确是否排除取消记录，再把业务定义写进术语或经过核对的查询示例。这样做的价值，是把人的业务判断变成后续生成时能利用的参考。它不等于只要多聊几次，系统就会自动学会所有内部口径；材料仍需管理员添加、编辑和维护。

采用之前，需要配置 AI 模型并接入至少一个可用数据源。可以从一张公开样例表或已授权的非敏感数据开始，用自己知道答案的问题，对照 SQL、明细和图表是否一致，再逐步扩大范围。平台提供工作空间和权限相关能力，实际可用范围应结合版本、部署与账号配置核对。

官方提供 Docker、1Panel 及离线安装路线，但模型服务并不会随软件安装自动具备。模型若走外部接口，相应请求也会进入服务提供方；自建应用与模型处理所在位置，需要分别选择。软件许可不包含模型额度和服务器费用。

仓库使用带附加条件的 FIT2CLOUD Open Source License，正文条款要求保留前端 Logo 与版权信息等，不能仅概括成普通 GPLv3。自行部署或二次开发前，应阅读实际 LICENSE及对应商业服务条件。

SQLBot 比较适合的起点，是让一类反复出现、口径已经明确的临时查询走通：用户能用中文问，核对者能看 SQL 和明细，图表也能继续进入现有工作。业务含义准备得越清楚，这段问答越容易产生真正可用的结果。