架构决策记录 (Architecture Decision Records)
在编码会话中实时捕获架构决策。这些决策不再仅存于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——未经用户确认不要自动创建）
- 比较两个框架或库并得出结论
- 在给出明确理由的情况下做出数据库模式设计选择
- 在架构模式之间选择（单体与微服务、REST与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（务必链接替代者）
值得记录的决策类别
| 类别 | 示例 |
|---|---|
| 技术选择 | 框架、语言、数据库、云服务商 |
| 架构模式 | 单体与微服务、事件驱动、CQRS |
| API 设计 | REST vs GraphQL、版本控制策略、认证机制 |
| 数据建模 | 模式设计、规范化决策、缓存策略 |
| 基础设施 | 部署模型、CI/CD流水线、监控栈 |
| 安全 | 认证策略、加密方法、密钥管理 |
| 测试 | 测试框架、覆盖率目标、E2E与集成测试平衡 |
| 流程 | 分支策略、审查流程、发布节奏 |
与其他技能的集成
- 规划器代理：当规划器提议架构变更时，建议创建ADR
- 代码审查代理：标记那些引入架构变更但没有相应ADR的PR