1. 开场为什么要搭建 LLM Wiki很多人都有知识管理工具比如 Obsidian、Notion、语雀、飞书文档、OneNote。但大多数知识库最后都会遇到同一个问题收集很多复用很少资料很多真正能指导行动的知识很少。传统知识库通常依赖人工完成这些事情给资料分类做摘要建立链接整理概念维护索引定期复盘从旧资料中找出可复用结论。问题是这些事情很重要但非常耗时。于是很多知识库慢慢变成“资料坟场”东西都在但用不起来。LLM Wiki 的思路是人负责判断价值和提供方向AI 负责整理、摘要、归类、链接、维护和复盘。它不是简单地把 ChatGPT 接进笔记软件而是建立一套适合 AI 长期协作维护的本地知识库结构。2. 什么是 LLM WikiLLM Wiki 可以理解为一个由大语言模型参与维护的 Markdown 知识库。它通常具备几个特点本地优先所有资料以 Markdown 文件形式保存在本地方便长期保存、迁移和版本管理。来源可追溯知识不是凭空生成的每个结论都尽量能追溯到原始资料、网页、项目代码或人工记录。AI 可维护目录结构、命名规则、日志协议、索引页面都为 AI 读取和维护做了约定。面向复用不只是保存资料而是把资料沉淀成来源摘要、概念页、项目页、方法页和报告。持续反馈知识库不仅等你搜索还能通过每日简报、每周复盘主动给你反馈。3. 整体架构设计一个完整的 LLM Wiki 可以按下面的结构搭建LLMWiki/ inbox/ 临时收集箱 raw/ 原始资料区 wiki/ 正式知识库 index.md 总索引 log.md 操作日志 sources/ 来源摘要 concepts/ 概念页 projects/ 项目页 people/ 人物/组织页 methods/ 方法流程页 outputs/ reports/ 报告、简报、复盘 lint/ 健康检查报告 prompts/ 可复用提示词 docs/ 设计文档和实施计划 AGENTS.md 多 AI 协作主协议 README.md 使用说明这套结构的核心思想是分层临时输入 → 原始证据 → AI 摘要 → 稳定知识 → 报告输出也就是inbox/ → raw/ → wiki/sources/ → wiki/concepts 或 wiki/projects/ → outputs/4. 各目录的作用4.1inbox/临时收集箱inbox/是低摩擦入口。所有还没有整理的东西都可以先放进来网页剪藏临时想法文章摘抄聊天记录项目线索一段还没想清楚的话一个希望 AI 后续处理的问题。它的原则是先收集不分类先放进来再让 AI 消化。不要一开始就追求分类完美。过早分类会提高记录成本最后导致你懒得记。4.2raw/原始资料区raw/是证据区。它保存原始来源或来源记录例如网页链接和自写摘要PDF 或文档的引用记录外部项目路径访谈记录原始笔记重要材料的归档版本。这里有一个非常重要的原则既有raw/文件尽量不改写只新增。原因是raw/是知识库的证据基础。如果 AI 随意改写原始资料就会破坏可追溯性。推荐做法raw/ 2026-07-08-csdn-llm-wiki-reference.md 2026-07-08-xj-rq2-ywgl-project-reference.mdraw/只保留原始资料和来源记录文件名保持“日期 来源 主题”的稳定格式便于追溯。日常导航统一通过wiki/index.md的“来源”章节完成。4.3wiki/正式知识库wiki/是知识库的核心。它不是原始资料堆放区而是经过整理后的正式知识区。wiki/index.md总索引。所有 AI 查询和维护知识库时都应该先读这里。它相当于知识库的首页告诉 AI有哪些核心入口有哪些来源有哪些概念有哪些项目有哪些方法有哪些报告。wiki/log.md操作日志。每次有意义的知识库变更都要追加记录。日志的作用是让人知道 AI 做了什么让其他 AI 知道历史变更方便回滚和审计避免多 AI 协作时互相覆盖。wiki/sources/来源摘要区。它负责把raw/中的原始资料整理成可读摘要。例如一篇文章进入raw/后AI 可以在wiki/sources/中生成一句话摘要关键观点对本知识库的启发不确定性相关概念链接。wiki/concepts/稳定概念区。这里保存长期可复用的概念解释。例如LLM-Wiki.mdObsidian.md多AI协作.md知识库主动反馈闭环.md概念页不应该只是复制来源摘要而应该沉淀成更稳定、更抽象、可反复引用的知识。wiki/projects/项目知识区。这里保存某个具体项目的结构、背景、接口、数据模型、开发指南等。例如在 Felix AI Wiki 中已经把一个 Java 项目做成了本地 RAG 文档包wiki/projects/xj-rq2-ywgl/ 00-项目入口.md 01-AI开发指南.md 02-总体架构.md 03-模块地图.md 04-接口清单.md 05-数据模型清单.md 06-编码约定.md 07-证据索引.md这样其他 AI 想参与这个项目开发时不需要重新从零理解项目只要先读项目 RAG 入口。wiki/methods/方法流程区。这里保存可重复执行的工作流。例如每日收件箱整理.md每日简报.md每周复盘.md网页剪藏约定.md这些方法页让 AI 知道“下次遇到类似任务应该怎么做”。4.4outputs/输出区outputs/保存 AI 生成的结果。常见子目录outputs/reports/ 报告、简报、复盘、导出文档 outputs/lint/ 知识库健康检查报告例如outputs/reports/2026-07-08-LLMWiki搭建完整讲稿.md outputs/lint/lint-2026-07-08.md4.5prompts/提示词模板prompts/保存可复用提示词。推荐至少准备 4 个prompts/摄入.md prompts/查询.md prompts/健康检查.md prompts/摘要.md它们的作用是让不同 AI 都能按同一套流程工作。4.6docs/设计与计划docs/保存知识库自身的设计和实施计划。推荐结构docs/ superpowers/ specs/ plans/其中specs/放设计文档plans/放实施计划保留目录结构方便 AI 工具继续使用默认路径。5. 核心协议AGENTS.mdLLM Wiki 最关键的文件之一是AGENTS.md。它是所有 AI 的共同操作协议。建议包含这些内容知识库定位目录说明操作原则页面类型ingest 工作流查询工作流lint 工作流命名约定多 AI 分工用户个人上下文。示例原则1. 修改 wiki 前先读 AGENTS.md、wiki/index.md 和 wiki/log.md。 2. raw/ 下既有文件默认不改写。 3. 不删除 wiki 页面除非用户明确批准。 4. 内部引用使用 Obsidian wikilink。 5. 每个正式 wiki 页面必须有 YAML frontmatter。 6. 断言应可追溯到 raw 或其他来源。 7. 每次有意义的 wiki 变更都要更新 index 和 log。这份协议的目的不是限制 AI而是让多个 AI 能长期、安全、可追踪地协作。6. 页面 frontmatter 规范正式wiki/页面建议统一使用 YAML frontmatter---title:页面标题type:conceptsources:-raw/example.mdrelated:-wiki/concepts/example.mdcreated:2026-07-08updated:2026-07-08confidence:medium---推荐字段字段作用title页面标题type页面类型sources来源related相关页面created创建日期updated更新日期confidence置信度页面类型可以包括sourceconceptprojectpersonmethodindexlogreport7. 命名策略LLM Wiki 的命名要同时照顾人和 AI。7.1 人常看的文件中文 编号项目 RAG 文档推荐00-项目入口.md 01-AI开发指南.md 02-总体架构.md 03-模块地图.md 04-接口清单.md 05-数据模型清单.md 06-编码约定.md 07-证据索引.md优点Obsidian 文件列表里好找阅读顺序清晰中文直观AI 也容易按顺序读取。7.2 原始资料日期 来源 主题raw/中建议保留日期和来源2026-07-08-csdn-llm-wiki-reference.md 2026-07-08-xj-rq2-ywgl-project-reference.md原因是raw/主要用于追溯不是日常阅读。7.3 复杂目录使用00-项目入口.md不是所有目录都需要单独放00索引页。当前推荐做法是wiki/index.md wiki/projects/xj-rq2-ywgl/00-项目入口.md也就是说raw/和docs/不单独放中文索引统一从wiki/index.md导航只有项目 RAG 这种文档较多、阅读顺序明确的目录才保留00-项目入口.md。8. 搭建步骤下面是一套从零搭建 LLM Wiki 的完整步骤。第一步创建目录结构在本地创建一个 vault例如D:\LLMWiki然后创建目录inbox/ raw/ wiki/ wiki/sources/ wiki/concepts/ wiki/projects/ wiki/people/ wiki/methods/ outputs/ outputs/reports/ outputs/lint/ prompts/ docs/ docs/superpowers/specs/ docs/superpowers/plans/PowerShell 示例$rootD:\LLMWiki$dirs (inbox,raw,wiki,wiki/sources,wiki/concepts,wiki/projects,wiki/people,wiki/methods,outputs,outputs/reports,outputs/lint,prompts,docs,docs/superpowers/specs,docs/superpowers/plans)foreach($din$dirs){New-Item-ItemType Directory-Force-Path(Join-Path$root$d)|Out-Null}第二步创建主协议AGENTS.md在根目录创建AGENTS.md它至少要写清楚目录作用raw/不随意改写正式页面必须有 frontmatter修改wiki/后要更新wiki/index.md和wiki/log.md查询时先读wiki/index.md多 AI 分工用户个人偏好。这个文件是 AI 协作的“宪法”。第三步创建总索引wiki/index.mdwiki/index.md是知识库入口。建议结构# Felix AI Wiki 总索引 ## 核心入口 ## 主动反馈流程 ## 提示词模板 ## 设计与计划 ## 来源 ## 概念 ## 项目 ## 方法 ## 报告每次新增重要页面都要把它挂到索引里。第四步创建操作日志wiki/log.mdwiki/log.md用于记录 AI 做过什么。推荐格式## 2026-07-08 ### 初始化 LLM Wiki 骨架 - Agent: Codex / Claudian - Operation: initialize - Created: - AGENTS.md - wiki/index.md - wiki/log.md - Notes: - 初始创建多 AI 协作型 LLM Wiki 骨架。日志非常重要。它能让你知道 AI 改了什么也能让下一个 AI 接着上下文工作。第五步创建提示词模板至少创建prompts/摄入.md prompts/查询.md prompts/健康检查.md prompts/摘要.md摄入提示词用于把raw/资料整理进wiki/。流程阅读AGENTS.md、wiki/index.md、wiki/log.md阅读指定raw/文件创建wiki/sources/来源摘要抽取概念到wiki/concepts/需要时更新项目页或方法页更新索引追加日志。查询提示词用于让 AI 根据 wiki 回答问题。流程从wiki/index.md开始找相关页面只读必要内容基于 wiki 证据回答证据不足时明确说明。健康检查提示词用于检查frontmatter 缺失wikilink 断链页面未进索引孤立页面重复概念无来源断言过期或冲突内容。摘要提示词用于快速把一篇材料总结成一句话摘要关键观点重要术语潜在概念页相关页面不确定问题。第六步建立主动反馈流程LLM Wiki 不应该只是等你搜索。更好的方式是建立主动反馈闭环低摩擦收集 → AI 消化 → 每日反馈 → 每周复盘建议创建wiki/methods/每日收件箱整理.md wiki/methods/每日简报.md wiki/methods/每周复盘.md wiki/methods/网页剪藏约定.md每日收件箱整理每天让 AI 扫描inbox/判断哪些是资料哪些是想法哪些是项目事项哪些值得进入raw/哪些需要生成来源摘要哪些应该变成概念页或项目页。每日简报每天输出今日新增值得保留的观点隐藏关联可能的认知冲突今天最值得思考的问题建议下一步行动。每周复盘每周输出本周核心输入正在形成的新观点新旧认知冲突知识体系缺口反复出现的主题下周最高杠杆行动。第七步建立来源摘要和概念页当一篇资料进入raw/后不要直接把它当知识用。推荐流程raw/来源记录 ↓ wiki/sources/来源摘要 ↓ wiki/concepts/稳定概念例如一篇介绍 LLM Wiki 的文章可以生成raw/2026-07-08-csdn-llm-wiki-reference.md wiki/sources/2026-07-08-CSDN-Obsidian-Codex第二大脑.md wiki/concepts/LLM-Wiki.md wiki/concepts/知识库主动反馈闭环.md这样知识就从“文章”变成了“可复用概念”。第八步把项目做成本地 RAG如果你有一个开发项目可以把它做成项目 RAG 文档包。例如wiki/projects/xj-rq2-ywgl/ 00-项目入口.md 01-AI开发指南.md 02-总体架构.md 03-模块地图.md 04-接口清单.md 05-数据模型清单.md 06-编码约定.md 07-证据索引.md项目 RAG 的目标是让其他 AI 在开发这个项目时不需要从零理解项目结构。项目 RAG 应该包括项目路径技术栈启动类模块结构Controller 清单Entity / 表清单Mapper / XML 清单开发约定敏感信息处理规则证据索引。注意项目 RAG 不应该复制全量源码也不应该保存明文密码、token、access-key、secret-key 或内网地址。第九步建立统一导航为了让人和 AI 都好找资料推荐把全局导航集中放在wiki/index.md而不是在每个目录都放一个00索引页。当前推荐结构是wiki/index.md wiki/projects/xj-rq2-ywgl/00-项目入口.md这样做的好处是raw/保持原始资料区的稳定性docs/保持工具默认目录结构日常入口统一不会出现太多索引文件项目 RAG 这种复杂目录仍然有自己的局部入口。第十步做健康检查知识库运行一段时间后一定会出现问题链接断了页面没进索引概念重复资料没有来源某些页面过期不同页面说法矛盾。因此要定期 lint。检查项包括Markdown 是否有 frontmatterwikilink 是否断链页面是否进入wiki/index.md是否有孤立页面是否有重复概念是否有缺少来源的断言是否存在过期或矛盾内容。报告保存到outputs/lint/lint-YYYY-MM-DD.md9. 多 AI 协作方式LLM Wiki 的一个优势是可以让多个 AI 分工协作。推荐分工AI / 工具适合任务Codex / Claudian文件操作、批量整理、项目 RAG、代码分析、索引和日志Reasonix概念审查、矛盾检测、推理质量检查WorkBuddy项目、任务、流程沉淀Gemini / Google Antigravity长上下文资料阅读、网页和文档分析Claude 兼容工具写作、总结、概念整理关键不是每个 AI 都做所有事情而是让所有 AI 遵守同一份AGENTS.md协议。10. 安全与边界搭建 LLM Wiki 时要注意几个边界。10.1 不要让 AI 随便改 rawraw/是证据层。如果需要更新优先新增新版本。10.2 不要让 AI 删除页面删除是高风险操作。默认只新增、更新、标记废弃不直接删除。10.3 不要保存敏感配置尤其是项目 RAG 中不能保存数据库密码tokenaccess-keysecret-key内网地址Docker 仓库账号密码Nacos 凭据。只写组件类型和用途即可。10.4 不确定就标注不确定AI 很容易把“推测”写成“事实”。所以文档中要区分代码事实合理推断待确认事项。11. 一个完整工作流示例假设今天看到一篇好文章。第一步放入 inboxinbox/2026-07-08 - 某篇文章.md第二步判断是否值得保留AI 阅读后判断是否有长期价值是否和已有概念相关是否值得进入raw/。第三步进入 rawraw/2026-07-08-xxx-reference.md保存标题URL访问日期自写摘要不复制全文。第四步生成来源摘要wiki/sources/2026-07-08-xxx.md包含一句话摘要关键观点对本知识库的启发不确定性相关页面。第五步抽取概念页如果出现稳定概念创建或更新wiki/concepts/某个概念.md第六步更新索引和日志更新wiki/index.md wiki/log.md第七步进入每日简报输出到outputs/reports/brief-YYYY-MM-DD.md这就是完整闭环。12. 常见误区误区一目录越复杂越专业不是。目录只要能支持工作流即可。推荐从最小结构开始inbox/ raw/ wiki/ outputs/ prompts/后续再扩展。误区二所有东西都要马上分类不需要。先进入inbox/再定期让 AI 消化。误区三让 AI 直接生成结论LLM Wiki 强调来源追溯。AI 可以总结但重要结论最好能链接到来源。误区四只收集不复盘没有复盘知识库就只是仓库。每日简报和每周复盘才是“主动思考”的关键。误区五项目 RAG 复制源码项目 RAG 不是源码备份。它应该是结构化理解和开发导航。13. 最终效果一个搭建好的 LLM Wiki应该具备这些能力新资料能低成本进入原始来源可追溯AI 能把资料转成摘要和概念项目能被整理成本地 RAG其他 AI 能读文档后快速进入开发每日能生成简报每周能做复盘索引和日志持续维护知识库能被 lint 检查健康状态人和 AI 能长期协作。一句话总结LLM Wiki 不是一个“AI 帮你写笔记”的工具而是一套让 AI 长期参与知识维护、项目理解和认知反馈的本地知识系统。14. 推荐落地顺序如果从零开始不要一次做太多。推荐顺序建目录写AGENTS.md写wiki/index.md写wiki/log.md建prompts/做第一个来源摄入做第一个概念页做第一个项目 RAG加每日简报加每周复盘定期 lint。15. 结尾知识库最重要的不是“存了多少”而是能不能找到能不能复用能不能追溯能不能产生行动能不能随着时间变得更聪明。LLM Wiki 的价值就在于它把 AI 从一次性问答工具变成了长期知识维护者。当这套系统跑起来后你不是在维护一堆 Markdown 文件而是在建设一个能持续理解你、辅助你、提醒你、帮你沉淀经验的个人知识系统。
的深度解析与安全实践)
