#知识生命周期：让变化决定回答状态

核心概念 · 知识不是一次写入后永久正确

资料会更新、撤回、拆分或被新版本替代。用户需要的是一套能让答案跟随这些变化的工作流，而不是只把文本永久堆进索引。

#一个知识单元的状态

#哪些状态转换需要被解释

状态不是内部技术日志。每一次会影响回答保证的转换都要让使用者能理解原因：

若一个状态变化无法说明用户结果如何改变，它还不是可用的生命周期语义。

#先按变化事件决定动作

#更新不是简单覆盖

更新一份政策页时，需要分别回答：原文是否变了、哪些知识单元受影响、哪些索引需要重建、旧引用是否还能解释当时的答案。这个过程需要 revision、idempotency 和激活状态，而不是一次无痕覆盖。

#失败时保持事实边界

如果某个 adapter 没有完成重建，系统不应假装所有检索结果已经最新。正确行为是保留清晰状态、支持重试，并让调用方知道当前保证到哪里为止。

#当前可做与目标版本的区别

当前阶段，团队可在资料卡和变化演练中维护这些状态；0.x 目标版本则必须把状态、修订关系、影响范围和处理边界带到使用者可查看的结果中。具体的队列、任务和存储实现可以变化，但“未完成不能冒充已最新”的合同不能变化。

#给使用者的恢复问题

发生变化后，先问四件事：哪份原文变了？哪些知识单元受影响？哪些索引或检查点仍未完成？面向用户的回答是否需要暂停、降级或重新检查？把答案写进工作流卡，才能让“更新完成”成为可验证的结论。

下一步：处理资料更新、替代与撤回。