企业官网建设流程全解析

系列目录（共 15 篇）：
1-7（略）
8.4 步选型法（下）：评估打分与最终决策（本文）
9-15（略）

关键词：技术选型决策、加权评分、雷达图对比、PoC 验证、风险评估、最终决策

目录

• 一、写在前面：从标准到决策
• 二、第 3 步：评估打分
• 三、加权评分模板
• 四、雷达图对比
• 五、风险评估
• 六、第 4 步：最终决策
• 七、决策矩阵
• 八、PoC 验证
• 九、推演示例：某金融公司的决策过程
• 十、总结

一、写在前面：从标准到决策

上一篇我们讲了明确场景和定义标准，这一篇讲评估打分和最终决策。

核心问题：

候选项目有 5 个，怎么客观对比？ 评估结果出来后，怎么做最终决策？

这一篇我会给你一套实战可用的评估和决策方法。

二、第 3 步：评估打分

2.1 评估的三层结构

评估不是简单的"打分"，而是一个三层结构：

第 1 层：加权评分（量化对比） ↓ 第 2 层：雷达图（直观对比） ↓ 第 3 层：风险评估（识别坑点）

2.2 加权评分法的核心公式

总分 = Σ（标准得分 × 标准权重）

2.3 评分的客观性保证

原则 1：多维度打分

不要只用一个总印象分，要按维度打分。

原则 2：多人打分

至少 3 个人独立打分，避免主观偏差。

原则 3：基于事实

每个分数都要有依据，不能拍脑袋。

原则 4：权重透明

权重设定要提前公开，避免事后调整。

三、加权评分模板

3.1 评分表模板

我设计了一个标准评分表，可以直接用：

3.2 详细评分依据示例

以 SuperSonic 为例：

场景匹配度：9 分（满分 10）

依据：

• ✅ 业务自助分析 ✓ （9 分）
• ✅ 复杂多表查询 ✓ （9 分）
• ✅ 归因分析 △ （8 分）
• 加权：9 × 0.6 + 9 × 0.3 + 8 × 0.1 = 8.9 ≈ 9

语义管理：10 分（满分 10）

依据：

• ✅ Metric Registry ✓ （10 分）
• ✅ 实体建模 ✓ （10 分）
• ✅ 强制消歧 ✓ （10 分）
• ✅ Owner 责任体系 ✓ （10 分）

易用性：6 分（满分 10）

依据：

• ⚠️ 业务同学需培训 △ （6 分）
• ⚠️ 部署较复杂 △ （5 分）
• ✅ 文档质量 ✓ （7 分）

生态：8 分（满分 10）

依据：

• ✅ GitHub 5,100（2026-09 抓取） stars （8 分）
• ✅ Issue 响应快 （8 分）
• ✅ 文档完整 （8 分）

3.3 加权计算过程

总分 = 9 × 0.35 + 10 × 0.30 + 6 × 0.25 + 8 × 0.10 = 3.15 + 3.00 + 1.50 + 0.80 = 8.45

3.4 多项目对比

四、雷达图对比

4.1 为什么用雷达图？

雷达图能直观展示多维度对比：

• 一眼看出每个项目的"形状"
• 识别优势和短板
• 横向对比多个项目

4.2 4 个核心候选的雷达图

SuperSonic 场景匹配 9 ▲ /|\ / | \ / | \ / | \ / | \ SQL ◀─────●─────▶ 语义管理 10 生成 9 \ | / \ | / \ | / \ | / \|/ ▼ 易用性 6

解读：

• 场景匹配、SQL 生成、语义管理都很强
• 易用性是短板（Java 栈部署重）

4.3 多个项目叠加对比

把 4 个项目的雷达图叠加：

SuperSonic: 9-10-6-8 (强语义) DB-GPT: 9-7-5-10 (强生态) WrenAI: 8-6-9-8 (强易用) SQLBOT: 8-9-8-7 (强语义+强易用)

直观看出：

• SQLBOT 是均衡派
• SuperSonic 偏语义牺牲易用
• DB-GPT 偏生态牺牲易用
• WrenAI 偏易用牺牲语义

4.4 用雷达图识别"短板"

SuperSonic: 易用性 6（短板） DB-GPT: 易用性 5（短板） WrenAI: 语义管理 6（短板） SQLBOT: 全部均衡（无明显短板）

[截图位置 1：4 个项目的雷达图叠加对比]

五、风险评估

5.1 为什么需要风险评估？

加权评分只反映当前能力，不反映未来风险。

5.2 风险评估维度

维度 1：技术风险

维度 2：业务风险

维度 3：组织风险

维度 4：未来风险

5.3 风险评分

给每个风险打分（1-10 分，分数越低风险越大）：

六、第 4 步：最终决策

6.1 决策的 3 个层级

第 1 层：基于评分选 Top 1 ↓ 第 2 层：基于风险评估修正 ↓ 第 3 层：基于实际情况拍板

6.2 不能只看总分

反面案例（示意，非真实项目记录）：

某公司选了评分最高的 SuperSonic 但团队不熟悉 Java，部署阶段反复卡住 最后换了 Vanna，反而更快落地

教训：评分是参考，不是唯一标准。

6.3 最终决策的 5 大考量

考量 1：评分排名

按加权总分排名，Top 1 优先考虑

考量 2：风险评估

如果有重大风险，Top 1 可能不是最优选择

考量 3：团队实际能力

团队能不能 hold 住这个项目

考量 4：实施成本

包括部署成本、培训成本、运营成本

考量 5：未来扩展性

能不能支撑未来 3-5 年的发展

6.4 决策矩阵

把多个考量综合到一个矩阵里：

结论：

• SuperSonic 综合得分最高，但实施成本分低
• WrenAI 综合得分次高，但语义管理弱
• 最终选择要根据公司具体情况

七、决策矩阵

7.1 单选 vs 组合

决策类型 1：单选（适合小公司）

直接选 1 个项目，全力投入

决策类型 2：组合（适合大公司）

SuperSonic 做语义层底座 DB-GPT 做上层应用 WrenAI 做业务前端

7.2 组合方案的优势

┌────────────────────────────────┐ │ WrenAI（业务前端） │ │ - 体验好 │ └────────────┬───────────────────┘ ↓ 调用 ┌────────────────────────────────┐ │ SuperSonic（语义层） │ │ - 指标统一 │ │ - 权限管控 │ └────────────┬───────────────────┘ ↓ 调用 ┌────────────────────────────────┐ │ DB-GPT（复杂 Agent） │ │ - 数据应用 │ └────────────────────────────────┘

7.3 决策树

场景：企业级 BI 落地 ↓ Q1：团队有没有 Java 能力？ ├─ 是 → 候选 SuperSonic、SQLBOT └─ 否 → 候选 DB-GPT、WrenAI ↓ Q2：是否需要复杂语义治理？ ├─ 是 → 候选 SuperSonic、SQLBOT └─ 否 → 候选 WrenAI、DB-GPT ↓ Q3：是否需要 Agent 应用？ ├─ 是 → 加 DB-GPT └─ 否 → 单选 SuperSonic/SQLBOT ↓ Q4：预算和时间？ ├─ 充足 → SuperSonic + DB-GPT 组合 └─ 紧张 → WrenAI 单选

八、PoC 验证

8.1 为什么必须做 PoC？

核心理由：

Demo 不能替代 PoC。Demo 是厂商环境，PoC 是你的真实环境。

PoC（Proof of Concept）验证 =真实环境、真实数据、真实场景。

8.2 PoC 验证清单

必测场景：

• Top 5 业务查询场景
• 复杂多表查询（5+ 表 JOIN）
• 模糊查询（“上个月大概…”）
• 数据权限（不同角色看到不同数据）
• 性能压测（并发 10 个用户）

必测能力：

• 准确率（至少 80%）
• 响应时间（< 3 秒）
• 异常处理
• 权限管控

8.3 PoC 周期

推荐 PoC 周期：2-4 周 第 1 周：环境搭建 第 2 周：真实数据接入 第 3 周：业务场景验证 第 4 周：评估报告

8.4 PoC 评估报告

PoC 结束后，输出一份评估报告：

1. 测试场景覆盖度 2. 准确率测试结果 3. 性能测试结果 4. 用户体验评估 5. 问题清单 6. 最终推荐

九、推演示例：某金融公司的决策过程

本节的公司背景、人数、天数、准确率与效果数字全部是虚构的教学推演，不是任何真实项目的记录，也不构成对任何厂商产品效果的陈述。

9.1 公司背景

• 行业：金融
• 规模：5000 人
• 数据团队：30 人
• 业务团队：500+ 人

9.2 决策过程

第 1 阶段：明确场景（1 周）

核心场景： 1. 业务自助分析（80%） 2. 监管报表自动生成（15%） 3. 风险分析（5%） 关键约束： - 必须符合金融监管要求 - 必须支持细粒度权限 - 必须支持行级数据脱敏

第 2 阶段：定义标准（1 周）

场景匹配度：35% 语义管理：30% 合规能力：20% 易用性：10% 生态：5%

第 3 阶段：评估打分（2 周）

PoC 候选：SuperSonic、SQLBOT、DB-GPT 评估结果： - SuperSonic：8.2 分（语义管理强、合规能力强） - SQLBOT：7.8 分（权限强、商业支持好） - DB-GPT：7.0 分（生态强但合规弱）

第 4 阶段：最终决策（1 周）

决策： - 主体：SuperSonic（语义治理底座） - 补充：DB-GPT（复杂 Agent 应用） - 不用：WrenAI、SQLBOT 理由： - SuperSonic 语义层最完整 - 金融合规能力到位 - DB-GPT 补充复杂场景

第 5 阶段：试点落地（3 个月）

试点： - 选择 1 个业务线（信用卡） - 治理 20 个核心指标 - 100 个业务同学使用 - 准确率：88%

第 6 阶段：全公司推广（6 个月）

全公司部署： - 治理 200 个指标 - 1000+ 业务同学使用 - 准确率提升到 92% - 业务满意度：85%

9.3 关键经验

1. 场景定义要细：不能停留在"业务自助分析"这种大概念
2. 标准要量化：每个标准都要有具体评分细则
3. PoC 必须做：不能直接信厂商演示
4. 试点先行：不要一上来就铺全公司
5. 组合方案：单个项目不够就组合用

十、总结

第 3 步：评估打分

• 用加权评分表量化对比
• 用雷达图直观识别优劣势
• 多人打分避免主观偏差

第 4 步：最终决策

• 不能只看总分，要综合考量
• 必须做 PoC 验证
• 大公司优先考虑组合方案

5 大决策考量：

1. 加权评分排名
2. 风险评估结果
3. 团队实际能力
4. 实施成本
5. 未来扩展性

核心认知：

评分是参考，决策要综合考虑。PoC 是必须做的，不是可选的。

下一步预告：不同场景下的选型推荐矩阵——我会针对 10+ 个具体场景（小团队、大企业、金融、电商、客服等），给出明确的选型推荐。

本系列基于 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 原生）
• 榜单类分数与厂商宣传数字一律按「厂商宣称 / 第三方整理」标注口径引用，找不到一手出处的不写成事实。