企业官网建设流程全解析

1. 项目概述：构建一个由AI维护的复合型个人知识库

如果你和我一样，每天都会接触到大量的技术文档、研究论文、博客文章和零散的笔记，并且一直在寻找一种方法，让这些信息不再是孤立的文件，而是能真正连接起来、持续增值的知识网络，那么这个项目可能就是你要找的答案。Personal Knowledge Base Creator（个人知识库创建器）不是一个简单的笔记工具，而是一个工作流模板，它利用你现有的AI编程助手（如Cursor、Claude Code或VS Code/Copilot），将你扔进去的原始资料，自动转化、链接成一个结构化的、可浏览的纯Markdown维基。

这个项目的核心灵感来源于Andrej Karpathy提出的“LLM Wiki”模式。它解决了一个关键痛点：大多数知识管理工具只解决了“存储”问题，而这个方案解决了“连接”与“生长”问题。你不需要部署向量数据库、搭建嵌入服务器或申请额外的API密钥。一切都在你的IDE内部，通过三个简单的斜杠命令（/compile-wiki,/ask-wiki,/lint-wiki）完成，完全利用你已有的订阅计划。最终生成的wiki/文件夹就是一堆纯文本Markdown文件，你可以在任何编辑器（包括Obsidian）中打开、浏览，知识以[[维基链接]]的形式自动关联，形成一个不断生长的知识图谱。

2. 核心设计理念与架构解析

2.1 为什么选择“纯Markdown + 维基链接”模式？

在深入实操之前，理解其背后的设计哲学至关重要。当前知识管理领域，从Notion、Roam Research到各种基于向量的RAG（检索增强生成）方案层出不穷。这个项目选择了一条看似“复古”但极其务实的路径：纯Markdown文件和双括号维基链接。

首要优势是极致的可移植性与零锁定。你的知识资产最终是一堆.md文件，这意味着它们不受任何专有软件或云服务的束缚。十年后，即使这个项目不再维护，你的wiki/文件夹依然可以被任何文本编辑器读取，[[链接]]的语义也清晰可辨。这从根本上保障了知识资产的长期安全。

其次，它巧妙地避开了RAG的复杂性与成本。传统的RAG方案需要将文档切片、生成嵌入向量、存入数据库，并在查询时进行相似度检索。这个过程不仅需要额外的基础设施（数据库、嵌入模型API），还引入了“语义相似度不等于逻辑关联”的噪音。本项目采用的“图遍历检索”则更为直接：AI首先阅读一个精简的索引文件（index.md），根据问题决定需要查看哪些具体的维基页面，然后按[[链接]]关系进行深度遍历。这模拟了人类研究员查阅文献时的行为——先看目录，再根据引用链深入——而非简单地匹配关键词向量。根据项目作者的实践，对于中小型知识库，这种方法能减少约50%至90%的上下文令牌消耗。

最后，它实现了知识的“复合增长”。每一次你运行/ask-wiki提问，AI生成的报告会被保存，并且其核心见解可以通过后续的/compile-wiki被重新整合进维基。这意味着知识库不是一个静态的档案，而是一个通过与AI对话不断被提炼、丰富和连接的活系统。

2.2 核心工作流与数据流转

整个系统的运转围绕三个核心目录和三个AI技能展开，形成了一个清晰的输入-处理-输出循环。

raw/ # 输入区：你放置原始文件的地方 │ # 支持 .md, .pdf, .txt 格式 └─ /compile-wiki # 处理引擎：AI技能 │ ▼ wiki/ # 核心知识库：AI生成并维护的结构化维基 │ # 包含 index.md（索引）, log.md（日志） ├─ /ask-wiki # 查询引擎：基于维基回答问题，输出报告 └─ /lint-wiki # 维护引擎：月度健康检查，修复链接、合并重复项 output/ # 输出区：`/ask-wiki`生成的报告（被git忽略）

关键细节与设计考量：

1. raw/目录的“增量处理”逻辑：/compile-wiki技能会参考wiki/log.md中的记录，只处理那些尚未被处理或已被更新的源文件。这意味着你可以随时丢入新文件，而无需担心整个知识库被重新处理，效率极高。
2. wiki/index.md的核心作用：这是整个系统的“大脑”。它不是一个简单的文件列表，而是一个由AI维护的、按主题分类的目录，包含了每个页面的核心摘要和关键链接。所有查询（/ask-wiki）和维护（/lint-wiki）都从这里开始，避免了每次都需要将整个知识库加载到上下文窗口中。
3. AGENTS.md文件的个性化配置：这是你引导AI的“指挥棒”。文件中的“My Interests / Focus Areas”部分，你需要填入自己关心的领域关键词（如“机器学习”、“气候科学”、“产品设计”）。AI在编译维基时，会依据这些兴趣领域来识别概念、聚类主题并创建链接，确保生成的知识图谱与你的认知焦点对齐。

3. 环境准备与初始化配置详解

3.1 平台选择与前期准备

项目支持Cursor、Claude Code和VS Code（搭配GitHub Copilot）三大平台。选择哪一个主要取决于你的个人偏好和现有订阅。

• Cursor：目前兼容性最好，也是作者主要测试的环境。其Agent模式对这类需要长时间、多步骤推理的任务支持度很高。
• Claude Code：由Anthropic推出，同样具备强大的代码理解和生成能力，是Cursor的有力替代品。
• VS Code + GitHub Copilot：如果你已经是Copilot的重度用户，不想切换IDE，这是最无缝的选择。但需要注意，Copilot Chat的上下文长度和复杂指令执行能力可能略逊于前两者。

一个重要的共识是：无论选择哪个平台，你都需要一个有效的、支持高级AI功能的订阅（如Cursor Pro、Claude Code订阅或GitHub Copilot）。项目本身不产生额外API费用，它本质上是将你的IDE订阅能力“重定向”到了知识库管理这个特定任务上。

对于Windows用户的一个关键步骤：由于安装脚本会尝试创建符号链接（symlink），你需要确保系统已开启“开发者模式”。前往设置 > 系统 > 开发者选项，开启“开发者模式”。如果未开启，脚本会自动降级为文件复制，功能不受影响，但未来更新时需要重新运行脚本以覆盖旧文件。

3.2 执行初始化安装

安装过程的核心是运行setup.sh（macOS/Linux）或setup.ps1（Windows）脚本。这个脚本完成了三件关键事：

1. 克隆项目：将模板仓库克隆到本地你指定的目录（例如MyKnowledgeBase）。
2. 解除与上游仓库的关联：这是一个非常贴心的安全设计。脚本会自动执行git remote remove origin，切断你的本地副本与原始模板仓库的连接。这从根本上防止了你未来不小心将包含个人笔记（在raw/和output/里）的内容git push到公共仓库，确保了隐私。
3. 安装AI技能：将skills/目录下的三个技能文件，以符号链接或文件拷贝的方式，安装到你的AI助手平台指定的技能目录中（例如Cursor的~/.cursor/skills/），并生成一个关键的wiki-config.md配置文件。

安装范围的选择：全局 vs 本地这是配置中最关键的一个决策点，决定了你的知识库是“中心辐射”式还是“项目隔离”式。

• 全局安装（推荐给大多数个人用户）：

  # 在你的知识库项目根目录下执行 ./setup.sh cursor global

  这会在你的AI助手技能目录（如~/.cursor/skills/）旁生成一个wiki-config.md文件，其中包含了当前这个知识库克隆的绝对路径。此后，无论你在电脑上打开哪个项目、哪个文件夹，只要在Cursor里调用/ask-wiki或/compile-wiki，AI都会定位到这个全局的知识库进行操作。这非常适合打造一个统一的、涵盖你所有兴趣领域的个人总知识库。

• 本地安装（适合项目专属知识库）：

  # 首先进入你的某个特定项目目录 cd /path/to/your/other/code-project # 然后从知识库克隆的位置运行脚本，指定‘local’ /path/to/PersonalKnowledgeBaseCreator/setup.sh cursor local

  这会在当前项目目录下创建一套完整的本地结构：raw/,wiki/,output/,AGENTS.md以及一个本地的wiki-config.md。此时，AI技能会优先使用当前项目根目录下的这个配置文件。这非常适合为某个大型代码项目、研究课题或客户案例单独维护一个知识库，使其与主知识库分离。

路径解析的优先级规则：AI技能在运行时，会首先检查当前打开的工作区根目录是否存在wiki-config.md。如果存在，则使用它（本地模式）。如果不存在，则回退到使用全局技能目录旁的wiki-config.md（全局模式）。你可以通过重命名或删除本地的wiki-config.md来切换回全局模式。

3.3 个性化配置：编辑AGENTS.md

安装完成后，不要急于添加文件。首先用文本编辑器打开项目根目录下的AGENTS.md文件。找到“My Interests / Focus Areas”部分，你会看到一些占位符示例。

你需要将其替换为你自己真实关心的领域列表。例如：

## My Interests / Focus Areas - Machine Learning: Transformers, Diffusion Models, Reinforcement Learning - Software Engineering: System Design, Distributed Systems, Rust - Biotechnology: CRISPR, mRNA Vaccines, Synthetic Biology - Personal Productivity: Note-taking Systems, Habit Formation

这个列表是AI为你构建知识图谱的“分类法”和“引力中心”。AI在解析你的原始笔记时，会试图识别内容中的概念，并将其归类或链接到这些兴趣领域下。列表越具体、越有层次，生成的维基结构就越贴合你的思维模式。

4. 核心技能实操与经验分享

4.1/compile-wiki：知识编译引擎

这是知识库生长的核心驱动力。当你将新的Markdown、PDF或文本文件放入raw/目录后，在IDE中激活AI助手，输入/compile-wiki并发送。

内部运作流程：

1. 读取与比对：AI首先读取wiki/log.md，确定raw/目录中哪些文件是新的或已修改的。
2. 内容提取与概念识别：AI逐篇阅读待处理的原始文件，提取核心论点、事实、定义和关键概念。同时，它会参考AGENTS.md中的兴趣领域。
3. 页面创建/更新与链接：对于识别出的核心主题，AI会在wiki/目录下创建或更新对应的Markdown页面。页面的内容是对原始资料的提炼、总结和重组，而非简单复制。最关键的一步是自动添加[[维基链接]]。AI会分析当前主题与维基中已有主题之间的关联，并插入相应的双括号链接。例如，在一篇关于“Transformer架构”的笔记中，它可能会自动链接到已有的[[Attention Mechanism]]和[[BERT]]页面。
4. 更新索引与日志：最后，AI会更新wiki/index.md，将新页面纳入分类索引，并在wiki/log.md中记录本次处理的文件和时间戳。

实操心得与注意事项：

• 批量处理的黄金法则：不要一次性向raw/中倒入数十个文件。AI的上下文窗口和注意力是有限的。最佳实践是每次投入5到15个相关主题的文件，运行一次/compile-wiki，让AI能更专注、更高质量地建立连接。处理完成后，浏览一下生成的页面和链接，确认无误后再投入下一批。
• 处理大型文档：如果有一个超过3万词的PDF（如一篇博士论文），最好先用其他工具（如pandoc或Adobe Acrobat）将其按章节拆分成多个较小的文件，再放入raw/。这能保证AI在单次处理中有足够的上下文来理解每个部分并建立精准链接。
• 审查与微调：AI生成的链接大部分是合理的，但并非完美。定期用Obsidian打开wiki/文件夹，利用其图形视图检查链接网络。你可能会发现一些错误的关联或缺失的关键链接。你可以直接手动编辑Markdown文件来修正或补充[[链接]]。下一次运行/compile-wiki时，AI会读取这些手动更改，并在此基础上进行更新（尽管它也可能根据对新内容的理解进行新的调整，这是一个协作过程）。

4.2/ask-wiki：知识查询与报告生成

当你的维基初具规模后，/ask-wiki就成了你与知识库对话的接口。这不是一个简单的关键词搜索，而是一个基于理解的问答过程。

查询过程分解：

1. 索引引导：AI首先快速阅读wiki/index.md，对整个知识库的拓扑结构有一个概览。
2. 路径规划：根据你的问题（例如：“我收集的关于能源系统优化的主要方法有哪些？还存在哪些空白？”），AI会规划一个查询路径，决定需要深入查看哪几个具体的维基页面。
3. 图遍历与信息合成：AI按计划加载相关的页面内容，沿着页面内的[[链接]]进行有限的跳转，收集相关信息。
4. 生成与集成报告：AI综合所有检索到的信息，生成一份结构化的回答（通常是一份简明的报告），并自动保存到output/目录下，文件名包含时间戳和问题摘要。更强大的是，这份报告中的核心见解可以被标记，并在你下次运行/compile-wiki时，作为一种新的“原始资料”被吸收进维基，实现知识的闭环增长。

提问技巧：

• 避免过于宽泛：不要问“告诉我关于机器学习的一切”。要问“对比一下我维基中关于监督学习和无监督学习在数据需求上的主要观点”。
• 利用连接性：问一些需要“连接”不同页面知识的问题，最能体现这个系统的价值。例如：“关于‘注意力机制’的笔记，和我在‘蛋白质结构预测’方面的资料有什么理论上的关联？”
• 请求指出空白：经常问“在这个主题下，我的知识库还缺少哪些重要的方面或观点？”这能引导AI帮你发现知识盲区，指导你下一步的阅读方向。

4.3/lint-wiki：知识库健康检查

这是一个月度或季度维护工具。运行/lint-wiki，AI会对整个维基进行一次全面扫描，执行以下任务：

• 验证Frontmatter：检查每个页面顶部的YAML元数据（如果有）格式是否正确。
• 查找损坏链接：找出指向不存在的页面的[[链接]]。
• 发现孤儿页面：找出没有被任何其他页面引用的页面。
• 检测重复主题：识别内容高度相似、可能应该合并的页面。
• 同步索引：确保index.md包含了所有实际存在的页面。
• 矛盾检测：尝试发现不同页面之间可能存在的事实或观点冲突。
• 新主题建议：基于现有内容，推荐可能值得创建新页面来阐述的衍生主题。

运行后，AI会生成一份维护报告。你可以根据报告手动修复问题，或者直接授权AI尝试自动修复某些类别的问题（如创建缺失的页面来修复损坏链接）。

5. 高级使用场景与性能调优

5.1 规模扩展与性能边界

这个模式在约100个原始资料源，生成数百个维基页面的规模下运行最为顺畅，这大约对应40万单词的编译知识。这是Karpathy原文中提到的“甜蜜点”，也经过了实践验证。

应对大规模知识库的策略：如果知识库持续增长，超过了400页，单纯的索引扫描会变得低效。此时，不应抛弃现有模式，而是考虑增加一个轻量级的搜索层。Karpathy本人推荐使用像qmd这样的工具。你可以在/ask-wiki技能执行前，先使用qmd对wiki/目录进行快速全文搜索，筛选出最相关的几个页面路径，然后将这些路径作为上下文提供给AI。这样，AI无需阅读整个索引，可以直接精读相关页面。你的知识资产（Markdown文件）完全不变，只是在查询前端加了一个高效的过滤器。

5.2 与Obsidian的深度集成

虽然wiki/文件夹可以用任何编辑器查看，但与Obsidian的集成能将其价值放大十倍。

1. 将wiki/文件夹作为Obsidian的库打开。
2. 立即获得图形视图，你的知识图谱以节点和连线的形式直观呈现，颜色代表聚类。
3. 反向链接面板会自动显示所有链接到当前页面的其他页面，这是发现意外关联的利器。
4. 可以利用Obsidian的标签系统、查询语言和无数插件来进一步定制你的知识工作流。

项目自带的.obsidian/文件夹提供了一套基础的优化配置，开箱即用。你可以在此基础上，安装诸如“Dataview”（将页面数据表格化）、“Excalidraw”（内嵌手绘图表）等插件来增强功能。

5.3 备份与版本控制策略

由于raw/,output/和整个wiki/文件夹都在.gitignore中，它们不会被自动纳入Git版本控制。这是为了保护隐私。但备份至关重要。

推荐策略：

1. 为你的知识库创建独立的私有Git仓库：

   cd /path/to/MyKnowledgeBase git init git add . # 注意：此时.gitignore已生效，个人数据不会被添加 git commit -m "Initial knowledge base structure" # 添加你的私有远程仓库（如GitHub Private, GitLab, Gitea） git remote add origin git@your-private-repo.com:yourname/MyKnowledgeBase.git git push -u origin main

   这样，项目模板的代码和你的个性化配置（AGENTS.md， 技能文件）得到了备份。
2. 使用同步工具备份个人数据：对于raw/,output/和wiki/里的实际内容，使用云同步服务（如iCloud Drive, Dropbox, OneDrive）或定期压缩拷贝到外部硬盘。Obsidian也提供官方的同步服务。
3. 考虑使用git annex或git lfs：如果你希望用Git管理但又不希望大文件（如PDF）进入历史，可以研究这些工具，它们能将文件内容存储在别处，只在Git中保留指针。

6. 常见问题与故障排查

在实际搭建和使用过程中，你可能会遇到一些典型问题。以下是一些排查思路和解决方案。

最后，我想分享一点个人体会：这个项目的最大魅力不在于其技术复杂度，而在于它提供了一种“低摩擦、高复合”的知识工作流。它不会强迫你改变记录习惯（你还是可以随意保存各种格式的笔记），但却在你背后默默地将这些碎片编织成网。最大的挑战可能在于初期需要一点耐心来调教AGENTS.md和审查AI生成的初始链接。一旦这个系统运转起来，每次向raw/里丢入新资料，然后看着wiki里的链接网络自动生长、扩展，那种知识自发组织起来的感觉，是任何静态笔记软件都无法给予的。它让你的阅读和思考，真正产生了复利。