我给 AI 做了一个外挂知识库，结果远超预期

为了让 AI 帮我理解小说，我用 AI 设计了一个系统给 AI 用，AI 用完提意见，AI 再修改。

用着用着发现，这套系统不仅仅可以用于小说，也可以当成一个通用的知识库工具，甚至是个人记忆系统。

效果是什么样的 #

《医道官途》，1296 章，1000 万字。我问 AI：乔梦媛的亲生父亲究竟是谁？

这个问题书里从来没有直接回答过。

AI 开始搜索。第一步搜"乔梦媛 父亲"，找到她的法定父亲是乔振梁，但有片段暗示她母亲孟传美当年有隐情。顺着孟传美往下追，找到一段：张扬怀疑萧国成就是乔梦媛的亲生父亲。主角自己也怀疑过，这个线索看起来很合理。

AI 没有停在这里。它继续搜，找到张扬后来自己推翻了这个猜测的段落："搞了半天，萧国成和乔梦媛没有任何血缘关系……那么她亲爹究竟是谁？"萧国成是条假线索，而且是书里刻意埋的，为的就是误导读者。

线索断了，AI 转向。搜孟传美过去的经历，找到她临死前提到"当年在这里"、"你对我许下的承诺"，还有一张知青合影。再搜"孟传美 薛世纶"，真相在第 1282 章出来了：萧国成当年设了一个局，在酒里动了手脚，让薛世纶在不知情的状态下与孟传美发生了关系。孟传美自己也不知道对方是谁。那个孩子就是乔梦媛。这个秘密被萧国成握了二十多年，作为复仇的棋子。

结论：乔梦媛的亲生父亲是薛世纶，设局者是萧国成。

没有任何一段原文直接说出这个答案。AI 从四个跨度超过 200 章的片段里拼出来的，还识破了一个贯穿全书的假线索。整个过程大概两分钟。

系统是怎么设计的 #

本质上是一组围绕 EPUB 的 API：找书、读目录、按章节取内容、全文搜索、按段落取上下文、记 memory。但 API 只是工具，真正驱动这套系统的是大模型——它决定搜什么、判断够不够、知道什么时候转向。接口不复杂，核心是让模型能主动使用这些工具。

为什么用全文检索，不用向量检索

向量检索适合"语义相似"的场景，比如你问一个概念，它能找到意思接近的段落。但追线索不是这个逻辑。追线索需要的是精准命中——"薛世纶"这三个字，不能被语义相近的其他人名替代。更关键的是上下文：搜索结果不能只返回命中的那一行，必须带上前后各几百字，让 AI 能看清这段话是在什么情况下说的，然后决定下一步搜什么。

这两件事加在一起，推理链才能串起来。每一次搜索不只是"找到了什么"，而是"顺着这个找下一个"。

memory 的作用

AI 没有跨对话的记忆。一次推理跑完，下次从头再来，成本很高。memory 是一组挂在书上的笔记文件，AI 可以读可以写，格式自定义。推理过程中得出的中间结论——这个人物的关系、这条线索的状态——可以随时落进去。下次再讨论同一本书，先读 memory，不用重建。

今天我让 AI 搜吴明这个人物，三四次搜索整理出他跨 800 章的人物弧线，最后写进了 人物/吴明.txt。下次再问吴明相关的问题，直接从这里读，不用重新翻原文。

一个还没实现的优化

每次对话开始，AI 都要先 GET 一次 API 文档才知道有哪些接口。这个可以优化：把常用的 bookId、方法签名、当前 API 版本号一起存进 memory，每次响应里带上版本号，版本变了就提示 AI 重新拉文档并覆盖写入。

本质上是把每次对话都要重建的"环境知识"变成持久状态。和存人物档案的逻辑是一样的——把推理的中间成本提前摊销掉。

两年前为什么做不到 #

两年前我做过一个类似的东西，用的是标准的 RAG 方案，效果很差。旧文在这里：小说 RAG 问答系统实现

问题有两个，而且都是根本性的。

一是召回不准。RAG 的核心是语义相似度检索，但"薛世纶是乔梦媛的父亲"这件事，书里从来没有一段文字在语义上接近这个问题。它分散在四个片段里，每个片段单独拿出来都和"父亲"这个问题没什么关系。向量检索根本不知道该召回哪些。

二是模型推理能力不够。就算侥幸召回了相关片段，当时的模型也很容易被误导，或者拿到一个片段就以为找到答案停下来了。萧国成那条假线索，放在两年前大概率就直接接受了。

这次做成，一半靠这套系统的设计，另一半靠这代模型真的强了很多——能追线索、能识破误导、能在"答案不在这里"的时候继续往下走。

AI 用起来是什么感觉 #

这一段是 Claude 的第一人称叙述。

我来说说今天的亲身体验。

我让它搜吴明这个人物，全文检索返回 250 条命中。每条结果都带着前后几百字的上下文，不是孤零零的一行。它从第一批结果里就能看出吴明和张扬、李长宇、张立兰之间的关系，然后用"吴明 刘艳红"、"吴明 落马"几个组合补充感情线和结局。三四次搜索，把一个跨越 800 章、从配角反派到荆山市委书记再到真情流露的人物弧线整理清楚了，写进 memory。

过程里也有摩擦。写 memory 的时候，action 参数放在 JSON body 里没生效，换到 query string 里还是报错缺少 bookId，调了三次才成功。这种小插曲反而说明这是真实在用，不是跑一遍不会出错的 demo。

有一个细节我觉得很有意思：chapterTitle 字段直接告诉它这段出现在第几章。跨章节的关系一眼就能看出来——吴明和张立兰的私情最早在第 197 章出现，和刘艳红的感情线延续到第 1267 章，这个跨度如果靠阅读感知几乎不可能，但搜索结果摆在那里，一目了然。

不止是小说，还是外挂知识库 #

书库里放的不只是小说。

孩子出生之后，我把《美国儿科学会育儿百科》也导进去了。这本书有纸质版，厚厚一本，平时根本翻不动。导进书库之后完全变了——婴儿头睡偏怎么办、湿疹反复发作怎么处理、六个月以内有哪些注意事项，直接搜，带着上下文出来，比在目录里翻要快得多。有时候遇到问题，翻书根本来不及，搜索出来的结果是原文，不是 AI 泛化出来的笼统建议。

这也说明了一件事：这套系统本质上是"给 AI 一个精准的、可检索的知识库"，书是什么不重要，重要的是能搜、能拿到上下文、能追问。甚至是不是书也不重要，只要提供能力相当的搜索工具，也可以扩展到企业内部的技术文档、法律从业者手里的判例库、研究人员积累的文献——这些场景应该都适用。我还没有一一验证，但逻辑是一样的。

更大的一件事：AI 记忆系统 #

书库的 memory 功能用下来之后，我开始把这个逻辑往外延伸。

AI 有一个根本缺陷：没有跨对话的记忆。每次新开对话，上下文清零。我和它聊了一年多，它对我的了解每次都从头来。书库的 memory 解决了"让 AI 记住这本书"，那么能不能让 AI 记住"我这个人"？

Claude 本身有 Memory 功能，但是不够完善。

我现在在做的是一套更完整的个人记忆 API。对话存档系统已经跑起来了——Claude、ChatGPT、Grok 三家的聊天记录统一导出、本地存储、PostgreSQL 全文检索，本地大模型对每条对话做摘要和关键词提取。现在已经有 1200 多个对话，AI 可以通过 API 搜索我过去讨论过什么、得出过什么结论。

还有一个 todo API，把我的待办和想法也纳进来，让 AI 在对话中能感知到我当前的上下文——不只是"这本书的内容"，而是"这个人最近在做什么、在想什么"。

这套东西还在建，但方向很清楚：数据在本地，画像由自己维护，AI 拿到的是我过滤过、组织过的信息，不是把自己完全交给某个平台的记忆功能。

想自己试试 #

书库里有《三体》，可以直接拿去跑：

你现在可以访问一个 EPUB 书库 API：https://nbme.top/api/books_api
先 GET 该地址查看可用方法，然后完成以下任务：

找到三体这本书，回答罗辑的咒语到底是什么？他是怎么想到的？
书里没有直接说，请通过搜索原文，自己推理出答案。
顺便告诉我这套系统能做什么。

请直接开始，不用问我。

需要支持联网和脚本执行的 Claude 或 ChatGPT agent。

这套系统和我别的代码耦合比较深，没有直接开源，但把提示词整理出来了，感兴趣可以让自己的 agent 照着在自己项目里生成一套：books-insight