记录架构决策的理由与适用条件

这个场景能帮你做什么

架构图说明“是什么”，决策记录还要解释“为什么”。WorkBuddy 可以依据评审与验证记录，整理选择、放弃方案及约束，帮助后续维护者理解取舍。

开始前需要准备什么

提供决策议题、候选、需求约束、验证、会议结论与批准状态。标明决策日期和适用版本；没有形成决议的讨论不能写成已批准选择。

具体怎么做

第一步：明确决定的问题

描述触发背景与约束，区分业务需求、工程事实和团队偏好。问题范围过宽时先聚焦本次决定。

第二步：还原候选与证据

列考虑过的方案、依据、好处和代价，包括为什么放弃某候选。不要事后补造当时未讨论的理由。

第三步：记录结论与后果

说明采用什么、在何种条件下成立、留下什么风险或后续工作。记录状态、确认人及何时需要重新评估。

第四步：关联实现与后续变化

连接设计和实现版本，后续改变时新增替代关系，保留历史理由。不能把后来知道的信息写成当时已经掌握。

可以直接交给 WorkBuddy 的完整要求

依据附件真实评审与验证起草架构决策记录：背景/约束、候选、证据、决定、理由、代价、状态和重审条件。
已确认与讨论中分开，不补造历史理由；未知列待补。关联设计实现版本及被替代记录，不改写历史事实或自行批准技术路线。

完成后会得到什么

一份可追溯的架构决策记录，维护者能理解当前结构为何存在、什么变化会使它失效。

结果应该怎么检查

由参与者核对候选、理由、状态和日期，确认代价未被删掉。检查当前实现是否符合决策，不以记录存在代替落实。

遇到这些情况怎么处理

原决策没有书面依据时标为事后整理并注明来源。参与者有分歧则保留问题。新信息改变结论时记录新决定，不抹去旧理由。

哪些必须人工决定

技术负责人确认决策和状态，维护者确认实现关联。AI 整理证据，不追认未获批准的架构选择。