1. 为什么我要折腾一个“会自我维护”的知识库

先说结论：我一行代码没写，用 Trae 搭了一个能自己整理、自己打标签、自己更新索引的知识库。它不是什么黑科技，核心就是AGENTS.md 规则文件 + Markdown 目录结构 + LLM 自动处理这三样东西的组合。

我做知识管理大概有六七年了，从最早的印象笔记，到后来的 Obsidian、Notion，再到自己拿 Python 写脚本做自动化，几乎每一条路都走过。踩过的坑基本都一样：手动整理的成本远高于记录的成本。你记了 500 条笔记，可能只有 50 条被真正整理过，剩下的全是“待归档”状态，时间一长就变成了垃圾场。我试过用各种自动化工具去补，但要么配置复杂到劝退，要么规则写死了不够灵活，遇到新类型的笔记就歇菜。

Trae 这个 AI IDE 出来之后，我第一反应是拿它写代码，后来发现它真正好用的地方不在写代码，而在于它能理解项目上下文，并且可以按照你定义的规则去执行重复性任务。这就意味着，我可以把“整理知识库”这件事拆成一套规则，写进 AGENTS.md 里，然后让 Trae 按照规则去处理 Markdown 文件。整个过程不需要我写一行 Python 或者 JavaScript，只需要把规则说清楚。

这个知识库适合什么人？如果你是那种“记录很多但整理很少”的人，或者你已经在用 Markdown 管理笔记但苦于维护成本太高，再或者你想试试 AI IDE 除了写代码之外还能干什么，那这套方案可以直接抄作业。它不依赖任何特定平台，所有文件都在本地，格式是纯 Markdown，迁移成本几乎为零。

我用的核心工具就三个：Trae（AI IDE）、AGENTS.md（规则定义文件）、Markdown（数据格式）。下面我会把整个搭建过程拆开讲，包括我为什么这么设计、每一步的具体操作、以及我踩过的那些坑。

2. 整体设计思路：让规则文件成为知识库的“大脑”

2.1 为什么选 Markdown 作为知识库的底层格式

这个选择几乎没有犹豫。Markdown 的好处在于：纯文本、结构清晰、任何工具都能读、版本控制友好。我之前的笔记散落在各种平台里，导出格式五花八门，迁移一次就要掉一层皮。Markdown 不存在这个问题，它就是一个文本文件，用任何编辑器都能打开，用 Git 可以追踪每一次修改，用脚本可以批量处理。

更重要的是，Markdown 的结构化程度刚好适合 LLM 处理。它不像纯文本那样完全没有结构，也不像 JSON 或 XML 那样对格式要求极其严格。标题、列表、表格、代码块这些元素，LLM 都能很好地理解。你可以把一篇 Markdown 笔记想象成一张“半结构化的卡片”，人看着舒服，机器处理起来也不费劲。

我目前的知识库目录结构是这样的：

knowledge-base/ ├── AGENTS.md ├── inbox/ │ ├── 20250115-关于RAG的思考.md │ └── 20250116-读论文笔记.md ├── notes/ │ ├── ai/ │ │ ├── RAG原理与实践.md │ │ └── Agent设计模式.md │ ├── tools/ │ │ └── Trae使用心得.md │ └── reading/ │ └── 2024年读书记录.md ├── index/ │ ├── 全部笔记索引.md │ └── 标签索引.md └── templates/ ├── 笔记模板.md └── 读书笔记模板.md

inbox是收件箱，所有新笔记先扔进去，不做任何整理。notes是正式归档区，按主题分目录。index存放自动生成的索引文件。templates放模板，新建笔记时直接复制。

这个结构的关键在于：inbox 和 notes 是分离的。记录的时候只管往 inbox 里扔，整理的时候由 Trae 按照规则把 inbox 里的内容处理到 notes 里。这样就把“记录”和“整理”两个动作彻底解耦了，记录的时候没有任何心理负担，整理的时候也不需要我手动操作。

2.2 AGENTS.md 到底扮演什么角色

AGENTS.md 是这套方案的核心。你可以把它理解成一份“给 AI 看的操作手册”。Trae 在打开一个项目时，会自动读取项目根目录下的 AGENTS.md 文件，把它作为上下文的一部分。这意味着，你在这个文件里写的规则，Trae 会当作“项目级别的指令”来执行。

我一开始也没太在意这个文件，觉得就是个说明文档。后来发现，AGENTS.md 写得好不好，直接决定了 Trae 能不能准确理解你的意图。如果你只是随便写几句“帮我整理笔记”，Trae 每次的处理方式可能都不一样。但如果你把规则写得足够具体，比如“所有笔记必须包含 title、tags、created 三个字段”“标签必须从预定义列表中选择”“超过 500 字的笔记必须生成摘要”，Trae 就会严格按照这些规则来执行。

我的 AGENTS.md 大概长这样（简化版）：

# 知识库维护规则 ## 角色定义 你是一个知识库维护助手，负责整理和归档 Markdown 笔记。 ## 目录约定 - inbox/：收件箱，存放未整理的笔记 - notes/：正式归档区，按主题分类 - index/：自动生成的索引文件 - templates/：笔记模板 ## 笔记格式要求 每篇笔记必须包含以下 frontmatter： - title：笔记标题 - tags：标签列表，从预定义标签中选择 - created：创建日期，格式 YYYY-MM-DD - updated：最后更新日期 ## 整理流程 1. 读取 inbox/ 中的所有 .md 文件 2. 为每篇笔记生成或补全 frontmatter 3. 根据内容判断所属主题，移动到 notes/ 对应目录 4. 更新 index/ 中的索引文件 5. 在原文件位置留下归档记录 ## 标签体系 预定义标签：ai, llm, tools, reading, workflow, idea, tutorial 新标签需要先添加到标签列表才能使用 ## 索引更新规则 - 全部笔记索引：按更新时间倒序排列 - 标签索引：按标签分组，每组内按标题排序

这份规则文件大概 60 行，但就是这 60 行，让 Trae 能够稳定地执行整理任务。我试过把规则写得更简略，结果 Trae 每次的处理方式都不一样，有时候加标签有时候不加，有时候移动文件有时候不移动。后来我把规则细化到“每一步做什么、输出什么格式”，稳定性就上来了。

2.3 为什么不用脚本而用 AI IDE

你可能会问：这些操作写个 Python 脚本不就行了？为什么要用 AI IDE？

我一开始也是这么想的，而且确实写过脚本。但脚本的问题在于：规则是硬编码的，遇到新情况就要改代码。比如我一开始只处理.md文件，后来想处理.txt文件，就要改代码。再后来想根据内容自动判断标签，又要改代码。每次改代码都要测试、调试，时间成本很高。

用 Trae 的好处是：规则是用自然语言写的，修改规则不需要改代码。我想增加一种新的笔记类型，只需要在 AGENTS.md 里加一段描述，Trae 就能理解并执行。我想调整标签体系，也只需要改规则文件。这种灵活性是脚本很难做到的。

当然，代价是每次执行都需要调用 LLM，速度比脚本慢，而且有 token 成本。但对于知识库整理这种低频操作（我大概每周整理一次），这点成本完全可以接受。而且 Trae 有免费的额度，日常使用基本够用。

3. 核心细节解析：AGENTS.md 怎么写才有效

3.1 规则文件的三个关键要素

写 AGENTS.md 不是写作文，不需要文采，需要的是精确、具体、可执行。我总结下来，一份有效的规则文件必须包含三个要素：

第一，明确的角色定义。你要告诉 Trae 它是什么角色，负责什么任务。比如“你是一个知识库维护助手，负责整理和归档 Markdown 笔记”。这句话看起来简单，但它决定了 Trae 处理任务时的“视角”。如果没有这句话，Trae 可能会把整理笔记当成一个编程任务来处理，输出一堆代码而不是直接操作文件。

第二，具体的操作流程。不要写“帮我整理笔记”这种模糊的指令，要写“读取 inbox 中的所有 md 文件，为每篇笔记生成 frontmatter，根据内容判断主题并移动到对应目录”。步骤越具体，执行结果越稳定。我甚至会把每一步的输入和输出格式都写清楚，比如“frontmatter 必须包含 title、tags、created 三个字段，tags 从预定义列表中选择”。

第三，边界和约束。告诉 Trae 什么能做、什么不能做。比如“不要修改笔记正文内容”“不要删除任何文件”“新标签必须先添加到标签列表”。这些约束可以防止 Trae 在执行过程中做出意料之外的操作。我就遇到过 Trae 把一篇笔记的正文给“优化”了的情况，虽然内容变得更通顺了，但那是我的原始记录，我不希望被改动。后来加了“不要修改正文”的约束，这个问题就解决了。

3.2 标签体系的设计技巧

标签体系是知识库整理中最容易出问题的部分。如果标签太自由，最后会变成一堆同义词和拼写错误；如果标签太严格，又不够灵活。我的做法是：预定义一组核心标签，同时允许在规则中扩展。

核心标签我控制在 10 个以内，覆盖大部分场景：ai、llm、tools、reading、workflow、idea、tutorial、life、career、misc。这些标签足够宽泛，不会出现“这个笔记不知道放哪个标签”的情况。

扩展标签的规则是：新标签必须先添加到 AGENTS.md 的标签列表中，才能使用。这样做的好处是，标签体系是可控的，不会无限膨胀。当我发现某个新标签被反复使用时，我会把它加到列表里。如果只是一次性的标签，就不加，归到misc里。

还有一个技巧是：给每个标签写一句描述。比如ai: 人工智能相关，包括模型、算法、应用，tools: 工具使用心得和评测。这样 Trae 在判断标签时有了参考依据，准确率会高很多。我试过不写描述，结果 Trae 把一篇关于“写作工具”的笔记打上了ai标签，因为那篇文章提到了 AI 辅助写作。后来加了描述，明确tools是“工具使用心得”，这个问题就少了。

3.3 frontmatter 的标准化

frontmatter 是 Markdown 文件开头用---包裹的元数据区域。我的知识库要求每篇笔记都必须有 frontmatter，包含以下字段：

--- title: 笔记标题 tags: [tag1, tag2] created: 2025-01-15 updated: 2025-01-16 source: 可选，来源链接或出处 summary: 可选，一句话摘要 ---

title和tags是必填的，created和updated由 Trae 自动生成或更新。source和summary是可选的，但对于长笔记，我会要求 Trae 生成摘要。

为什么要强制 frontmatter？因为它是索引的基础。有了结构化的元数据，生成索引就变得非常简单：读取所有文件的 frontmatter，按标签分组、按时间排序，输出成 Markdown 表格。如果没有 frontmatter，就要从正文中提取信息，准确率和效率都会差很多。

我踩过的一个坑是：早期笔记没有 frontmatter，Trae 在整理时要从正文中猜测标题和标签，结果经常猜错。后来我写了一个“补全 frontmatter”的规则，让 Trae 先给所有旧笔记补上 frontmatter，再执行整理流程。这个补全过程花了大概半小时（因为要逐篇处理），但一次性解决了历史遗留问题。

4. 实操过程：从零搭建知识库的完整步骤

4.1 环境准备与 Trae 初始化

首先你需要下载并安装 Trae。官网直接搜“Trae”就能找到，支持 Windows、macOS 和 Linux。安装过程没什么好说的，一路下一步就行。安装完成后，用邮箱注册一个账号，登录后就能用了。

这里有个小细节：Trae 有国内版和国际版，我用的国内版，访问速度更快，而且有免费额度。注册后会送一些积分，日常整理笔记完全够用。如果你用量大，可以考虑积分兑换码，但我不建议一开始就折腾这个，先用免费额度跑通流程再说。

安装完成后，新建一个项目，目录就选你存放知识库的文件夹。如果你还没有知识库，就新建一个空文件夹，比如knowledge-base。Trae 打开项目后，会在项目根目录下寻找 AGENTS.md 文件。如果没有，它会用默认的全局规则。所以第一步就是创建 AGENTS.md。

创建 AGENTS.md 的方式很简单：在 Trae 的文件管理器里右键新建文件，命名为AGENTS.md，然后把前面写的规则内容粘贴进去。注意文件名必须是大写的AGENTS.md，小写的不行。我试过用agents.md，Trae 没有识别，改成大写后就正常了。

4.2 目录结构的创建与模板准备

按照前面的设计，创建以下目录：

knowledge-base/ ├── AGENTS.md ├── inbox/ ├── notes/ │ ├── ai/ │ ├── tools/ │ ├── reading/ │ └── misc/ ├── index/ └── templates/

这些目录可以手动创建，也可以在 Trae 的终端里用mkdir命令创建。我习惯用命令行，一条命令搞定：

mkdir -p inbox notes/{ai,tools,reading,misc} index templates

然后在templates/目录下创建笔记模板笔记模板.md：

--- title: tags: [] created: updated: --- # ## 背景 ## 内容 ## 总结

这个模板的作用是：新建笔记时直接复制，保证格式统一。我一开始没有用模板，结果每篇笔记的格式都不一样，有的有 frontmatter 有的没有，有的用#标题有的用##。后来统一用模板，Trae 处理起来就顺畅多了。

4.3 写一条完整的整理指令

环境准备好之后，就可以让 Trae 执行整理任务了。在 Trae 的对话窗口中输入指令：

请按照 AGENTS.md 中的规则，整理 inbox/ 目录下的所有笔记。

Trae 会读取 AGENTS.md，然后开始处理。它会做以下几件事：

1. 扫描inbox/目录，找到所有.md文件
2. 读取每个文件的内容
3. 检查 frontmatter 是否完整，不完整就补全
4. 根据内容判断所属主题，移动到notes/对应目录
5. 更新index/中的索引文件
6. 在inbox/中留下归档记录

整个过程大概需要几十秒到几分钟，取决于笔记数量。我第一次整理时，inbox 里有 30 多篇笔记，Trae 花了大概 3 分钟处理完。处理结果让我挺惊喜的：所有笔记都补上了 frontmatter，标签打得也比较准，索引文件也自动生成了。

不过也有翻车的时候。有一次 Trae 把一篇关于“读书笔记”的文章归到了ai目录，因为那本书是关于 AI 的。但我的本意是把它放在reading目录。后来我在 AGENTS.md 里加了一条规则：“读书笔记优先归入 reading 目录，即使内容涉及 AI”。这个问题就解决了。

4.4 索引文件的自动生成

索引文件是知识库的“地图”，没有索引的知识库就是一堆散落的文件。我的索引文件有两个：全部笔记索引.md和标签索引.md。

全部笔记索引.md的格式是这样的：

# 全部笔记索引 | 标题 | 标签 | 更新时间 | 路径 | |------|------|----------|------| | RAG原理与实践 | ai, llm | 2025-01-16 | notes/ai/RAG原理与实践.md | | Trae使用心得 | tools, ai | 2025-01-15 | notes/tools/Trae使用心得.md |

标签索引.md的格式是这样的：

# 标签索引 ## ai - [RAG原理与实践](notes/ai/RAG原理与实践.md) - [Agent设计模式](notes/ai/Agent设计模式.md) ## tools - [Trae使用心得](notes/tools/Trae使用心得.md)

这两个索引文件都是由 Trae 自动生成的，我只需要在 AGENTS.md 里定义好格式，Trae 就会按照格式输出。生成索引的规则我写得很具体：

## 索引更新规则 - 全部笔记索引：读取 notes/ 下所有 .md 文件的 frontmatter，按 updated 字段倒序排列，输出为 Markdown 表格，包含标题、标签、更新时间、路径四列 - 标签索引：按 tags 字段分组，每组内按标题排序，输出为 Markdown 列表，格式为 [标题](路径)

有了这两个索引，我找笔记的时候就不需要翻目录了，直接看索引就行。而且索引是自动更新的，每次整理完 inbox，索引也会同步更新。

5. 常见问题与排查技巧实录

5.1 Trae 不读取 AGENTS.md 怎么办

这是最常见的问题。我一开始也遇到了，Trae 好像完全忽略了我写的规则，整理结果乱七八糟。排查下来有几个原因：

文件名不对。必须是AGENTS.md，全大写。我试过Agents.md、agents.md、AGENT.md，都不行。这个文件名是 Trae 约定的，不能改。

文件位置不对。AGENTS.md 必须放在项目根目录下。如果你放在子目录里，Trae 不会自动读取。我试过放在docs/AGENTS.md，结果 Trae 没识别。后来移到根目录就正常了。

文件内容格式有问题。AGENTS.md 必须是纯 Markdown 格式，不能用其他格式。我试过用 YAML 写规则，Trae 读不懂。后来改成 Markdown 的标题和列表结构，就正常了。

Trae 版本太旧。早期版本的 Trae 可能不支持 AGENTS.md，需要更新到最新版。我用的版本是 1.0 以上，支持得比较好。

如果确认以上都没问题，但 Trae 还是不读取，可以尝试在对话中显式提醒：“请读取项目根目录下的 AGENTS.md 文件，并按照其中的规则执行”。这样 Trae 会强制读取一次。

5.2 标签打得不准怎么调整

标签准确率是我最关心的问题，因为标签错了，索引就错了，整个知识库的可用性就下降了。我总结了几种提高标签准确率的方法：

给标签写描述。前面提到过，在 AGENTS.md 里给每个标签写一句描述，Trae 判断时会参考这些描述。比如tools: 工具使用心得、评测、教程，ai: 人工智能模型、算法、应用。有了描述之后，准确率大概能提升 30%。

提供示例。在 AGENTS.md 里给每个标签举一两个例子，比如ai: 例如“RAG原理”“Agent设计模式”。这样 Trae 有了参考样本，判断会更准。

限制标签数量。每篇笔记的标签不要超过 3 个。标签太多会导致重点不突出，而且容易打错。我在规则里写了“每篇笔记最多 3 个标签”，Trae 就会优先选择最相关的标签。

人工复核。整理完成后，我会快速扫一遍索引，看看有没有明显打错的标签。如果有，就手动改一下，然后在 AGENTS.md 里补充规则。比如我发现 Trae 总是把“写作”相关的笔记打到ai标签，我就在规则里加了一条“纯写作技巧类笔记归入 misc，除非涉及 AI 工具”。

5.3 整理速度太慢怎么优化

Trae 整理笔记的速度取决于笔记数量和长度。我测试下来，处理 10 篇中等长度的笔记（每篇 500-1000 字）大概需要 1-2 分钟。如果笔记很多，时间会更长。

优化速度的方法有几个：

分批处理。不要一次性整理所有笔记，可以按日期分批。比如每次只整理一周内的笔记，这样每次处理量小，速度快，而且不容易出错。

减少不必要的操作。如果某篇笔记已经整理过了，就不要重复处理。我在 AGENTS.md 里加了一条规则：“如果笔记已经在 notes/ 目录下，跳过处理”。这样可以避免重复劳动。

用更简单的规则。规则越复杂，Trae 处理越慢。如果只是简单的归档，不需要生成摘要、不需要更新索引，速度会快很多。我平时整理用简化规则，周末做一次完整整理。

升级硬件。Trae 是本地运行的 IDE，但 LLM 调用是云端的。如果你的网络速度慢，处理速度也会受影响。我用的是有线网络，比无线稳定一些。

5.4 常见问题速查表

5.5 我踩过的三个大坑

第一个坑：没有备份就整理。我第一次让 Trae 整理时，它把几篇笔记的文件名改了，导致我原来的链接全部失效。幸好我有 Git 版本控制，回滚了。从那以后，我每次整理前都会先 commit 一次，确保可以回滚。

第二个坑：规则写得太模糊。我一开始写的是“帮我整理笔记”，结果 Trae 把笔记内容给“优化”了，改得面目全非。后来我把规则改成“只处理 frontmatter 和文件位置，不修改正文内容”，问题就解决了。

第三个坑：标签体系失控。我一开始没有限制标签数量，结果 Trae 给每篇笔记打了七八个标签，索引变得非常臃肿。后来我限制了每篇最多 3 个标签，并且预定义了核心标签列表，标签体系才变得可控。

6. 进阶玩法：让知识库真正“活”起来

6.1 自动生成周报和月报

知识库整理好之后，我加了一个规则：每周日自动生成本周笔记的摘要汇总。Trae 会读取notes/目录下updated字段在本周内的笔记，提取标题和摘要，生成一份周报。月报同理，只是时间范围变成一个月。

这个功能的实现完全靠 AGENTS.md 里的规则描述：

## 周报生成规则 - 每周日执行 - 读取 notes/ 下 updated 字段在本周内的笔记 - 提取标题和 summary 字段 - 按标签分组输出 - 保存到 index/周报-YYYY-MM-DD.md

我只需要在周日打开 Trae，输入“生成本周周报”，它就会自动完成。周报的好处是：我能快速回顾一周内记录了什么，哪些主题比较集中，哪些笔记还没有深入整理。

6.2 笔记之间的自动关联

知识库的价值不仅在于存储，还在于关联。我在 AGENTS.md 里加了一条规则：整理笔记时，检查是否有其他笔记包含相同标签，如果有，在笔记末尾添加“相关笔记”链接。

比如一篇关于“RAG”的笔记，标签是ai, llm，Trae 会找到其他带有ai或llm标签的笔记，在末尾生成一个“相关笔记”列表。这样我在阅读一篇笔记时，可以顺藤摸瓜找到相关内容，知识库就从“孤岛”变成了“网络”。

这个功能的实现也不复杂，规则大概是这样：

## 关联笔记规则 - 整理笔记时，查找 notes/ 下具有相同标签的其他笔记 - 最多关联 5 篇 - 在笔记末尾添加“## 相关笔记”章节 - 格式为 [标题](路径)

6.3 定期清理和归档

知识库用久了，会有一些过时的笔记。我在 AGENTS.md 里加了一条规则：每季度检查一次，将超过一年未更新的笔记标记为“归档”。归档的笔记不会删除，只是移动到archive/目录，并在索引中标注。

这个规则帮我清理了不少“僵尸笔记”。有些笔记是当时觉得有用记下来的，但后来再也没有看过。归档之后，notes/目录保持精简，找东西更快。

6.4 与其他工具的联动

虽然知识库是纯 Markdown 的，但可以通过 Trae 与其他工具联动。比如：

• 导出为 Word：Trae 可以把 Markdown 转换成 Word 格式，方便分享给不用 Markdown 的人。
• 生成表格：把 Markdown 表格转换成 Excel 格式，方便数据分析。
• 发布到博客：把整理好的笔记转换成博客格式，直接发布。

这些操作都不需要写代码，只需要在 Trae 的对话中输入指令，比如“把 notes/ai/RAG原理与实践.md 转换成 Word 格式”。Trae 会调用相应的工具完成转换。

我个人的体会是，这套方案最大的价值不在于“自动化”，而在于“可持续”。以前我整理知识库，坚持不了几周就放弃了，因为手动整理太累。现在有了 Trae 和 AGENTS.md，整理变成了一件“说一句话就能完成”的事情，我坚持了三个月，知识库从 30 篇笔记增长到 200 多篇，而且每一篇都是整理过的、有标签的、可检索的。

最后分享一个小技巧：AGENTS.md 不是一次写完的，而是逐步迭代的。我一开始只写了 20 行规则，后来遇到问题就加一条，现在大概有 100 多行。每次加规则都是一次优化，知识库的整理质量也随之提升。如果你刚开始搭，不用追求一步到位，先跑通基本流程，然后根据实际使用中的问题逐步完善规则。