拿到一个从没听过的技术（比如开源能耗仿真引擎 EnergyPlus），怎么在有限时间里得出"用还是不用"的可靠结论？答案不是"读源码"，而是一条带时间盒的漏斗。这套方法对任何技术通用。
最常见的失败调研长这样：git clone → 跑通官方示例 → 写一篇"XX 技术初探"。忙了三天，还是回答不了"我们该不该用它"。因为它从头到尾没有一个要回答的问题。
正确的第一步是写出调研问题句——一句话，判据来自你要解决的问题的质量要求（性能、可集成性、可维护性……）与红线约束（license、合规、技术栈、预算）：
注意问题句里每个条件都可度量、可判定——写不出这样的句子，说明你还不知道自己为什么调研，先回去把需求想清楚。（判据的系统写法可参考姊妹课程《技术架构方法论》第 1 课的质量属性场景，非必读。）
调研成本逐层上升（30 分钟 → 半天 → 1~3 天），所以要像漏斗一样：便宜的检查放前面，尽早淘汰不合格候选，最贵的验证只留给幸存者。
| 层 | 时间盒* | 做什么 | 产出 |
|---|---|---|---|
| ① 资质初筛 看"这个项目会不会死" |
30 分钟/候选 | 不看功能，只看项目健康度：定位（README 第一段）、license、发版节奏、维护方是谁、文档与社区、issue 响应。可用 OpenSSF Scorecard 自动打分辅助。 | 候选从 N 个 → 2~3 个 |
| ② 能力对标 看"它接不接得住我们的场景" |
半天/候选 | 不写代码，只读文档与架构：把问题句的判据逐条对到官方文档找证据，填评估矩阵（权重先定、后打分，防止先有结论再凑分）；红线项（license/合规/平台）单列，一票否决。 | 矩阵得分 + 存疑项清单 |
| ③ 限时试点 看"存疑项到底成不成立" |
1~3 天 | XP 的 spike：用真实数据跑通"最薄垂直切片"，专测第②层的存疑项，不做 demo。代码写完即弃，时间盒到点必停。 | 每个存疑项的实证 → 结论 |
* 时间盒是课程给的默认值，按决策的重要程度伸缩；但"有时间盒"本身不可省略——没有截止点的调研会无限膨胀。
以 github.com/NatLabRockies/EnergyPlus 为例，30 分钟初筛实际看什么（信号 → 解读）：
| 检查项 | EnergyPlus 的信号 | 解读 |
|---|---|---|
| 定位 | README：全楼能耗仿真引擎，工程师/建筑师/研究者用于建模能耗与水耗 | 与"能耗模拟"诉求对口，不是勉强凑合 |
| 维护方 | 美国能源部（DOE）出资、国家实验室维护，官网 energyplus.net | 机构背书，非个人项目——bus factor 风险低 |
| 发版节奏 | 每年 3 月、9 月两次正式发版，43,000+ 提交，CI 完整（单元/集成/回归测试） | 可预期的节奏比 star 数更能预测"三年后还活着" |
| License | BSD-3 类 | 商用闭源集成无障碍——红线通过 |
| 技术形态 | C++ 内核 + Python API 绑定，文档在 ReadTheDocs | 与 Python 栈可集成；但 C++ 构建链重 → 记入存疑项 |
| 风险信号 | 800+ 开放 issue；领域门槛高（建筑热工学） | 不必然是坏事（大项目 issue 天然多），抽查 10 条看响应速度再下结论 |
初筛结论示例：健康度高，进入第②层；带入的存疑项——单次年度模拟耗时是否 ≤ 60s？我们的楼宇数据转成它的输入格式成本多大？这两条文档答不了，最终要靠第③层 spike 用一栋真实楼宇模型实测。
调研结束的动作只有两个：结论写成 ADR（决策记录，含"不采用"——记下来，防止半年后有人重复调研一遍，模板见 ADR 模板集），并给该技术定一个技术雷达环位（Adopt / Trial / Assess / Hold）。
做完把你的结论发回对话里，我来点评——重点看：存疑项是否可度量、是否真的只能靠 spike 回答。
主推资料源：Dan McKinley 的 Choose Boring Technology（演讲文稿全文，20 分钟读完）——技术选型领域被引用最多的一篇，"创新代币"的出处。工具向：OpenSSF Scorecard 一条命令自动评估开源项目健康度；方法向：Thoughtworks Tech Radar 的四环模型可直接搬来做团队自己的技术台账。
💬 对某一层想深入（比如评估矩阵怎么定权重、spike 怎么切"最薄垂直切片"）——回到对话里直接提问。