给 AI 装上“外挂记忆”：我的个人知识库搭建实践

在之前的文章Claude Code 不止能编程，我用它每周写两万字中，我分享了如何使用 Claude Code 进行写作。文章发出后，有不少朋友问我，平时是怎么管理自己的写作素材和知识积累的。毕竟，每周要完成公众号文章、极客时间专栏、各种分享材料，这些内容之间还经常需要相互引用和复用。如果没有一套好的知识管理系统，很容易陷入混乱。

今天这篇文章，就和大家分享一下我是如何搭建个人知识库的。这套方案可能更适合有一定技术背景的朋友，但即便你不写代码，其中的一些思路也许也能给你一些启发。

PART01

为什么选择这套方案？

市面上有很多知识管理工具，Notion、语雀、Obsidian、飞书文档等等。我也用过不少，但最终还是选择了一个看起来有点“原始”的方案：Markdown 文件 + VSCode + Claude Code + Git。

选择这套方案，主要基于以下几个考虑：

对 AI 友好

这是最核心的原因。在之前的文章中我提到过，我现在的写作流程已经离不开 AI 了。而要让 AI 能够高效地协助写作，它需要能够方便地读取和理解我的历史内容、了解我的写作风格、理解不同内容之间的关联。

Markdown 是一种对 AI 非常友好的格式。相比 Word 文档或者富文本，Markdown 是纯文本格式，AI 可以直接读取和处理，不需要额外的格式转换。同时，Markdown 的语法足够简单，AI 生成的内容可以直接嵌入，不会出现格式错乱的问题。

版本管理

作为程序员，我对版本管理有天然的需求。一篇文章从初稿到定稿，往往要经过多轮修改。有了 Git，我可以清楚地看到每次修改了什么，必要时可以回退到之前的版本。这比在文件名后面加”_v1"、“_v2"、”_最终版”、“_最终版2”要优雅得多。

可迁移性

Markdown 文件就是纯文本，不依赖任何特定的软件或平台。即便将来 VSCode 或者 Claude Code 不存在了，我的内容依然可以用任何文本编辑器打开。这种可迁移性让我很安心。

与开发工具链的融合

我的日常工作主要在 VSCode 中进行。用同样的工具进行写作，可以复用很多操作习惯，比如快捷键、搜索、批量替换等。更重要的是，Claude Code 本身就是在 VSCode 中运行的，这让 AI 辅助写作变得非常顺畅。

PART02

目录结构的设计

一个好的知识库，目录结构是基础。我的目录结构大致如下：

这个结构的设计有几个要点：

按输出渠道组织

我的写作内容会发布到不同的渠道：公众号、极客时间、内部分享等。每个渠道的受众不同，写作风格也会有差异。所以顶层目录按输出渠道来划分，方便管理。

区分已发表和待发表

对于公众号这类需要持续更新的内容，我会区分 released（已发表）和 drafts（待发表）两个子目录。已发表的内容可以作为写作风格的参考，待发表的内容则是当前正在进行的工作。

每个目录都有 README.md

这是一个很关键的设计。每个目录下都有一个 README.md 文件，用来说明这个目录的用途、包含的内容类型、以及特定的写作规范。这不仅方便自己回顾，更重要的是方便 AI 理解上下文。

PART03

CLAUDE.md 的设置

CLAUDE.md 是整个知识库中最重要的文件之一。它是专门为 Claude Code 准备的上下文文件，让 AI 能够快速理解这个项目的背景和规范。

我的 CLAUDE.md 通常包含以下几个部分：

作者信息

简单介绍自己的背景、专业领域、写作动机等。这些信息帮助 AI 理解我的视角和立场，在生成内容时能够保持一致性。

目录结构说明

详细描述每个目录的用途，方便 AI 在需要查找或引用内容时知道去哪里找。

通用写作规范

包括一些基本的格式要求，比如：

• 英文单词前后要加空格（如 AI 、Claude Code 等）
• 使用中文全角标点符号
• 专业术语需要适当解释

注意事项

一些特殊的提醒，比如不同渠道要参考各自的 README.md、Git 提交时的注意事项等。

这个文件的价值在于，每次我打开这个项目用 Claude Code 进行写作时，AI 都能自动读取这些信息，不需要我每次都重新解释背景。

PART04

子目录的 README.md

除了项目级别的 CLAUDE.md，每个子目录也需要有自己的 README.md。以公众号目录为例，我的 README.md 包含：

目录说明

解释 released、drafts、素材等子目录的用途。

文字风格

这是最关键的部分。例如，我让 AI 分析了我之前发表的所有公众号文章，总结出了我的写作风格特点：

• 整体定位：理性思考 + 真诚分享 + 实践导向
• 结构组织：系列文章有前文回顾、正文采用明确分段、文章结尾有总结和互动
• 语言表达：专业但不晦涩、逻辑严密、诚恳谦逊
• 常用句式：长短句结合、善用过渡词
• 常用表达模式：开篇方式、过渡衔接、总结方式

写作禁忌

明确列出不应该出现的内容，比如过度使用 emoji、过于口语化、绝对化表达等。

审校要点

最后校对时需要检查的项目清单。

有了这些详细的规范，AI 在帮我写作或校对时，就能更好地保持我的个人风格。

PART05

实际的工作流程

说完了结构设计，再来聊聊实际的工作流程。下面我用两个真实的场景来说明这套知识库是如何运转的。

场景一：准备一个对外分享的 PPT

前段时间，有客户邀请我做一次分享。从拿到邀请到完成 PPT，整个过程是这样的：

首先，对方会给我一些关于分享主题和受众的信息，可能还有一些具体的问题和期望。我会把这些信息丢给 AI，让它帮我梳理总结，提炼出几个核心要点。这一步的价值在于，AI 能够帮我从零散的信息中找到主线，避免遗漏重要的内容。

接下来，基于 AI 梳理的结果，结合我知识库中以往的素材，我会让 AI 生成一个 Markdown 格式的 PPT 大纲。这里的关键是“结合知识库中的素材”——因为 AI 可以读取我之前写过的文章、做过的分享，所以它能够找到可以复用的内容，避免重复造轮子。

大纲确认之后，我会让 AI 根据大纲逐页生成 PPT 的内容，以 draw.io 格式保存。选择 draw.io 格式是因为它是基于 XML 的开放格式，AI 可以直接生成和修改，而且 draw.io 本身也是免费工具，编辑起来很方便。

最后，我会人工对每一页做检查和微调，然后粘贴到正式的 PPT 中。虽然这一步还是需要人工介入，但相比从零开始做 PPT，效率已经提升了很多。

场景二：撰写一篇公众号文章

这个场景可能更有普遍性。以本文为例，整个流程是这样的：

日常工作和生活中，我会有很多零散的想法和灵感。这些想法我会简短地记录下来，保存在 `公众号/drafts` 目录下。可能就是一两句话，也可能是一个简单的提纲。这些“种子”会在那里静静等待，直到某一天我决定把它写成一篇完整的文章。

当我准备写文章时，首先会跟 AI 一起讨论，把零散的想法整理成一个完整的大纲。这个过程通常需要几轮对话，AI 会帮我补充遗漏的角度，调整段落的顺序，确保逻辑通顺。

大纲确认后，我会让 AI 根据大纲，按照我以往的文字风格生成全文初稿。因为 README.md 中已经详细描述了我的写作风格，AI 生成的内容通常已经比较接近我的表达习惯了。

然后是最重要的一步：逐字阅读和修改初稿。虽然 AI 的初稿已经不错，但很多个人化的表达、具体的案例、微妙的语气，还是需要我自己来调整。这一步花的时间最多，但也是让文章有“人味”的关键。

定稿之后，我会让 AI 完成最终的排版和校对——检查错别字、检查英文单词前后的空格、检查标点符号等。这些机械性的工作 AI 做得又快又好。

文章发布之后，我会把它从 drafts 目录移动到 released 目录。这样，这篇文章就成为了知识库的一部分，未来写其他文章时，AI 可以参考它的风格和内容。

两个场景的共同点

回顾这两个场景，可以发现几个共同的模式：

第一，AI 负责繁重的基础工作，人负责关键的决策和打磨。不管是梳理信息、生成大纲、还是写初稿，这些工作量大但相对机械的任务都交给 AI；而确定方向、调整细节、把控质量这些需要判断力的工作则由我来完成。

第二，知识库是 AI 的“记忆”。因为所有的历史内容都在知识库中，AI 可以随时调取过往的素材和风格参考。这就像是给 AI 装上了一个“外挂记忆”，让它对我的偏好和习惯有了持续的了解。

第三，流程是标准化的，但输出是个性化的。每次写作都遵循类似的流程，但因为 AI 能够理解我的风格规范，最终的输出依然保持着个人特色。

PART06

一些实践中的小技巧

分享几个我在使用过程中总结出的小技巧：

善用 Markdown Preview 插件

VSCode 中有很多 Markdown 预览插件，可以实时看到渲染后的效果。我常用的是 Markdown Preview Enhanced，它支持表格、流程图等扩展语法的预览。

建立素材库

除了正式的文章，我还会在“素材”目录下积累一些零散的想法、引用的资料、读书笔记等。这些内容虽然不成文章，但经常会成为后续写作的素材来源。

定期整理和归档

每隔一段时间，我会对知识库做一次整理。把已发表的文章从 drafts 移到 released，清理掉不再需要的临时文件，更新目录结构说明等。

保持目录结构的简洁

虽然可以创建很深的目录层级，但我尽量保持结构的扁平化。太深的层级不仅自己找起来麻烦，AI 理解起来也会更困难。

常见操作工具化

在使用过程中，我发现有些操作会反复出现。与其每次都让 AI 来处理，不如把它固化成工具。举个例子，Claude Code 在处理中文引号时经常出错，一开始我是让 Gemini 读完全文再修正引号问题，但这样每次都要消耗不少 token。后来我索性让 Gemini 帮我写了一个专门处理引号的 Python 脚本，一劳永逸。类似的，一些格式检查、文件归档等重复性操作，都可以用脚本来自动化，既省时间又省 token。

PART07

写在最后

这套知识库方案，本质上是把程序员管理代码的方式，应用到了知识管理上。Markdown 对应源代码，Git 对应版本控制，CLAUDE.md 对应项目文档，目录结构对应代码架构。

当然，这套方案也有它的局限性。它对使用者有一定的技术要求，不像 Notion 那样开箱即用；它也不支持富文本编辑，排版上没有可视化编辑器那么直观。

但对于我这样一个程序员来说，这套方案的优点远大于缺点。最重要的是，它让 AI 能够深度参与到我的写作流程中，这在当下的 AI 时代，是一个巨大的效率优势。

如果你也在探索知识管理的方法，希望这篇文章能给你一些启发。不一定要照搬我的方案，但“对 AI 友好”这个原则，我觉得在未来会越来越重要。

以上是我个人的实践总结，一家之言，仅供参考。欢迎大家在评论区交流讨论。