★ FEATURED ARTICLE 1. 为什么我要折腾一个“会自我维护”的知识库先说结论我一行代码没写用 Trae 搭了一个能自己整理、自己打标签、自己更新索引的知识库。它不是什么黑科技核心就是AGENTS.md 规则文件 Markdown 目录结构 LLM 自动处理这三样东西的组合。我做知识管理大概有六七年了从最早的印象笔记到后来的 Obsidian、Notion再到自己拿 Python 写脚本做自动化几乎每一条路都走过。踩过的坑基本都一样手动整理的成本远高于记录的成本。你记了 500 条笔记可能只有 50 条被真正整理过剩下的全是“待归档”状态时间一长就变成了垃圾场。我试过用各种自动化工具去补但要么配置复杂到劝退要么规则写死了不够灵活遇到新类型的笔记就歇菜。Trae 这个 AI IDE 出来之后我第一反应是拿它写代码后来发现它真正好用的地方不在写代码而在于它能理解项目上下文并且可以按照你定义的规则去执行重复性任务。这就意味着我可以把“整理知识库”这件事拆成一套规则写进 AGENTS.md 里然后让 Trae 按照规则去处理 Markdown 文件。整个过程不需要我写一行 Python 或者 JavaScript只需要把规则说清楚。这个知识库适合什么人如果你是那种“记录很多但整理很少”的人或者你已经在用 Markdown 管理笔记但苦于维护成本太高再或者你想试试 AI IDE 除了写代码之外还能干什么那这套方案可以直接抄作业。它不依赖任何特定平台所有文件都在本地格式是纯 Markdown迁移成本几乎为零。我用的核心工具就三个TraeAI 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 └── 读书笔记模板.mdinbox是收件箱所有新笔记先扔进去不做任何整理。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就要从正文中提取信息准确率和效率都会差很多。我踩过的一个坑是早期笔记没有 frontmatterTrae 在整理时要从正文中猜测标题和标签结果经常猜错。后来我写了一个“补全 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.mdTrae 没有识别改成大写后就正常了。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然后开始处理。它会做以下几件事扫描inbox/目录找到所有.md文件读取每个文件的内容检查 frontmatter 是否完整不完整就补全根据内容判断所属主题移动到notes/对应目录更新index/中的索引文件在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 常见问题速查表问题可能原因解决方法Trae 不读取 AGENTS.md文件名或位置不对确认文件名为 AGENTS.md放在项目根目录标签打得不准标签描述不清晰给每个标签写描述和示例限制标签数量整理速度慢笔记太多或规则太复杂分批处理简化规则检查网络笔记被误改规则中没有约束在 AGENTS.md 中加“不要修改正文内容”索引没有更新规则中没有定义索引格式在 AGENTS.md 中明确索引的格式和更新规则新标签无法使用标签不在预定义列表中先将新标签添加到 AGENTS.md 的标签列表文件移动后链接失效索引中的路径没有更新确保索引生成规则中包含路径更新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, llmTrae 会找到其他带有ai或llm标签的笔记在末尾生成一个“相关笔记”列表。这样我在阅读一篇笔记时可以顺藤摸瓜找到相关内容知识库就从“孤岛”变成了“网络”。这个功能的实现也不复杂规则大概是这样## 关联笔记规则 - 整理笔记时查找 notes/ 下具有相同标签的其他笔记 - 最多关联 5 篇 - 在笔记末尾添加“## 相关笔记”章节 - 格式为 [标题](路径)6.3 定期清理和归档知识库用久了会有一些过时的笔记。我在 AGENTS.md 里加了一条规则每季度检查一次将超过一年未更新的笔记标记为“归档”。归档的笔记不会删除只是移动到archive/目录并在索引中标注。这个规则帮我清理了不少“僵尸笔记”。有些笔记是当时觉得有用记下来的但后来再也没有看过。归档之后notes/目录保持精简找东西更快。6.4 与其他工具的联动虽然知识库是纯 Markdown 的但可以通过 Trae 与其他工具联动。比如导出为 WordTrae 可以把 Markdown 转换成 Word 格式方便分享给不用 Markdown 的人。生成表格把 Markdown 表格转换成 Excel 格式方便数据分析。发布到博客把整理好的笔记转换成博客格式直接发布。这些操作都不需要写代码只需要在 Trae 的对话中输入指令比如“把 notes/ai/RAG原理与实践.md 转换成 Word 格式”。Trae 会调用相应的工具完成转换。我个人的体会是这套方案最大的价值不在于“自动化”而在于“可持续”。以前我整理知识库坚持不了几周就放弃了因为手动整理太累。现在有了 Trae 和 AGENTS.md整理变成了一件“说一句话就能完成”的事情我坚持了三个月知识库从 30 篇笔记增长到 200 多篇而且每一篇都是整理过的、有标签的、可检索的。最后分享一个小技巧AGENTS.md 不是一次写完的而是逐步迭代的。我一开始只写了 20 行规则后来遇到问题就加一条现在大概有 100 多行。每次加规则都是一次优化知识库的整理质量也随之提升。如果你刚开始搭不用追求一步到位先跑通基本流程然后根据实际使用中的问题逐步完善规则。
阅读完成 · 觉得有帮助？
