系列目录（共 15 篇） ：
1-6（略）
- 4 步选型法（上）：场景与标准（本文）
8-15（略）
关键词：Text2SQL 选型、ChatBI 选型、4 步选型法、场景定义、选型标准、技术选型方法论
目录
- 一、写在前面：为什么需要方法论
- [二、4 步选型法全景](#二、4 步选型法全景)
- [三、第 1 步：明确场景（最关键的一步）](#三、第 1 步：明确场景（最关键的一步）)
- [四、第 2 步：定义选型标准](#四、第 2 步：定义选型标准)
- 五、场景自检清单
- 六、选型标准的细化方法
- 七、不同维度的评分细则
- 八、常见选型错误
- 九、推演示例：某电商公司的场景定义过程
- 十、总结
一、写在前面：为什么需要方法论
过去 2 年，我见过太多团队的 Text2SQL 选型过程：
反面案例：
错误 1：领导拍脑袋
"听说 DB-GPT 火，就用它吧。"
错误 2：技术负责人随便选
"Vanna 看着简单，先跑起来再说。"
错误 3：业务同学被拉来试用
"这个好像不太行，换一个。"
结果：3 个月过去了，工具换了 3 个，一个都没真正落地。正面案例：
某大型企业：
- 第 1 月：用方法论明确场景
- 第 2 月：基于标准评估 5 个项目
- 第 3 月：选定 SuperSonic + DB-GPT 组合
- 第 4-6 月：试点落地
- 第 7-12 月：推广到全公司
结果：1 年内完成全公司部署，业务满意度 90%。核心差异：有没有用方法论。
二、4 步选型法全景
我总结的 4 步选型法：
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 第 1 步 │ │ 第 2 步 │ │ 第 3 步 │ │ 第 4 步 │
│ 明确场景 │ → │ 定义选型标准 │ → │ 评估打分 │ → │ 最终决策 │
│ │ │ │ │ │ │ │
│ ·业务场景 │ │ ·场景匹配度 │ │ ·加权打分 │ │ ·推荐方案 │
│ ·团队能力 │ │ ·易用性 │ │ ·雷达图对比 │ │ ·备选方案 │
│ ·数据现状 │ │ ·语义管理 │ │ ·风险评估 │ │ ·下一步行动 │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘第一步 ：明确场景------搞清楚你要解决什么问题
第二步 ：定义标准------什么样的项目才适合你
第三步 ：评估打分------客观对比候选项目
第四步：最终决策------结合实际情况拍板
这一篇讲第 1 步和第 2 步，下一篇讲第 3 步和第 4 步。
三、第 1 步：明确场景（最关键的一步）
3.1 为什么场景最重要？
核心认知：
选型不是为了找一个"最好"的项目，而是找一个"最适合你的场景"的项目。
不同场景下，最佳选择可能完全不同：
| 场景 | 最佳选择 |
|---|---|
| 业务自助分析 | WrenAI |
| 企业级数据治理 | SuperSonic |
| Agentic 应用开发 | DB-GPT |
| 快速集成验证 | Vanna |
| Java 技术栈 | SuperSonic / SQLBOT |
| Python 技术栈 | DB-GPT / Vanna |
3.2 场景分析的 3 个核心问题
问题 1：你要解决什么业务问题？
不是"我想用 AI 提升效率"这种空话，而是要回答：
| 具体业务问题 | 优先级 | 量化指标 |
|---|---|---|
| 业务自助分析 | 高 | 减少 80% 提数需求 |
| 数据团队解放 | 高 | 数据团队工单 -70% |
| 实时决策支持 | 中 | 决策周期从周到小时 |
| 客服系统查询 | 低 | 客服效率 +30% |
问题 2：你的团队能力如何？
| 团队能力 | 影响选型 |
|---|---|
| 有 Java 团队 + 数据治理基础 | SuperSonic、SQLBOT |
| 有 Python 团队 + AI 能力 | DB-GPT |
| 团队偏业务、非技术 | WrenAI、SQLBOT |
| 团队极小、追求快速验证 | Vanna |
问题 3：你的数据现状如何？
| 数据现状 | 推荐 |
|---|---|
| 已建好数仓分层（ODS/DWD/DWS/ADS） | SuperSonic、DB-GPT |
| 数据源多但未分层 | DB-GPT、WrenAI |
| 单一数据源、简单查询 | Vanna、Chat2DB |
| 指标定义混乱、部门口径不一致 | 必须先做语义治理 |
3.3 场景分类框架
我用一个二维矩阵来分类场景：
数据治理要求高
▲
│
SuperSonic │ DB-GPT
│
业务 ─────────┼───────── Agentic
自助 │
WrenAI │ Vanna
│
▼
数据治理要求低
横向：业务重心（业务自助 vs Agentic 应用）
纵向：数据治理要求（高 vs 低）4 个象限的典型选择：
| 象限 | 场景 | 推荐 |
|---|---|---|
| 数据治理高 + 业务自助 | 企业级业务分析 | SuperSonic + WrenAI 组合 |
| 数据治理高 + Agentic | 企业级 Agent 应用 | SuperSonic + DB-GPT 组合 |
| 数据治理低 + 业务自助 | 业务团队快速验证 | WrenAI |
| 数据治理低 + Agentic | 开发者快速集成 | Vanna、LangChain SQL |
四、第 2 步：定义选型标准
4.1 4 大核心选型标准
基于第一步的场景分析，定义 4 条核心选型标准。
标准 1：场景匹配度（权重 35%）
优先选择能快速解决你核心数据查询和报表生成问题的方案，
而非功能最全的方案。为什么权重最高：场景匹配度直接决定项目能否真正用起来。
标准 2：易用性（权重 25%）
倾向于开箱即用、部署简单、文档友好的方案，
以降低初期试错成本和人力投入。为什么权重次高：易用性直接影响落地速度和团队接受度。
标准 3：语义管理能力（权重 30%）
必须具备一定的语义层支持，能将核心业务指标进行清晰定义，
保证数据准确性。为什么权重这么高 ：我见过的失败项目里，多数卡在语义治理而不是模型能力上。这是一条经验判断，不是行业统计------我早期稿里引用过一个「70%」的咨询机构数字，至今没回到一手出处，所以本篇不再拿它当论据。
标准 4：生态与成长性（权重 10%）
考虑项目社区的活跃度，确保未来遇到问题能找到解决方案。为什么权重最低：项目本身能用最重要，社区是加分项。
4.2 各标准的评分要点
场景匹配度的评分要点：
| 评分要素 | 分值范围 |
|---|---|
| 核心查询场景能否解决 | 0-5 分 |
| 项目擅长的领域是否需要 | 0-3 分 |
| 功能丰富度是否匹配 | 0-2 分 |
易用性的评分要点：
| 评分要素 | 分值范围 |
|---|---|
| 业务同学能否直接使用 | 0-4 分 |
| 部署复杂度 | 0-3 分 |
| 文档质量 | 0-3 分 |
语义管理能力的评分要点：
| 评分要素 | 分值范围 |
|---|---|
| 是否有 Metric Registry | 0-4 分 |
| 是否有实体建模 | 0-3 分 |
| 是否有强制消歧 | 0-2 分 |
| 是否有 Owner 责任体系 | 0-1 分 |
生态与成长性的评分要点：
| 评分要素 | 分值范围 |
|---|---|
| GitHub Star 数 | 0-3 分 |
| Issue 响应速度 | 0-3 分 |
| 文档完整性 | 0-2 分 |
| 商业支持 | 0-2 分 |
五、场景自检清单
为了帮你明确自己的场景，我整理了一份自检清单。
5.1 业务需求清单
请勾选符合你情况的选项：
业务目标：
- 让业务同学自己查数（提数自助）
- 让数据团队解放（从提数到治理）
- 让管理层实时决策（实时看板）
- 让客服快速查询（客服系统）
- 让 AI 自动分析（Agentic 应用）
- 让数据可视化（GenBI 体验）
典型查询场景：
- 查 GMV、订单数等销售指标
- 查复购率、转化率等运营指标
- 查营收、成本、毛利等财务指标
- 查用户数、活跃度等用户指标
- 查库存、周转等供应链指标
- 查 ROI、CPC 等营销指标
- 查归因分析、根因分析
- 查趋势预测
5.2 团队能力清单
技术栈：
- Java 为主
- Python 为主
- 前端为主
- 混合
AI 能力：
- 有专职 AI 工程师
- 有熟悉大模型的工程师
- 没有 AI 背景，靠开源项目
数据团队规模：
- 1-3 人
- 5-15 人
- 20+ 人
5.3 数据现状清单
数仓建设：
- 已建好分层（ODS/DWD/DWS/ADS）
- 部分分层
- 没有分层
指标管理：
- 有完整的指标字典
- 有部分指标定义
- 没有指标定义，依赖人工沟通
数据源：
- 单一数据源（MySQL）
- 多种数据源（MySQL、PG、数仓）
- 异构数据源（关系型 + NoSQL）
权限管理：
- 有完整的权限体系
- 有部分权限
- 没有权限管控
截图位置 1：场景自检清单的可视化展示
六、选型标准的细化方法
6.1 把标准细化为具体问题
标准不能停在抽象层面，要细化为具体问题。
场景匹配度的具体问题：
1. 这个项目能解决我的核心业务问题吗？
□ 完全解决
□ 大部分解决
□ 部分解决
□ 不能解决
2. 这个项目擅长的领域是我需要的吗？
□ 完全匹配
□ 大部分匹配
□ 部分匹配
□ 不匹配
3. 这个项目的功能丰富度符合我的需求吗？
□ 功能太多
□ 功能刚好
□ 功能略少
□ 功能严重不足6.2 用打分表量化
每个问题用 1-10 分打分，最后加权求和：
| 项目 | Q1 | Q2 | Q3 | 加权得分 |
|---|---|---|---|---|
| SuperSonic | 9 | 8 | 7 | 8.05 |
| DB-GPT | 8 | 6 | 6 | 6.80 |
七、不同维度的评分细则
7.1 场景匹配度评分细则
| 等级 | 评分 | 描述 |
|---|---|---|
| 完全匹配 | 9-10 | 项目核心功能 100% 解决你的问题 |
| 高度匹配 | 7-8 | 项目核心功能 80% 解决问题 |
| 部分匹配 | 5-6 | 项目核心功能 50% 解决问题 |
| 基本不匹配 | 3-4 | 项目核心功能 30% 解决问题 |
| 完全不匹配 | 1-2 | 项目无法解决你的问题 |
7.2 易用性评分细则
| 等级 | 评分 | 描述 |
|---|---|---|
| 极易用 | 9-10 | 业务同学直接用，无需培训 |
| 易用 | 7-8 | 简单培训即可上手 |
| 中等 | 5-6 | 需要 1-2 周培训 |
| 较难 | 3-4 | 需要 1 个月以上学习 |
| 很难 | 1-2 | 需要专业团队维护 |
7.3 语义管理能力评分细则
| 等级 | 评分 | 描述 |
|---|---|---|
| 极强 | 9-10 | 有完整 Metric Registry + 实体建模 + 强制消歧 |
| 强 | 7-8 | 有 Metric Registry + 部分实体建模 |
| 中等 | 5-6 | 有部分指标管理能力 |
| 弱 | 3-4 | 依赖大模型硬扛 |
| 无 | 1-2 | 没有语义管理 |
7.4 生态评分细则
| 等级 | 评分 | 描述 |
|---|---|---|
| 极好 | 9-10 | 10k+ stars，Issue 1 天内响应 |
| 好 | 7-8 | 5k+ stars，Issue 3 天内响应 |
| 中等 | 5-6 | 1k+ stars，Issue 1 周内响应 |
| 弱 | 3-4 | < 1k stars，Issue 响应慢 |
| 差 | 1-2 | 项目停滞或归档 |
八、常见选型错误
错误 1：被 Star 数忽悠
错误：DB-GPT 有 20,014（2026-09 抓取） stars，肯定比 SuperSonic 好
真相：DB-GPT 是综合框架，SuperSonic 是 BI 平台，
在企业 BI 场景下 SuperSonic 更合适错误 2：被功能数量忽悠
错误：拿功能条目数量当选型依据（这类清单数字无法核对，我也不报）
真相：功能的多少不重要，重要的是解决你的问题错误 3：忽略团队能力
错误：DB-GPT 最强大，就选 DB-GPT
真相：DB-GPT 学习曲线陡，没有 Python AI 工程师根本用不起来错误 4：忽略数据现状
错误：SuperSonic 语义层最强，就选 SuperSonic
真相：SuperSonic 需要建语义层，团队没有这个能力就用不起来错误 5：被营销话术忽悠
错误："AI 原生"、"企业级"、"一站式" 这些词很吸引人
真相：要看到具体的功能实现，不能只看宣传九、推演示例：某电商公司的场景定义过程
本节的公司背景、人数、天数、准确率与效果数字全部是虚构的教学推演，不是任何真实项目的记录，也不构成对任何厂商产品效果的陈述。
9.1 公司背景
- 行业：电商
- 规模：500 人
- 数据团队：8 人
- 业务团队：100+ 人
9.2 场景定义过程
第 1 周：业务调研
调研 20 个业务同学，收集 50+ 个数据需求
统计：
- 70% 的需求是查数（GMV、复购率等）
- 20% 的需求是分析（为什么下降、原因）
- 10% 的需求是预测第 2 周：团队能力盘点
团队技术栈：
- 后端 Java 为主
- 数据团队 Python 为主
- 业务团队非技术
数据团队规模：8 人
AI 经验：有 2 人了解大模型第 3 周：数据现状梳理
数仓：已建好 ODS/DWD/DWS/ADS
指标：有部分指标定义，但分散
数据源：MySQL + Doris + Hive
权限：有部分权限体系第 4 周：场景定义
基于调研，定义核心场景：
1. 业务自助分析（70% 需求）
2. 复杂归因分析（20% 需求）
3. 实时决策支持（10% 需求）
优先级：
1. 业务自助分析（高）
2. 复杂归因分析（中）
3. 实时决策支持（中）9.3 选型标准定义
标准 1：场景匹配度（35%）
- 必须能解决业务自助分析问题
- 必须能处理复杂多表查询
- 最好支持归因分析
标准 2：易用性（25%）
- 业务同学能直接使用
- 数据团队能配置语义层
- 部署不能太复杂
标准 3：语义管理能力（30%）
- 必须有指标管理
- 必须有实体建模
- 必须有权限管控
标准 4：生态（10%）
- 社区活跃
- 文档完善9.4 候选项目初步筛选
基于场景和标准，初步筛选出 3 个候选：
- SuperSonic（数据治理强）
- DB-GPT（生态强）
- WrenAI（易用性强）十、总结
第 1 步：明确场景
回答 3 个核心问题：
- 你要解决什么业务问题？
- 你的团队能力如何？
- 你的数据现状如何？
第 2 步：定义选型标准
4 大标准（按权重）：
- 场景匹配度（35%）
- 语义管理能力（30%）
- 易用性（25%）
- 生态（10%）
关键认知：
选型不是找"最好的"，而是找"最合适的"。
下一步预告 ：[4 步选型法（下）：评估与决策](#4 步选型法（下）：评估与决策)------我会讲解如何用打分表客观评估候选项目，如何用雷达图直观对比，如何做出最终决策。
本系列基于 2026 年 6-7 月的公开资料（官方文档、GitHub 仓库、公开分享）整理撰写。凡标注「推演示例」的案例均为教学虚构，不是任何真实项目的记录；未标来源的周期、规模与资源配置区间是作者的经验估算，不是行业统计。文末「本篇依据」列出全部外部事实的来源与抓取日期。
如果你在评估智能问数 / ChatBI 的落地方案，站内私信我说「评估」，我把《企业智能问数落地评估清单》发你；也接企业内训与落地评估（10 年金融/保险/通信数据工程，Oracle OCP、RHCE，做过真实上线与踩坑）。
本篇依据（外部事实，统一抓取日期 2026-09-19，Star 数与版本会随时间变化）
- DB-GPT：https://github.com/eosphoros-ai/DB-GPT （20,014★；最新正式 release v0.8.2，2026-08-26）
- SuperSonic：https://github.com/tencentmusic/supersonic （5,100★；由腾讯音乐开源；Java 包根为
com.tencent.supersonic，顶层模块为 auth / chat / common / headless / launchers / webapp / benchmark / docker / evaluation） - Vanna：https://github.com/vanna-ai/vanna （23,816★；仓库已归档停更，本系列把它作为学习参考，生产选型需先评估自维护成本）
- SQLBot：https://github.com/dataease/SQLBot （dataease 组织，仓库主语言 JavaScript + Python，不是 Java 原生）
- 榜单类分数与厂商宣传数字一律按「厂商宣称 / 第三方整理」标注口径引用，找不到一手出处的不写成事实。