先给结论:旧笔记失效,通常不是“知识全错了”,而是笔记里混进了三类内容——当时有效的平台规则、你当时能观察到的现象、以及你从现象推出的因果解释。修订时不要整本重写,而是先把这三类拆开,只替换“规则”和“因果解释”,保留可复用的判断流程。判断该不该改,看的是新证据能不能区分两种解释,而不是看笔记写得早不早。
很多人遇到的情况是:笔记里写“先做A,再做B,结果C会出现”,你按顺序执行,C却没出现,甚至出现相反的D。此时有两种合理解释。
这两种解释会导致完全不同的修订动作。如果是解释一,你要更新规则;如果是解释二,你要删掉那条因果,而不是换成一条新的因果。
关键证据是时间序列上的对照,而不是单次结果。假设你笔记里有一条:“把标题改短后,点击率会上升”。现在改短后点击率没升,你可以这样取证据:
能区分解释一和解释二的证据,是旧规则在旧条件下的复现能力。如果你能找到一个仍然满足旧条件的小场景,旧规则依然成立,那更可能是条件变了;如果连旧条件都凑不齐、或者凑齐了也不成立,才考虑是笔记本身记错了。
不要直接删掉旧句子,先给每条结论加一个状态标记。一个可用的做法是:
[规则]:有明确适用条件、可重复验证的操作,比如“提交前检查结构化数据是否通过校验”。[观察]:某次看到的现象,尚未确认因果,比如“某次改版后收录变快”。[假设]:你推测的原因,等待证据,比如“可能是因为内链变多了”。标记完你会发现,真正需要改的往往只有少数几条[假设]。这一步的实际动作是:把失效的那条从[规则]降级为[观察],并写清楚它当时成立的条件。这样做的影响是,你下次遇到类似情况时不会直接套用,而是先核对条件是否还在。
假设你的笔记里写着:“新页面发布后,24小时内手动提交,收录会更快。”现在你照做,收录没有变快。你可以这样处理:把这条降级为[观察],并补一句“当时站点整体抓取频率较高”。然后下一步动作是:不再把“手动提交”当作收录加速的固定步骤,而是先看站点日志里抓取是否正常。如果抓取本身正常,提交与否对结果的影响就有限;如果抓取异常,才需要单独排查原因。这个动作的结果,会决定你是继续修订提交策略,还是把精力转到抓取诊断上。
并非所有失效都值得改。如果一条笔记只服务于一个已经不再做的项目、或者只针对一个已经下线的功能,保留它但标注“已归档”比花时间修订更划算。判断标准是:这条结论会不会影响你接下来的决策。会影响的,按上面的状态标记修订;不会影响的,归档即可。修订的目的是让笔记继续帮你做判断,而不是让它看起来永远正确。