从一个项目
看通用工程

结论先行

它在资料进入时生成可读 Markdown、链接与索引，让部分推理结果能够跨查询复用；查询阶段仍使用关键词、向量和图扩展。 真正可迁移的思路，是把概率模型放进可追踪、可校验、可回滚的流水线，而不是复制某个 UI、向量库或 Prompt。

我们如何审计

项目快照

当前审计对象是 nashsu/llm_wiki 的 main 分支固定快照， 提交 889789c、标签 v0.6.10。 以下讲解以实际代码为准，而非仅复述 README。

测试规模只用于描述工程投入，不能替代语义评测、安全审计或线上可靠性证据。

七章审计地图

每章都保留案例证据，同时补上适用边界、失败模式和可验收的改进项。

不止一个桌面界面

保留价值，也拆掉光环

值得学习的地方

• 资产可退出：知识不是锁在应用数据库里，而是用户能直接拿走的 Markdown。
• 把维护当成产品核心：来源追踪、增量摄入、级联删除、文件历史与 Lint 都在解决“长期变脏”。
• 确定性代码包围概率模型：LLM 负责语义判断，路径校验、索引、日志、缓存和写入完整性由程序兜底。
• 能力渐进增强：小 Wiki 可只用索引和关键词；规模增长后再开启向量、图扩展、Agent 和外部研究。

需要正视的代价

• 写时计算比纯 RAG 更贵，摄入质量直接决定后续知识质量。
• 当前摄入缓存主要绑定源内容哈希，未把 Prompt、模型、解析器和 Schema 版本纳入完整指纹，规则升级后可能错误跳过重建。
• 单文件具备原子替换与历史，但多文件摄入失败会保留部分写入；这不是知识库级事务，重试和并发合并仍可能漂移。
• 来源主要停留在页面级元数据，尚不足以支撑主张级引用、冲突裁决、有效期和可信度管理。
• README 给出的检索提升指标在固定版本仓库中没有发现可复现的数据集、脚本和报告，不能作为已验证效果。
• 项目横跨 React、Rust、文件解析、LLM Provider、向量库和本地服务，维护面明显大于简单知识库。
• README 的 Rust 1.70+ 与 Cargo.toml 实际要求 Rust 1.88 存在文档漂移；构建时应以清单为准。