前段时间，我重新整理了一遍自己的资料。
里面有上千篇过去写过的文章，还有项目记录、聊天内容、网页收藏、AI 对话、选题、复盘和各种临时想法。
文件很多，但真到写文章的时候，还是经常找不到。
有些内容我明明写过，想不起来放在哪里；有些项目踩过坑，下一次又重新踩一遍；还有不少选题散落在几十个文档里，记完就再也没有打开。
我以前也用过不少笔记工具。它们解决了"把东西存进去"的问题，却没有解决另外几个更现实的问题：
- 资料进来以后放哪里？
- 原文、笔记和准备发布的文章怎么区分？
- AI 怎么知道哪些能改，哪些不能动？
- 写新文章时，怎么让过去积累的资料真正参与进来？
- 换一个 AI 工具以后，这套系统还能不能继续用？
后来我用 Obsidian 管文件，再让 Codex、WorkBuddy 这类 Agent 直接操作知识库，才慢慢搭出现在这套系统。
它不是一个装满笔记的仓库。
它更像一个本地内容工作台：资料可以进来，AI 可以整理，人负责判断，最后还能继续产出文章。
这篇我会从零开始，把安装、目录、规则、AI 接入和内容工作流全部拆开讲一遍。
如果你只想抄一个能马上使用的版本，照着前半部分操作就够了。后半部分是我自己用了一段时间后，逐渐补上的进阶做法。
一、先说清楚：Obsidian 和 AI 各自负责什么
这套系统最容易被误解的地方，是把它当成"在 Obsidian 里装一个 AI 插件"。
我做的不是这个。
在我的系统里，Obsidian 和 AI 是两层：
Obsidian 是文件和知识层。 文章、项目、素材、规则、日志，本质上都是本地 Markdown 文件。即使某一天某个 AI 工具不能用了，这些文件仍然在我的电脑里，可以继续搜索、编辑和迁移。
Codex、WorkBuddy、TRAE 这类 Agent 是操作层。它们可以读取一个文件夹里的内容，根据规则搜索资料、修改 Markdown、创建文章、运行脚本、检查链接。
所以，真正重要的不是一定要用哪一个 AI，而是满足下面三个条件：
- 能打开或访问你的知识库目录；
- 能读取和修改本地 Markdown 文件；
- 能遵守项目里的长期规则。
我现在会用 Codex，也用过 WorkBuddy。你也可以换成 TRAE、Claude Code，或者其他具备本地文件操作能力的 Agent。
==工具可以换，知识库的目录、规则和内容资产不要跟着工具一起换。==
二、第一步：安装 Obsidian，建立本地知识库
Obsidian 官网：https://obsidian.md/download
下载安装后，第一次打开会看到创建仓库的入口。Obsidian 把一个知识库文件夹叫作 Vault。
点击"创建新仓库"，给它起一个名字，再选择本地保存位置
建议不要一开始放进层级很深的目录，也不要使用一个随时会被清理的临时文件夹。
创建完成后，你在 Obsidian 里写的每一篇笔记，其实都是这个文件夹里的 .md 文件。图片也是普通图片文件。
这也是我选择 Obsidian 的主要原因：
- 数据在本地；
- 文件格式简单；
- 不绑定某个笔记平台；
- AI 和脚本容易读取；
- Git、网盘和移动硬盘都可以备份。
三、第二步：搭建五层目录
很多知识库后来变乱，不是因为文件太多，而是不同性质的内容混在了一起。
收藏的外部文章、自己写的原稿、提炼出的观点、待发布文章和系统规则，全都放在同一层。时间一长，人和 AI 都不知道哪个才是可以相信的版本。
我现在使用的是下面五层结构：
00_Inbox：临时收集箱
刚收进来、还没有判断放在哪里的内容，先放这里。例如：一张截图、一段聊天记录、一个临时想法、刚导出的飞书文档、还没来得及处理的网页内容。
Inbox 的作用是降低收集门槛，但不能变成永久垃圾场。我会定期让 AI 检查这里的内容：该归档的归档，该提炼的提炼，没有长期价值的只保留原始记录。
01_Sources：原始资料
Sources 保存原文和证据。例如：我过去写过的完整文章、项目原始记录、AI 对话、用户反馈、外部文章、课程笔记、原始截图。
这里最重要的规则是：尽量保留原貌，不要让 AI 为了"整理得更漂亮"擅自改写原文。 因为你以后写文章、复盘项目或者检查事实，最后都要能回到原始资料。
02_Wiki：提炼后的长期知识
Wiki 不保存一篇又一篇完整文章，而是保存可以反复使用的东西。
例如，我做完一个小程序，不会把整个开发日志复制进 Wiki，而是提炼成：这个项目解决了什么问题、哪些做法有效、哪些坑下次不要再踩、哪些案例以后可以写进文章、哪些判断已经被真实数据验证。
03_Output：准备对外发布的内容
Output 放正在生产和准备发布的东西：公众号文章、X 帖子、小红书笔记、视频口播稿、课程大纲、产品方案。
这里可以继续细分成：待发布、已发布、发布素材、运营记录。
这样，原始资料不会和文章草稿混在一起，不同平台版本也不会互相覆盖。
04_System：系统规则
这个目录不放业务内容，放系统本身：AI 操作说明、目录规则、写作风格、模板、索引、操作日志、脚本说明。
它相当于知识库的说明书。
四、第三步：让 AI 进入知识库
Obsidian 准备好以后，接下来需要一个能操作本地文件的 AI Agent。
这里不展开做某一个工具的完整安装教程，只讲接入思路。
方案一：Codex
Codex 适合把整个知识库目录作为一个工作区打开，然后直接让它搜索、读取和修改文件。
使用时，把刚才创建的 Vault 根目录作为工作目录。第一次不要直接说"帮我整理整个知识库"，而是给一个边界清楚的小任务：
把 00_Inbox 里的 2026-05-27_参加AI出海大会.md 拆成：
- 原文（01_Sources）
- 素材提炼（02_Wiki/素材库）
- 增加一个选题卡（03_Output/00_选题库）先确认它能找到文件、理解规则，再逐渐让它执行写入。
方案二：WorkBuddy
WorkBuddy 更偏桌面 AI 助手，适合不想经常使用命令行的人。
你可以给它指定本地项目或知识库目录，再让它处理文档、建立笔记、运行重复任务。我自己使用时，比较看重的是它能直接处理电脑里的文件，而不是只在聊天框里给一段答案。
方案三：TRAE 或其他 Agent 编辑器
TRAE、Claude Code 等工具也可以使用同样的方法。
核心动作只有一个：打开知识库根目录，让 Agent 看到规则文件和 Markdown 内容。
不同工具的按钮、权限提示和模型选择会变化，但知识库本身不需要重建。
五、第四步：给 AI 写一份说明书
只让 AI 看到文件夹还不够。
没有规则时，AI 很容易做出一些"看起来很勤快，实际上很麻烦"的事情：
- 全量扫描所有文件，浪费时间；
- 把完整文章塞进 Wiki；
- 遇到相似主题就创建新页面；
- 为了格式统一改写原始资料；
- 输出一篇文章，却不更新选题和状态；
- 在错误的目录里再建一套新系统。
我的做法是在根目录放三类入口文件。
1. AGENTS.md：长期操作规则
它告诉 Agent 这个项目是什么、目录怎么用、哪些事不能做。一个最小版本可以这样写：
# 知识库名称
## 目录结构
00_Inbox = 待处理
01_Sources = 原始资料（不修改原文）
02_Wiki = 提炼后的长期知识
03_Output = 准备发布的内容
04_System = 系统规则和说明
## 规则
- 不修改 01_Sources 里的原文；
- 新增 Wiki 页面时，先检查是否有同类主题；
- 每次操作后，在操作日志里记录做了什么。2. SOURCE_OF_TRUTH.md：谁才是最新规则
系统用久以后，最麻烦的不是没有文档，而是同一件事有三份文档，彼此还不一致。
所以我增加了一份"真源说明"：
当前项目状态：2026-06 正在运行
最新规则文件：AGENTS.md
如果 AGENTS.md 和以下文件冲突，以 AGENTS.md 为准：
- README.md（可能已过时）
- docs/（部分已不适用）
- 其他 Skill 文件这份文件的作用，是防止 AI 看见旧说明后继续按旧流程工作。
3. AI-START.md：每次从哪里开始
AI-START 不需要写得很长，只负责导航：
# 开始工作前
1. 先读取 AGENTS.md 了解规则
2. 检查 00_Inbox 是否有新内容
3. 检查 03_Output/00_选题库 是否有待处理选题
4. 检查 03_Output/01_待发布 是否有可以发布的文章这三份文件看起来多了一点，但它们解决的是三个不同问题：
- AGENTS：平时怎么做；
- SOURCE_OF_TRUTH：冲突时信谁；
- AI-START：每次从哪里开始。
提示词只解决一次对话，规则文件才会逐渐变成长期协作方式。
六、第五步：先跑通一个最小任务
不要刚搭好目录，就把几千篇旧文章全部扔给 AI。
先拿一份普通资料做测试。例如，在 00_Inbox 里放一篇你过去写的文章，然后让 Agent：
1. 读取 00_Inbox 里的文章；
2. 提炼关键观点（300 字以内），放入 02_Wiki/素材库；
3. 新增一个选题卡到 03_Output/00_选题库/；
4. 在 04_System/log.md 记录这次操作；
5. 将原文移动到 01_Sources/下对应目录；
6. 清空 Inbox。执行完成后，人工检查四件事：
- 原文有没有被改坏；
- Wiki 里是不是只留下了可复用内容；
- 有没有重复创建同义页面；
- 日志和来源链接是否完整。
这一步通过以后，再批量处理。
AI 知识库最怕的不是 AI 不够聪明，而是错误流程一次执行几百遍。 先用一个文件验证，再扩大到十个，最后才是批量。
七、第六步：搭建一条内容工作流
目录和规则都只是基础。
真正让我觉得这套系统有用的，是过去积累的内容开始重新参与写作。
内容工作流流程图
1. 收集：先保存，别急着提炼
看到一篇好文章、一个案例或者一段对话，先进入 Inbox。如果是外部内容，要记录公开链接、作者和时间。如果是自己的内容，保留原始版本，尤其不要让 AI 覆盖。
2. 提炼：不要只让 AI 写摘要
"帮我总结一下"通常只能得到一份更短的原文。更有用的问法是：
这篇内容里，哪些是我以前不知道的？
哪些可以做选题？
有没有可以验证或推翻的判断？
哪些做法对我当前的项目有用？这样提炼出来的东西，才适合进入 Wiki。
3. 选题：不要让选题散落在几十个文件里
我的选题库会给每个选题一个状态：待判断、待写、已成稿、已发布、暂停、不做。
除了标题，还会记录：写给谁、解决什么问题、为什么由我来写、可用素材、发过哪些平台、发布链接、阅读/点赞/收藏/咨询等数据。
这样，AI 下次推荐选题时能先检查"有没有写过、发过"，不会换个标题又推荐一遍。
4. 写作：先找自己的材料，再生成正文
确认一个选题以后，不要马上让 AI 凭空写。先让它搜索：
- 自己过去写过的相关文章；
- 相关项目；
- 真实数据；
- 反面案例；
- 已经发布过的同类内容；
- 写作风格和反感表达。
你会发现，文章质量真正拉开差距的地方，不是模型会不会写，而是它能不能找到只属于你的材料。
5. 成稿：自动分段、加小标题和重点
我的旧文章不少是连续长段落，直接搬到公众号阅读体验很差。所以在成稿环节，我会让 AI 做这些机械工作：
- 增加自然的小标题；
- 把过长段落拆开；
- 检查是否缺少前置条件和步骤；
- 给重要结论加粗；
- 给关键数字、风险和操作条件做重点标记；
- 检查 AI 套话；
- 列出需要补充的真实截图。
但重点不能满屏都是。观点文重点标判断、反差和行动结论；实操文重点标参数、风险、关键步骤和验收结果。全文到处加粗，等于什么都没有强调。
6. 发布：Markdown 只是内容母版
Markdown 确认以后，再转换成公众号 HTML，生成封面、正文知识卡片和发布素材。
这个阶段要人工检查：标题和摘要、封面、正文图片、手机端段落、重点颜色、外部链接、原创声明、是否真的进入草稿箱、是否已经公开发布。
进入草稿箱不等于已发布。 正式公开以后，再更新发布日期、链接和数据，避免系统错误地把草稿当成历史文章。
7. 回流：发布不是结束
一篇文章发布以后，评论和数据会继续产生新材料：
- 大量读者在同一个步骤卡住，说明教程缺了一段；
- 某个案例被频繁转发，说明它适合继续扩写；
- 有人因为文章来咨询，说明这个问题有真实需求；
- 数据很差，也可能说明标题、切入角度或目标人群出了问题。
这些信息可以继续进入 Sources，再提炼回 Wiki 和选题库。
这时，知识库才不是一个只进不出的收藏夹。
八、把重复工作做成 Skill 或脚本
当一个流程已经稳定执行过几次，就不要每次重新写一大段提示词。
适合做成 Skill 的事情
Skill 更像给 AI 的专项操作手册，适合需要判断的流程：
- 如何处理一篇新资料；
- 如何筛选旧文章；
- 如何检查同题重复；
- 如何写公众号观点文；
- 如何把文章转换成技术实操文；
- 发布后需要更新哪些状态。
适合做成脚本的事情
脚本适合规则非常明确、重复率很高的动作：
- 批量改文件名；
- 生成选题面板；
- 检查失效链接；
- Markdown 转公众号 HTML；
- 上传正文图片；
- 同步到 Notion；
- 更新发布状态和日志。
我的判断标准很简单：需要理解上下文和做判断的，交给 Agent；可以明确写成输入输出的，交给脚本。
不要为了显得高级，把所有事情都自动化。涉及删文件、公开发布、覆盖原文、修改大批量资料的操作，最好保留人工确认。
九、日常怎么使用和维护
系统搭好以后，不需要每天维护半小时。
每天
临时资料先进 Inbox；正在写的内容放 Output；不在收集时纠结每一条资料的最终归属。
每周：清理一次 Inbox；检查待写选题；合并重复主题；看看是否有文章状态没有更新。
每月：复盘发布数据；检查哪些 Wiki 页面被真正使用过；清理失效链接；更新 AI 规则和写作偏好；备份整个 Vault。
备份：本地文件不等于自动安全。至少选择一种备份方式：Obsidian Sync、Git 私有仓库（我用的这个，有大量更新就提交到 GitHub）、可靠的网盘同步、定期复制到移动硬盘。
如果知识库里有 API Key、Cookie 或平台密钥，不要直接写进普通 Markdown，更不要提交到公开 Git 仓库。使用本地环境变量或被 Git 忽略的配置文件。
以上就是最近一个月使用 Obsidian + Codex 搭建 AI 内容知识库的经验，希望对你有帮助。