知识库这东西，几乎每个折腾过笔记软件的人都搭过。Notion、Obsidian、Logseq、飞书文档，工具换了一茬又一茬，最后真正能坚持用下去的没几个。问题不在于工具不好，而在于维护成本太高了——你今天记了十条笔记，过两周回头看，标签乱了、链接断了、格式五花八门，想找的东西找不到，不想找的倒是天天冒出来。久而久之，知识库就变成了"知识坟场"。
我这次用 Trae 搭的这套知识库，核心思路就一个：让知识库自己管自己。我不写一行代码，全靠 Trae 的 AI 能力和一套约定好的文件规范，让它在每次我丢进去新内容的时候，自动完成分类、打标签、建立关联、修正格式、更新索引这一整套动作。听起来有点玄乎，但实际跑下来，这套东西是真的能自己转起来的。
这篇文章我会把整个搭建过程拆开讲清楚：为什么选 Trae 而不是别的 AI IDE，AGENTS.md 这个文件到底在里面扮演什么角色，Markdown 文件怎么组织才能让 AI 读得懂，以及我在实际使用中踩过的那些坑。如果你也在找一个"记了就不用管"的知识库方案，这篇应该能给你省不少时间。
1. 为什么我放弃了传统笔记软件，转向 Trae + Markdown
1.1 传统知识库的三个死结
先说说我为什么对传统笔记软件失望。用了三年 Obsidian，插件装了四十多个，双链、图谱、看板、日历视图全配齐了，看起来很美好。但实际使用中，有三个问题始终绕不过去。
第一个是分类僵化。你建文件夹的时候，是按主题分、按时间分还是按项目分？按主题分，一个笔记可能同时属于"AI"和"效率工具"，你只能选一个；按时间分，找的时候又完全想不起来是哪天记的。标签系统看似灵活，但标签一多就失控，最后变成"标签的标签"。
第二个是格式漂移。今天用##做标题，明天觉得###更好看；今天用-列要点，明天用1.编号。三个月后回头看，整个库的格式像被不同的人编辑过一样。手动统一？几百篇笔记改到你想砸键盘。
第三个是关联断裂。你记了一篇关于"提示词工程"的笔记，又记了一篇关于"上下文窗口"的，明明两者强相关，但当时忘了加链接，之后就永远想不起来去补。知识库的价值在于连接，但连接这件事靠人手动做，基本等于不做。
1.2 Trae 吸引我的三个点
Trae 是字节跳动出的 AI IDE，我最初是冲着它的代码补全去的，后来发现它处理 Markdown 文件的能力意外地强。具体来说，有三个点让我决定用它来搭知识库。
第一，它能理解整个项目目录。不像网页版 AI 只能一次看一个文件，Trae 打开一个文件夹后，AI 能看到目录结构、文件之间的引用关系、甚至 git 历史。这意味着我让它"整理一下这个知识库"，它是真的能看到全貌的，而不是盲人摸象。
第二，AGENTS.md 这个机制太适合做知识库规范了。你可以在项目根目录放一个 AGENTS.md 文件，里面写清楚这个项目的规则、约定、工作流程。Trae 每次执行任务前会先读这个文件，相当于给 AI 发了一本"员工手册"。知识库的分类规则、标签体系、格式要求，全写进去，AI 就按这个来。
第三，它支持自定义工作流。我可以把"新增笔记后自动执行整理"这件事做成一个可复用的指令，每次丢完新内容，一句话触发，剩下的它自己跑。
1.3 这套方案到底"自我维护"在哪
说"自我维护"不是噱头，具体体现在四个环节。
入库自动分类：我把一篇新笔记丢进inbox/文件夹，触发整理指令后，Trae 会读内容，判断它属于哪个主题域，移动到对应的notes/子目录，并重命名成规范格式。
标签自动生成与去重：AI 根据内容提取关键词作为标签，同时检查现有标签库，避免出现"AI"和"人工智能"这种同义不同名的标签。
关联自动建立：AI 扫描全库，找出与新笔记内容相关的已有笔记，在双方文件里都加上双向链接。
索引自动更新：每次整理完，自动更新根目录的INDEX.md，按主题、按时间、按标签三个维度生成导航。
整个过程我不写代码，只维护 AGENTS.md 里的规则。规则改一次，之后所有整理都按新规则来。
2. AGENTS.md：让 AI 真正"懂"你知识库的那份说明书
2.1 AGENTS.md 到底是什么，为什么它比提示词更重要
很多人用 AI 工具的习惯是每次对话都重新描述一遍需求："帮我整理一下这个文件夹，按主题分类，标签用中文，格式统一成……"说一次两次还行，说一百次就是折磨。而且每次描述可能有细微差别，导致 AI 的输出也不稳定。
AGENTS.md 解决的就是这个问题。它是一个放在项目根目录的 Markdown 文件，Trae 在执行任何任务前会自动读取它。你可以把它理解成给 AI 看的"项目宪法"——里面写清楚这个项目是干什么的、目录怎么组织、文件怎么命名、格式有什么要求、遇到不同情况该怎么处理。
关键区别在于：提示词是临时的，AGENTS.md 是持久的。你把规则写进去一次，之后所有操作都自动遵循，不用重复交代。而且因为它是文件，你可以用 git 管理它的版本，改了什么、为什么改，都有记录。
2.2 我这份 AGENTS.md 的完整结构
下面是我实际在用的 AGENTS.md 的核心内容，做了脱敏处理，你可以直接参考这个结构。
# 知识库管理规范 ## 项目定位 这是一个个人知识库，用于沉淀技术笔记、阅读摘要和项目复盘。 所有内容以 Markdown 格式存储，通过 AI 辅助进行自动整理和维护。 ## 目录结构 - inbox/ 新内容入口，未经整理 - notes/ 已整理的正式笔记，按主题域分子目录 - tech/ 技术相关 - reading/ 阅读笔记 - project/ 项目复盘 - life/ 生活杂记 - archive/ 归档内容，不再活跃但保留 - INDEX.md 总索引，自动生成 - TAGS.md 标签库，自动维护 ## 文件命名规范 格式：YYYY-MM-DD-简短标题.md 标题用中文，不超过20字，不含特殊符号。 示例：2024-03-15-提示词工程入门.md ## 标签规范 - 标签用中文，2-6个字 - 每篇笔记3-5个标签 - 优先复用 TAGS.md 中已有标签 - 新增标签需在 TAGS.md 中登记 ## 格式规范 - 一级标题用 ##，二级用 ### - 列表统一用 - - 代码块必须标注语言 - 表格前后空一行 - 文末不加总结性段落 ## 整理工作流 当收到"整理 inbox"指令时： 1. 读取 inbox/ 下所有文件 2. 逐篇分析内容，确定主题域 3. 按命名规范重命名，移动到对应目录 4. 提取标签，检查 TAGS.md 去重 5. 扫描 notes/ 找出相关笔记，建立双向链接 6. 更新 INDEX.md 和 TAGS.md 7. 清空 inbox/这份文件大概两百行，但它是整个知识库能"自转"的核心。我后面所有的操作，本质上都是在触发这份文件里定义的工作流。
2.3 写 AGENTS.md 时最容易犯的三个错
第一个错：规则写得太抽象。比如写"标签要合理"，AI 根本不知道什么叫合理。要写成"每篇3-5个标签，用中文，优先复用已有标签"，它才能执行。规则必须是可判断、可执行的，不能是主观描述。
第二个错：忘了写"例外情况"。比如我有一篇笔记同时涉及技术和阅读，按规则该放 tech 还是 reading？后来我在 AGENTS.md 里加了一条："跨主题内容优先放入 tech/，并在 reading/ 中建立引用。"这种边界情况不写清楚，AI 每次处理的结果都不一样。
第三个错：规则和实际目录不一致。我一开始在 AGENTS.md 里写了notes/tech/，但实际建目录时手滑建成了notes/technology/，结果 AI 整理时找不到目标目录，直接把文件丢在根目录。这种低级错误排查起来很费时间，建议写完 AGENTS.md 后对照实际目录检查一遍。
提示：AGENTS.md 不是写完就一劳永逸的。我大概每两周会回顾一次，把新遇到的边界情况补进去。它应该是一个活的文档，跟着你的知识库一起成长。
3. Markdown 文件怎么组织，才能让 AI 读得懂、改得动
3.1 为什么 Markdown 是 AI 时代知识库的最优格式
有人问为什么不用 Word 或者富文本。原因很简单：Markdown 是纯文本，AI 处理起来没有歧义。Word 文档里一个加粗可能是<strong>也可能是<b>，还可能是样式表定义的，AI 解析起来要处理一堆兼容性问题。Markdown 就是**加粗**，所见即所得，AI 读写都不会出错。
另外 Markdown 天然适合版本管理。每次 AI 修改后，git diff 能清楚看到改了哪几行，出问题可以回滚。富文本格式的 diff 基本没法看。
还有一个实际的好处：Markdown 的表格、代码块、链接这些结构，AI 理解起来非常准确。我让 Trae 从一篇笔记里提取所有代码示例，它从来没出过错，因为代码块有明确的 ``` 标记。
3.2 我的笔记模板长什么样
为了让 AI 整理时有一致的输入，我定了一个笔记模板。新笔记丢进 inbox 时，尽量按这个格式来，AI 处理起来会顺畅很多。
## 核心内容 （正文，分段写，每段不超过6行） ## 关键要点 - 要点1 - 要点2 ## 相关链接 （留空，由 AI 整理时填充） ## 标签 （留空，由 AI 整理时填充）这个模板的好处是，AI 知道去哪里找正文、去哪里填链接和标签。如果笔记格式完全自由，AI 每次都要先猜结构，效率和准确率都会下降。
当然，不是所有笔记都能套模板。比如我从网页剪藏的片段，格式五花八门。这种情况我会在 AGENTS.md 里加一条规则："对于非模板格式的笔记，AI 先做格式归一化，再执行整理流程。"
3.3 文件命名和目录划分的实操细节
文件命名我踩过坑。一开始用英文命名，比如prompt-engineering-basics.md，后来发现中文标题在搜索时更直观，改成了2024-03-15-提示词工程入门.md。日期前缀的好处是文件按时间自然排序，找"上个月记的那篇"时特别方便。
目录划分我调整过三次。最初按"技术/非技术"分，太粗；后来按具体技术栈分，太细，很多笔记跨栈。最后定下来按"用途"分：tech（技术学习）、reading（阅读摘要）、project（项目复盘）、life（生活杂记）。这个粒度刚好，AI 判断起来也不纠结。
有一个细节值得说：目录不要超过两层。我试过notes/tech/frontend/react/这种三层结构，结果 AI 经常放错层级，而且我自己找文件时也要点好几次。两层足够，再细的分类交给标签。
3.4 表格和代码块的处理技巧
知识库里难免有表格。Markdown 表格的语法对 AI 很友好，但有个坑：表格前后必须空行，否则某些渲染器会把表格和正文混在一起。我在 AGENTS.md 里专门写了这条规则，AI 整理时会自动补空行。
代码块的处理更简单，只要标注语言类型，AI 就能正确识别。我有个习惯，代码块里的注释用中文写，这样 AI 提取要点时能直接理解代码意图，不用猜。
# 计算两个日期之间的工作日天数 def workdays_between(start, end): # 省略实现 pass像上面这样，AI 看到注释就知道这段代码是干什么的，整理时能生成准确的摘要。
4. 从"丢进去"到"整理好"：一次完整的自动化流程拆解
4.1 触发整理：一句话启动整个工作流
我的日常操作是这样的：看到有价值的内容，复制粘贴到 Trae 里，让它生成一篇笔记草稿，保存到inbox/。攒够三五篇后，在 Trae 的对话框里输入一句"整理 inbox"，然后就可以去干别的了。
Trae 会读取 AGENTS.md，按里面定义的工作流一步步执行。整个过程大概需要一到两分钟，取决于笔记数量和全库大小。整理完成后，inbox 文件夹清空，新笔记出现在对应的 notes 子目录里，INDEX.md 和 TAGS.md 也更新了。
这里有个小技巧：不要一篇一篇整理。单篇整理时，AI 能关联到的已有笔记有限，建立的双向链接质量不高。攒几篇一起整理，AI 能在新笔记之间也建立关联，效果更好。
4.2 AI 在整理时到底做了哪些判断
我观察过 Trae 整理时的"思考过程"，大致分这么几步。
第一步是内容理解。它读一篇笔记，判断主题是什么。比如一篇讲"如何写系统提示词"的笔记，它识别出关键词是"提示词""系统""LLM"，主题域归到 tech。
第二步是分类决策。根据 AGENTS.md 里的目录定义，决定放哪个子目录。如果内容跨域，按预设的优先级规则处理。
第三步是标签提取。从内容里提取3-5个关键词，然后去 TAGS.md 里比对。如果已有"提示词"标签，就不会新建"prompt"标签。这一步的去重逻辑很关键，不然标签库很快就乱了。
第四步是关联发现。它扫描 notes/ 下所有文件，找出内容相关的。判断依据包括标签重合度、关键词出现频率、甚至语义相似度。找到相关笔记后，在双方文件里都加上链接。
第五步是索引更新。重新生成 INDEX.md，按主题、时间、标签三个维度列出所有笔记。
这五步里，最耗时的是第四步，因为要扫描全库。我的库现在有三百多篇笔记，扫描一遍大概二十秒，可以接受。
4.3 整理结果长什么样：一个真实案例
拿我最近整理的一篇笔记举例。原始内容是我从一篇技术文章里剪藏的，讲的是"上下文窗口管理策略"，格式很乱，有中英文混杂，还有几段没头没尾的代码。
整理后，文件变成了notes/tech/2024-03-20-上下文窗口管理策略.md，内容结构化了：核心内容分了三段，关键要点提取了四条，标签是"LLM""上下文""提示词""性能优化"，相关链接指向了另外三篇笔记——"提示词工程入门""Token计算原理""长文本处理方案"。
INDEX.md 里，这篇笔记同时出现在"技术"分类下和"LLM"标签下。TAGS.md 里，"上下文"这个标签的引用计数加了一。
整个过程我没有手动改任何东西，只说了句"整理 inbox"。
4.4 整理后的验证：怎么确认 AI 没搞错
完全信任 AI 是不行的，我每次整理完会花两分钟做抽查。
看分类对不对：随机点开两三篇，确认目录放对了。放错的概率大概5%，主要是跨主题内容。
看标签有没有重复：打开 TAGS.md，扫一眼有没有"AI"和"人工智能"这种同义标签。有的话手动合并，然后在 AGENTS.md 里加一条去重规则。
看链接是否合理：点开几篇笔记的"相关链接"，确认指向的笔记确实相关。偶尔会出现关联牵强的情况，手动删掉就行。
看格式是否统一：抽查几篇，看标题层级、列表符号、空行是否一致。不一致的地方，说明 AGENTS.md 里的格式规则还不够细，补上。
这个抽查流程听起来麻烦，但熟练后两分钟搞定，比手动整理一篇笔记还快。
5. 让知识库"活"起来：标签体系与双向链接的自动维护
5.1 标签去重：一个必须自动化的环节
标签体系最大的敌人是同义词。你今天记"AI"，明天记"人工智能"，后天记"机器学习"，三个标签指向同一类内容，但搜索时只能命中一个。手动维护？不可能，你根本记不住自己用过哪些标签。
我的做法是在 AGENTS.md 里定义一套标签合并规则，让 AI 自动执行。
## 标签合并规则 - AI / 人工智能 / 机器学习 → 统一用 "AI" - 提示词 / prompt / 提示工程 → 统一用 "提示词" - 大模型 / LLM / 大语言模型 → 统一用 "LLM" - 效率 / 生产力 / 效率工具 → 统一用 "效率工具"每次整理时，AI 提取标签后会先过一遍这个规则表，把同义标签归一化。新增标签时，也会检查是否和已有标签语义重复。
这套规则我维护了大概三十条，覆盖了常见的技术和生活类标签。新出现的同义词，我发现了就补进去，规则表越来越完善，标签库也越来越干净。
5.2 双向链接的自动建立逻辑
双向链接是知识库的灵魂，但手动加链接基本等于不加。我让 AI 自动做这件事，逻辑是这样的。
基于标签匹配：如果两篇笔记有2个以上相同标签，建立链接。这是最基础的匹配。
基于关键词共现：扫描笔记正文，如果两篇笔记都频繁出现某几个相同的关键词（排除停用词），建立链接。
基于显式引用：如果笔记A里提到了笔记B的标题，自动在B里加上指向A的反向链接。
基于语义相似：这个最复杂，Trae 会用嵌入模型计算笔记之间的语义相似度，超过阈值的建立链接。实际用下来，这一条的准确率大概七成，偶尔会有牵强的关联，但整体可接受。
四种逻辑叠加，一篇新笔记整理完，通常能自动关联到3-8篇已有笔记。这个数量刚好，太多会稀释相关性，太少又起不到连接作用。
5.3 INDEX.md 的三种视图
INDEX.md 是知识库的门面，我让它自动生成三种视图。
按主题：列出所有目录和其中的笔记，适合系统性浏览。
按时间：按日期倒序列出最近整理的笔记，适合回顾近期输入。
按标签：列出所有标签及其下的笔记，适合按兴趣探索。
三种视图各有用途，我平时用得最多的是按标签，因为标签最能反映内容之间的隐性关联。
INDEX.md 的生成也是自动的，每次整理完 inbox 后重建。文件不大，三百篇笔记的索引大概两百行，加载很快。
5.4 定期"体检"：让 AI 找出知识库的病灶
除了日常整理，我每个月会让 Trae 做一次"知识库体检"。指令很简单："检查知识库，找出以下问题：孤立笔记（没有任何链接指向）、重复内容、过期信息、标签异常。"
AI 会扫描全库，生成一份体检报告。我处理过的问题包括：十几篇孤立笔记（后来手动加了链接或合并）、三组重复内容（合并了）、一批过期信息（移到 archive/）、几个异常标签（合并了）。
这个体检流程让知识库保持健康。没有它，库会慢慢腐化，链接失效、内容重复、标签混乱，最后又变成"知识坟场"。
6. 实测中踩过的坑和对应的解法
6.1 坑一：AI 把文件放错目录
现象：一篇明显是技术类的笔记，被放进了 reading/ 目录。
排查过程：我打开 AGENTS.md 检查目录定义，发现 tech/ 的描述是"技术相关"，reading/ 是"阅读笔记"。这篇笔记确实是从一篇文章里读来的，AI 可能因此判断为阅读笔记。
根因：目录描述太模糊，没有明确的判断优先级。
解法：在 AGENTS.md 里加了一条："内容主题优先于内容来源。从文章读来的技术内容，归 tech/ 而非 reading/。"之后这类错误基本消失了。
6.2 坑二：标签越整理越多
现象：整理了几十篇笔记后，TAGS.md 里出现了两百多个标签，很多只用过一次。
排查过程：我检查了标签提取逻辑，发现 AI 倾向于从内容里提取具体名词作为标签，导致标签过于细碎。
根因：缺少标签数量的约束和复用优先的规则。
解法：在 AGENTS.md 里明确："每篇笔记3-5个标签，优先复用 TAGS.md 中引用次数大于3的标签。新增标签需在 TAGS.md 中登记，且每月清理引用次数为1的标签。"标签库稳定在了八十个左右。
6.3 坑三：双向链接指向了不相关的内容
现象：一篇讲"数据库索引"的笔记，关联到了一篇讲"文件索引"的笔记，两者其实没什么关系。
排查过程：发现是关键词共现逻辑导致的，两篇笔记都频繁出现"索引"这个词，但语境完全不同。
根因：关键词匹配没有考虑语境。
解法：把关键词共现的权重调低，语义相似度的权重调高。同时在 AGENTS.md 里加了一条："关联笔记需同时满足标签重合或语义相似，单纯关键词共现不作为关联依据。"
6.4 坑四：整理速度越来越慢
现象：知识库到两百篇以后，每次整理要等三四分钟。
排查过程：发现瓶颈在全库扫描环节，AI 每次都要读所有文件来计算关联。
根因：没有增量更新机制，每次都全量处理。
解法：在 AGENTS.md 里加了缓存规则："关联计算时，优先扫描最近30天更新的笔记，全库扫描每周执行一次。"整理速度回到了半分钟以内。
6.5 坑五：格式规则执行不一致
现象：有的笔记用-列要点，有的用*，有的用1.。
排查过程：检查 AGENTS.md，发现格式规则写的是"列表统一用 -"，但 AI 有时会忽略。
根因：规则不够显眼，且没有验证环节。
解法：把格式规则移到 AGENTS.md 的开头部分，并在整理工作流里加了一步"格式校验"。AI 整理完会自查一遍格式，不一致的自动修正。
7. 关于这套方案，我的一些真实体会
跑了三个月，知识库从零长到三百多篇，我最大的感受是：AI 整理的质量，取决于你给它的规则有多清晰。同样的 Trae，同样的 Markdown，AGENTS.md 写得细不细，结果天差地别。我前两周的整理结果惨不忍睹，后来花了一个周末把 AGENTS.md 重写了一遍，之后基本就没怎么手动干预过了。
另一个体会是，不要追求一步到位。我一开始想把所有规则都写全，结果写了两百多条，AI 反而执行混乱。后来精简到核心的三十条，剩下的边用边补，效果好很多。规则这东西，够用就行，多了是负担。
还有一点，定期体检比日常整理更重要。日常整理保证新内容入库，体检保证老内容不腐化。我现在的节奏是每天整理一次 inbox，每月体检一次全库，这个频率刚刚好。
最后说个实际的：这套方案不适合所有人。如果你只是偶尔记几笔，用手机备忘录就够了，没必要折腾。但如果你像我一样，每天有大量信息输入，又想让它们真正沉淀下来形成体系，那这套"AI 自维护知识库"的思路值得试试。核心不是 Trae 这个工具，而是"用规则驱动 AI 自动维护"这个模式——工具会换，模式可以一直用。
