Master Architecture Decision Records (ADRs): Best Practices for Effective Decision-Making — 导读 未开始

题记与说明

这篇讲什么

Nygard 2011 年给了 ADR 模板，但"模板有了、怎么在真实团队跑起来"一直缺一份操作手册。这篇 AWS 架构博客（2025-03-20）补的就是这个空白：三位 AWS ProServe 作者基于 3 年多、200+ 条 ADR 的落地经验——团队规模从不足 10 人到 100 人、跨 10 个工作流——提炼出 10 条可直接照做的团队流程建议：会议控制在 30–45 分钟、采用 readout 式评审（先静读 10–15 分钟、逐段写评论）、参会人跨职能但总数低于 10、一条 ADR 只做一个决策、设计探索放独立设计文档并在 ADR 里引用、1–3 轮评审后必须拍板、被取代的 ADR 要互相链接、集中存储。

核心观点

1. 评审是阅读，不是演讲：readout 式会议让所有人先花 10–15 分钟安静读文档并写下评论，再讨论分歧点。这把会议从"谁的嗓门大"变成"谁的意见有文本依据"。
2. 多数决策是双向门：大部分架构决策错了可以低成本改回来，所以"It's always better to make a decision and try it fast instead of endlessly discussing it"——1–3 轮 readout 还没结论，就该缩减参会人或缩小 ADR 范围，而不是继续开会。
3. ADR 是团队之法：单条 ADR 聚焦单个决策、supersede 链接保持更新、集中存储让所有团队可见——流程本身要坚持最高标准，否则整套机制迅速烂掉。

最值得记住的数字与金句

• 20–30%：作者三年项目经验里，开发团队花在与其它团队协调上的时间占比——这是 ADR 想削减的真实成本。
• "Most of the decisions are two-way door decisions... It's always better to make a decision and try it fast instead of endlessly discussing it." —— 用 Bezos 的双向门框架给"快决策"正名。
• "one to three ADR readouts should be sufficient" —— 给评审轮次划了硬上限，超了就说明 ADR 本身要瘦身。

对我的启发

• Agent 系统决策也可以 ADR 化：给 AI/Agent 项目里的关键决策（上下文策略、工具选型、模型选择）各写一条单决策 ADR，"one decision per ADR"的原则能防止决策文档变成大杂烩。
• readout 模式可迁移到 AI 生成方案的评审：先静读、逐段书面评论、限时拍板——这正是 review AI 产出时避免"看一眼就说好/不好"的好流程。
• 对个人知识管理同样成立：单决策单文件、supersede 双向链接、集中存储——个人决策日志完全可以借用这套结构。
• 写作上：设计探索放外链、正文只留决策本身，是"短文+附录"式写作的范本。

适合谁读

刚开始引入 ADR 的技术负责人与架构师；读过 Nygard 原文后想知道落地细节的工程师；被无休止架构评审会议折磨的工程经理。不需要 AWS 背景，全文 15 分钟可读完，配套资源是 AWS Prescriptive Guidance 的 ADR 指南和 adr.github.io。