初筛的幸存者进入半天的文档对标。这一课教两件事：判据怎么"找证据"，以及评估矩阵怎么填才不会变成给既定结论凑分的工具。
把调研问题句拆成一条条判据，逐条到官方文档、架构说明、发布说明里找证据。纪律是：每条判据必须落进三个筐之一，且证据要留链接：
| 结果 | 含义 | 下一步 |
|---|---|---|
| ✅ 明确支持 | 文档白纸黑字，或有官方示例佐证 | 记录证据链接，进矩阵打分 |
| ❌ 明确不支持 | 文档明说不支持，或 issue 里官方明确拒绝 | 若是红线 → 淘汰；否则矩阵低分 |
| ❓ 查不到 | 文档、issue 搜索、讨论区都没有可信答案 | 记入存疑项清单，留给第③层实测 |
文档搜不到时的两个补充渠道：在仓库 issue 里搜关键词（官方对功能请求的答复往往比文档诚实）；搜"技术名 + limitations / vs 竞品名"看第三方工程博客——只作线索，不作证据。
打分用 1~5 分制，每个分值先写锚点定义再打（例：集成成本 5 分 = 官方 SDK 直接可用；3 分 = 需自写适配层 ≤ 1 人周；1 分 = 需 fork 改源码）。没有锚点的打分就是拍脑袋投票。
场景延续第 1 课：给楼宇 SaaS 加能耗模拟。候选：EnergyPlus vs 自研简化模型（度日法级别的近似算法）。以下数字为教学示例：
| 维度（来自问题句） | 权重 | EnergyPlus | 自研简化模型 |
|---|---|---|---|
| 模拟精度（对标行业标准） | ×3 | 5（行业基准工具） | 2（近似算法） |
| 单次模拟耗时 ≤ 60s | ×3 | ❓ 存疑 → spike | 5（毫秒级） |
| Python 服务集成成本 | ×2 | 4（官方 Python API） | 5（原生） |
| 楼宇数据 → 输入格式转换 | ×2 | ❓ 存疑 → spike | 4（自定格式） |
| 长期维护成本 | ×1 | 4（上游机构维护） | 2（全靠自己） |
怎么读这张表：两个候选各有明确强项，但 EnergyPlus 有两个高权重维度悬而未决——矩阵此刻的作用不是分出胜负，而是把"值得花 1~3 天验证什么"精确圈出来。若 spike 证实耗时达标、转换成本可接受，加权总分明显胜出；若不达标，自研简化模型（或"EnergyPlus 离线预算 + 简化模型在线估算"的混合方案）上位。这就是第②层的真正产出：矩阵得分 + 存疑项清单。
给下面这个虚构场景做第②层的骨架（不用真查文档）：
你的团队要给内部系统选一个工作流引擎（审批流、状态机、定时触发），Python 栈，3 人维护，公司要求所有组件可私有化部署。
发回对话里，我来点评——重点看：红线有没有混进矩阵、权重理由能不能追溯到场景。
主推资料源：Choose Boring Technology 的后半部分——McKinley 讲"怎么让引入新技术这件事在组织里变成一个有摩擦、要举证的流程"，正是评估矩阵存在的组织学理由。
💬 想让我帮你审一张真实的评估矩阵——回到对话里直接贴上来。