tech-evaluation

---
name: tech-evaluation
version: 1.0.0
last_updated: 2026-04-08
repository: https://github.com/312362115/claude
description: >
  技术选型技能：在多个候选方案中做出有依据的决策。
  和 deep-research 的区别：deep-research 是广度调研（搞清楚一件事），
  tech-evaluation 是聚焦决策（A 还是 B，选哪个，给结论）。
  包含权重矩阵、PoC 验证流程、决策报告模板。
  触发词：选型、选哪个、A 还是 B、对比、评估方案、用什么框架、用什么库。
  触发场景：task-start 方案阶段遇到选型问题、引入新依赖前、架构决策。
  即使用户没有说"选型"，只要意图是"在几个方案中做选择"，都应触发此技能。
---

# 技术选型（Tech Evaluation）

> 选型的核心不是"哪个更好"，而是"在我们的场景下哪个更合适"。
> 没有最好的技术，只有最合适的技术。

---

## 第一步：定义选型问题

用 `AskUserQuestion` 明确以下信息：

| 要素 | 问什么 | 为什么重要 |
|------|--------|-----------|
| **要解决的问题** | 选型是为了解决什么？ | 锚定评估标准 |
| **候选方案** | 已经有哪些候选？需要我帮忙发现更多吗？ | 确定评估范围 |
| **硬性约束** | 必须满足的条件（许可证、语言、兼容性） | 先排除不合格的 |
| **优先维度** | 最看重什么？（性能 / 生态 / 学习成本 / 成本） | 决定权重 |
| **决策时间** | 需要多深入？快速判断还是深度评估？ | 控制投入 |

---

## 第二步：快速筛选

### 2.1 排除不合格的

用硬性约束做第一轮筛选：

```markdown
## 候选方案筛选

| 候选 | 约束 1（MIT 许可） | 约束 2（支持 TS） | 约束 3（活跃维护） | 结果 |
|------|-------------------|-------------------|-------------------|------|
| 方案 A | ✅ | ✅ | ✅ | 进入评估 |
| 方案 B | ✅ | ❌ | ✅ | 排除 |
| 方案 C | ✅ | ✅ | ❌（2 年无更新） | 排除 |
```

### 2.2 快速判断路径

如果筛选后只剩 1-2 个候选，且差异明显：
- 直接给出推荐 + 理由，不需要走完整评估
- 记录决策到 spec 文档中即可

如果筛选后有 2-3 个势均力敌的候选 → 进入第三步完整评估。

---

## 第三步：多维度评估

### 3.1 构建评估矩阵

根据用户关注的维度，构建权重矩阵：

```markdown
## 评估维度与权重

| 维度 | 权重 | 说明 |
|------|------|------|
| 功能匹配度 | 30% | 是否满足核心需求 |
| 性能 | 25% | 对应场景下的实际表现 |
| 生态与社区 | 20% | 文档质量、社区活跃度、第三方集成 |
| 学习成本 | 15% | 团队上手难度 |
| 运维成本 | 10% | 部署复杂度、监控、升级成本 |
```

**权重确定方式**：
- 用户明确说了优先级 → 直接用
- 用户没说 → 给出建议权重，让用户确认

### 3.2 逐维度评估

对每个维度，用**事实和数据**评估，不用"感觉"：

| 维度 | 怎么评估 | 数据来源 |
|------|---------|---------|
| 功能匹配度 | 列出需求清单，逐项检查每个候选是否支持 | 官方文档、GitHub issues |
| 性能 | 找 benchmark 数据，或自己跑 PoC 测试 | 官方 benchmark、第三方评测、自测 |
| 生态与社区 | GitHub stars/issues 响应速度、npm 周下载量、Stack Overflow 问题数 | GitHub、npm、Stack Overflow |
| 学习成本 | 文档质量、API 设计是否直觉、有无迁移指南 | 官方文档、教程资源 |
| 运维成本 | 部署方式、配置复杂度、升级历史（有无 breaking changes） | CHANGELOG、升级指南 |

### 3.3 PoC 验证（可选但推荐）

对关键维度，**写代码验证**比看文档更可靠：

```markdown
## PoC 验证

### 验证目标
用方案 A 和方案 B 分别实现 <核心场景>，对比：
- 代码量和复杂度
- 实际性能数据
- 遇到的坑

### 验证结果
| 指标 | 方案 A | 方案 B |
|------|--------|--------|
| 代码行数 | 120 行 | 85 行 |
| 响应时间(p95) | 23ms | 18ms |
| 遇到的问题 | 文档缺失，靠看源码 | 顺利，文档完整 |
```

PoC 不需要做完整功能，只需要验证**最不确定的维度**。

---

## 第四步：综合评分与决策

### 4.1 评分汇总

```markdown
## 综合评分

| 维度 | 权重 | 方案 A | 方案 B | 方案 C |
|------|------|--------|--------|--------|
| 功能匹配度 | 30% | 9 | 8 | 7 |
| 性能 | 25% | 7 | 9 | 8 |
| 生态与社区 | 20% | 8 | 7 | 9 |
| 学习成本 | 15% | 6 | 8 | 7 |
| 运维成本 | 10% | 7 | 8 | 6 |
| **加权总分** | | **7.65** | **8.05** | **7.50** |
```

### 4.2 给出决策

```markdown
## 选型决策

**推荐：方案 B**

### 核心理由
- 加权总分最高（8.05）
- 在最看重的性能维度（权重 25%）上明显领先
- PoC 验证中开发体验最好

### 取舍说明
- 放弃方案 A 的原因：学习成本较高，团队没有相关经验
- 放弃方案 C 的原因：社区活跃但功能匹配度不足

### 风险提示
- 方案 B 的社区规模较小，未来可能面临维护风险
- 建议：核心功能不过度依赖其独有特性，保持可替换性
```

---

## 第五步：输出选型报告

选型结论写入 spec 文档（调 writing skill 的技术文档模式），至少包含：

- **背景与动机**：为什么需要选型
- **候选方案**：有哪些选项
- **评估过程**：评估维度、权重、数据来源
- **PoC 结果**：如果做了验证
- **决策与取舍**：选了什么、为什么选它、放弃了什么

---

## 选型准则

- **场景优先**：不存在"最好的"技术，只有"最合适当前场景的"技术
- **数据说话**：每个评分都要有事实依据，不凭印象打分
- **验证不确定性**：最不确定的维度用 PoC 验证，不靠猜
- **考虑团队**：技术本身好不等于团队用得好，学习成本是真实成本
- **留退路**：优先选不锁定的方案，保持可替换性
- **不过度评估**：2 个候选差异明显就直接选，不需要搞 5 维 10 分的矩阵

---

## 与其他 skill 的关系

```
task-start（方案阶段遇到选型）→ tech-evaluation（评估决策）
deep-research（需要广度调研时）← tech-evaluation 按需调用
tech-evaluation → writing（输出选型报告到 spec）
```

**tech-evaluation vs deep-research**：
- tech-evaluation：**必须给结论**。"选 A，因为 XYZ"
- deep-research：**不一定给结论**。"目前市场格局是这样，趋势是那样"
- 选型前如果对候选方案不够了解，可以先用 deep-research 调研，再用 tech-evaluation 决策