先把失效的结论标成“待验证”,再回到你最近一次真实操作的证据链上核对:哪一步的观察支持了旧结论,哪一步只是当时凑巧。修订笔记不是把旧内容删掉重写,而是把每条结论拆成“条件—动作—可核对结果”,条件变了就改条件,动作没变就保留动作。
这两种情况的修订方式完全不同,混在一起改,会把本来正确的操作一起推翻。
条件一:结论本身没错,但适用前提消失了。典型信号是,同一条操作在旧项目里有效,在新项目里无效,而两次的站点结构、内容类型或竞争环境明显不同。这时要改的是笔记里的前提描述,而不是动作本身。例如旧笔记写“栏目页集中内链到首页”,你后来发现这个做法只在栏目数量少时成立,栏目一多就稀释了重点。修订动作是在该条前加一行适用条件:“栏目数少于 X 且首页承担主要转化目标时使用”,动作保留。
条件二:结论从一开始就建立在错误归因上。典型信号是,你回看当时的记录,发现只有结果数据,没有中间观察;或者当时同时做了三件事,却把效果归给了其中一件。这时要改的是结论本身。修订动作是先把该条降级为“假设”,再补一个能区分原因的最小核对项,比如只改一个变量、只观察一个指标。
判断属于哪一种,可以问自己:如果今天把同样的动作放到同样的条件下,我是否仍然相信它会带来同样的结果?答“是”但条件不同,属于第一种;答“不确定”或“当时其实没单独验证过”,属于第二种。
多人对同一条笔记有不同理解时,争论记忆没有意义,因为记忆会随最近一次经历被改写。有效的做法是把分歧写成一张核对表,让每个人认领自己能提供证据的部分。
这样做的结果通常不是某一方获胜,而是发现分歧其实来自条件不同:一个人说的是新站冷启动阶段,另一个人说的是已有稳定流量的站点。把条件补进笔记后,两个人的说法可以同时成立,各自标注适用范围。
直接覆盖旧内容是修订笔记里最常见的错误,因为它让你失去对比的依据。更稳的做法是保留旧版本,在旁边写清修订原因和核对依据。
可以用一个最小结构记录每条结论:
结论:一句话写清动作和它指向的结果。适用条件:站点阶段、内容类型、页面规模等前提。核对依据:哪次操作、观察到什么、是否只改了一个变量。状态:有效、待验证、已失效。修订记录:日期加一句为什么改。当一条结论被标为“已失效”,不要立刻删除。先看它失效的原因是否属于上面第一种情况;如果是,改条件后重新标为“待验证”,并在下一次真实操作中专门观察它。这个动作会直接影响你下一步的笔记结构:如果反复出现“条件不同导致结论不同”,说明你的笔记缺的不是结论,而是条件字段。
假设你笔记里有一条“新页面发布后当天提交收录”。甲认为这条早已失效,因为他最近几次提交后当天都没有收录;乙认为仍然有效,因为他负责的站点提交后通常很快被处理。
把两人的记录摊开后可能发现:甲做的是内容高度重复的聚合页,乙做的是原创单页。那么这条笔记的正确修订不是判断“提交收录”这个动作有没有用,而是补上条件:“原创度较高、与已有内容差异明显的页面,提交后处理更快;重复度高的页面,提交动作本身不改变处理结果。”同时把“当天收录”这个预期结果改成“提交后进入待处理队列”,因为“当天”这个时间承诺本来就不该写进结论。
这个例子里,实施动作是补条件、改预期,而不是删动作。结果是甲和乙的操作笔记合并成一条带条件的结论,后续遇到新页面时可以按内容差异程度决定是否优先提交。
有两种例外值得保留原样。第一,某条结论只被一次观察否定,而这次观察同时伴随其他明显变化,比如站点改版、服务器异常或流量来源结构突变。这时证据不足以判定结论失效,只能标为“存疑”,并等下一次条件更干净的操作再核对。
第二,你暂时无法区分原因。此时正确动作不是改结论,而是设计一个只改一个变量的核对项,哪怕它很小。把无法区分原因的条目单独列成一个清单,定期回看,比仓促改写更能保护笔记的可靠性。
修订笔记的最终标准不是内容变新,而是每一条都能回答:它在什么条件下成立,我凭什么相信它,以及如果它不成立,我下一步该观察什么。