Grok Bot + Obsidian：搭建你专属的知识库

从笔记数量转向知识质量

打开 Obsidian 时，库里已有 5661 篇笔记。这个数字曾像一项积累成果，后来更像需要查看的体检指标：笔记很多，并不等于想法已经整理清楚。一个多月的实践围绕一个问题展开：怎样让 Grok Bot 帮忙发现联系、整理资料，同时避免自动化继续制造空壳和噪声。

这份实践把 Grok Bot 作为协作助手，把本机 Obsidian 作为长期知识库，并用提示词和 Skills 固定重复流程。重点不是让 Bot 尽可能多地操作，而是先界定它能读什么、能写到哪里，以及哪些操作必须等待确认。

先只读诊断，再决定怎么整理

9 月 17 日的一次只读检查统计了约 5488 篇 Markdown 笔记。根目录近四成几乎是空壳，未解析链接约八千条。检查只呈现库的现状，没有修改、移动或删除文件。结果提示，问题不只是链接断裂，也包括收集很多、却没有继续思考和整理。

请对整个库进行一次只读诊断，全程不修改、移动或删除文件。统计 Markdown 文件总数及根目录篇数；根目录中小于 50 字节的短桩数量和占比；未解析链接数量；中枢笔记各自的反链数。先输出数字，再用一句话概括主要问题，不给出治疗方案。不要建议批量创建空白页补断链。心情、焦虑和语音日记等隐私闪念跳过，不统计内容。

先用诊断理解现状，再决定是否采取行动。单次体检可以告诉人们问题在哪里，却不能代替逐条阅读、判断和写作。

把操作边界写成明确规则

整理过程中确立了几条底线：笔记以文件形式保存在自己的库中，工具可以更换；Bot 的产出集中放进 AI outputs/，不混入本人撰写的区域；从 flomo 导入的闪念保持原子记录，不合并、不改写；属性遵循库中既有词汇，能不增加就不增加。

涉及批量删除、修改、移动或加链的操作，先列出清单并等待确认。隐私闪念默认跳过，不擅自发布或部署；对外内容只陈述实际经历，不把未做过的事写成做过。边界越明确，后续会话越容易按同一规则协作。

你是我的 Obsidian 助手，请遵守以下规则：剪藏必须保留可用正文，不要只留下摘要或概念词；你的产出只写入 AI outputs/；导入内容保留双链；不要为断链批量创建空白页；重大删除、批量修改、移动或加链前，先列清单并等我确认；对外稿只写我实际做过的事。

让 flomo 与 Obsidian 各司其职

这套流程把 flomo 用作快速记录闪念和短内容的入口，把本机 Obsidian 用作保存长文剪藏、常青笔记、目录和双链网络的知识库。两边承担不同任务，避免把每条即时想法都自动扩写成文章，也避免需要长期保存的正文只停留在短记工具中。

文件夹约定保持简单：库根目录放本人写作，Clippings/ 保存他人原文，AI outputs/ 存放 AI 生成内容。按任务分工的 Bot 各自处理 Obsidian、flomo 或调度工作；遇到职责交叉时，再由调度流程协调。无论工具如何安排，最终都要遵守相同的文件边界和确认规则。

逐步完成库的初始化

首次搭建时，把装机过程设计成逐题确认：先确定双方称呼，再了解闪念工具的连接状态、Obsidian 库路径、文件夹约定和权限边界，最后安排一个可立即检查结果的小任务。每次只问一个问题，等回答确认后才继续，并把最终约定写入下一次会话也能读取的规则。

请带我完成一次数字花园初始化，一次只问一个问题，等我回答后再继续。依次确认：我如何称呼你、闪念工具接入到哪一步、Obsidian 库的本机路径、根目录与 Clippings/、AI outputs/ 的用途，以及隐私跳过、批量操作须先确认、不擅自发布部署、对外稿只写亲身经历等边界。最后给我一个能马上检查结果的小任务。每一步确认后，把结论写入后续会话可读取的规则。

用命令行减少全库扫描

初始化后打通 Obsidian CLI，能够直接检查标签、中枢笔记反链和库内状态，减少为了解答简单问题而反复扫描整个目录。排查时曾遇到 macOS 默认文件名大小写不敏感的问题：应用程序目录里有名称相近的图形界面程序和命令行程序，选错路径可能导致命令挂起。确认实际 CLI 后，将它放入已有 PATH 目录，避免为此改动系统级目录。

一次抽检统计了约 174 个标签，并检查两个中枢笔记分别有 13 和 17 条反链。让工具优先使用 CLI、少做全库扫描，也成为初始化规则的一部分。命令行只提供更直接的检查方式，结果仍需结合库的实际内容解释。

定期复查，而不是追逐漂亮数字

11 月 6 日的后续体检约有 5661 篇 Markdown 笔记，比 9 月 17 日增加约 173 篇；未解析链接从约八千降到 4747。根目录约有 4139 篇，其中小于 50 字节的短桩约占三分之一；若按“空壳感”估算，比例约为 43%，与九月底相比变化不大。

链接数量下降了，短桩却没有同步减少。实践记录据此把注意力转向抽样阅读和人工判断：不要先啃完所有断链；短桩先抽样处理；按明确模式清理脏链接；不要批量新建空壳页填补断链。工具能发现和修正链接，不能替人写出尚未想清楚的观点。

用常青笔记模板保留自己的观点

常青笔记模板经过精简后，默认不加 YAML 属性，标题写成完整主张，正文用自己的话表达，尽可能连接库中已有概念，标签保持精简。草稿先进入 AI outputs/。如果一句清楚的主张还写不出来，就先不要把这条想法包装成常青笔记。

请把下面的想法整理成一篇常青笔记草稿，保存到 AI outputs/。默认不加 YAML 属性；标题必须是一句完整主张；正文用我自己的话写，不复述原文；为已有相关概念补上双链；标签尽量少。如果无法写出明确主张，请告诉我这条想法还不适合成为常青笔记。

模板的价值在于让不同会话遵循相同写作习惯。试用时可以用同一份材料反复检查格式和边界，避免为了追求复杂结构加入自己并不想用的字段。

related-notes skill 用于寻找相关笔记，结果不应只是复述刚写下的内容。每条推荐都要说明为什么现在值得一起查看，并且默认不自动添加双链；确认之后再由使用者决定是否建立连接。

我今天的想法是：【写下今天的想法】。请在库中查找相关笔记，每条结果说明为什么值得一起查看。不要只复述我刚写的内容；默认不自动添加双链，等我确认后再修改。

孤儿笔记检查默认只读

orphan-notes skill 负责查找没有双链的笔记，以及可能相关却尚未互链的笔记对。默认只读，不直接清理或补链；删除孤儿和批量添加连接，都先列明候选清单，等待确认后处理。

请扫描库，找出没有双链的笔记，以及可能相关但互相没有连接的笔记对。默认只读，不做任何修改。删除孤儿笔记或批量加链之前，先列出清单并等我确认。

比较自动化方案时先看数据归属

常见做法包括把知识库放在 Bot 可持续访问的云端环境，或把本机 Obsidian 作为长期存储，再将即时闪念交由另一工具处理。前一种方式便于在设备离线时继续运行；后一种方式保留本地 Markdown 文件和双链网络。选择时需要先确定哪些资料必须留在本机、哪些任务需要后台运行，以及是否接受不同工具分别保存不同类型的内容。

另一项实践把工作流规则写进 Bot 的说明中，而不是只留在会话记忆；还有方案会锁定收件目录，并在文件处理后要求提交变更。它们共同强调：职责清楚、规则可持续读取、写入位置明确。具体采用哪种存储和部署方式，应由资料归属和实际工作需求决定。

从一个稳定任务开始

搭建时先选择一只 Bot，把一项具体工作说明白，观察它能否稳定遵守目录、隐私和确认规则。先让同一项任务做对，再考虑自动化或多 Bot 分工。权限不要一开始就全部放开；批量操作、发布和部署都保留明确的确认点。

这套个人库流程不适用于所有场景：只有几百篇笔记时，可以先继续记录；期待一键把整个库整理干净，容易得到更多结构整齐却内容空洞的页面；不愿意先定义目录和权限的人，也很难让 Bot 稳定遵守边界。本机 Obsidian 加闪念工具的分工面向个人知识库，不等同于团队协作方案。

实践最后留下的判断是：收集不是思考，链接数量也不是知识质量。工具可以搬运、搜索和连接资料，关键取舍仍需要使用者自己完成。

使用声明

本指南根据指定材料整理 Grok Bot 与 Obsidian 的个人知识库实践及提示词。案例数字和流程反映材料中的特定使用情境，不代表通用效果或适用于所有人的配置。执行前应按自己的文件结构、隐私要求和工具环境确认权限，并在批量操作前检查清单。