用途
Architecture Decision Records 技能用于在编码会话中实时捕获架构决策。它避免决策只存在于 Slack 讨论、PR 评论或某人的记忆中，而是生成结构化的 ADR 文档，与代码放在一起。
何时激活
- 用户明确说“let's record this decision”或“ADR this”
- 用户在重要备选方案之间做出选择（框架、库、模式、数据库、API 设计）
- 用户说“we decided to...”或“the reason we're doing X instead of Y is...”
- 用户询问“why did we choose X?”（读取已有 ADR）
- 在规划阶段讨论架构权衡时
ADR 格式
采用 Michael Nygard 提出的轻量 ADR 格式，并针对 AI 辅助开发做了适配：
# ADR-NNNN: [Decision Title]
Date: YYYY-MM-DD
Status: proposed | accepted | deprecated | superseded by ADR-NNNN
Deciders: [who was involved]
Context
What is the issue that we're seeing that is motivating this decision or change?
[2-5 sentences describing the situation, constraints, and forces at play]
Decision
What is the change that we're proposing and/or doing?
[1-3 sentences stating the decision clearly]
Alternatives Considered
Alternative 1: [Name]
Pros: [benefits]
Cons: [drawbacks]
Why not: [specific reason this was rejected]
Alternative 2: [Name]
Pros: [benefits]
Cons: [drawbacks]
Why not: [specific reason this was rejected]
Consequences
What becomes easier or more difficult to do because of this change?
Positive
[benefit 1]
[benefit 2]
Negative
[trade-off 1]
[trade-off 2]
Risks
[risk and mitigation]
工作流程
捕获新 ADR
当检测到决策时刻时：
- 初始化（仅首次） — 如果
docs/adr/不存在，在创建目录、带有索引表头的README.md以及供手动使用的空白template.md之前，先向用户确认。未经明确同意不要创建文件。 - 识别决策 — 提取正在做出的核心架构选择
- 收集背景 — 是什么问题促成了这个决策？存在哪些约束？
- 记录备选方案 — 还考虑过哪些其他选项？为什么被拒绝？
- 陈述后果 — 有哪些权衡？什么变得更容易/更难？
- 分配编号 — 扫描
docs/adr/中已有的 ADR 并递增 - 确认并写入 — 将 ADR 草稿提交给用户审阅。只有在明确批准后才写入
docs/adr/NNNN-decision-title.md。如果用户拒绝，丢弃草稿，不写入任何文件。 - 更新索引 — 追加到
docs/adr/README.md
读取已有 ADR
当用户询问“why did we choose X?”时：
- 检查
docs/adr/是否存在 — 如果不存在，回复：“No ADRs found in this project. Would you like to start recording architectural decisions?” - 如果存在，扫描
docs/adr/README.md索引中的相关条目 - 读取匹配的 ADR 文件并呈现 Context 和 Decision 部分
- 如果未找到匹配项，回复：“No ADR found for that decision. Would you like to record one now?”
ADR 目录结构
docs/
└── adr/
├── README.md ← index of all ADRs
├── 0001-use-nextjs.md
├── 0002-postgres-over-mongo.md
├── 0003-rest-over-graphql.md
└── template.md ← blank template for manual use
ADR 索引格式
# Architecture Decision Records
| ADR | Title | Status | Date |
|-----|-------|--------|------|
| [0001](0001-use-nextjs.md) | Use Next.js as frontend framework | accepted | 2026-01-15 |
| [0002](0002-postgres-over-mongo.md) | PostgreSQL over MongoDB for primary datastore | accepted | 2026-01-20 |
| [0003](0003-rest-over-graphql.md) | REST API over GraphQL | accepted | 2026-02-01 |
决策检测信号
留意对话中表明架构决策的这些模式：
显式信号
- “Let's go with X”
- “We should use X instead of Y”
- “The trade-off is worth it because...”
- “Record this as an ADR”
隐式信号（建议记录 ADR — 未经用户确认不要自动创建）
- 比较两个框架或库并得出结论
- 在说明理由的情况下做出数据库 schema 设计选择
- 在架构模式之间选择（单体 vs 微服务、REST vs GraphQL）
- 决定认证/授权策略
- 在评估备选方案后选择部署基础设施
什么造就好的 ADR
要
- 具体 — “Use Prisma ORM”而不是“use an ORM”
- 记录原因 — 理由比内容更重要
- 包含被拒绝的备选方案 — 未来的开发者需要知道考虑过什么
- 诚实陈述后果 — 每个决策都有权衡
- 保持简短 — ADR 应能在 2 分钟内读完
- 使用现在时 — “We use X”而不是“We will use X”
不要
- 记录琐碎决策 — 变量命名或格式选择不需要 ADR
- 写长篇大论 — 如果背景部分超过 10 行，就太长了
- 省略备选方案 — “we just picked it”不是有效理由
- 补录时不标注 — 如果记录过去的决策，注明原始日期
- 让 ADR 过时 — 被取代的决策应引用其替代者
ADR 生命周期
proposed → accepted → [deprecated | superseded by ADR-NNNN]
- proposed：决策正在讨论中，尚未确定
- accepted：决策已生效并正在遵循
- deprecated：决策不再相关（例如功能已移除）
- superseded：更新的 ADR 取代了它（始终链接替代者）
值得记录的决策类别
| 类别 | 示例 |
|---|---|
| 技术选择 | 框架、语言、数据库、云提供商 |
| 架构模式 | 单体 vs 微服务、事件驱动、CQRS |
| API 设计 | REST vs GraphQL、版本策略、认证机制 |
| 数据建模 | Schema 设计、规范化决策、缓存策略 |
| 基础设施 | 部署模型、CI/CD 流水线、监控栈 |
| 安全 | 认证策略、加密方式、密钥管理 |
| 测试 | 测试框架、覆盖率目标、E2E 与集成的平衡 |
| 流程 | 分支策略、评审流程、发布节奏 |
与其他技能的集成
- Planner agent：当 planner 提出架构变更时，建议创建 ADR
- Code reviewer agent：标记引入架构变更但没有对应 ADR 的 PR