写下可供日后复核的决策

保留决策理由

决策会议产生选择。决策记录保留这个选择为何合理的解释。

缺少理由时，后续团队可能把临时限制误当作永久原则，也可能重复组织已经完成的评估。

AWS 将架构决策记录用于记录决策及其背景。同样简洁的结构，也适用于 AI 开发运行模式。保持记录简短，让负责人愿意阅读。

比较现实可行的方案

一家虚构公司需要维护合同应用，考虑三种选项：

使用相同的应用范围、期间、数据假设和服务预期。不要把成熟的外购服务与内部系统的原型成本单独比较。

组合方案也可能合适。现有平台可以提供环境和部署，软件工厂则协调开发。应说明接口和职责，不必强行要求完全采用或完全排除某个选项。

写清六个部分

1. 背景。 说明问题，以及不作改变的后果。
2. 要求。 列出选项必须满足的条件。
3. 备选方案。 记录认真考虑的选项及主要取舍。
4. 证据。 链接评估、成本假设和尚未解决的问题。
5. 决定。 指定所选方案、范围、负责人和接受的限制。
6. 复核。 定义需要重新评估的日期或可观察事件。

区分观察与预期。“评估期间完成了这项维护变更”是观察结果。“服务将使年度维护成本减半”是预测，需要证据和明确假设。

纳入最有力的反对理由

对于合同应用，外购服务可能减少集成工作，却也会形成对外部提供方的依赖。记录这个反对理由，以及能够回应部分问题的导出演练。不要因为团队偏好该方案，就删去反对理由。

说明哪些未解决事项会阻止启用。为其余事项指定负责人和日期。决定继续，不会让尚未回答的控制问题变成已验证结果。

要求或证据变化时，复核记录。选择变化时添加新决策，并保留早先理由。继续学习Taiga 实用场景，将这些原则应用到产品工作流。