بنقرة واحدة
technical-decision
Technical decision making. 当用户需要做技术选型、讨论方案优劣、评估技术风险或做架构决策时使用此skill。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Technical decision making. 当用户需要做技术选型、讨论方案优劣、评估技术风险或做架构决策时使用此skill。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
季度竞品分析技能。每季度系统化收集市场竞品情报、构建竞争全景图、深度画像竞品、分析市场格局演变、提炼战略洞察,输出完整季度竞品分析报告。适用于产品战略规划、年度路线图制定、投融资汇报、高管决策支持等场景。当用户需要每季度深入了解竞争格局、识别战略机会、形成完整竞品分析报告时使用此 skill。
Git 标准操作流程 SOP,包含 init、add、commit、push、status、log、pull 等常用操作及自动检查验证。使用场景:用户要求执行 git 操作时。
API design specifications. 当用户需要设计 API、讨论 RESTful 规范、设计 GraphQL schema 或制定 API 规范时使用此skill。
Architecture quality assessment. 当用户需要评估架构质量、检查系统性能、分析安全风险或评估可扩展性时使用此skill。
System architecture design. 当用户需要设计系统架构、画架构图、讨论微服务拆分、CQRS、事件驱动、DDD等架构模式时使用此skill。
Code architecture review. 当用户需要评审代码架构、讨论设计模式、检查代码质量或进行代码评审时使用此skill。
| name | technical-decision |
| description | 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. [步骤]
## 监控指标
- [如何验证决策是否正确]