核心问题

ADR 到底记录什么？

真实场景

半年后，Kafka 运维出了问题。新人问：“当初为什么不用更简单的 Redis Stream？”

没人记得。只知道系统已经这样了。

这就是没有 ADR 的代价。

常见误区

坏文档写：

我们使用 Kafka。

好 ADR 写：

我们选择 Kafka，是因为需要高吞吐、多消费者和可重放，接受运维复杂度。

ADR 记录的是选择背后的判断。

工程视角

ADR 应该回答：

  • 当时背景是什么？
  • 有哪些候选方案？
  • 每个方案的利弊是什么？
  • 最终选择什么？
  • 接受了什么代价？
  • 未来什么条件下需要重评？

PM 可以怎么做

PM 可以把 ADR 当成工程版的产品决策记录。

不要只写“结论”，要写清楚：

  • 业务压力。
  • 技术约束。
  • 时间窗口。
  • 团队能力。
  • 被放弃的替代方案。

Atlas Action

每次重大技术选择后，补一句：

我们没有选择 X，是因为 Y。

这句话往往比“我们选择了什么”更有价值。

小结

ADR 是写给未来团队的解释权。

没有 ADR，未来的人只能从结果反推原因，成本很高，也容易误判。