隐性判断变显性规则，只需要三步

一个资深运营离职，他脑子里那些判断就没了。他能一眼看出某个品撑不住，这个能力写不进任何一份 SOP，因为它没有触发条件，只有一个模糊的感觉。

新人接手后从头摸索，摸索三个月，走的弯路跟他当年一样。这笔成本每年都在悄悄发生。

经验沉淀这件事，难的不是记录，是把感觉变成能用的东西。

三步：捕捉、归并、写死

隐性判断转显性规则的三步与两个陷阱

第一步，捕捉。在判断发生的当场记录，不靠事后回忆。

事后回忆出来的规则大部分是编的。人会给自己补一套听起来合理的原因。

捕捉只有三个字段：当时看到了什么信号、做了什么动作、结果如何。三行字。判断正确也记，判断错误更记——错误的判断后面会变成风险清单。

我自己的做法是手机备忘录，决策当场就写。事后整理这件事会拖，永远拖。

第二步，归并。把多次重复的判断合并成一条。

一个人三个月做了二十次砍品决策，其中十五次的判断依据是同一类信号，只是描述不同。这十五次应该合并成一条规则。

归并有两个门槛：同一类信号出现过三次以上，且每次的判断结论一致。不满足就不要合并。两条判断结论相反的，说明中间还有一个没识别出来的变量。

第三步，写死。规则必须有触发条件、有动作、有验证方式。

第三要素是最常被漏掉的，也是最重要的一条。一条永远不验证的规则，三个月后没人知道它还对不对，但它还在流程里。

两个陷阱

陷阱一：把流程写成规则。 步骤固定、结果固定的东西不是规则，是流程，放进 SOP 就行。规则的特征是有判断——同样的信号，不同的人可能给出不同结论，这类才需要沉淀。

陷阱二：规则写成了个人偏好。 "我们这个品永远不打九折"这不是规则，这是偏好。规则要有触发条件。没有触发条件的句子在规则库里会稀释整份文件的分量。

规则库要有人负责

我见过团队建了规则库，三个月后里面塞了两百条，然后废弃了。原因很简单：写的时候没人负责，出错的时候不知道改哪一条，最后没人信它。

规则库要有一个人做两件事：每季度复核一次，把已经不适用的删掉；出了新问题先查规则库，查到已有规则就用老规则，改了规则就更新版本。

删旧规则这件事很难，因为删除会让人不安。我现在的做法是每条规则标上生效日期和最后一次复核日期，超过一年没复核的自动降级为参考。

一个只有三十条、但每条都在用的规则库，胜过两百条没人查的。

判断沉淀有没有做出来

有一个检验方法：新人遇到问题时，第一个动作是查规则库，还是找人问。

一个月内被问的次数多，说明规则库写的是结论而不是触发条件——结论好记，触发条件难写，所以大多数团队只记了结论。

记触发条件才是全部的难点，也是全部的价值。