让 AI 维护的知识库经得起审计

背景与约束

当多个 AI Agent 长期参与同一个知识库维护时，最大的风险不是某一篇笔记写得不好，而是系统逐渐失去可追溯性：入口文件被漏扫、同一原件重复归档、来源不足的研究稿被当成事实，甚至历史日志会错误记录“审计已经通过”。

目标是让知识库持续回答三个问题：资料从哪里来、经过了什么处理、现在是否仍然符合规则。

关键判断

文件名不能证明重复

同名文件可能内容不同，异名文件也可能完全相同。重复清理必须用内容哈希建立证据，只删除确认重复的入口副本，保留唯一原件。

审计必须递归

只检查入口顶层会漏掉子目录研究稿。维护规则要求递归枚举全部有效入口，并把实际数量写入日志。

未处理入口必须让审计失败

旧脚本只有发现重复时才报错；全新但尚未处理的文件反而可能让审计通过。修复后，只要入口存在任何有效文件，就报告未处理入口并返回失败。

不确定内容进入复核

版本、性能、许可证和迁移结论可能过时或缺少一手来源。这类内容保留为低可信并进入复核队列，不会因为文件已经存在就自动升级为事实。

实施过程

1. 读取知识库规则、分类法、模板和最近日志。
2. 检查 Git 状态，隔离用户已有改动。
3. 递归枚举入口和归档，计算内容哈希。
4. 清理确认重复的入口副本，保留原始资料。
5. 补处理漏扫研究稿并建立低可信复核记录。
6. 修复重复别名、损坏字符和错误历史日志。
7. 强化审计脚本，让任何未处理入口成为硬失败。
8. 运行自测、全库审计和 Git 差异检查。

结果与复用

真正的产出不是“整理了多少文件”，而是把知识库从依赖 Agent 自觉的流程，变成带自动阻断、人工复核和 Git 证据的治理系统。

AI 参与知识管理时，最重要的不是让它写得更多，而是让它留下证据、承认不确定，并在规则不满足时主动失败。

Evidence

验证证据