上一章说，要主动去问「什么能证明我错」。这一章讲手艺：怎么设计那个问法。因为同样是去撞现实，有的撞法一下就问出真相，有的撞一百次还是一团浆糊。
先立一条贯穿全章的标准：一个检验的价值，等于它能帮你排除多少种可能。
好问题，是把可能性劈成两半的那种
玩过猜数字：我心里有个 1 到 100 的数，你来猜，我只答「大了」或「小了」。新手上来就猜「是 7 吗」——猜中的概率百分之一，多半只换来一句「大了」，一百种可能只划掉了一种。老手先问「比 50 大吗」：无论答大答小，剩下的可能当场砍掉一半。照这么砍，一百个数七次就锁定，一百万个数也不过二十次。
这就是二分——每次都问一个「无论答案朝哪边，都能划掉一大半可能」的问题。它的威力在于：好检验的关键不是「猜得准」，而是「问得狠」——让每一次撞现实都尽量多排除一些可能。一个不管结果如何都只能排除一点点的检验，基本是白撞。
工程师排 bug，本质就是二分，只是很多人没意识到。程序在一千行里某处出错，新手从第一行开始一行行盯——那是「猜是不是 7」。老手把程序从中间切开：让它只跑前一半，还崩吗？崩，问题在前五百行；不崩，在后五百行。一刀下去砍掉一半，再来一刀。十来刀，一千行里那一行就无处可藏。
版本控制里甚至有个命令直接叫 git bisect：这个功能昨天还好好的，今天坏了，中间提交了两百次。它不让你一个个试，而是自动帮你二分——每次拉出正中间那一版，问你「这版好还是坏」，几步就揪出是哪一次改动闯的祸。定位问题靠的不是死盯，是对半砍。
一次只动一个变量
光会砍还不够。假设你的网站变慢了，你一口气做了三件事：换了服务器、改了数据库、又删了一段代码。第二天，快了。是哪件事起的作用？你不知道。三个变量一起动，现实就算给了你「变快了」这个回答，你也没法把功劳分给谁——说不定是换服务器救的场，而删代码其实帮了倒忙，只是被另外两个盖过去了。
所以有了那条铁律：控制变量——一次只改一样东西，别的全按住不动，这样现实的回答才对得上你刚才那一下改动。想知道三件事各自的效果，就分三次做，一次一件。
这不是科学家的专利。程序员调参数一次调一个，厨子改配方一次改一味，产品经理做的 A/B 测试——把用户随机分成两拨，两拨看到的页面只有一个按钮颜色不同，其余一模一样——全是同一条铁律。A/B 测试之所以可信，正因为它死死按住了除颜色之外的一切。
没有对照，你根本不知道发生了什么
还有一个更隐蔽的坑。你感冒了，喝了三天姜汤，好了。姜汤有用吗？
你没法回答——因为感冒本来七天也会自己好。你缺一个「没喝姜汤的你」来做比较。这个「什么都照旧、唯独不接受那个处理」的对比组，叫对照组。药是不是真有效，得看吃药的一组比没吃药（只吃了外形一样的假药）的一组好得多多少；两组差不多，那就是你的身体自己好的，不是药。
为什么非要对照？回到第三章：现实给的回答天生是含糊的。「喝了姜汤，好了」这句话里，混着姜汤的效果、身体自愈、心理作用、天气转好……一大团东西。对照组的作用，就是把「别的原因」这一大团从两边同时减掉，剩下的差别，才是你真想量的那个东西。检验不是「做点什么看看」，是造一个干净的对比，逼现实只回答你问的那一个问题。
坏检验的通病：怎么着都说得通
现在能给「坏检验」下诊断了。坏检验有个共同的破绽：不管结果是哪样，都不改变你的结论。
你信某只股票会涨。它涨了，你说「看吧我没看错」；它跌了，你说「短期波动，长期看好」。这个「检验」怎么跑都证明你对——于是它什么信息都没给你（正是上一章的「不可证伪」在实战里的样子）。好检验反过来：它的两种结果指向两个不同的结论。「如果三个月内跌破某个价我就认错离场」——这才是个检验，因为它给了现实一个判你错的明确机会。
动手前先问一句
把这一章拧成一个随身可用的习惯——在你做任何测试、实验、尝试之前，先花十秒问自己：
「这件事可能出现的每一种结果，分别会让我怎么改想法？如果不管出什么结果，我的想法都不变——那就别做，重新设计一个。」
能通过这一问的检验，才配消耗你的时间。它会自动逼你避开上面所有的坑：逼你去砍一大半可能（二分），逼你一次只动一个变量，逼你留个对照，逼你让不同结果指向不同结论。
好了，假设你设计出了一个漂亮的检验，也诚实地跑了。现实给了回答，而且和你的预期对不上。这时最要命也最增值的一步来了：这个「对不上」——这个误差——到底在跟你说什么？下一章，学着读它。