核心问题
写 ADR 前必须回答哪些问题？
真实场景
技术决策会结束了，大家觉得“都明白”。但人的记忆很短，组织的记忆更短。
如果不写下来，未来只能靠猜。
常见误区
坏判断是：
等系统稳定后再补文档。
等到稳定后，当初的权衡通常已经忘了。
工程视角
ADR 要记录的是决策发生时的上下文，而不是事后美化的故事。
PM 可以怎么做
使用这张清单：
1. 这次决策要解决什么业务问题？
2. 当前有哪些硬约束？
3. 候选方案有哪些？
4. 每个方案的主要收益是什么？
5. 每个方案的主要代价是什么？
6. 为什么最终选择这个？
7. 为什么没有选择其他方案？
8. 我们接受了什么风险？
9. 需要哪些后续动作降低风险？
10. 什么条件出现时要重新评估？Atlas Action
建立一个 ADR 文件夹，并从下一次重大技术选择开始写，不追求补完历史。
docs/adr/001-use-kafka-for-learning-events.md小结
ADR 的本质是把工程判断保存下来。
PM 写好 ADR，就是在替未来团队节省理解成本。