摘要本文基于 Andrej Karpathy 提出的“自进化知识系统”思路系统解析三层 LLM Wiki 架构Raw Source / Wiki / Schema Rules并给出一个可运行的 Python Demo如何用大模型自动整理 Markdown 知识库并增强 AI 编码代理能力。文末附多模型接入实践与平台选型建议。一、背景介绍从“记笔记”到“为 Agent 造大脑”传统笔记/知识管理工具Notion、Obsidian 等本质上是“给人看的”人来写内容人来维护结构、标签和链接AI 只是做检索、摘要或问答的插件Andrej Karpathy 的设想把这件事完全反过来了不是“人写知识库、AI 来查”而是“人只丢原始资料知识库由大模型持续重构主要服务 AI Agent”。在视频中提到的案例 Farza Pedia输入2500 条原始数据备忘录、消息、日记等输出一套为 Agent 设计的“个人维基”包含数百篇结构化页面围绕人物、兴趣、想法、灵感等自动整理用途不仅能回答问题还能辅助设计 landing page、系统架构等实际任务更关键的是这个系统会持续自我更新、自我检查和自我修复让连接其中的 AI 编码代理不断“变聪明”。二、核心原理三层 LLM Wiki 架构Karpathy 提出的 LLM Wiki 大致分为三层Raw Sources、Wiki、Schema Rules。2.1 Raw Sources不可变「原始事实层」内容你的原始资料日志 / 笔记 / 代码片段项目需求文档 / API Spec历史聊天记录、邮件等特性尽量视为不可变immutable历史真实记录不做“重写”只 append不反复编辑作用给模型提供真材实料降低幻觉形成统一、持久的“事实源”2.2 WikiLLM 生成 持续重构的「知识视图层」形式大量 Markdown 文件如index.md、project_X.md等生成方式大模型从 Raw Sources 中抽取信息生成结构化条目概念、人物、项目、组件、API 等自动创建双向链接、索引和分类特点对 Agent 友好链接清晰易于遍历条目相对稳定语义清晰会持续被 LLM 自己“回读、改写、校对”典型能力检测矛盾两个页面对同一概念描述不一致补齐缺失链接发现可以互相链接的页面重写摘要把冗长笔记压缩成更高质量概述2.3 Schema Rules给 LLM 的「知识工程规范」这一层本质上是一个“约束文档 Prompt 模板”告诉模型如何命名页面命名规范如何组织章节如背景 / API / 使用示例 / 参考允许什么类型的链接人物—项目项目—组件组件—API 等如何更新新增条目、合并条目、标记废弃信息如何执行“知识库体检”lint / health check有了 Schema Rules大模型从“随缘写 wiki”变成“在统一知识工程规范下维护项目文档”。三、实战演示用 Python 搭建一个最小自进化知识库下面实现一个最小可用 Demo使用https://xuedingmao.com的 OpenAI 兼容接口模型claude-sonnet-4-6功能链路将原始笔记写到raw/目录调用大模型从raw/生成/更新wiki/index.md实现一个“知识库自检”函数检查矛盾、缺失链接等展示如何给编码代理提供更强的上下文说明代码为真实可运行 Demo需提前在环境变量中配置XUEDINGMAO_API_KEY。3.1 准备安装依赖与目录结构pipinstallopenai python-dotenvmkdir-pdata/raw data/wiki目录约定data/ raw/ notes_1.md notes_2.md wiki/ index.md # 由模型生成/更新 schema.md # 我们写给模型看的“Schema Rules”3.2 Python核心脚本importosfrompathlibimportPathfromdotenvimportload_dotenvfromopenaiimportOpenAI# 加载环境变量中的 API Keyload_dotenv()API_KEYos.getenv(XUEDINGMAO_API_KEY)ifnotAPI_KEY:raiseRuntimeError(请在环境变量中设置 XUEDINGMAO_API_KEY)# 初始化 OpenAI 兼容客户端base_url 指向薛定猫 AIclientOpenAI(api_keyAPI_KEY,base_urlhttps://xuedingmao.com/v1)BASE_DIRPath(__file__).resolve().parent RAW_DIRBASE_DIR/data/rawWIKI_DIRBASE_DIR/data/wikiSCHEMA_FILEWIKI_DIR/schema.mdINDEX_FILEWIKI_DIR/index.mdMODEL_NAMEclaude-sonnet-4-6defcall_llm(system_prompt:str,user_prompt:str)-str: 通用大模型调用封装。 使用 chat.completions.createOpenAI 兼容协议。 respclient.chat.completions.create(modelMODEL_NAME,messages[{role:system,content:system_prompt},{role:user,content:user_prompt}],temperature0.2,)returnresp.choices[0].message.contentdefread_all_raw_sources()-str: 读取 data/raw 下所有 .md 文件拼接为一个大文本 用于作为“不可变原始事实层”的输入。 parts[]forfinsorted(RAW_DIR.glob(*.md)):parts.append(f# FILE:{f.name}\n\n)parts.append(f.read_text(encodingutf-8))parts.append(\n\n)return\n.join(parts)defensure_schema_file(): 如果 schema.md 不存在则创建一个简单的 Schema 规则文件 用于约束模型如何组织 wiki。 ifSCHEMA_FILE.exists():returnschema_content# LLM Wiki Schema Rules ## 目标 - 为 AI 编码代理提供结构化、可链接、可扩展的知识库视图。 - 所有内容以 Markdown 组织使用标题、列表和代码块。 ## 结构规范 - 顶层文件为 index.md包含全局目录和主要实体列表。 - 对重要实体项目、组件、API、人物等创建单独小节 - 标题格式## [实体类型] 实体名 - 内容结构背景 / 关键信息 / 相关实体链接 / 示例。 ## 链接规则 - 使用 Markdown 链接引用其他部分例如 - [项目A](#project-项目a) - 链接文本尽量使用唯一名字 中文说明。 - 尽可能为相关概念之间建立交叉引用。 ## 更新策略 - 在保持一致性的前提下可以重写摘要、合并冗余内容。 - 新出现的重要实体应加入 index 总目录。 - 不直接修改“原始事实”仅在 wiki 层做抽象和总结。 ## 自检 (lint) 指南 - 检查是否存在明显矛盾描述并提出修正建议。 - 标记“缺失链接”的地方用 TODO 形式注明。 - 优化段落结构减少重复内容。 WIKI_DIR.mkdir(parentsTrue,exist_okTrue)SCHEMA_FILE.write_text(schema_content,encodingutf-8)defupdate_wiki_index(): 从 raw sources 生成/更新 wiki/index.md。 核心思路 - system 中注入 Schema Rules - user 中同时给出“当前 index.md如有 最新原始资料” - 让模型在保持结构的前提下增量更新 ensure_schema_file()schema_rulesSCHEMA_FILE.read_text(encodingutf-8)raw_textread_all_raw_sources()ifINDEX_FILE.exists():current_indexINDEX_FILE.read_text(encodingutf-8)else:current_indexsystem_promptf你是一个负责维护 LLM 驱动知识库的“知识工程师”。 你不会修改原始事实只会在 wiki 层做结构化抽象。 以下是知识库的 Schema 规则请严格遵守{schema_rules}user_promptf现在请基于“原始资料”更新 wiki 的 index.md。 要求 - 如果当前已有 index.md请在其基础上演化不要完全推翻重写。 - 提取出重要的实体项目、组件、API、人物、概念等建立清晰的小节结构。 - 为相关实体添加 Markdown 链接形成可遍历的知识图谱。 - 用简洁中文撰写摘要但可以保留英文标识符和专有名词。 - 输出完整的 index.md 内容不要省略。 --- 当前 index.md 内容可能为空 ---{current_index}--- 原始资料只读 ---{raw_text}new_indexcall_llm(system_prompt,user_prompt)INDEX_FILE.write_text(new_index,encodingutf-8)print(✅ wiki/index.md 已更新)deflint_wiki(): 对 wiki/index.md 做一次“自检” - 让模型阅读当前 wiki - 找出矛盾、缺失链接、结构问题 - 返回一份修订后的 index.md ensure_schema_file()ifnotINDEX_FILE.exists():raiseRuntimeError(index.md 不存在请先运行 update_wiki_index())schema_rulesSCHEMA_FILE.read_text(encodingutf-8)current_indexINDEX_FILE.read_text(encodingutf-8)system_promptf你是一个负责“知识库体检(lint)”的 LLM。 目标在不改变事实的前提下提升 wiki 的一致性、连贯性和可用性。 Schema 规则如下{schema_rules}user_promptf请对以下 wiki/index.md 进行全面审查和改进 - 修复明显矛盾或逻辑冲突如有不确定可用 TODO 标记。 - 为明显相关但未链接的实体补充链接。 - 标注发现的“缺失信息点”使用 TODO: 说明。 - 保持原有结构的同时可以合并冗余段落、优化标题。 输出改进后的完整 index.md 内容。 --- 当前 index.md ---{current_index}refined_indexcall_llm(system_prompt,user_prompt)INDEX_FILE.write_text(refined_index,encodingutf-8)print(✅ wiki/index.md lint 完成已自我修复)defanswer_question_with_wiki(question:str)-str: 示例编码代理在回答问题时如何利用 wiki/index.md 提升回答质量。 这里我们只做一个简单版 - 将 index.md 内容当作“知识上下文” - 提供给模型让其基于此回答问题 在实际项目中你可以在此处做分段检索、向量检索等。 ifnotINDEX_FILE.exists():raiseRuntimeError(index.md 不存在请先构建 wiki)index_contentINDEX_FILE.read_text(encodingutf-8)system_prompt你是一个 AI 编码助手善于阅读项目知识库wiki并基于此回答问题。 优先使用 wiki 中的内容不要凭空捏造不存在的 API 或模块。 如果 wiki 中信息不足请明确说明“不确定”并指出可能需要补充的原始资料类型。user_promptf以下是 wiki/index.md 的内容可视作整个知识库的导览 --- WIKI INDEX START ---{index_content}--- WIKI INDEX END --- 现在请基于 wiki回答用户问题{question}returncall_llm(system_prompt,user_prompt)if__name____main__: 简单 CLI 1. 先将若干 markdown 笔记放入 data/raw 2. 运行本脚本 - 自动构建/更新 wiki/index.md - 进行一次 lint 自检 - 演示基于 wiki 回答一个问题 print( Step 1: 更新 wiki/index.md )update_wiki_index()print( Step 2: 对 wiki 做一次 lint 自检 )lint_wiki()print( Step 3: 示例问答 )demo_q请根据当前知识库帮我总结这个项目涉及的主要模块并给出对新开发者的上手建议。answeranswer_question_with_wiki(demo_q)print( 模型回答 )print(answer)运行效果第一次运行时生成schema.md约束规则从data/raw中提取笔记生成一个结构化的index.md再次运行时update_wiki_index会在原有结构上增量演化lint_wiki会根据规则对 wiki 自我修复answer_question_with_wiki模拟一个“挂着知识库的 AI 编码代理”。在真实项目中你可以把answer_question_with_wiki换成完整的“代码 Agent”例如让 Agent 在回答问题前先“查表”读 wiki 的相关章节基于 wiki 中的组件、API、约束来生成代码而不是凭空发挥将 Agent 输出的设计文档、结果再写回 Raw Sources形成闭环四、注意事项与工程实践建议4.1 减少幻觉让事实和视图解耦Raw Sources 仅保存事实日志、Spec、代码Wiki 是 LLM 的“观点层”可以不断重写但必须可追溯到 Raw SourcesSchema 中明确“不要凭空增加新 API/模块除非在 Raw Sources 中有证据”4.2 Token 成本与上下文裁剪不要直接把所有 Raw Sources 丢进一次调用推荐做分片 召回向量检索 / 关键字检索Wiki 本身就是一种“稀疏摘要索引”大幅降低 Agent 调用大模型的 token 消耗4.3 自进化流程自动化建议把以下命令做成定时/CI 任务每天 / 每 PR 合并后从代码库、文档更新同步 Raw Sources调用update_wiki_index生成新的视图每周一次调用lint_wiki对整个知识库做“健康检查”这在中大型代码库尤其是多 Agent 协同场景会极大降低认知负担。五、技术资源与平台选型建议实现这类“自进化知识库 多 Agent 协同”一个现实问题是不同模型、不同厂商 API 的集成成本非常高GPT 系列适合复杂推理和代码生成Claude 系列在长上下文和说明文档整理方面表现优异Gemini 等模型在多模态和工具调用上有优势如果每个模型都单独接入会面临不同协议/SDK认证方式各异更新节奏不同维护成本高在这种场景下更推荐使用统一接入层的方式例如本文示例用到的薛定猫 AIhttps://xuedingmao.com聚合 500 主流大模型包括 GPT-5.4、Claude 4.6、Gemini 3 Pro 等新模型实时首发对实验性玩法比如让不同模型分别负责“Wiki 构建”、“Lint”、“编码 Agent”非常友好统一 OpenAI 兼容接口你可以像上面那样只写一套OpenAI客户端调用换模型只要改model名称即可适合多模型流水线用 Claude 4.6 做长文档整理和 wiki 构建用 GPT 系列做代码生成和调试用其他专长模型做向量检索、重排等从工程角度看这种统一接入层能显著降低“多模型自进化系统”的复杂度更利于将架构长期维护下去。小结通过一个最小实践你可以看到自进化知识库的关键不是 UI而是Raw Sources事实层Wiki视图层Schema Rules知识工程规范将这些与 AI 编码代理结合可以让 Agent 随着时间真正“变聪明”而不是每次都从零开始推理使用统一的多模型 API 平台可以极大降低实现这套体系的集成成本接下来你可以尝试把自己的项目需求文档、API 文档、历史 Issue 丢进raw/微调schema.md增加适合你团队的命名规范和文档模板在 CI 中加入自动update_wiki_index和lint_wiki步骤把现有的 AI 编码助手接入这个 wiki 系统观测回答质量的变化#AI #大模型 #Python #机器学习 #技术实战