那天我看到一批自动整理出来的经验条目，第一反应不是“这次总结得不错”，而是觉得里面有些话不太对。它们的格式很像经验：先写一条规矩，再补一句为什么，读起来完整、肯定，甚至带着一种已经被验证过的口气。
问题也正出在这里。经验一旦写成了规矩，就不再只是对过去的描述，而会影响下一次行动。如果我把一条未经核对的判断继续放进知识库，后面的人会把它当成前提；如果它还被展示成已经完成的沉淀，错误就会获得一层系统的权威感。
看起来像经验的文字，最多只能算待核验的候选，不能直接算作经验。
我一开始不相信的，不只是结论
最容易误判的做法，是只看结论有没有道理。比如，“拆分一个技能前，先检查脚本里有没有硬编码旧路径”，这句话本身听起来很合理。即使我认可它，也不能立刻接受后面那句解释。它究竟是来自一次真实的失败，还是因为这次刚好顺利，所以事后补了一段听起来很像原因的话？
这两个问题必须分开。结论可能有用，理由却可能是错的；一次操作可能没有出问题，也不代表它已经形成了可推广的规律。要是只检查前半句，就会把错误的因果关系一起保存下来。下一次遇到不同目录结构、不同项目归属时，别人可能照着错误理由做出更大的判断。
所以我把每条经验拆成几个部分来看：当时到底发生了什么，结论是什么，理由是否被事实支持，来源在哪里，以及它是否真的进入了后续使用的系统。经验的可信度不是由语气决定的，而是由事实、理由和落地结果共同决定的。
19条看似完整的经验，核验后分成了3类
逐条回到仓库、路径和实际流程核对后，19条经验没有被简单地分成“正确”和“错误”。最后只有6条完全正确，7条的结论可以保留，但原来的理由不成立，还有6条不应该写成规矩。
这个分类很重要。若把7条“结论可用但理由错误”的内容直接删掉，会损失一些有价值的提醒；若把它们原样留下，又会继续传播错误解释。更稳妥的做法，是保留结论能够被事实支持的部分，同时改写理由，明确它目前被什么证据支持、还有什么范围限制。
另外6条也不应该被称为“错误经验”后就结束。它们更准确的状态是“待修问题”：有的只是一次顺利运行，没有失败记录；有的把相关但不相同的现象拼到了一起；还有的把推测写成了已经发生的系统动作。一次跑通只能证明这一次没有失败，不能单独证明它值得沉淀成教训。
我更愿意把“失败或可复核依据”看成经验的最低门槛。失败说明某个做法在特定条件下确实产生了问题；可复核依据则让别人可以沿着同一条路径重新检查。没有这两类支撑，文字再像规矩，也应该停留在候选状态。
来源核对，常常比文字核对更关键
核验过程中还有一个容易被忽略的坑：用仓库名称做同名匹配。看起来只要搜到同名项目，就可以继续确认文件和路径；但不同项目可能共享相似名称。匹配错了以后，后面所有检查都会变得“有证据”，只是证据属于另一个地方。
我因此改用版本库的远程归属信息核对项目身份，再确认文件是否属于这次操作。这个变化看起来只是换了一种检索条件，实际却改变了证据质量。名称只能说明“可能是它”，归属信息才能更接近“确实是它”。
这件事让我重新意识到，核验不是把文字里的关键词再搜索一遍。它要回答的是：这条经验指向的对象是不是当时那个对象？路径是否真实存在？操作是否真的发生？如果不处理这些问题，会导致一条看似严谨的经验把别的项目、别的文件和别的结果串在一起。
“已经入库”也必须有回执
我还发现一个更直接的问题：有一条描述声称经验已经自动解析并写入系统，但实际流程里并没有运行这一步。它不是“入库失败”，而是根本没有发生。
这类错误尤其危险，因为“已入库”会改变读者对内容状态的理解。读者会以为系统已经保存、后续可以检索、规则队列也会使用它，于是跳过再次确认。如果不处理，错误结论和错误状态会叠加，最后连排查入口都很难找。
我的选择是增加一个明确的核验入口，并留下回执结果。它不需要把整个内部过程展示出来，但至少要能说明：解析是否运行、写入是否完成、写入了什么、回读是否一致。“系统说已经保存”和“回读证明确实保存”是两件不同的事。
后来呈现方式也随之调整。原来那种把经验包在一大段标记里的写法，容易让人把格式当成可信度；我改成引用卡片，区分原始判断、核验结果和当前状态，并删除没有证据的自动入库描述。写入线上后再回读，确认页面呈现和本地模板一致。格式不是装饰，它会影响读者把什么当成事实。
一套可以复用的逐条核验流程
现在遇到模型自动生成的经验，我会先把它当作候选记录，而不是直接沉淀。第一步记录事实来源：它来自哪次操作、哪个对象、哪段过程。第二步分别检查结论和理由，不因为结论听起来合理，就默认理由也成立。
第三步给它标记结果类型。事实，是能够在原始记录或实际对象中直接复核的内容；推断，是基于事实得到、但还需要说明条件和范围的判断；待修，是证据不足、来源串错、理由不成立，或者声称完成却没有回执的内容。三者必须在呈现上分开。
第四步执行针对性的检查：确认对象归属，回到真实路径和实际流程，检查关键动作是否发生，最后检查写入后的回读结果。不要用一条“整体看起来没问题”替代这些检查，因为不同类型的错误藏在不同环节里。
第五步才决定去向。完全正确的内容进入规则队列；结论可用但理由错误的内容先修正文案；待修内容保留问题和证据缺口，但不继续作为规矩传播。这个流程的价值，不是把所有不确定性都消灭，而是让不确定性有一个不会误伤后续工作的容器。
这里尤其要给“推断”留出位置。很多工作判断并不是原始事实本身，却也不是随意猜测。例如，某个路径检查在这次拆分中确实帮助我们避开了问题，可以推断它值得在类似场景中优先检查；但这不等于所有项目、所有目录都必须用同一种方式处理。推断要附带条件，事实要保留出处，待修要写明缺口。把这3种内容挤成同一种肯定语气，才是经验系统最危险的失真。
我还会记录“为什么暂时不能确认”，而不是只写一个模糊的待定。是原始记录缺失，还是对象归属没有确认？是动作没有回执，还是理由和结果不匹配？这些差异决定下一轮该查哪里，也让后来的人知道这条内容不是被随手否定，而是卡在一个明确的证据门槛上。
下次我会怎么做
下次再看到自动生成的经验，我不会先问它写得像不像，而会先问它能不能被核对。我会要求每条记录同时带着事实来源、核验动作、结果类型和不确定性；只要其中一项缺失，就不把它当成完成的经验。
我也会把“入库”拆成几个可观察的状态：准备写入、已写入、回读一致，分别留下最小必要的结果。这样，呈现格式和核验流程就不会各自发展成一套说法。读者看到的卡片，应该能知道这句话是什么、凭什么、现在处于哪一步。
真正值得沉淀的，不是模型替我们写出的漂亮总结，而是经过核对后仍然站得住的判断。一个经验系统成熟的标志，不是它能自动生成多少条经验，而是它能在错误出现时阻止错误继续变成规矩。