---

name: weighted-scoring 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"