全自动跑起来了、成本降下来了、信任梯子搭好了——我以为接下来就是复制成功、放大规模。

但产品有一个问题我一直没解决——而且我越做越觉得它可能根本解决不了。

我想根据HR的回复来反向优化产品。具体来说就是：如果HR看到我的开场白之后没有回复——那是不是说明开场白写得不对？如果是——那我应该自动改开场白——让它变得更好。如果改了之后回复率上来了——那就说明优化方向对了。

这个逻辑链条听起来很完美。但当我真的开始做的时候——卡住了。而且卡得非常彻底。

一、我能看清的两端

HR对一次打招呼的回复——大概有三种情况。

第一种是约面试。HR直接回「明天下午方便吗」「发一份简历到我邮箱」——信号极其清晰。你不需要任何分析就知道——这次打招呼成功了。第二种是秒拒。HR回「暂时不匹配」「已读不回但不点开」——也十分清晰。这两种情况占全部回复的大概百分之三四十。

问题是第三种——也是占大多数的——已读不回。HR点开了你的消息——看到了——没回。为什么没回？可能性太多了。他可能正在忙——打算晚点回然后忘了。他可能看到了开场白但觉得不够吸引——但也没到要拒绝的程度——就放在那里了。他可能打开看了觉得还可以——但想先看看其他候选人。他可能手机响了被叫去开会了——回来就忘了这回事。他甚至可能只是手滑点开了——根本没看到内容。

已读不回——这个中间状态——占了总回复量的百分之六十以上。而这百分之六十——我完全不知道它是好信号还是坏信号。它既像《信号》——但更像「没有信号」。

我刚入行的时候甲方也经常这样——发过去一张效果图或者一个方案文本——微信显示已读——但没有回复。我等一整天、等两天、等一周——最后忍不住发消息问对方「您看过了吗有什么意见」——对方才回一句「哦好的收到了我看看」。已读不回在设计行业几乎是一个默认状态——因为客户同时在盯三个项目、开四个会、回五条消息。你发的图可能只是他今天未读列表里的第不知道多少条。

所以我清楚地知道一个问题：已读不回有至少二十种原因——而我没有任何办法区分它们。这就像你在工地上听到地下有声音——但你不能确定那是水管漏水还是电缆短路还是老鼠在跑——因为声音穿过土层到你这儿的时候已经失真了——你所有的信号都是经过了一层噪声过滤之后的版本。你只能知道『有声音』——但不知道那是什么声音。而且最让人难受的是——你知道这个信息是有用的——但你就是提取不出来。

二、我想做「反馈闭环」——但闭环缺了一整段

我的设想是这样的：每次开场白发出去之后——如果HR给了正面回复——说明开场白方向对——系统就记住这个方向——下次写类似岗位时复用。如果HR已读不回——说明开场白可能有问题——系统自动尝试另一种风格的开场白——然后对比回复率——找出更优的那个。

这个设想需要的前提是：我能准确判断「已读不回是因为开场白不好」。但我能判断吗？不能。

已读不回可能是因为开场白不好——也可能是因为HR今天心情不好、因为他已经招到人了但还没关岗位、因为公司内部冻结招聘了但HR忘了撤、因为他职位虽然是运营但实际想要的是有技术背景的人而我的简历上写的不是那个方向。二十种原因里——真正跟开场白有关的——可能只有三四条。剩下的——是全然的噪声。

如果我强行做这个闭环——我会做一件更糟糕的事：我会根据错误的归因调整产品的行为。我会把一个完全没问题开场白改掉了——改完之后回复率没变——我得出结论「这个方法没用」。或者恰好相反——我把开场白改成另一版——碰巧今天HR心情好——回复了——我得出结论「这个方向对了」——然后开始全面复制这个方向。两种都是灾难。前者让我放弃一个正确的策略——后者让我放大一次偶然的运气。

这就是归因困境：你看到了一个结果——但你不知道导致这个结果的原因是什么。

三、苏姐说「你非要知道吗」

我带着这个问题去找苏姐。我把我的困境说了一遍——「已读不回」有二十种可能的原因、我没办法用它来做闭环优化、我卡住了。

苏姐听完之后没有给我解法。她反问我一个问题——这个问题的答案我现在还记得。

「你为什么要知道？」

「因为我想做闭环优化——」

「不——我问的是：你为什么要知道『到底是二十种原因里的哪一种』？知道了之后你能做什么？」

我愣了一下。「知道了之后——我就能针对性地改——」

「那如果你不知道——只是换一个开场白风格——然后在两周后看总回复率有没有变化——你能得到什么？」

「那我只能知道『换了有没有用』——不知道『为什么有用』。」

「对。那你知道『换了有没有用』这件事——够不够你做决策？」

我犹豫了一下。「够——如果换了之后总回复率确实涨了——那我就继续用新版本。」

「那你知道『为什么有用』这件事——它对你的决策有影响吗？」

我想了一会儿。很诚实地说：「没有。」

「所以你不是卡在归因上——你是卡在『我必须知道原因才能做决定』这个预设上。但你的实际情况是——不需要知道原因——只需要知道相关性——就已经可以做出优化的决策了。」

苏姐的话让我意识到一件事——我一直以为做好闭环优化的前提是能精确归因。但精确归因在真实世界里几乎不可能。你不知道一个用户为什么没有点你的产品——但你可以在首页上同时放两个不同版本的引导文案——然后看哪个点击率高。后者不需要你知道原因——你只需要知道结果。我又追问了一句：「但如果对照实验也看不出差异呢——比如两版开场白的回复率只差了零点几个百分点——那怎么办？」苏姐说：「那就说明这件事不值得纠结。两个版本差不多——你就选成本低的那一版——或者选你更喜欢的那一版——翻篇做下一件事。」我后来发现这个回答其实透露了一个很重要的产品思维方式——不是所有差异都值得优化。有些差异是噪声——你花精力去找最优解——找到的最优解和次优解的差距本身就没有意义。

苏姐的话让我意识到一件事——我一直以为做好闭环优化的前提是能精确归因。但精确归因在真实世界里几乎不可能。你不知道一个用户为什么没有点你的产品——但你可以在首页上同时放两个不同版本的引导文案——然后看哪个点击率高。后者不需要你知道原因——你只需要知道结果。

四、阿 May 说「土看不见下面有什么——但你照样种东西」

我跟阿 May 吃饭的时候说了这件事——我说我想找到「已读不回」的原因——找不到。然后苏姐告诉我你可以不用找。

阿 May 听完之后擦了擦嘴——然后说了一句让我没想到的话。

「你们做产品的有一个毛病——总觉得什么事情都得搞清楚才能动。但我们种树的不是这样的。你挖一个坑——土翻出来——你不知道下面有没有石头、有没有管道、有没有古墓——你不知道。但你不能因为不知道就不种了。你挖下去——碰见石头就绕开——碰见管道就改位置。你不是先搞清楚再动手——你是动手的过程中搞清楚。」

「那要是碰到古墓呢？」

「那就停——上报——等文物局的人来看。但这是极少数情况——百分之九十的情况是石头和管道——绕开就行了。」

阿 May 说的「动手的过程中搞清楚」——我后来想了很久。我回想起在设计公司的时候——每次做驻场配合——你不可能在开工之前搞清楚地下所有管线的位置。设计院给的管线综合图永远跟现场有出入——煤气管道标在图纸的A位置——但现场挖开发现它在B位置——因为施工的时候遇到石头绕了一下——但图纸没更新。你能做的不是提前搞清楚——是挖到的时候及时调整。产品优化也是一样的——你不可能在做A/B测试之前搞清楚所有变量——你只能设计好实验——做了之后根据结果调整。而且还有一个重要的点——阿 May 说他们碰到管线的时候不是停下来开会——是施工队长当场就决定往左偏三十公分绕过去——边干边调。产品也要这样——发现问题的时候——最小改动方向迈出去——而不是停下来分析为什么。

我卡住的原因是我试图在做一件事之前先把所有变量控制住——但这在真实世界里不可能。真实世界的做法是：先画一条线——然后边画边看边调整。你不知道已读不回的确切原因——但你可以先换一版开场白——然后观察两周后的总回复率变化。如果涨了——继续优化这个方向。如果没涨——换另一个方向。你不需要知道原因——你只需要知道「动了一下之后——结果变了没有」。

五、坑在哪

坑一：以为所有的数据都能被归因。已读不回有一二十种原因——你不可能知道是哪一种。强行归因只会让你做出错误的决定。承认「我看不清」——比强行「我看清了」靠谱得多。

坑二：把「知道原因」当作「做决定」的前提。苏姐那一问让我意识到——我其实不需要知道原因。我只需要知道「变了没有」。A/B测试不需要归因——只需要对照结果。相关性已经足够指导决策了。

坑三：低估了噪声的规模。已读不回占总回复量的百分之六十以上——而我之前一直试图在这百分之六十里找信号。但正确的做法是：放弃对中间状态的精确分析——只分析两端（约面试和秒拒）——中间那一片交给对照实验来处理。

坑四：闭环设计得太理想。我设想中的闭环是「判断原因→调整策略→验证效果」——但现实中「判断原因」这一步根本走不通。正确的闭环应该是「提出假设→做改动→看结果→根据结果决定下一步」——不需要归因——只需要知道结果比之前好还是差。

坑五：不知道什么时候该停。有的问题就是解不开的——或者说——以当前的样本量和技术条件——就是解不开的。承认「这一片我看不清」本身就是一种判断能力。不是所有问题都能被解决——有些问题只能被绕过。

六、速查卡

七、这一章我真正学会的那一招

这一章的怪物叫「中间那一片我看不清」。我直到现在也没完全看清那一片。但苏姐教会我一件更重要的事——有些问题你不需要看清——你只需要知道怎么在看不清的情况下往前走。已读不回有二十种原因——我不知道是哪一种。但这不妨碍我换一版开场白——然后看结果。世界是不透明的——但你可以敲一敲——根据回声判断方向。

便利贴又更新了。在「双Agent」下面我加了一行：「看清两端就行——中间那一片用对照实验。不归因——只对照。不知道自己不知道——比假装知道好。」

「已读不回有二十种原因——你永远不可能知道是哪一种。但你不需要知道——你只需要知道『动了之后结果变了没有』。」

【掉落】看清两端——中间用对照实验。你的产品不是所有问题都能归因的。大部分反馈都是噪声——但你不必等到看清全部再做决定。先换一版——看结果——然后根据结果决定下一步。不知道原因——也可以做对的决定。