很多 AI 数据分析项目最先做出来的是一个聊天框：用户输入问题，模型返回一段 SQL，看起来已经完成了从自然语言到数据查询的跨越。
但真正把它交给分析师使用后，很快会遇到另一组问题：这段 SQL 参考了哪套口径？Agent 正在检索还是卡住了？刷新页面后任务还在不在？查询结果放在哪里？同一个问题下周能否接着分析？
这篇文章分享我在一个指标知识库项目中构建 WebUI 的过程。它不是给大模型套一层聊天界面，而是尝试把知识检索、Agent 执行、SQL 生成、查询结果、图表和分析报告组织成一条可追溯的工作流。
全文已对业务名称、指标、表名、编码和内部平台信息做泛化处理，重点讨论可复用的架构思路与工程取舍。
数分团队做 text-to-SQL，最常见的失败模式不是「SQL 语法写错」，而是看起来很像真的——表名对了一半、过滤条件漏了、业务编码用错了版本，跑出来的数字和口径完全对不上。
这篇文章分享一套我在实际项目中落地的方案：用本地混合检索做路由，用标准 SQL 全文做生成依据，而不是把文档 chunk 丢给 LLM 自由发挥。全文数据已脱敏，业务域、表名、编码 ID 均为虚构占位。
Climb Date: 2025/08/31 · Distance: 246m · Grade: 5.10c · Pitches: 9 · Type: Sports · Field: 白河
线路名称：歪瓜裂枣
岩场位置：北京密云白河峡谷
攀登日期：2025-08-31
队伍成员：
天气状况：☀️晴, 气温 18~30℃，风力 南风2 级
线路信息：5.10c 246m 9Pitches （以下信息来自北京多段线路指南20241021版PDF)
🧗🏻
线路分段信息
Pitch1：24m / 5.7 / 4Bolts Pitch2：32m / 5.10b / 12Bolts Pitch3：28m / 5.10c / 11Bolts Pitch4：24m / 5.9 / 7Bolts Pitch5：32m / 5.10c / 12Bolts Pitch6：33m / 5.10a / 13Bolts Pitch7：24m / 5.9 / 8Bolts Pitch8：25m / 5.9 / 8Bolts Pitch9：25m / 5.10a / 10Bolts
