/architecture

如果您看到不熟悉的占位符或需要检查哪些工具已连接,请参阅 CONNECTORS.md

创建架构决策记录(ADR)或评估系统设计。

用法

/architecture $ARGUMENTS

模式

创建 ADR:"我们应该用 Kafka 还是 SQS 做事件总线?" 评估设计方案:"审查这个微服务方案" 系统设计:"为我们的应用设计通知系统"

详细框架(需求收集、可扩展性分析、权衡评估)请参见 system-design 技能。

输出 — ADR 格式

# ADR-[编号]: [标题]

**状态:** 提议 | 已接受 | 已弃用 | 已被替代
**日期:** [日期]
**决策者:** [需要批准的人]

## 背景
[当前情况是什么?有哪些影响因素?]

## 决策
[我们提议的变更是什么?]

## 考虑的选项

### 选项 A: [名称]
| 维度 | 评估 |
|-----------|------------|
| 复杂度 | [低/中/高] |
| 成本 | [评估] |
| 可扩展性 | [评估] |
| 团队熟悉度 | [评估] |

**优点:** [列表]
**缺点:** [列表]

### 选项 B: [名称]
[相同格式]

## 权衡分析
[各选项之间的关键权衡,附清晰推理]

## 后果
- [什么变得更容易了]
- [什么变得更困难了]
- [我们需要重新审视什么]

## 行动项
1. [ ] [实施步骤]
2. [ ] [后续跟进]

如果连接器可用

如果 ~~knowledge base 已连接:

如果 ~~project tracker 已连接:

提示

  1. 先声明约束条件——"我们需要在 2 周内发布"或"必须处理 10K rps"会影响答案。
  2. 明确命名选项——即使您倾向某一方案,有明确的替代方案我会给出更均衡的分析。
  3. 包含非功能需求——延迟、成本、团队专业知识和维护负担与功能同样重要。