不是所有停止都意味着系统坏了
这次遇到的场景很具体：我在构建一个知识库，构建过程因为书封哈希与目录台账不一致而停了。表面看，这就是一个报错。命令没有跑完，章节和段落级的出处包暂时不能使用；但另一条金句检索路径仍然正常。
如果只看结果，很容易得出一个粗糙判断：既然有一条路径还能用，那就先把校验关掉，让剩下的内容继续生成。可我停下来想了想，真正需要处理的不是“这次构建为什么没跑完”，而是“系统眼里的这份资产，到底是不是它台账里记录的那一份”。
哈希不一致首先是事实差异，不是程序心情不好。
这个区别很重要。程序本身并不知道文件为什么变化，它只能告诉我：目录里保存的承诺，与当前读到的文件不再相同。变化可能来自资产被更新，也可能来自目录记录过期。两种情况都能触发同一个提示，但后续动作完全不同。
我一开始最想做的，是让流程先跑起来
面对停止的构建任务，人很自然会想先恢复产出。最容易误判的地方，是把“校验失败”理解为“校验太严格”。如果我直接把当前文件的哈希写回台账，或者干脆关闭检查，构建可能很快恢复，看上去也像是问题解决了。
但这种做法只是把问题从入口推到了结果里。知识库后面要提供章节和段落级出处。如果资产已经被替换，却没有留下替换的事实，未来有人根据旧目录追溯来源时，就无法判断当时检索到的内容对应哪个版本。一个能运行的索引，可能因此变成一个无法解释的索引。
如果不处理这层关系，会导致更隐蔽的后果：今天构建成功，过一段时间检索结果仍然能返回，但我已经说不清它引用的封面、章节或参考资料是哪一版。错误不会每次都以失败的形式出现，也可能以“看起来正常”的结果继续扩散。
所以，错误捷径不是让程序失败，而是让程序失去拒绝错误资产的能力。我没有直接改成当前哈希，也没有关闭校验，是因为这两种动作都绕开了最有价值的事实：文件究竟发生了什么变化。
先把“文件变了”与“台账旧了”分开
我会把这次问题拆成两个对象来看。第一个对象是实际文件，第二个对象是目录里的资产记录。记录通常包含文件位置、哈希和其他用于识别资产的信息；实际文件则是构建过程当前真正读到的内容。两者不一致，只说明它们之间的契约被打破了，还没有说明谁应该被修改。
第一步不是编辑任何一边，而是保留证据。先读取台账中的旧记录，再对当前文件重新计算哈希，记录文件的修改线索，并确认这个文件是否就是构建所引用的那个资产。尤其要注意近期是否新增了参考图：新增文件可能本来就是一次合法更新，也可能只是把另一个相似文件放进了目录，导致引用关系发生漂移。
这里的顺序不能倒。若先改台账，再去检查文件，我就失去了比较前后的基准。等到后来发现这不是一次正常更新，而是文件放错位置或被意外覆盖时，已经很难还原原来的状态。
判断哈希漂移的关键，不是哪个值“看起来更新”，而是变化是否有来源、是否有版本、是否能被解释。
如果证据显示资产内容确实被更新，就应该把它视为一次版本变化。台账需要补充新的哈希、对应的版本或变更说明，旧记录不能被悄悄抹掉。如果证据显示文件没有合理的更新来源，或者当前文件与目录声明的资产并不是同一个对象，那么应该先恢复正确引用关系，而不是把异常文件认领进台账。
台账不是备份，它是资产的承诺
以前我容易把目录台账看成一个方便检索的清单：文件在哪里、叫什么名字、哈希是多少。遇到不一致时，改掉那个值似乎只是维护工作。但这次让我重新意识到，台账更像一份契约。它向后续流程承诺：这条记录指向某个确定的资产，构建出来的索引可以被追溯，检查结果可以被复核。
契约的价值，恰恰体现在不一致的时候。顺利时，文件和台账自然会对上，没人会特别感受到校验的存在；发生变化时，校验把“我以为没变”和“它实际上变了”之间的距离显露出来。它不是为了让流程难受，而是为了阻止不明来源的变化进入长期资产。
这也解释了为什么另一个金句检索路径仍然可用，并不能证明章节出处包也可以照常使用。不同检索路径可能依赖不同的数据产物。一条路径正常，只能说明它自己的依赖没有被这次差异击穿，不能替另一条路径作担保。
我会因此把“部分可用”写成边界，而不是写成“系统基本正常”。能够继续使用的部分继续保留；依赖不一致资产的部分明确暂不可用。这样做的好处是，用户知道哪些结果仍可相信，也知道哪些结果必须等待修复后再验证。
修正完成不等于出处包可信
按契约维护资产之后，下一步才是重建知识库。这里仍然有一个容易省略的动作：不要把构建命令退出成功当成最终验收。构建成功只说明程序完成了它的流程，未必说明章节和段落级出处已经真的可检索。
我会在重建后做一次实际的章节检索，确认结果能返回，且返回内容与修正后的资产关系一致。这个检索不是为了再跑一遍命令，而是为了验证用户最终会使用的路径。若索引文件生成了，但检索不到章节，或者检索结果无法对应出处，形式上的成功仍然没有转化为可用的知识库。
失败也有不同层次。资产校验失败时，问题在来源契约；重建失败时，问题可能在构建过程；重建成功但章节检索失败时，问题落在产物或查询链路。把它们分开，才能知道下一步该检查哪里，而不是反复重跑同一个入口。
真正的验收不是“构建结束”，而是“依赖这份资产的实际检索能够被解释和复核”。
这条规则对其他资料库也适用。图片、音频、文档、模型文件，只要目录记录了哈希或版本，就不能把哈希当成装饰字段。字段存在的意义，就是在资产改变时迫使我们回答：为什么变、谁批准、如何追溯、哪些产物需要重建。
我留下了一套可复用的判断流程
后来我把这类问题整理成一个很短的流程。先停住受影响的构建，不扩大损坏范围；再同时保留旧台账和当前文件的证据；接着判断差异来自合法更新、台账过期，还是文件错位。确认是合法更新后，补版本与变更说明，再更新台账；确认不是合法更新，就恢复正确资产关系。最后重建依赖它的索引，并用实际章节检索验证结果。
这个流程看起来比“改一个哈希值”慢，但它把一次偶发报错变成了一条可以复查的变更记录。以后再看到同类提示，我不需要从“能不能先跳过”开始想，而会先问两个问题：这份资产的变化有没有来源？这条台账记录是否仍然代表我想交付的对象？
我也会把可用范围写清楚。未受影响的金句路径可以继续使用，但章节和段落级出处包在重建并检索验证前，不能被默认视为可用。边界写得越明确，后续协作越不容易把“部分恢复”误读成“全部恢复”。
一个成熟的知识库，不是永远不报错，而是在报错时能保住证据、解释变化，并按契约恢复。
这件事让我重新意识到，长期积累的价值不只在于资料越来越多，也在于每份资料的身份越来越清楚。没有台账，文件只是堆在目录里的内容；没有哈希，台账只是一个人的记忆；没有重建后的检索验证，构建结果又只是一个漂亮的结束信号。三者连在一起，知识库才真正拥有可以持续维护的秩序。
下次我会怎么做
下次遇到资产校验失败，我会先把它当成一次版本审计，而不是一次普通报错。第 1 步，暂停受影响的构建并标记受影响范围；第 2 步，保留旧台账和当前文件的对照证据；第 3 步，确认变化来源，区分资产更新、台账过期和文件错位；第 4 步，按契约补版本与变更说明，或者恢复正确引用；第 5 步，重建相关索引；第 6 步，用实际章节检索验收。
我会特别提醒自己，不因为另一条路径还能用，就替失败的路径提前背书，也不因为构建命令成功退出，就跳过用户真正需要的检索验证。工具真正改变的不是速度，而是我们愿不愿意把判断过程留下来，让下一次面对变化时，不必从猜测开始。