漏斗走完了，证据在手。最后两个固定动作：把决策写成一页 ADR，把技术钉上团队雷达。这一课教两者的写法，并把 EnergyPlus 案例完整收官。
ADR（Architecture Decision Record）出自 Michael Nygard 2011 年的原文 Documenting Architecture Decisions，五节结构，全文一到两页，对话式写作：
| 节 | 写什么（调研场景的对应物） |
|---|---|
| Title 标题 | 简洁名词短语，带编号：「ADR-007 采用 EnergyPlus 作为能耗模拟引擎」 |
| Context 背景 | 各方力量的客观陈述：调研问题句 + 三层漏斗的证据摘要（初筛结论、矩阵得分、spike 实测值），全部留链接 |
| Decision 决策 | 完整句子、主动语态："我们将采用 X"——以及不采用了谁、为什么 |
| Status 状态 | Proposed 提议 / Accepted 已接受 / Superseded 已废止 |
| Consequences 后果 | 正负都写：得到什么，付出什么（学习成本、运维负担、花掉的创新代币），以及什么条件下应重新评估 |
两条纪律：
Status：Accepted（2026-07-30）
Context：楼宇 SaaS 需新增能耗模拟能力。调研问题句：EnergyPlus 能否满足单栋楼年度模拟 ≤ 60s、Python API 集成、license 允许商用闭源？三层证据：①初筛——DOE 出资、国家实验室维护、半年一发版、BSD-3，健康度高（初筛记录）；②对标——精度与维护成本占优，耗时与数据转换两项存疑（矩阵）；③spike——真实楼宇模型年度模拟实测 41s（判定线 60s，通过）；数据转换脚本 1.5 人天跑通（判定线 2 人天，通过）。备选"自研简化模型"在精度维度不满足行业对标要求。
Decision：采用 EnergyPlus 作为能耗模拟引擎，经官方 Python API 集成，模拟任务走异步队列。不采用自研简化模型作为主引擎（保留其作线上快速估算的候选，另行立项评估）。
Consequences：（+）行业基准级精度；上游机构维护，跟随半年发版节奏升级。（−）花掉一枚创新代币：团队需建立建筑热工学基础知识；C++ 构建链使容器镜像变重约 800MB；输入格式转换脚本成为需长期维护的资产。重新评估条件：上游发版停滞两个周期，或模拟量级增长使单机耗时突破判定线。
注意 Context 一节：三层漏斗的产出（初筛结论/矩阵/spike 报告）逐层链接——ADR 是漏斗的收口，不是重写。spike 数字为教学示例。
单篇 ADR 是点，技术雷达是面：团队所有技术判断的一张总图，四环语义（Thoughtworks 模型）：
| 环 | 语义 | 动作 |
|---|---|---|
| Adopt | 默认选择，成熟可靠 | 新项目直接用，不必重新调研 |
| Trial | 值得用，但先在能承受失败的项目上 | 限定范围试用，定复盘时间 |
| Assess | 值得研究，尚不建议投产 | 允许 spike，不允许上生产 |
| Hold | 暂缓：新项目不再引入 | 存量不强拆，增量禁止 |
落地办法（半小时起步）：Google Sheet / CSV 列出技术项，粘进 Thoughtworks 免费的 Build Your Own Radar 工具即得交互式雷达图（开源可私有部署）。两条运营规则：
二选一，做完本课程结业：
发回对话里，我来点评。之后你手里的每一次真实调研，都欢迎按漏斗贴回来一起过。
主推资料源：Nygard 的 ADR 原文（10 分钟读完，ADR 的一切变体都源于此）；模板与各语言示例见 ADR 模板集；自建雷达用 Build Your Own Radar。
💬 想让我帮你审第一篇真实 ADR、或把团队技术台账整理成雷达——回到对话里直接开工。