不要用行动代替思考：携程 AI 面试反馈

最近做了不少 AI 面试，携程是其中唯一一个给了我比较明确反馈的。读起来也和我印象中携程强调的一些想法相近。不过比起这些，我更想聊聊它让我重新考虑的一件事：我过去是怎么解决问题的，以后又可以怎么做。

回头看，我在之前的工作里解决过不少问题。数据指标发生波动以后，尝试做全面的归因；跨部门协作遇到阻力，就去沟通，拿量化数据帮助大家做判断；碰到不熟悉的事情，先搜集资料，尝试一些方案，再从结果里慢慢找到规律。事情大多也解决得不错，所以我并不觉得这些做法有什么根本性的问题。

但把它们放在一起看，会发现一个共同点：我经常是在问题已经出现以后，才开始组织思考和行动。至于方案为什么值得先试、它依赖什么条件、条件不成立以后怎么办，这些判断有时要等到做了一阵子才逐渐清楚。

这次反馈让我想把一部分思考往前放。在动手之前，先对问题有一个初步解释，列出几个可以验证的假设，也想一想做错了以后会在哪里暴露。先写下来，至于能不能在实际工作里用好，还要继续试。

搜集了很多信息，然后呢

我过去比较习惯先去了解一个问题。资料多看一点，可能的方案多尝试几个，等信息积累到一定程度以后，再形成自己的判断。对于不熟悉的领域，这样做有它的必要性。连问题里有哪些东西都不知道，很难一上来就提出一个像样的假设。

不过，调研也很容易一直进行下去。看完一篇资料，发现还有几个概念没弄懂，于是接着看；知道一种方案，又发现另外几种似乎也值得研究。最后对这个领域了解得更多了，但最初要解决的那个问题，可能依旧没有答案。信息还在增加，我却未必知道下一条信息会怎样影响自己的决定。

这也是我想调整的地方。可以先用已有信息给出一个粗浅的解释，明确这次要解决什么、哪些事情暂时不管，再决定去找什么证据。解释可以很粗糙，后面也可以推翻，但它至少让我知道自己为什么要做下一步。

拿指标波动举个例子。先不急着把所有数据都拉出来，可以从整体环境、外部竞争和内部变更三个方向想一想：市场需求是不是下降了？竞品有没有促销或产品调整？我们自己的版本、策略或者渠道是不是发生了变化？另外还得给数据本身留一个位置，采集出了问题或者指标口径变了，也会让人对着一张图分析半天。

这些都还只是候选解释。写成 H1、H2、H3、H4 也行，画一棵简单的归因树也行，形式没那么重要。我更在意的是，写完以后能不能接着说清楚：如果某个解释成立，我应该看到什么；如果没有看到，我又准备怎么调整判断。

假设我怀疑内部版本变更，就可以去看波动的时间和受影响的范围是否与变更对应；怀疑整体需求下降，就需要找能反映市场变化的证据。这些检查未必足以确定原因，但可以帮助我决定下一步先查哪里。几个假设也不需要平均用力，要考虑它们对决策的影响，以及验证需要付出多少成本。

每次调研最好能回答一个具体问题，拿到的证据也应该能改变我接下来要做的事。 这样信息搜集才有了方向。

这里也要给自己打个补丁。先有假设，很容易变成先有答案，然后专门去找支持它的材料。假设只是暂时采用的解释，我需要同样在意那些与它矛盾的结果。如果几个假设都解释不了，那就回去重新拆问题。画过一张图，不代表问题就只能长在图里。

复盘能不能早一点

以前我比较熟悉的另一套过程，是先让方案跑起来，碰到问题再分析，修好以后继续，最后做一次复盘。很多工作确实只能边做边看，尤其在试错成本不高的时候，先做一个小尝试，往往比坐着讨论更容易知道哪里有问题。

但如果项目已经上线，资源已经投入，几个团队也已经按原来的安排开始工作，这时候才发现方案依赖的条件根本不成立，改起来就没那么轻松了。有些风险值得在动手前先想一遍。

所谓沙盘推演，名字听起来有点大，落到这里其实可以很简单。假设方案失败了，最可能卡在哪里？是资源不够，还是某个环节太依赖一个人、一个团队，或者一个外部条件？原来默认能拿到的资源如果拿不到，哪些部分还能继续，哪些部分需要换个做法？

再往下想，就要考虑备用方案和退出条件。如果 A 不成立，我准备切到什么方案？出现什么信号以后应该调整，什么情况下应该直接停下来？这些问题最好在投入之前有个初步答案。等到已经做了很久，再决定是否放弃，之前花掉的时间也会混进判断里。

这里的分寸并不好把握。事前很难把所有风险都猜中，为了一个很小的尝试写一份庞大的预案，也有点为难自己。我想优先处理的是那些一旦判断错了，就需要很多人一起返工、或者要付出很大代价才能改回来的部分。其余的不确定性，可以留给小范围的尝试和执行中的观察。

复盘仍然需要做，只是它可以多一个去处。过去踩过的坑，除了写进项目结束后的总结，也可以变成下次启动前需要确认的条件。这样下一次遇到相近的问题时，才算真的用上了之前的经验。

下次还要再解决一遍吗

把分析和风险推演往前放以后，还剩下一件事：当前的问题解决了，团队下次遇到类似的事情，会不会仍然从头再来？

仍然用指标波动举例。找到这次下降的原因，可以让当前的业务恢复。但如果希望下次处理得更快，就得继续想，哪些指标值得持续监控，变化到什么程度需要提醒，收到提醒以后先查什么，由谁来判断要不要介入。以前出现过的类似情况也可以留下来，帮助后来的人区分哪些变化可以再观察一下，哪些需要马上处理。

这些事情都很具体。只说要建立一个“解决问题的系统”，其实还是什么都没说。得把检查的方法、判断的依据和负责的人写清楚，团队才有可能沿着它继续工作。

跨部门协作也一样。我可以通过沟通把这次事情推动下去，但如果每次都卡在相同的地方，就值得看看目标是不是一致、职责有没有说清楚、信息有没有及时同步，以及需要做决定的时候到底由谁来决定。否则就算这一次沟通得很好，下次还是要重新找人、重新解释一遍。

之前我把这种区别理解成执行者和规划者的区别，现在觉得也不用把人分得那么清楚。同一个人处理同一件事，既要解决眼前的问题，也可以顺手多问一句，哪些经验值得变成团队以后都能用的办法。当然，一次偶发的小问题未必值得建一套流程；如果已经反复发生，或者处理一次就很昂贵，那就值得多做一点。

先给自己留几个问题

写到这里，其实和我在 AI Native Game 那篇博客里反复问的事情有点像。把 AI 做进游戏之前，得想清楚玩家为什么需要它，它能给玩法带来什么。一个功能做出来了，只能说明我们把它做出来了，玩家会不会因此觉得更好玩，还需要另外回答。换到这次的反馈里，我也得先想清楚自己要改变什么，再决定去收集哪些信息、尝试哪些方案。

如果需要一个方便记忆的顺序，我仍然会保留这几个词：

Problem framing → Hypothesis → Validation → Decision → Execution → Risk control

用中文说，就是把问题和边界说清楚，提出假设，做一个足以帮助判断的最小验证，再据此决定怎么行动。风险要在行动前推演，执行中也要继续看，必要时回头修改假设。这几个词写成一行很整齐，实际工作多半还是要来回走。

我准备先给自己留一份简单的检查清单，遇到复杂问题的时候拿出来问一下：

我这次到底要解决什么？什么暂时不解决？
结果主要受哪些变量影响？哪些条件是方案成立的前提？
根据已有信息，我有哪些可能的解释？
哪个假设最值得先查？什么证据能最快支持或推翻它？
如果判断错了，最先会在哪里暴露？我能不能及时看见？
失败以后还有什么办法？什么结果意味着继续、调整或放弃？

这些问题可以先写得很简略，重点是给接下来的行动一个依据。如果某一项暂时答不上来，也可以把它留作下一步需要查清楚的事情。等事情做完，再回来对照一下，看看当时漏掉了什么，哪些检查值得留给下一次。

写在最后

“不要用行动代替思考，也不要用信息量代替判断力”，这句话我还是想留下来。它和我过去的工作方式有关系，也能提醒我，忙了很久和判断得更清楚之间，并没有一个自动成立的等号。

过去解决问题的经验仍然有用，行动和试错也会继续。我想做的调整，是尽量在投入之前说清楚自己的判断，给它设计一个验证办法，并想好判断错误以后如何发现、如何处理。做完以后，再看看哪些经验能够让下次少绕一点路。

这篇文章写完，也还只能算把这件事想了一遍。下次再碰到一个复杂问题，我想先试着写下自己现在的解释，以及什么结果会让我改变它。然后带着这两个问题开始做事，看看和过去有什么不同。