Technical decision making. 当用户需要做技术选型、讨论方案优劣、评估技术风险或做架构决策时使用此skill。
技术选型与决策技能，系统化分析技术方案并做出合理决策。
┌─────────────────────────────────────────────────────────┐
│ 决策流程 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 问题定义 │───▶│ 方案收集 │───▶│ 分析评估 │───▶│ 决策记录 │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────────┘
在讨论解决方案之前，先明确定义问题：
□ 核心问题是什么？（一句话描述）
□ 约束条件有哪些？（时间、成本、技术限制）
□ 利益相关者是谁？（业务、开发、运维、客户）
□ 成功标准是什么？（可量化的指标）
□ 决策的紧迫性？（紧急 vs 重要）
| 维度 | 考虑因素 |
|---|---|
| 功能性 | 功能满足度、扩展性、灵活性 |
| 性能 | 响应时间、吞吐量、并发处理 |
| 可靠性 | 可用性、容错性、数据一致性 |
| 可维护性 | 学习曲线、文档、社区活跃度 |
| 安全性 | 安全机制、漏洞历史、社区支持 |
| 成本 | 许可费用、人力成本、运维成本 |
| 团队适配度 | 现有技能、技术栈一致性 |
┌────────────────┬─────────┬─────────┬─────────┐
│ 维度 │ 方案A │ 方案B │ 方案C │
├────────────────┼─────────┼─────────┼─────────┤
│ 功能性 │ ●●●○ │ ●●●● │ ●●○○ │
│ 性能 │ ●●●● │ ●●○○ │ ●●●○ │
│ 可维护性 │ ●●●○ │ ●●●● │ ●●○○ │
│ 成本 │ ●●○○ │ ●●●● │ ●●●● │
│ 团队适配度 │ ●●●● │ ●●○○ │ ●●●○ │
├────────────────┼─────────┼─────────┼─────────┤
│ 总分 │ 17 │ 15 │ 14 │
└────────────────┴─────────┴─────────┴─────────┘
评分：●●●● = 4, ●●●○ = 3, ●●○○ = 2, ●○○○ = 1
| 需求 | 方案A | 方案B | 方案C | 权重 |
|---|---|---|---|---|
| 实时处理 | ✅ | ❌ | ✅ | 高 |
| 离线分析 | ✅ | ✅ | ❌ | 中 |
| 多租户 | ❌ | ✅ | ✅ | 高 |
| ... |
可能性
低 中 高
┌──────┬──────┬──────┐
高│ 中风险│ 高风险│高风险│
影 ├──────┼──────┼──────┤
响 中│ 低风险│ 中风险│高风险│
度 ├──────┼──────┼──────┤
低│ 低风险│ 低风险│中风险│
└──────┴──────┴──────┘
□ 学习曲线有多陡？（1-5分）
□ 迁移成本有多高？
□ 退出策略是什么？
□ 供应商锁定风险？
# ADR-[编号]: [决策标题]
## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
## Context
[描述做出这个决策的情况，包括约束、问题定义]
## Decision
[描述实际做出的决策，使用主动语气如"我们将采用..."]
## Options Considered
### 选项A: [名称]
**优点**: [列表]
**缺点**: [列表]
### 选项B: [名称]
**优点**: [列表]
**缺点**: [列表]
## Consequences
### 正面
- [列表]
### 负面
- [列表]
### 权衡
[如果适用，描述需要做的权衡]
## Related Decisions
[相关 ADR 链接]
## Notes
[其他备注]
| 场景 | 推荐 | 备选 |
|---|---|---|
| OLTP / 事务系统 | PostgreSQL | MySQL |
| OLAP / 分析 | ClickHouse | PostgreSQL |
| 缓存 | Redis | Memcached |
| 文档存储 | MongoDB | PostgreSQL (JSONB) |
| 图数据 | Neo4j | RedisGraph |
| 时序数据 | InfluxDB | TimescaleDB |
| 搜索 | Elasticsearch | Meilisearch |
| 策略 | 适用场景 | 一致性 | 复杂度 |
|---|---|---|---|
| Cache-Aside | 读多写少 | 最终一致 | 低 |
| Write-Through | 数据一致性要求高 | 强一致 | 中 |
| Write-Behind | 写入性能重要 | 最终一致 | 中 |
| Read-Through | 简化读取逻辑 | 最终一致 | 低 |
| 需求 | 推荐 |
|---|---|
| 简单队列 | RabbitMQ |
| 高吞吐 | Kafka |
| 低延迟 | Redis Streams |
| 事务消息 | RocketMQ |
| 云原生 | AWS SQS/SNS |
做出决策前，问自己：
□ 我是否理解了所有选项的权衡？
□ 我是否考虑了短期和长期影响？
□ 团队是否理解并认同这个决策？
□ 如果决策错误，恢复成本有多高？
□ 是否有足够的信息支持这个决策？
□ 是否有可能改变的技术趋势？
□ 决策是否可逆？
# 技术决策报告
## 决策标题
[简明扼要的标题]
## 问题陈述
[清晰描述需要决策的问题]
## 约束条件
- [列表]
## 候选方案
### 方案A: [名称]
- **描述**: [简述]
- **优点**: [列表]
- **缺点**: [列表]
- **成本**: [估算]
- **风险**: [评估]
### 方案B: [名称]
...
## 推荐方案
[方案名称]
## 推荐理由
[解释为什么这个方案是最佳的]
## 实施计划
1. [步骤]
2. [步骤]
3. [步骤]
## 监控指标
- [如何验证决策是否正确]