Architecture Decision Records

捕捉新的 ADR

当检测到决策时刻时：

1. 初始化（仅首次） — 如果 docs/adr/ 不存在，在创建目录、一个包含索引表头（见下方 ADR 索引格式）的 README.md 以及一个供手动使用的空白 template.md 之前，询问用户进行确认。未经明确同意，不要创建文件。
2. 识别决策 — 提取正在做出的核心架构选择
3. 收集上下文 — 是什么问题引发了此决策？存在哪些约束？
4. 记录备选方案 — 考虑了哪些其他选项？为什么拒绝了它们？
5. 陈述后果 — 权衡是什么？什么变得更容易/更难？
6. 分配编号 — 扫描 docs/adr/ 中的现有 ADR 并递增
7. 确认并写入 — 向用户展示 ADR 草稿以供审查。仅在获得明确批准后写入 docs/adr/NNNN-decision-title.md。如果用户拒绝，则丢弃草稿，不写入任何文件。
8. 更新索引 — 追加到 docs/adr/README.md

读取现有 ADR

当用户询问"我们为什么选择了 X？"时：

1. 检查 docs/adr/ 是否存在 — 如果不存在，回复："在此项目中未找到 ADR。您想开始记录架构决策吗？"
2. 如果存在，扫描 docs/adr/README.md 索引以查找相关条目
3. 读取匹配的 ADR 文件并呈现上下文和决策部分
4. 如果未找到匹配项，回复："未找到关于该决策的 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 作为前端框架 | 已采纳 | 2026-01-15 |
| [0002](0002-postgres-over-mongo.md) | 主数据存储选用 PostgreSQL 而非 MongoDB | 已采纳 | 2026-01-20 |
| [0003](0003-rest-over-graphql.md) | 选用 REST API 而非 GraphQL | 已采纳 | 2026-02-01 |

决策检测信号

留意对话中指示架构决策的以下模式：

显式信号

• "让我们选择 X"
• "我们应该使用 X 而不是 Y"
• "权衡是值得的，因为..."
• "将此记录为 ADR"

隐式信号（建议记录 ADR — 未经用户确认不要自动创建）

• 比较两个框架或库并得出结论
• 做出数据库模式设计选择并陈述理由
• 在架构模式之间选择（单体 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
• 代码审查代理：标记引入架构变更但未附带相应 ADR 的 PR