我们办的工作坊，几乎每一节都会有东西坏掉。桥被书压垮了。再放一块积木塔就倒了。纸板探测车第一次开就翻了。有意思的是，搭它的那个学生通常在别人开口之前就已经知道哪儿出了问题。
那一下子的反应，「哦，它从接头断了，因为我胶水打太急」，是整节课里最棒的事。没有什么失败了。你刚拿到一条信息。
工程师问的第一个问题
东西坏了的时候，工程师不会问「我做错了什么」。他们会问一个好得多的问题：它是从哪儿断的，这在告诉我什么？
桥从正中间断，就是在告诉你中间最弱。接头脱开，就是在告诉你那个连接扛不住。断裂基本上是在给你留下一次搭建的笔记。
工程思维框架
改进循环
工程师是故意绕圈子的。设计循环不是从想法直奔成功的一条直线。它长这样：
- 1
把目标说具体
扛住 5 磅？跨过 30 厘米？轻到不能再轻？目标含糊，结果也含糊。
- 2
先搭出第一版
别追求完美，追求能测。你要的是十分钟内就能往上压重量的东西。
- 3
认真测
把真实荷载压上去。猜它「大概能行」不算测试。
- 4
盯住它怎么坏的
不只是坏了，而是究竟从哪儿、以什么方式坏的。那个细节就是你的数据。
- 5
一次只改一处
一次改三处，你永远不会知道到底是哪一处救了你。
- 6
再测一遍
再来。每一轮给你的都比上一轮多。
这在 Avanza STEM 工作坊是什么样子
在桥梁课上，大多数小组搭一次、测一次。这就够了。当桥开始弯，然后扭，最后终于撑不住的时候，全场都能看清哪一部分扛得最多。
真正的关键在之后。它从哪里失效的？为什么偏偏是那儿？如果明天再搭一座，第一个要加固的是什么？
只改一处规则
这条比学生想的重要得多。东西坏了之后，在下次测试前只改一处，就一处。
假设你的桥断了，你重建时换了更好的接头，又换了桁架形状，还加了支撑。也许它这次扛得更多。那又怎样？你完全不知道是哪一处起了作用，所以下次一个都用不上。你没学到东西，你只是运气好。
这种思维方式适用于所有地方
这一套完全不只关于结构。观察、猜测、测试、改进。同一个循环会在你生活的各个角落冒出来：
- 科学：一个搞砸的实验，正在告诉你关于装置或假设的某个具体问题
- 编程：崩溃会给你一条报错信息。碰代码之前先读它
- 数学：一个错答案指向该回去看的那一步。它不是对你本人的判决
- 运动：没投中的那一球是关于姿势或时机的反馈，不是放弃的理由