架构决策记录 是做什么的？
在编码会话期间即时捕获架构决策。与其让决策只存在于 Slack 聊天、PR 评论或某人的记忆中，此技能会生成结构化的 ADR 文档，与代码共存。
何时触发
- 用户明确说出“让我们记录这个决策”或“记录此 ADR”
- 用户在重大备选方案之间做选择（框架、库、模式、数据库、API 设计）
- 用户说“我们决定...”或“我们之所以选择 X 而不是 Y，是因为...”
- 用户问“我们为什么选择了 X？”（读取现有的 ADR）
- 在规划阶段讨论架构权衡时
ADR 格式
采用 Michael Nygard 提出的轻量级 ADR 格式，并针对 AI 辅助开发进行了调整：
# ADR-NNNN：[决策标题]
**日期**：YYYY-MM-DD
**状态**：proposed | accepted | deprecated | superseded by ADR-NNNN
**决策者**：[参与人员]
## 上下文
促使此决策或变更的问题是什么？
[2-5 句话描述情况、约束条件和影响因素]
## 决策
我们正在提议或执行什么变更？
[1-3 句话明确陈述决策]
## 备选方案
### 方案 1：[名称]
- **优点**：[好处]
- **缺点**：[缺点]
- **为何不选**：[拒绝此方案的具体原因]
### 方案 2：[名称]
- **优点**：[好处]
- **缺点**：[缺点]
- **为何不选**：[拒绝此方案的具体原因]
## 后果
由于此变更，哪些事情变得更容易或更困难？
### 积极
- [好处 1]
- [好处 2]
### 消极
- [权衡 1]
- [权衡 2]
### 风险
- [风险与缓解措施]
工作流程
捕获新的 ADR
当检测到决策时刻时：
- 初始化（仅首次） —— 如果
docs/adr/不存在，请在创建目录、预填充索引表头（见下方 ADR 索引格式）的README.md以及供手动使用的空白template.md之前，先征求用户确认。未经明确同意，不得创建文件。 - 识别决策 —— 提取核心的架构选择
- 收集上下文 —— 是什么问题引发了此决策？存在哪些约束？
- 记录备选方案 —— 考虑了哪些其他选项？为什么被拒绝？
- 陈述后果 —— 有哪些权衡？哪些变得更容易/更困难？
- 分配编号 —— 扫描
docs/adr/中现有的 ADR，然后递增编号 - 确认并写入 —— 向用户展示 ADR 草稿以供审阅。只有在用户明确批准后，才写入
docs/adr/NNNN-decision-title.md。如果用户拒绝，则放弃草稿，不写入任何文件。 - 更新索引 —— 追加到
docs/adr/README.md
读取现有的 ADR
当用户问“我们为什么选择了 X？”时：
- 检查
docs/adr/是否存在 —— 如果不存在，回复：“此项目中未找到 ADR。是否希望开始记录架构决策？” - 如果存在，扫描
docs/adr/README.md索引以查找相关条目 - 读取匹配的 ADR 文件并展示“上下文”和“决策”章节
- 如果未找到匹配项，回复：“未找到该决策的 ADR。是否现在记录一个？”
ADR 目录结构
docs/
└── adr/
├── README.md ← 所有 ADR 的索引
├── 0001-use-nextjs.md
├── 0002-postgres-over-mongo.md
├── 0003-rest-over-graphql.md
└── template.md ← 供手动使用的空白模板
ADR 索引格式
# 架构决策记录
| ADR | 标题 | 状态 | 日期 |
|-----|------|------|------|
| [0001](0001-use-nextjs.md) | 使用 Next.js 作为前端框架 | accepted | 2026-01-15 |
| [0002](0002-postgres-over-mongo.md) | 主数据存储选用 PostgreSQL 而非 MongoDB | accepted | 2026-01-20 |
| [0003](0003-rest-over-graphql.md) | REST API 而非 GraphQL | accepted | 2026-02-01 |
决策检测信号
在对话中留意这些表明架构决策的模式：
显式信号
- “我们选 X”
- “我们应该用 X 而不是 Y”
- “这个权衡是值得的，因为...”
- “把这个记录为 ADR”
隐式信号（建议记录 ADR —— 未经用户确认不要自动创建）
- 比较两个框架或库并得出结论
- 做出有理由说明的数据库 Schema 设计方案选择
- 在架构模式之间做选择（单体 vs 微服务，REST vs GraphQL）
- 决定认证/授权策略
- 评估备选方案后选择部署基础设施
好的 ADR 应具备的特征
应当
- 具体 —— 写“使用 Prisma ORM”，而不是“使用一个 ORM”
- 记录原因 —— 理由比“做了什么”更重要
- 包含被拒绝的备选方案 —— 未来的开发者需要知道考虑过哪些选项
- 诚实地陈述后果 —— 每个决策都有权衡
- 保持简洁 —— 一份 ADR 应该能在 2 分钟内读完
- 使用现在时态 —— 写“我们使用 X”，而不是“我们将使用 X”
不应
- 记录琐碎决策 —— 变量命名或格式选择不需要 ADR
- 写成论文 —— 如果上下文章节超过 10 行，就太长了
- 遗漏备选方案 —— “我们就是选了它”不是有效的理由
- 补记时不加标记 —— 如果记录一个过去的决策，请注明原始日期
- 让 ADR 过时 —— 被取代的决策应引用其替代者
ADR 生命周期
proposed → accepted → [deprecated | superseded by ADR-NNNN]
- proposed：决策正在讨论中，尚未承诺
- accepted：决策已生效并正在遵循
- deprecated：决策不再相关（例如，功能已移除）
- superseded：更新的 ADR 取代了此 ADR（务必链接替代者）
值得记录的决策类别
| 类别 | 示例 |
|---|---|
| 技术选型 | 框架、语言、数据库、云提供商 |
| 架构模式 | 单体 vs 微服务、事件驱动、CQRS |
| API 设计 | REST vs GraphQL、版本化策略、认证机制 |
| 数据建模 | Schema 设计、规范化决策、缓存策略 |
| 基础设施 | 部署模型、CI/CD 管道、监控栈 |
| 安全 | 认证策略、加密方法、密钥管理 |
| 测试 | 测试框架、覆盖率目标、E2E 与集成测试的平衡 |
| 流程 | 分支策略、评审流程、发布节奏 |
与其他技能的集成
- 规划器代理：当规划器提议架构变更时，建议创建 ADR
- 代码审查代理：标记那些引入了架构变更但缺少相应 ADR 的 PR