| name | weighted-scoring |
| description | 加权评分决策矩阵框架，用于技术选型、供应商选择、方案对比等多准则决策场景。引导用户系统化地明确评估维度、分配权重、逐项评分，并通过敏感性分析验证结论的稳健性。当用户提到决策矩阵、加权评分、技术选型、方案对比、供应商评估、build vs buy、多维度打分、权重分配、评分表、选型对比，或询问“选哪个方案好”、“帮我比较几个选项”时触发。 |
| license | MIT |
Decision Matrix — 加权评分决策框架
系统化的多准则决策方法论。适用于技术选型、供应商选择、Build vs Buy、工具对比、招聘评估等需要在多个维度上比较多个方案的场景。
Quick Start
引导用户完成 5 步：
- 列出候选方案（2-7 个）
- 定义评估维度（4-8 个）
- 分配权重（总和 = 100%）
- 逐项评分（1-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：排序分配法（推荐）
适合用户对权重没有明确数字感的场景。
步骤：
- 先让用户把维度按重要性排序（最重要排第一）
- 用 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，输 = 0，平 = 0.5）
- 每个维度的得分 = 赢的次数 / 总对比次数
示例（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%。
权重质量检查
分配完权重后，做以下校验：
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]
}
}'
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 列表更高效
- 决策高度依赖单一因素 → 不需要多维度框架
- 信息极度不完整 → 评分无意义，先做信息收集
- 涉及强感情因素的个人决策 → 理性框架可能掩盖真实偏好
常见误区
- 维度过多：超过 8 个维度导致每个维度权重都很低，区分度下降
- 虚假精确：3.72 vs 3.68 不代表 A 真的比 B 好——注意敏感性分析
- 忽略定性判断：矩阵是辅助工具，不是替代直觉的算法
- 一次定终身：决策条件变化时应重新评估
参考文档
- 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"
