# Weighted Scoring

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

- Skill: `haomingz/weighted-scoring` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add haomingz/weighted-scoring`
- Raw SKILL.md: https://api.skillmd.com/api/skills/haomingz/weighted-scoring/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: haomingz (https://skillmd.com/u/haomingz)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/haomingz/weighted-scoring

---


# 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 的评分)
```

#### 输出格式

用标准表格呈现结果：

```markdown
| 维度 | 权重 | 方案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 排序法自动计算权重
- 检测评分一致性问题（如某维度零区分度）

**使用方式**：
```bash
# 完整评分计算 + 敏感性分析
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"