OpenDeepWiki / AACR

摘要：知识不是“能搜到”，而是“能继续做”

很多知识库在演示时都很顺利：导入一个仓库，生成一份漂亮目录，再让模型回答几个问题。但真正交接一个持续变化的项目时，问题会变成另一组：哪份文件才是当前事实？某项功能是已完成、失败了，还是只存在于聊天里？如果生成过程半途停止，应该重新来过，还是保护已有成果？

我把 OpenDeepWiki 作为知识生成运行时，把 AACR 作为长期项目记忆和证据治理层。前者负责理解项目，后者负责告诉下一位执行者：结果从哪里来、验证到哪一步、失败发生在哪里、接下来怎样安全继续。

为什么普通“项目总结”不够

模型很擅长把大量信息压缩成一段通顺的说明，但压缩会抹平状态差异。历史计划可能听起来像已完成功能，一次聊天中的建议也可能被误认成正式决策。

因此我给系统设定了三条事实规则：

1. 文件和 Git 记录是长期事实源；聊天只提供发现路径。
2. 任何“完成”都要指向可检查的文件、运行结果或验证记录。
3. 未完成、受阻和替代方案必须与成功结果放在同一层级记录。

这让知识库不只回答“这个项目是什么”，还能回答“现在究竟做到哪了”。

把真实工作目录安全地交给系统

早期导入失败暴露了一个很现实的问题：工作目录不只有源代码，还混有嵌套 Git、依赖、缓存、虚拟环境和构建产物。直接复制整个目录既慢，也可能因为一个不可读的 pack 文件让任务全部失败。

我的选择不是要求使用者手动维护第二份“干净项目”，而是在导入边界解决它：

• 使用者继续粘贴熟悉的 Windows 路径；
• 容器只读挂载原项目；
• 导入器跳过版本库内部、依赖、缓存和构建目录；
• 单个不可读文件只记录警告，不再让整次分析失败。

这项决定看似偏工程，实际是产品体验：系统适应人的真实工作环境，而不是把清理成本转嫁给使用者。

最重要的一次判断：先保护 68 份文档

在一次高价值项目恢复中，中文 Wiki 的 68 份文档和思维导图已经完成，随后原生 Graphify 进入长时间 I/O 等待，没有生成结果。

最容易做的动作是按下“全部重新生成”。但这会让已经验证过的文档再次暴露在模型、配额和运行时变化中，也无法证明图谱问题会因此消失。

我选择把图谱故障隔离：先将残留任务标记为需要人工复核，再从已有目录、文档和来源文件元数据中导出轻量图谱。这个导出不调用模型、不修改数据库文档，只产生可以人工检查的 JSON 和 Markdown。它不是完整语义图谱，却足以完成 v0.1 的目录关系和来源追踪。

不让“功能必须全部成功”的执念，破坏已经真实成立的价值。

结果不是一个数字，而是一条可追踪链路

这次恢复最终留下 86 个图谱节点，其中 68 个具有文档内容，并建立 51 条来源文件边。数字本身不是目标；重要的是阅读者能从一个结论回到目录、文档，再回到产生它的真实文件。

系统同时保留运行手册、错误处理、保护规则和下一步。因此新的 Agent 不需要相信上一段聊天，也不需要从数千条记录中猜测当前状态。

我在这个项目中学到的事

知识系统真正的产品指标，不是保存了多少内容，而是下一位执行者能否：

• 在几分钟内找到当前事实；
• 分辨完成、计划、失败和推断；
• 知道哪些成果不能被覆盖；
• 沿着证据继续工作，而不是重新开始。

对我而言，这也是 AI Product Design Engineering 的一个缩影：模型负责理解和生成，工程系统负责边界、状态与恢复，人负责决定什么值得保护，以及什么时候应该停止自动化。