智搜宝使用教程：旧笔记失效后该删条目还是改判断条件
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /57b5fe4c5ca3.html
📄
智搜宝使用教程：旧笔记失效后该删条目还是改判断条件
先给结论：如果旧笔记失效的原因是结论本身错了，删掉条目；如果只是适用条件变了，保留条目并补上“失效边界”。判断依据是能否指出一个具体反例——在什么输入、什么版本、什么权限下，原结论不再成立。能指出反例的，属于条件问题，改条件；指不出的，才是结论问题，删掉重写。
先分清两种失效：结论错了还是条件漏了
很多人修订笔记时第一反应是整段划掉重写，结果把仍然有效的部分一起丢掉。更省事的做法是先做一次归因：把旧结论拆成“前提 + 动作 + 预期结果”三段，逐段对照现在的情况。
- 前提变了：动作和结果之间的因果关系仍然成立，只是你当时没写清前提。例如笔记写“先建索引再导入”，但没说索引字段类型必须匹配，换了数据类型后导入失败。这属于条件漏写。
- 动作本身不再适用：操作入口、参数含义或流程顺序已经不同，照着做会走错路。这属于结论过期。
- 预期结果被误读：动作没变，但当时把“没有报错”当成了“处理成功”。这属于判断标准问题，既不是删也不是改条件，而是补一条验证动作。
只有第一类适合“保留 + 补条件”，后两类都要动结论本身。把这三类混在一起改，笔记会越改越乱。
一个反例：为什么“补一句适用版本”有时反而有害
假设你的笔记里有一条：“批量导入前先清空目标表，避免重复记录。”后来你发现清空会连带删掉另一批正在使用的数据，于是改成“导入前先清空目标表（仅限独立测试库）”。这个修订看起来合理，但它制造了一个新风险：读者看到括号里的限定，会默认只要不在测试库就无需清空，而真正该做的是改成“按主键去重后追加”。
这个反例说明：当失效原因是动作选错了，补限定条件只是把错误圈在一个更小的范围里，并没有修好它。判断方法很简单——问自己“如果条件永远满足，这个动作还会不会出问题”。会，就说明问题在动作，不在条件。
修订笔记时先做一次“条件回填”
对判定为条件问题的条目，不要只写一句“注意版本差异”，而要回填成可执行的判断句。一个可用的格式是：
- 写出触发条件，用可观察的事实描述，而不是“旧版本”“某些情况”这类模糊词；
- 写出满足条件时的动作；
- 写出不满足条件时的替代动作，避免读者卡在原地；
- 写出一个能验证结果是否正确的检查点。
例如把“导入前先清空目标表”改写成：“若目标表只被本次任务使用，先清空再导入；若与其他任务共用，按主键去重后追加；导入后核对记录总数与去重后预期值是否一致。”这样修改后，下一步动作是明确的，而不是让读者自己去猜。
改完之后，用一次小范围复现来确认
修订完成不等于笔记可用。挑一个最小输入复现一次，重点看两件事：按新条件执行时是否真的走到了预期分支，以及在不满足条件时替代动作是否也能跑通。如果替代分支跑不通，说明条件划分还不完整，需要继续拆分，而不是急着把笔记发布出去。
复现时记录下你实际使用的输入和观察到的结果，而不是只写“验证通过”。这份记录本身就是下一次修订的起点——当它再次失效时，你能立刻看出是条件又变了，还是当初的验证覆盖不够。
下一步动作
打开你最近一次失效的笔记，只做一件事：给它补一个具体反例。写不出反例的条目直接删掉；写得出的，按上面的格式回填条件和替代动作，然后用最小输入跑一遍。跑通之后再决定是否保留原条目，这比一次性重写整份笔记更可靠。
