将 Obsidian Markdown 连接至 Claude Code，打造自动化工作引擎

从清理 Web Clipper 抓取的垃圾数据开始

从网上抓取的 Markdown 文件通常充斥着广告和菜单栏等噪声。如果混入这些文本，RAG（检索增强生成）的性能会显著下降。实际上，未经整理的数据会分散模型的注意力，而整洁的 Markdown 则能提高检索准确度。剔除冗余文本后，本地 LLM 消耗的 Token 也能减少 30% 以上，省下不少开支。

我们需要使用 Python 的 BeautifulSoup 库来剔除这些噪声：

1. 在终端输入 pip install beautifulsoup4 lxml 来搭建环境。
2. 在脚本中使用 decompose() 方法将 .ad-container 或 .nav-menu 等不必要的 CSS 类整体删除。
3. 使用 lxml 解析器仅提取正文并保存为 Markdown，存入 Obsidian 库中。
   这样，模型就能专注于核心内容，减少胡言乱语（幻觉），且 Token 消耗量也会骤降至 25% 左右。

让 Claude Code 不迷路的文件夹设计

当文件增加到数百个时，再聪明的模型也会丢失上下文。不要只是堆积文件，请根据信息状态划分区域。我参考 PARA 框架并将其微调为三阶段结构（01_Raw_Inbox, 02_Processed_Wiki, 03_Project_Action）。这是在给 Claude Code 提供一个物理指南，告诉它该信任并引用哪些信息。

为了让智能体不迷路，可以利用文件名和终端选项：

1. 在所有文件名前加上 YYYY-MM-DD，让模型了解信息的新鲜度。
2. 运行 Claude Code 时使用 --newer-than 选项，使其仅读取最近 24 小时内更改的文件。
3. 在 03_Project_Action 文件夹中只存放记录工作状态的文件。
   建立这种结构后，Claude 就不会去做“翻遍整个仓库”这种蠢事。得益于此，原本需要 10 分钟的搜索现在只需 30 秒即可完成。

用 YAML 元数据弥补搜索盲点

单纯的文本搜索无法区分该文档是“重要的”还是“已完成的”。因此，必须在文档顶部添加 YAML Frontmatter。有了元数据，你就可以给 Claude Code 下达更精细的指令。

对于知识创业者的工作引擎来说，有三个字段就足够了：

1. 在笔记最上方写下划分主题的 topic、衡量重要程度的 source_importance 以及工作状态 status。
2. 使用 Obsidian 的“YAML Toolkit”插件，将此规则一次性应用到现有的数百个文件中。
3. 在 Claude Code 的配置文件（CLAUDE.md）中写下：“请仅参考 status 为 Doing 的文档来安排工作清单。”
   这样，你就能从每天早上花费 2 小时整理资料的苦差事中解脱出来，进入 10 分钟内即可获取工作简报的状态。

一行命令搞定每日简报流程

基于终端的 Claude Code 在与 Shell 脚本结合时才能发挥真正的威力。每天上班只需输入一个命令，就能完成对昨日学习内容的分析，并生成今日待发邮件的草稿。你无需再为每天早上先做哪件事而浪费精力。

自动化流程可以这样构建：

1. 创建一个包含 claude --bare 命令的 Shell 脚本（.sh 或 .bat），以提高初始启动速度。
2. 在脚本中混合使用 find -mtime -1 命令，将最近一天内创建的笔记交给 Claude。
3. 利用 Claude Code 的 PostToolUse 功能，自动纠正生成的邮件草稿中的错别字，并将其自动保存到特定文件夹。
   写一封邮件的时间从 30 分钟缩短到了 5 分钟。

应对数据爆炸的分层引用策略

当文件超过一千个时，20 万 Token 的上下文窗口也会很快填满。此时，不能让模型读取所有文件，而应采用先读取起到“全图”作用的 master_index.md 的两阶段方式。这种方式可以将 API 调用次数减少近 60%。

为了保持性能，必须精明地管理上下文：

1. 通过以下公式理解并管理总 Token 消耗：$$T_{total} = T_{system} + T_{index} + T_{active\_files} + T_{history}$$
2. 让 Claude Code 先阅读 Master Index，仅查找回答问题所需的必要文件路径。
3. 仅额外读取找到的路径文件来生成答案；如果对话过长，使用 /compact 命令压缩历史记录。
   引入这种层级结构后，无论数据如何堆积，你都能获得毫无延迟的即时决策支持。