加权评分决策矩阵Skill weighted-scoring

一个系统化的多准则决策框架,用于在技术选型、供应商选择、方案对比等场景中,通过定义维度、分配权重、逐项评分和敏感性分析,辅助用户做出理性决策。关键词:决策矩阵、加权评分、技术选型、方案对比、供应商评估、多维度打分、权重分配、敏感性分析。

管理咨询 0 次安装 2 次浏览 更新于 7/8/2026

name: 加权评分决策矩阵 description: “加权评分决策矩阵框架,用于技术选型、供应商选择、方案对比等多准则决策场景。引导用户系统化地明确评估维度、分配权重、逐项评分,并通过敏感性分析验证结论的稳健性。当用户提到决策矩阵、加权评分、技术选型、方案对比、供应商评估、build vs buy、多维度打分、权重分配、评分表、选型对比,或询问“选哪个方案好”、“帮我比较几个选项”时触发。” license: MIT

Decision Matrix — 加权评分决策框架

系统化的多准则决策方法论。适用于技术选型、供应商选择、Build vs Buy、工具对比、招聘评估等需要在多个维度上比较多个方案的场景。

Quick Start

引导用户完成 5 步:

  1. 列出候选方案(2-7 个)
  2. 定义评估维度(4-8 个)
  3. 分配权重(总和 = 100%)
  4. 逐项评分(1-5 分制)
  5. 计算加权总分 + 敏感性分析

用户只需说:

“帮我做一个技术选型,比较 PostgreSQL、MySQL 和 MongoDB,用于我们的电商订单系统”

Agent 会引导用户逐步完成整个决策流程。


一、完整流程详解

Step 1:明确决策上下文

在开始评分前,先厘清以下信息(用提问方式引导用户):

问题 目的
这个决策要解决什么问题? 聚焦真实需求,避免为比较而比较
有哪些候选方案? 确定比较对象(建议 2-7 个)
谁是关键利益相关者? 不同角色关注不同维度
决策时间节点? 影响信息收集深度
有没有一票否决项? 识别硬约束,先过滤不可行方案

硬约束过滤:如果某方案不满足任何一票否决项(如预算上限、合规要求、技术兼容性),直接排除,不进入评分环节。

Step 2:定义评估维度

维度选择原则

  • MECE 原则:维度之间互不重叠、合在一起完整覆盖
  • 可评估性:每个维度必须能给出有区分度的评分
  • 数量控制:4-8 个维度最佳。少于 4 个决策太粗糙,多于 8 个信号被噪声稀释

常用维度模板

技术选型

维度 说明 评估方法
功能匹配度 满足核心需求的程度 列出需求清单,逐项对比
性能 延迟、吞吐量、并发能力 benchmark 数据或官方文档
可扩展性 水平/垂直扩展能力 架构设计分析
社区与生态 文档、社区活跃度、第三方集成 GitHub stars/issues、Stack Overflow 活跃度
学习成本 团队上手难度 团队现有技能匹配度
运维复杂度 部署、监控、故障排查难度 运维经验或文档评估
成本 许可费、基础设施、人力成本 TCO(总拥有成本)估算
长期风险 厂商锁定、技术过时风险 开源/闭源、市场趋势

供应商选择

维度 说明
产品能力 功能覆盖度、易用性、定制性
价格与商务条款 总费用、付款方式、折扣条件
技术支持 SLA、响应时间、支持渠道
安全合规 数据安全、认证资质、合规能力
集成能力 API、SDK、与现有系统的兼容性
公司实力 财务稳定性、市场份额、客户案例

Build vs Buy

维度 说明
需求匹配度 定制化需求满足程度
上线速度 从决策到可用的时间
总成本(3年) 开发/购买+维护+机会成本
团队能力匹配 自建是否在团队能力范围内
战略价值 是否构建核心竞争力
维护负担 长期维护的人力和复杂度

Step 3:分配权重

权重反映各维度的相对重要性。总和必须为 100%。

方法 A:直接分配法(快速)

适合维度少(≤5)或决策者对优先级有明确判断的场景。

操作:让用户直接给每个维度分配百分比,总和 = 100%。

提示用户的引导话术:

“请把 100 分分配到这些维度上。最重要的维度给更多分。不需要精确,先凭直觉分,我们之后可以调整。”

方法 B:排序分配法(推荐)

适合用户对权重没有明确数字感的场景。

步骤:

  1. 先让用户把维度按重要性排序(最重要排第一)
  2. 用 ROC(Rank Order Centroid)公式自动算权重:
第 k 个维度的权重 = (1/k + 1/(k+1) + ... + 1/n) / n

其中 n = 维度总数,k = 该维度的排名(1 = 最重要)
排名 4 维度权重 6 维度权重 8 维度权重
1 52.1% 40.8% 34.0%
2 27.1% 24.2% 21.5%
3 14.6% 15.8% 15.2%
4 6.3% 10.3% 11.1%
5 6.1% 7.9%
6 2.8% 5.4%
7 3.3%
8 1.6%

不需要手动计算,可使用 scripts/decision_matrix.py 自动生成。

方法 C:两两对比法(精确)

适合团队决策、维度较多(>5)、需要减少主观偏差的场景。

步骤:

  1. 把所有维度两两配对
  2. 对每一对,判断哪个更重要(赢 = 1,输 = 0,平 = 0.5)
  3. 每个维度的得分 = 赢的次数 / 总对比次数

示例(4 维度:A、B、C、D):

对比 结果
A vs B A 赢
A vs C C 赢
A vs D A 赢
B vs C C 赢
B vs D 平局
C vs D C 赢

结果:A=2/6=33%, B=0.5/6=8%, C=3/6=50%, D=0.5/6=8%。归一化为 100%。

权重质量检查

分配完权重后,做以下校验:

  • [ ] 极端检验:权重最高的维度是否真的比最低的重要那么多?
  • [ ] 分辨力检验:是否有维度权重 < 5%?如果是,考虑合并或删除
  • [ ] 覆盖检验:前两大维度权重之和是否 > 70%?如果是,其他维度是否真的不重要
  • [ ] 利益相关者检验:如果换一个角色来分配,权重会有很大不同吗?

Step 4:逐项评分

评分标尺(1-5 分制)

必须在评分前定义每个分数的含义,否则评分者之间的标准不一致:

分数 通用含义 示例(以"性能"维度为例)
5 卓越,显著超出需求 延迟 <10ms,轻松支撑 10x 预期流量
4 良好,满足需求并有余量 延迟 <50ms,可支撑 3x 预期流量
3 达标,刚好满足当前需求 延迟 <100ms,满足当前流量
2 不足,需要额外工作才能满足需求 延迟 100-500ms,需要优化
1 严重不足,基本不可用 延迟 >500ms,无法满足基本需求

评分规范

  • 先定锚点:对每个维度,先快速判断哪个方案最好(5分)、哪个最差(1-2分),再给中间方案评分
  • 维度优先:按维度逐列评分(而非按方案逐行),这样跨方案比较更公正
  • 有据可依:每个评分附带一句话理由,避免事后遗忘评分依据
  • 区分度:如果某维度所有方案评分相同,说明该维度没有区分价值,考虑移除

Step 5:计算与分析

加权总分计算

方案 X 的总分 = Σ(维度 i 的权重 × 方案 X 在维度 i 的评分)

输出格式

用标准表格呈现结果:

| 维度 | 权重 | 方案A | 方案B | 方案C |
|------|------|------|------|------|
| 功能匹配度 | 30% | 4 (1.20) | 5 (1.50) | 3 (0.90) |
| 性能 | 25% | 5 (1.25) | 3 (0.75) | 4 (1.00) |
| 成本 | 25% | 3 (0.75) | 4 (1.00) | 5 (1.25) |
| 学习成本 | 20% | 4 (0.80) | 2 (0.40) | 3 (0.60) |
| **加权总分** | **100%** | **4.00** | **3.65** | **3.75** |
| **排名** | | **1** | **3** | **2** |

括号中为该维度的加权得分(权重 × 评分)。


二、敏感性分析(关键步骤,不可跳过)

加权评分结果取决于权重和评分的假设。如果第1名和第2名的总分差距 < 0.3 分(满分5分制),必须做敏感性分析

分析方法

1. 权重波动测试

对每个关键维度,将其权重 ±10%(其他维度等比例调整),观察排名是否变化:

原始权重:功能 30%, 性能 25%, 成本 25%, 学习 20%
测试 1:功能 40%, 性能 21.4%, 成本 21.4%, 学习 17.1%  → 排名变了吗?
测试 2:功能 20%, 性能 28.6%, 成本 28.6%, 学习 22.9%  → 排名变了吗?

2. 评分波动测试

对评分有争议的单元格 ±1 分,观察排名是否变化。

3. 逆转点分析

计算"要让第2名反超第1名,某个维度的权重/评分需要变化多少"。如果只需微小变化就能逆转,说明两个方案实质上难分高下。

分析结论模板

结论:方案 A 以 4.00 分领先方案 C 的 3.75 分(差距 0.25 分)。敏感性分析显示,当"成本"维度权重提升至 35%(+10%)时,方案 C 反超方案 A。建议关注成本维度的权重合理性,或进一步收集成本数据以提高评分准确性。


三、认知偏差检查清单

在完成评分后,逐项检查以下常见偏差:

偏差 表现 应对方法
锚定效应 第一个评估的方案分数偏高 评完所有方案后,回头重新审视第一个
光环效应 对某方案整体印象好,所有维度都给高分 按维度逐列评,不要按方案逐行评
现状偏好 倾向于选现在已经在用的方案 假设从零开始选择,排除迁移成本的干扰
确认偏差 先有结论,再找证据支持 让不同立场的人分别评分,对比差异
沉没成本 因为已经投入了,不愿意换方案 明确区分"过去投入"和"未来价值"
可得性偏差 最近听说某方案好/坏,影响判断 要求每个评分附带客观证据

四、脚本工具

提供 scripts/decision_matrix.py 用于自动化计算:

功能

  • 输入维度、权重、评分,输出加权评分表(Markdown 格式)
  • 自动进行敏感性分析(权重 ±10% 波动测试)
  • ROC 排序法自动计算权重
  • 检测评分一致性问题(如某维度零区分度)

使用方式

# 完整评分计算 + 敏感性分析
python3 scripts/decision_matrix.py --json '{
  "dimensions": ["功能", "性能", "成本", "学习成本"],
  "weights": [30, 25, 25, 20],
  "options": ["PostgreSQL", "MySQL", "MongoDB"],
  "scores": {
    "PostgreSQL": [4, 5, 3, 4],
    "MySQL":      [5, 3, 4, 2],
    "MongoDB":    [3, 4, 5, 3]
  }
}'

# ROC 权重计算:只需提供维度排名(从最重要到最不重要)
python3 scripts/decision_matrix.py --roc '["功能", "性能", "成本", "学习成本"]'

五、完整案例:电商系统数据库选型

背景

  • 电商订单系统,日订单量 10 万
  • 团队 5 人,主要经验在关系型数据库
  • 预算有限,优先开源方案

Step 1:候选方案

PostgreSQL、MySQL、MongoDB(硬约束过滤:Oracle 因许可费超预算排除)

Step 2:维度定义

功能匹配度、性能、可扩展性、社区生态、学习成本、运维复杂度、成本

Step 3:权重(排序分配法)

用户排序:功能 > 性能 > 成本 > 学习成本 > 社区 > 运维 > 可扩展性

ROC 权重:功能 37.0%, 性能 22.8%, 成本 15.6%, 学习 10.9%, 社区 7.3%, 运维 4.4%, 扩展 2.0%

Step 4:评分

维度 权重 PostgreSQL MySQL MongoDB
功能匹配度 37.0% 5 4 3
性能 22.8% 4 4 5
成本 15.6% 5 5 4
学习成本 10.9% 3 4 2
社区生态 7.3% 5 5 4
运维复杂度 4.4% 3 4 2
可扩展性 2.0% 4 3 5

Step 5:结果

  • PostgreSQL: 4.45 分 → 排名第 1
  • MySQL: 4.21 分 → 排名第 2
  • MongoDB: 3.57 分 → 排名第 3

敏感性分析:PostgreSQL 与 MySQL 差距 0.24 分。敏感性分析显示所有维度权重 ±10% 波动后排名不变,虽然分差较小,但结论对权重变化不敏感,可信度较高。


六、适用场景与局限性

适用场景

  • 候选方案 2-7 个,评估维度 4-8 个
  • 决策需要多人参与或需要留档记录
  • 需要向利益相关者解释"为什么选这个"

不适用场景

  • 只有 2 个选项且差异明显 → 直接 Pros/Cons 列表更高效
  • 决策高度依赖单一因素 → 不需要多维度框架
  • 信息极度不完整 → 评分无意义,先做信息收集
  • 涉及强感情因素的个人决策 → 理性框架可能掩盖真实偏好

常见误区

  1. 维度过多:超过 8 个维度导致每个维度权重都很低,区分度下降
  2. 虚假精确:3.72 vs 3.68 不代表 A 真的比 B 好——注意敏感性分析
  3. 忽略定性判断:矩阵是辅助工具,不是替代直觉的算法
  4. 一次定终身:决策条件变化时应重新评估

参考文档

  • Keeney, R. & Raiffa, H. — Decisions with Multiple Objectives(多目标决策经典教材)
  • Belton, V. & Stewart, T. — Multiple Criteria Decision Analysis(MCDA 实务指南)
  • ROC 权重法 — Barron & Barrett (1996), “Decision quality using ranked attribute weights”