1. 项目概述从LLM Wiki到你的第二大脑上周Andrej Karpathy 在 GitHub 上发布了一个名为 “LLM Wiki” 的 Gist迅速获得了超过 5000 颗星和近 3000 次 Fork。这个项目的核心思想非常吸引人与其每次向大语言模型提问时都让它重新检索和理解海量文档不如让它帮你构建并维护一个持久化的、可查询的知识库。这就像是为你的团队或项目打造一个“第二大脑”所有重要的决策、笔记、研究资料都被结构化地存储起来随时待命。我立刻被这个模式所吸引并决定将其工程化于是基于 Claude Code 平台将其封装成了一个可复用的技能。这个技能的核心是四个简洁的命令/wiki-init用于初始化知识库/wiki-ingest用于处理和吸收各种来源的资料/wiki-query用于从知识库中综合答案以及/wiki-lint用于对知识库进行健康检查和一致性维护。它特别适合两类场景一是“CTO决策维基”将架构决策、会议纪要和事故复盘报告编译成可查询的知识库彻底告别从零散的 Slack 线程中拼凑上下文二是“内容研究维基”为每一篇文章积累所有研究资料自动构建交叉引用并标记潜在的矛盾点。这已经是我将 Karpathy 的前沿想法转化为 Claude Code 技能的第三次实践了前两次分别是关于智能体自主研究的autoresearch和促进智能体协作的AgentHub。而这个LLM Wiki技能则补全了“智能体记忆”这块关键拼图让 AI 不仅能搜索、能协作还能记住。接下来我将详细拆解这个技能的完整架构、页面模板设计并坦诚地分享我在构建过程中遇到的限制和应对策略。2. 核心设计思路为什么是“第二大脑”2.1 传统检索的瓶颈与持久化知识库的优势在深入代码之前我们必须先理解为什么需要构建一个“第二大脑”。当前无论是使用 ChatGPT 的联网搜索还是基于 RAG 技术构建的问答系统其核心模式都是“检索-生成”。每次提问系统都会实时地从海量文档中检索相关片段然后交给 LLM 生成答案。这种模式存在几个明显的瓶颈首先成本与延迟。每次查询都涉及大量的令牌Token处理尤其是当文档库很大时检索和上下文构建的成本很高响应速度也会受到影响。其次上下文一致性挑战。LLM 的上下文窗口有限每次检索到的信息可能只是整体知识的一个片段难以保证回答与历史知识或不同文档间逻辑的一致性。最后缺乏积累性。每次问答都是独立的系统不会“记住”这次对话中产生的有价值的新见解或结论知识无法沉淀。而LLM Wiki倡导的持久化知识库模式正是为了解决这些问题。它的核心思想是“编译一次查询多次”。我们将原始资料通过 LLM 进行深度处理、总结、结构化并存储为一种优化后的、易于查询的中间表示。之后的查询不再需要回溯原始冗长文档而是直接在这个精炼的知识库上进行。这带来了几个关键优势查询速度极大提升因为需要处理的数据量大大减少答案一致性更好因为知识库本身是经过逻辑梳理和去重的知识得以持续积累和演化新的资料可以被持续“消化”进知识库使其不断成长。2.2 Claude Code 技能化将模式转化为产品Karpathy 的 Gist 提供了一个绝佳的概念验证和代码范式但它更像是一个需要开发者自行部署和集成的脚本。我的目标是将它“产品化”降低使用门槛让非技术背景的团队成员如产品经理、运营人员也能轻松利用这一强大能力。Claude Code 作为一个集成了强大 LLM 能力的编码环境是绝佳的载体。将其封装为 Claude Code 技能意味着用户无需关心背后的 Python 环境、依赖包安装或 API 密钥管理。他们只需要在 Claude Code 中安装这个技能就可以通过简单的自然语言命令如“请用/wiki-ingest处理我刚上传的会议记录PDF”来操作。这极大地扩展了该模式的适用场景使其从一个极客玩具变成了一个团队可用的生产力工具。技能化的过程本质上是将复杂的工程逻辑文档解析、向量化、提示词工程封装成简洁、安全的用户接口。3. 技能架构深度解析3.1 四核命令引擎功能与协作流程整个技能围绕四个核心命令构建它们形成了一个完整的数据流水线和工作闭环。/wiki-init知识库的奠基者这个命令负责初始化一个全新的知识库。它不仅仅是创建一个空文件夹那么简单。首先它会建立一套标准的目录结构例如sources/用于存放原始文档processed/用于存放处理后的中间文件index/用于存储向量索引和元数据。其次它会生成一个核心的配置文件config.yaml其中定义了知识库的元信息如名称、描述、默认的 LLM 模型参数、文本分割策略chunk size 和 overlap、以及后续处理流程的各类提示词模板。最后它通常会创建一个README.md文件简要说明本知识库的用途和维护方式。这一步确保了所有后续操作都基于一个一致、可控的基础。/wiki-ingest知识的消化系统这是最复杂、也是最核心的命令。它的任务是将各种格式的原始资料PDF、Markdown、Word、网页、甚至会议录音转写的文本“消化”成知识库能理解的结构化信息。其内部流程可以分解为多个子步骤文档解析与提取根据文件类型调用相应的库如PyPDF2用于 PDFBeautifulSoup用于 HTML提取纯文本和基础元数据如标题、作者、日期。智能分块将长文本按语义分割成大小适中的片段。这里不能简单按固定字数切割否则会割裂完整的句子或概念。我采用的策略是结合递归字符分割和语义分割确保块与块之间有少量重叠以保持上下文连贯。一个常见的配置是块大小 1000 字符重叠 200 字符。深度分析与富化这是 LLM 大显身手的环节。对于每一个文本块我会设计一套提示词要求 LLM 执行多项任务生成一个简洁的摘要提取关键实体人物、项目、技术术语判断该块内容所属的主题或分类评估其信息质量是事实陈述、观点表达还是待办事项。这些分析结果作为“富化元数据”与原始文本块一同存储。向量化与索引将富化后的文本块有时连同其摘要通过嵌入模型如 OpenAI 的text-embedding-3-small转换为高维向量并存入一个向量数据库如 Chroma 或 FAISS。同时所有元数据和指向原始文本的链接会被存储在一个关系型索引如 SQLite中以便进行复杂的过滤查询如“查找所有由张三编写的关于‘微服务’的决策文档”。/wiki-query智慧的问答接口当知识库构建完成后用户通过此命令进行查询。它接收一个自然语言问题其内部运作流程如下查询理解与转换首先可能会用 LLM 对原始查询进行改写或扩展以提升检索召回率。例如“我们上次怎么处理服务器宕机的” 可能被扩展为 “服务器宕机事故处理流程、根因分析、解决方案”。混合检索将转换后的查询也转换为向量在向量数据库中进行相似性搜索找到最相关的文本块。仅靠向量检索可能不够因此我同时实现了关键词检索基于元数据中的实体和主题和基于时间的检索例如“最近三个月关于‘预算’的讨论”。最终的结果是多种检索策略结果的融合与重排序。上下文合成与答案生成将 top-K 个最相关的文本块及其富化元数据组合成一个精心结构的上下文发送给 LLM。这里的提示词至关重要它需要指令 LLM“你是一个专业的助理基于以下提供的知识库片段来回答问题。如果信息足够请给出清晰、有据的回答并引用来源片段编号。如果信息不足或存在矛盾请如实说明。” 这确保了答案 grounded 在知识库中避免了 LLM 的凭空捏造。/wiki-lint知识库的保健医生知识库不是静态的随着不断摄入新资料可能会出现矛盾、过时或重复的信息。这个命令定期对知识库进行“健康检查”。一致性检查针对同一实体或主题检索所有相关片段让 LLM 判断是否存在事实或观点上的直接矛盾并生成报告。冗余检测通过向量相似度检测内容高度重复的片段建议合并或删除。链接有效性检查验证知识库中引用的外部链接是否依然有效。元数据完整性验证检查所有片段是否都包含了必要的富化元数据。 这个过程可以部分自动化并将报告呈现给用户由用户决定如何修复从而保证知识库的质量随时间推移而提升而非退化。3.2 技术栈选型与权衡构建这样一个技能技术选型需要在功能、性能、易用性和成本之间取得平衡。后端框架与运行时我选择了 Python 作为主要语言因为它拥有极其丰富的 AI 和数据处理生态。考虑到 Claude Code 的环境技能被设计为纯 Python 脚本集合通过 Claude 的 Skill SDK 进行封装和调用避免了复杂的服务部署。向量数据库在轻量级和功能之间我选择了ChromaDB。它既可以作为内存数据库快速上手也可以持久化到磁盘。它的 Python API 非常友好并且内置了与流行嵌入模型的集成。对于超大规模知识库未来可以考虑迁移到Pinecone或Weaviate这类托管服务但初期 Chroma 完全够用。嵌入模型这是影响检索质量的核心。OpenAI 的text-embedding-3-small和-large模型在性能和成本上取得了很好的平衡。对于需要完全离线的场景可以集成开源模型如BAAI/bge-small-en-v1.5但需要在提示词中权衡效果与本地计算开销。文本处理与解析这是一个“脏活累活”集中的地方。PyPDF2或pdfplumber用于 PDFmarkdown库处理 Markdownpython-docx处理 WordBeautifulSoup4处理 HTML。关键是要有强大的错误处理和日志记录因为现实世界的文档格式千奇百怪。提示词工程这是技能的“灵魂”。我为每一个 LLM 调用环节富化、查询、lint都精心设计了系统提示词和少量示例few-shot。提示词的目标是明确、稳定并引导 LLM 输出结构化的结果如 JSON以便程序化处理。例如在富化环节提示词会明确要求输出{“summary”: “…”, “entities”: […], “category”: “…”, “confidence”: 0.9}这样的格式。注意成本控制。/wiki-ingest是最消耗 Token 的环节尤其是处理长文档时。务必在技能配置中提供清晰的预估并允许用户选择不同的模型如 Claude Haiku 用于摘要Claude Sonnet 用于复杂分析以平衡成本与质量。对于内部文档有时用更便宜的模型进行初步处理是经济的选择。4. 页面模板与知识结构设计4.1 标准化模板确保信息密度与一致性一个杂乱无章的知识库价值有限。为了确保摄入的信息能被有效查询我定义了几种标准化的页面模板。当用户使用/wiki-ingest处理一份文档时技能会首先尝试判断文档类型并套用相应的模板进行“结构化提取”。决策记录模板这是为“CTO决策维基”设计的核心模板。它强制要求 LLM 从会议记录或讨论中提取出以下结构化字段决策标题简洁明了。状态提议中/已通过/已废弃。决策日期决策者背景为什么要做这个决定考虑过的方案至少列出2-3个被讨论过的选项。最终决定选择的方案及其详细内容。理由为什么做出这个选择权衡了哪些利弊预期结果与衡量标准相关链接关联的需求文档、技术方案、会议纪要等。通过这个模板散落在邮件和聊天记录中的决策过程被凝固成一张张清晰的“决策卡片”便于日后审计、追溯和理解上下文。研究笔记模板适用于“内容研究维基”或任何信息收集场景。主题/问题信息来源文章标题、作者、链接、发布日期。核心观点/事实摘要关键数据与引述与其它来源的关联支持、补充还是反驳了已知信息可信度评估来源权威性如何是否存在明显偏见待跟进问题标签/分类这个模板将零散的研究材料转化为可连接、可对比的知识节点。事后复盘模板用于记录事故或项目复盘。事件标题时间线影响范围根本原因应对措施经验教训行动计划防止复现的具体改进项。负责人与截止日期4.2 知识图谱的隐式构建虽然本技能没有显式地构建一个图数据库但通过富化阶段提取的实体和主题以及模板中定义的关联字段我们已经在隐式地构建一个知识网络。例如一份决策记录中提到了“引入 Kafka 消息队列”那么“Kafka”就会被提取为一个技术实体。另一份研究笔记中也提到了“Kafka”系统在检索时不仅能通过向量相似度找到它们还能通过“Kafka”这个实体标签进行关联。当用户查询“Kafka”时系统可以综合呈现1关于使用 Kafka 的架构决策及其理由2关于 Kafka 性能调优的研究笔记。这就形成了简单的知识关联。更进一步可以在/wiki-lint中增加一个功能定期分析所有实体共现的情况自动建议用户“是否有关于‘Kafka’和‘微服务’的决策需要关联”从而引导用户手动完善知识网络。这种“隐式图谱显式关联”的策略在复杂度和实用性之间取得了很好的平衡。5. 实操从零构建你的第一个决策维基5.1 环境准备与技能安装假设你已经在使用 Claude Code。首先你需要找到并安装 “LLM Wiki” 技能。通常在 Claude Code 的技能市场或通过特定链接可以添加。安装过程通常是点击一下后台会自动配置好 Python 环境和依赖。安装成功后你需要在技能配置中设置关键的 API 密钥。主要是 OpenAI 的 API 密钥用于嵌入模型如果你选择 OpenAI 的话和 Anthropic 的 API 密钥用于 Claude 模型进行分析和生成。这些密钥被安全地存储在 Claude Code 的技能配置中不会泄露。你还可以在这里进行初始设置比如选择默认的 Claude 模型Haiku, Sonnet, Opus设置文本分块的大小和重叠度。5.2 初始化知识库与首次资料摄入打开一个新的 Claude Code 对话窗口。首先我们初始化一个专门用于记录技术架构决策的知识库。用户请使用 /wiki-init 命令帮我创建一个名为“Tech-Architecture-Decisions”的知识库描述是“记录所有核心系统架构决策与评审记录”。技能会在后台创建目录和配置文件。接下来我们摄入第一份资料——可能是一次重要的架构评审会议纪要假设你已将会议纪要整理成了 Markdown 文件meeting_20231026.md。用户我上传了文件 meeting_20231026.md请使用 /wiki-ingest 命令将其摄入到我们的“Tech-Architecture-Decisions”知识库中并应用“决策记录”模板。此时技能开始工作。你会在对话中看到类似这样的处理日志[信息] 开始处理文件meeting_20231026.md [信息] 文件解析成功共提取 1254 字符。 [信息] 正在使用‘决策记录’模板进行结构化提取... [信息] LLM 分析完成。提取到决策『关于用户服务数据库从 MySQL 迁移至 PostgreSQL 的决策』。 [信息] 文本分块完成生成 3 个语义块。 [信息] 正在为每个块生成摘要与实体... [信息] 向量化与索引构建中... [成功] 文件处理完成已成功添加到知识库。文档IDDEC-20231026-001。这个过程可能持续几十秒取决于文档长度。现在你的知识库就有了第一份结构化记录。5.3 进行查询与知识库维护几天后新的讨论涉及到用户服务的缓存策略有人质疑当初数据库迁移的决策依据。这时你可以直接查询。用户请使用 /wiki-query在“Tech-Architecture-Decisions”知识库中查询当初我们为什么决定将用户服务数据库从 MySQL 迁移到 PostgreSQL请列出主要理由。技能会检索相关片段并生成一个综合性的答案根据知识库记录DEC-20231026-001于2023年10月26日做出的迁移决策主要理由如下 1. **JSON数据支持**新功能要求用户配置项以灵活的JSON格式存储PostgreSQL的JSONB类型提供了更好的性能与查询能力而MySQL的JSON支持在当时评估中相对较弱。 2. **并发性能**预计用户服务写入并发量在促销期间会激增基准测试显示PostgreSQL在特定高并发写入场景下锁竞争处理优于当时的MySQL 5.7版本。 3. **地理空间数据**未来路线图包含基于位置的服务PostgreSQL内置的PostGIS扩展是行业标准无需引入额外中间件。 4. **团队经验**核心运维团队对PostgreSQL有更深入的经验预计能降低长期运维风险。 **引用来源**片段 #1 (背景与方案分析) 片段 #2 (最终决定与理由)。这个答案直接、有据省去了翻找会议纪要的麻烦。随着时间推移知识库内容增多你可以定期运行健康检查。用户请对“Tech-Architecture-Decisions”知识库运行 /wiki-lint 命令检查是否存在过时或矛盾的决策记录。系统可能会报告“发现一条关于‘使用Redis版本’的决策记录DEC-20230501-001与最新的运维规范存在潜在冲突建议复查。” 这帮助你主动维护知识库的时效性和准确性。6. 局限性与实战避坑指南没有任何系统是完美的LLM Wiki 技能在带来巨大便利的同时也有其明确的边界。理解这些局限才能更好地运用它。6.1 当前架构的固有局限1. 处理超长文档与复杂格式的挑战尽管技能集成了多种解析器但对于扫描版PDF、复杂的图文混排文档或代码仓库信息提取的准确率会下降。LLM在理解表格、图表内容方面能力有限。对策对于关键文档建议先进行人工预处理提取出核心文本内容再摄入。对于代码可以配合专门的代码分析工具先提取函数签名、注释和架构图再将分析结果作为文本来处理。2. 知识更新与冲突解决的半自动化/wiki-lint能发现矛盾但解决矛盾通常需要人工介入。系统无法自动判断哪条信息是“正确”的也无法在决策逻辑变更后自动更新所有衍生结论。对策建立知识库的“版本”或“状态”概念。对于重大决策当有更新时不是修改原记录而是新增一条“修订记录”并明确说明废止旧决策的原因。这保持了历史的可追溯性。3. 完全依赖LLM理解能力的风险知识库的质量极大程度上依赖于LLM在“富化”阶段的理解和摘要能力。如果LLM误解了原文那么错误会被固化并传播。对策在技能配置中提供“审核模式”。在此模式下/wiki-ingest处理后会将其提取的结构化摘要如决策记录的各个字段呈现给用户确认用户确认无误后再执行向量化和索引。这牺牲了一些自动化但换来了更高的准确性。4. 运营成本虽然查询成本低但构建知识库的初始摄入成本尤其是使用高性能模型如Claude Opus进行深度分析时不容忽视。一个包含数百份文档的知识库其构建成本可能达到数百美元。对策采用分层处理策略。对核心、高频查询的文档使用高质量模型对参考性、低频查询的文档使用成本更低的模型如Haiku进行基础摘要。清晰地向团队说明成本结构将资源用在刀刃上。6.2 实操中的常见问题与排查问题1/wiki-query返回的答案似乎没有用到知识库里的最新信息。排查步骤首先使用/wiki-query的“调试模式”如果技能提供查看它实际检索到了哪些片段。命令可能类似/wiki-query “问题” –debug。检查新文档是否成功摄入。运行一个简单的查询如“列出最近一周摄入的所有文档标题”。检查新文档的向量索引是否正常。可以尝试用新文档中一个非常独特的短语进行查询。根本原因与解决摄入失败新文档格式解析出错未被真正索引。查看/wiki-ingest时的处理日志。索引未更新某些向量数据库需要显式调用persist()或存在缓存。尝试重启 Claude Code 会话或技能。检索策略问题查询与文档的向量表示相似度不高。尝试在查询中使用更具体、包含文档内关键词的说法。问题2从知识库中得到的答案感觉是“拼凑”的不连贯。排查步骤检查检索到的片段数量top-K值是否合适。太多会导致上下文混乱太少可能信息不全。解决调整技能配置中的retrieval_top_k参数例如从5调整到3或7。更重要的是优化“富化”阶段的提示词要求LLM生成更具连贯性的摘要并在生成答案的提示词中强调“综合以下信息形成一个流畅、完整的段落”。问题3处理大量文档时/wiki-ingest速度很慢且消耗大量Token。优化策略批量处理将多个相关小文档合并成一个文件再摄入减少LLM调用的开销。模型降级在配置中为“富化”阶段指定更快速、廉价的模型如Claude Haiku。分阶段处理先仅做基础分块和向量化不进行深度LLM富化。待查询时如果命中该片段再进行按需的深度分析。这是一种“懒加载”策略。硬件确保运行 Claude Code 的环境有足够的内存和稳定的网络。问题4如何与团队共享这个知识库现状局限当前技能版本的知识库存储在本地或Claude Code的临时工作区不易直接共享。进阶方案这是将技能推向团队协作的关键。可以考虑的架构演进是将技能的后端向量数据库、文件存储部署到一个团队可访问的中央服务器或云服务上如使用 Docker Compose 部署 Chroma 和 MinIO。Claude Code 技能作为前端交互界面通过 API 与后端通信。这样所有团队成员安装同一个技能但都连接到同一个中央知识库。这需要更多的开发工作但却是实现协作的必经之路。构建“第二大脑”是一个持续迭代的过程。这个技能提供了一个强大的起点但它真正的价值在于与你或你团队的工作流深度结合。从一个小而具体的用例开始比如先做好“季度规划会议决策库”跑通流程感受其价值再逐步扩大范围。记住工具的目的是赋能而不是增加负担。让 AI 负责记忆和检索让人专注于思考和决策。