技术调研方法论 · 第 4 课
第③层展开：spike 是实验，不是开发
第②层圈出了存疑项，现在花 1~3 天买答案。这一课教 spike 的三件套：把存疑项写成可判定的实验假设、切出最薄垂直切片、守住时间盒纪律。
知识点一：先写假设，再写代码
spike（XP 实践）与日常开发的根本区别：开发的产出是能用的代码，spike 的产出是一个问题的答案。所以开工前，每个存疑项必须先写成实验卡——一张卡三行字：
存疑项：EnergyPlus 单栋楼年度模拟耗时未知
假 设：在我们的标准容器规格上，真实楼宇模型跑一次年度模拟 ≤ 60 秒
判定线：≤ 60s 通过；60~120s 存疑（记录，评估异步化方案）；> 120s 不通过
判定线必须开工前写死。跑出 90 秒才开始讨论"90 秒行不行"，结论一定被沉没成本绑架——都跑到这了，谁舍得说不行？
✗ 探索式 spike
"先把 EnergyPlus 跑起来，看看有什么发现。"——没有判据，三天后只有一堆笔记，没有结论。
✓ 实验式 spike
两张实验卡：①年度模拟耗时 ≤ 60s？②一栋真实楼的数据转成 epJSON 输入，人工成本 ≤ 2 人天？每张卡有判定线。
知识点二：最薄垂直切片怎么切
最薄垂直切片：从你的真实输入到你要的真实输出，端到端打穿一条最担心的路径，宽度压到最窄。三条切法规则：
- 垂直，不是水平：不是"每个功能都试一点"（那是 demo），而是一条路走到黑。EnergyPlus 例：真实楼宇数据 → 转换成输入格式 → Python API 调用 → 拿到年度能耗结果 → 核对量级。中间任何一环断了都算发现。
- 用真实数据：官方示例数据是铺好的路。你的楼宇数据里那些缺失字段、非标准围护结构，才是集成成本的真相。
- 砍掉一切旁支：UI 不做、异常处理不写、性能不调、代码不抽象。硬编码可耻但有效——spike 代码的寿命只有几天。
选路原则：最担心的先走
切片走哪条路？挑判定失败会直接否决候选的那条。耗时超标会否决 EnergyPlus → 先测耗时；数据转换贵三倍不会否决但影响排期 → 排第二。风险从高到低,时间盒用完为止。
知识点三：时间盒纪律与 spike 报告
- 到点必停。时间盒（1~3 天）在开工前和团队约定。到点没跑通？停下，把"没跑通"写进报告——在时间盒内无法完成集成，本身就是集成成本的实测证据。
- 不许续盒。"再给我一天就通了"是 spike 最大的陷阱：无限续盒的 spike 就是一个没立项的开发项目。确实值得再投入？那是一个新的、单独审批的实验卡，不是旧盒的延长。
- 代码即弃。spike 代码不进主仓库、不做 code review、永不投产。防止"试验代码顺势上线"这个千古大坑。
收工产出一页 spike 报告，三段式，直接喂给下一课的 ADR：
① 假设与判定线（开工前写的，原样贴）
② 实际做了什么（环境、数据、路径，一段话）
③ 证据与结论（每张实验卡：测得值 → 过/不过/存疑）
随堂测验
1. spike 实验假设的正确写法是？
2. "最薄垂直切片"指的是？
3. 时间盒到了 spike 还没跑通，应该？
实战练习（15 分钟）
接第 3 课工作流引擎场景（或用你手头真实的调研）。假设第②层留下了这两个存疑项：
- "引擎能否支撑我们峰值每分钟 200 次流程实例创建"
- "现有审批数据（自研表结构）迁移进引擎的成本"
为每个存疑项写一张实验卡（存疑项 / 假设 / 判定线三行），并回答：两张卡先做哪张，为什么？时间盒各给多长？
发回对话里，我来点评——重点看：判定线是否可判定、先后排序是否按"否决性风险优先"。
课后延伸
主推资料源：回读 Choose Boring Technology 中"你对老技术的失败模式了如指掌，对新技术的失败模式一无所知"一节——spike 的全部意义，就是在签字采用前，花最小的钱把未知的失败模式变成已知。