工具之间的接缝，比工具本身更重要
一只阿木木约 20 分钟Module 7｜整合
工具之间的接缝，比工具本身更重要
你已经装好了三个工具。但三个工具放在那里，和一个系统运转起来，是两件完全不同的事。这一讲，我们来做那个最关键的连接。
写在前面
有一个我见过很多次的场景。
一个人花了两周，认真学完了某套工具的教程。
每个工具单独用，都能用起来。
但当他真正开始工作，需要这些工具协同的时候——
他发现自己站在工具和工具之间的空白地带，不知道下一步应该做什么。
Skill 生成好了，但不知道什么时候应该加载它。
Wiki 页面有了，但写项目文档的时候没有想起来去查。
Claudian 装好了，但遇到需要深度处理的任务，还是打开了 Claude 网页版。
这不是工具的问题。
这是接缝的问题。
每个工具单独能用，不等于工具之间能流畅地传递信息、无缝地切换角色。
接缝不通畅，你每次都需要消耗认知资源来"翻译"——
把这个工具的输出，手动搬运到下一个工具的输入。
翻译的次数越多，摩擦越大，系统越难坚持用。
这一讲要做的事，就是把接缝焊死。
不是让你记住一套操作步骤。
而是让你理解每个接缝存在的原因，以及如何设计让它自动流动。
7.1 先画一张图
在我们讲任何操作之前，我想让你先做一件事。
拿出一张纸，现在就画。
不用漂亮，不需要精准。
画出你到目前为止对这套系统的理解：
三个工具分别在哪里？ 信息是怎么在它们之间流动的？ 你在系统里扮演什么角色？
花 5 分钟。
画完了吗？
好。
把这张图放在旁边，不要扔。
这一讲结束之后，我会让你重新画一次。
到时候你对比两张图，就能知道你在这一讲里真正理解了什么。
现在，我来给你看系统的完整数据流。
text
┌────────────────────────────────────────────────────────────┐
│ 完整数据流 │
│ │
│ 外部世界 │
│ 书籍 / 文章 / 会议 / 想法 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ 输入层 │ │
│ │ raw/（原始文件） │ │
│ │ inbox/（碎片想法） │ │
│ └──────────────┬──────────────────────┘ │
│ │ │
│ 两条加工路径 │
│ │ │
│ ┌───────┴───────┐ │
│ ▼ ▼ │
│ ┌─────────────┐ ┌───────────────┐ │
│ │ book-to- │ │ claude- │ │
│ │ skill │ │ obsidian │ │
│ │ │ │ /wiki-ingest │ │
│ │ 深度结构提取 │ │ 知识摄入 │ │
│ └──────┬──────┘ └───────┬───────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────┐ ┌───────────────┐ │
│ │~/.claude/ │ │ wiki/ │ │
│ │skills/<slug>│ │（知识图谱） │ │
│ │（可调用Skill)│ │ │ │
│ └──────┬──────┘ └───────┬───────┘ │
│ │ │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ CLAUDE.md │ │
│ │ （系统规则层） │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Claudian │ │
│ │ （交互界面层） │ │
│ │ 或 Claude Code │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────┐ │
│ │ 项目输出层 │ │
│ │ 文档 / 分析 / 方案 / 代码 / SOP │ │
│ └────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 知识沉淀回流 │
│ 项目经验 → inbox/ → wiki/ │
└────────────────────────────────────────────────────────────┘
看这张图的时候，注意两件事：
第一：有两条并行的加工路径。
book-to-skill 和 claude-obsidian 是两条路径，不是先后关系。
书走 book-to-skill，生成深度的可调用 Skill。
文章和碎片走 claude-obsidian 的 wiki-ingest，摄入知识图谱。
两个输出最终都汇入交互层，被 Claudian 或 Claude Code 统一调用。
第二：有一个回流箭头。
项目输出之后，知识沉淀回流到 inbox/，再进入 wiki/。
这个回流，是系统真正实现复合增长的关键。
大多数人只做"往里喂"，忘了"往里存"。
7.2 三个接缝，逐一拆开
整个数据流里，有三个接缝最容易出问题。
我逐一说清楚：它在哪里，为什么容易断，怎么把它焊好。
接缝一：raw/ → wiki/
在哪里：
内容进入 raw/ 之后，到被 wiki-ingest 处理进入 wiki/ 之间。
为什么容易断：
raw/ 是零摩擦输入的地方——随时可以扔东西进去。
但处理它，需要一个"主动触发"的动作。
你剪藏了一篇文章，感觉"已经保存了"，然后忘了处理。
raw/ 开始积压。积压到一定程度，你看到它就心虚，开始回避。
这个积压，是整个系统最常见的阻塞点。
怎么焊好：
把"处理 raw/"绑定到一个固定的时间点，而不是等你"有空的时候"。
方法一：每天中午，5 分钟，清空昨天和今天早上进来的内容。
不需要处理完所有的，处理最新的就好。积压越少，每次处理越快。
方法二：剪藏之后立刻处理。
不是剪藏完就关掉浏览器，而是剪藏之后，打开 Claudian，运行 /process-article。
"剪藏"和"处理"变成同一个动作，raw/ 不再积压。
方法三：每周一次批量处理。
如果你的工作节奏不适合每天处理，那就每周固定一次——周五下午，把这周进来的所有内容一次性处理完。
三种方法，选一种，但必须选。
"有空再处理"不是方法，是积压的开始。
接缝二：Skills + wiki/ → 工作现场
在哪里：
你有了 Skills，有了 wiki 页面，但在真正工作的时候，没有想起来用它们。
为什么容易断：
知识库是被动的。
它不会主动提醒你："嘿，你现在做的这件事，我这里有相关内容。"
你需要主动去调用它。
但在深度工作状态下，你的注意力集中在手头的问题上，很难分出一部分去想"我应该查一下知识库"。
结果就是：知识库存在，但工作时没有用到它。
怎么焊好：
方法一：项目开始前，先召唤知识库。
每次开始一个新的工作任务，先运行 /project-brief。
这一步强迫你在开始工作之前，先看一眼知识库里有什么相关内容。
建立一个条件反射：开始工作 = 先看知识库。
方法二：在 CLAUDE.md 里加一条提示规则。
Markdown
## 工作提示在帮助处理任何具体问题时，
先搜索 wiki/ 里是否有相关的概念或案例。
如果有，在回答里标注"基于知识库中的 [[页面名]]"。
这样 Claudian 在帮你工作的时候，会自动去查知识库，并告诉你它引用了什么。
你不需要主动记得，系统帮你记得。
方法三：遇到任何专业判断，先问知识库。
养成一个习惯：每次你要做一个专业判断之前，先问一句：
text
我的知识库里有没有和这个决策相关的框架或案例？
这不是增加工作量，是把"有了知识库但没用"变成"每次都在用知识库"。
接缝三：项目输出 → 知识库回流
在哪里：
你在做项目时学到了很多，解决了很多问题，有很多新的洞见。
但项目结束之后，这些洞见停留在项目文档里，没有沉淀进知识库。
为什么容易断：
项目结束有一种完成感，你想休息，不想再做"知识整理"这件事。
而且"把项目洞见整理进知识库"这件事，看起来没有直接的产出，很容易被推后。
但这个接缝断掉的代价，是巨大的：
你下一个项目，会重新犯同样的错误，因为这次的教训没有被系统性地保存下来。
怎么焊好：
不要等项目结束再做知识沉淀，在项目进行中就实时沉淀。
每次你在项目里发现一个新洞见，当场在 Claudian 里：
text
我刚才发现了一个重要的规律：
[你的洞见]请检查这个内容是否应该进入知识库，如果是，
建议创建或更新哪个 wiki 页面？
30 秒，洞见不会流失。
项目结束时，做一次正式的"项目复盘沉淀"——
text
@projects/your-project/
回顾这个项目的所有文档，
提取出以下内容沉淀进知识库：
1. 新学到的框架或原则
2. 有价值的决策模式
3. 值得记录的反模式（踩过的坑）
生成建议的 wiki 页面列表，等我确认后再执行
7.3 三条集成路径：选一条适合你的
整个系统，有三条不同的集成路径。
它们不是好坏之分，是适合不同工作方式的选择。
路径 A：Claudian（GUI 优先）
适合谁：
你的主要工作在 Obsidian 里完成，你不喜欢频繁切换到终端，你的工作以写作和分析为主，不需要大量的文件批处理。
工作方式：
所有 AI 交互都在 Claudian 侧边栏完成。
Slash Commands 处理你所有的高频任务。
只有在做系统维护（/lint-wiki、批量摄入、更新 CLAUDE.md）的时候才打开终端。
接缝设计重点：
Slash Commands 要覆盖你所有高频的接缝操作。
/process-article、/process-meeting、/project-brief、/daily-review——这些命令要设计好，因为它们是你日常工作里最频繁的工具切换点。
典型的一天：
text
早上 → /daily-review（Claudian）
工作中 → 剪藏文章 → /process-article（Claudian）
开会 → 会后 /process-meeting（Claudian）
写文档 → @wiki/ + @skills/ 内联辅助（Claudian）
结束 → /daily-review 更新（Claudian）
路径 B：Claude Code CLI（终端优先）
适合谁：
你本来就在终端里工作（工程师、数据科学家），你需要处理大量文件，你喜欢脚本化的工作流，你需要精细控制执行过程。
工作方式：
终端是主要工作界面。
Claude Code 直接操作 Vault 文件。
Obsidian 主要用来阅读和浏览知识库（Claudian 轻度使用，处理内联编辑）。
接缝设计重点：
建立一套 bash alias 或者 Makefile，把常用的 Claude Code 操作封装起来：
Bash
# 在你的 .zshrc 或 .bashrc 里加入# 快速进入 Vault + 打开 Claude Code
alias vault='cd ~/knowledge/vault && claude'
# 处理所有新的 raw 文件
alias process-raw='cd ~/knowledge/vault && claude --command "/wiki-ingest raw/"'
# 运行知识库健康检查
alias lint-kb='cd ~/knowledge/vault && claude --command "/lint-wiki"'
# 每日回顾
alias daily='cd ~/knowledge/vault && claude --command "/daily-review"'
典型的一天：
text
早上 → daily（终端）
工作中 → process-raw（终端，批量处理）
写代码时 → @wiki/concepts/xxx 内联查询（偶尔用 Claudian）
结束 → lint-kb 检查（每周一次）
路径 C：MCP Server（跨工具优先）
适合谁：
你同时使用多个工具（Cursor、VS Code、其他 AI 工具），你希望知识库能被多个工具访问，你的工作不局限在 Obsidian 里。
工作方式：
通过 MCP（Model Context Protocol）把你的 Vault 暴露给所有支持 MCP 的工具。
你的知识库不只是 Claudian 的上下文，也可以是 Cursor 编码时的上下文，或者其他工具的上下文。
接缝设计重点：
配置 MCP Server，让 Vault 目录对所有工具可见。
确保 CLAUDE.md 对所有工具都能被正确读取和遵守。
MCP 配置基础：
JSON
// 在你的 MCP 配置文件里（通常是 ~/.config/claude/mcp_servers.json）
{
"obsidian-vault": {
"command": "node",
"args": ["/path/to/obsidian-mcp-server/index.js"],
"env": {
"VAULT_PATH": "/Users/yourname/knowledge/vault"
}
}
}
具体配置根据你使用的 MCP Server 实现而定。
典型的一天：
text
写代码时 → 在 Cursor 里直接 @wiki/concepts 查阅设计决策
写文档时 → Obsidian + Claudian
做分析时 → 终端 Claude Code
所有工具 → 共享同一个知识库，共享同一份 CLAUDE.md
三条路径的选择决策
text
你主要在 Obsidian 里写作和思考？
└── 是 → 路径 A（Claudian 优先）你主要在终端里工作，需要大量文件处理？
└── 是 → 路径 B（CLI 优先）
你需要多个工具共享同一个知识库？
└── 是 → 路径 C（MCP 优先）
一个实用的建议：
如果你不确定，从路径 A 开始。
它的门槛最低，上手最快，大多数知识工作者的日常工作都能被它覆盖。
如果用了一个月发现某些场景不够用，再考虑切换或混合使用。
不要在还没开始使用的时候，就花时间纠结路径选择。
7.4 日常节奏：把系统变成习惯
系统装好了，接缝也焊好了。
但还有最后一道关：让它变成你不需要"提醒自己"就会自然执行的习惯。
节奏设计的原则
不是增加新的工作任务，而是把已有的工作动作，替换成系统化的版本。
你本来就会：
每天开始工作前看一眼今天的计划 读文章 开会 写文档 结束工作
你只是把这些动作，嵌入一套标准化的流程。
每日节奏（15 分钟总成本）
早上开始工作（5 分钟）
text
打开 Obsidian
→ 打开 Claudian
→ 运行 /daily-review
→ 读报告（今天知识库的状态，昨天积累了什么）
→ 确定今天的工作重点
这 5 分钟替换掉的是：
打开电脑，看看 Slack，刷刷微信，还没开始工作就已经分心了。
工作中（随时，每次 30 秒）
每次遇到新信息：
text
值得保留？
├── 是 → Web Clipper 剪藏 → 稍后 /process-article
└── 否 → 看完就过，不要剪
每次遇到新想法：
text
扔进 inbox/，继续工作
不需要现在整理，不需要想格式
中午（5 分钟）
text
打开 Claudian
→ 运行 /process-inbox（处理上午的 inbox 碎片）
→ 如果 raw/ 里有新文件，运行 /process-article
→ 结束
结束工作（5 分钟）
text
打开 Claudian
→ 运行 /daily-review（生成今天的知识日志）
→ 快速扫描 wiki/log.md 今天的条目
→ 如果有任何 [!contradiction] 标注，记在明天的待处理里
→ 关闭 Obsidian
每周节奏（30 分钟总成本）
周五下午（30 分钟）
text
第一步：/weekly-synthesis（10 分钟）
读本周的综合报告
确认最重要的新连接
处理本周未解决的矛盾第二步：检查 raw/ 积压（5 分钟）
如果还有未处理的文件，这时候处理掉
不要让 raw/ 的内容跨周积压
第三步：CLAUDE.md 小迭代（5 分钟）
这周有没有出现让你不满意的输出？
如果有，加一条规则，更新版本号
第四步：下周知识重点（10 分钟）
根据本周的知识缺口，确定下周要读什么方向
在 inbox/ 里记下来，下周一处理
每月节奏（60 分钟总成本）
月末最后一个工作日（60 分钟）
text
第一步：/lint-wiki（20 分钟）
运行知识库健康检查
处理所有红色问题（断链、长期未解决矛盾）
标记需要深化的空壳页面第二步：Graph View 回顾（10 分钟）
打开 Graph View
对比上月和本月的形状变化
找出这个月增长最多的领域和最稀疏的领域
第三步：Skill 库审计（15 分钟）
现有的 Skills 还在被用吗？
有没有新书值得加入？
有没有需要用 update 模式更新的？
第四步：系统整体复盘（15 分钟）
这个月系统运行得怎么样？
哪些习惯执行了，哪些没有？
CLAUDE.md 需要做什么大调整？
在 inbox/ 里写一份月度系统复盘
节奏的真相
我要说一件实话：
前三个月，这个节奏你会做得断断续续。
这很正常。
不是因为你懒，是因为任何新习惯的建立，都需要时间让它变成自动的。
衡量标准不是"这周做了多少天"，而是"这个月有没有在进步"。
第一个月：能执行 50% 就很好。
第二个月：目标是 70%。
第三个月：你会开始觉得"不做这些，工作里有什么东西不对劲"。
那个"不对劲"的感觉，就是系统开始成为你工作一部分的信号。
7.5 CLAUDE.md 作为系统中枢：再深挖一次
我们在 Module 3 详细讲了 CLAUDE.md 怎么写。
这一讲，我想从"系统整合"的角度，再说几件 Module 3 没有说透的事。
CLAUDE.md 是所有工具的共同语言
Claude Code（在终端里）和 Claudian（在 Obsidian 里）读的是同一份 CLAUDE.md。
book-to-skill 生成 Skill 之后，Claudian 调用那个 Skill 时，也是在 CLAUDE.md 的规则框架下工作的。
这意味着：CLAUDE.md 里的每一条规则，影响的是整个系统的所有环节，不只是某一个工具的行为。
当你修改一条规则，你在同时影响：
wiki-ingest 如何处理新内容 Claudian 如何在工作时调用知识库 book-to-skill 生成的 Skill 如何和 wiki 协作 /project-brief 命令如何寻找相关知识
理解这个整体影响，你才能更谨慎地修改 CLAUDE.md——改一条规则之前，想想它会影响系统的哪几个环节。
CLAUDE.md 里需要加入"工具协作规则"
到目前为止，你的 CLAUDE.md 主要定义了：
系统身份 Vault 结构 页面格式 链接规则 标签体系
在整合阶段，还需要加入工具协作规则——告诉 AI 在不同场景下应该调用什么资源。
在你的 CLAUDE.md 里加入这个模块：
Markdown
## 工具协作规则### 处理新内容时
1. 文章、网页 → /wiki-ingest（创建 wiki 页面）
2. 核心专业书 → /book-to-skill（生成可调用 Skill）
3. 碎片想法 → 存入 inbox/（不立即处理）
4. 会议记录 → /process-meeting（整理后摄入 wiki）
### 工作时调用知识
1. 开始任何重要工作前，先运行 /project-brief
2. 遇到专业判断，先搜索 wiki/concepts/
3. 遇到需要深度框架的问题，先查 ~/.claude/skills/
4. 在回答里标注知识来源：[[wiki页面]] 或 /skill-slug
### Skills 和 wiki 的分工
- Skills（~/.claude/skills/）：深度的书籍框架，调用时用 /slug
- wiki/（knowledge/vault/wiki/）：日常积累的知识库，调用时用 [[链接]]
- 两者不重复：同一个知识点，存在一处，不在两处维护
### 项目文档的知识沉淀
- 项目进行中：实时把洞见存入 inbox/
- 项目结束：运行 /project-debrief 命令做正式沉淀
- 不把项目文档直接当 wiki 用：项目文档在 projects/，通用知识在 wiki/
一个常见的 CLAUDE.md 问题：规则冲突
随着 CLAUDE.md 不断迭代，规则越来越多，开始出现规则之间的隐性冲突。
举个例子：
你有一条规则说"每篇文章最多创建 3 个概念页面"。
你还有一条规则说"重要概念必须建立独立页面，不能合并"。
当一篇文章有 5 个重要概念的时候，这两条规则就冲突了。
AI 会随机选一条执行，或者两条都不满足地做一个折中。
如何发现和处理规则冲突：
每次 CLAUDE.md 更新到一个新版本，做一件事：
在 Claudian 里输入：
text
请阅读 CLAUDE.md，找出所有可能存在逻辑矛盾或
在边界情况下会产生冲突的规则。
列出你发现的矛盾，并建议如何解决。
AI 会帮你找出矛盾点。
然后你来判断：哪条规则优先，或者两条如何合并成一条更清晰的规则。
规则冲突检查，每季度做一次。
7.6 会话管理：高质量工作会话的起点
很多人没有意识到：如何开始一次 Claude Code / Claudian 会话，决定了这次会话的上限。
一个糟糕的会话开始方式：
直接问问题。
text
帮我分析这个业务问题……
AI 不知道你的背景，不知道你的系统，不知道你想要什么样的输出。
它只能给一个通用回答。
一个高质量的会话开始方式：
text
今天我要处理的任务是：[具体任务，1-2句话]
相关的知识库资源：@[相关wiki页面] @[相关Skill]
我需要的输出是：[具体格式和用途]
我已经知道的是：[你的已有判断，避免 AI 重复你知道的]
我不确定的是：[你希望 AI 帮你突破的地方]
这 5 行，把会话的方向、资源、期望全部说清楚。
AI 的第一个回答，就能直接进入有效工作状态。
会话的黄金区间
Claude Code 的上下文窗口有上限。
当一个会话的对话轮次超过 20-30 轮，上下文开始拥挤，AI 的输出质量开始下滑。
怎么判断一个会话该结束了：
你注意到 AI 开始"忘记"前面说过的设定 你开始需要重复解释已经说过的背景 这个任务的主要目标已经完成，接下来是新的任务
这时候，开一个新的会话，用 2-3 句话重新介绍背景，比继续当前会话效果更好。
重要会话的"上下文快照"
对于跨天的重要工作，每次会话结束前做一件事：
text
请生成这次会话的"上下文快照"：
- 我们讨论了什么
- 达成了哪些共识
- 下一步计划是什么
- 需要在 CLAUDE.md 或 wiki/ 里更新什么把结果保存到 projects/[项目名]/session-log/YYYY-MM-DD.md
下次继续这个项目，先读这个快照文件，然后开新会话。
AI 不需要记住上次的内容——你帮它把上次的内容结构化好，它读了就能继续。
7.7 系统退化的早期预警信号
系统退化，通常不是一次性崩溃，而是慢慢变坏的。
你需要知道退化的早期信号，在它变成大问题之前介入。
信号一：raw/ 里的积压超过 10 个文件
说明：raw/ 到 wiki/ 的接缝断了，输入速度超过处理速度。
处理：立刻运行一次批量 wiki-ingest，然后调整摄入节奏。
信号二：你最近三天没有问知识库任何问题
说明：知识库存在，但没有参与你的工作，变成了死存档。
处理：回顾最近做的三件工作，每件都问一次"我的知识库里有没有相关内容"。
让知识库重新参与进来。
信号三：wiki/ 里出现了你不认识的页面
说明：AI 在处理内容时创建了你没有审核的页面。
这本身不是问题，但如果你对 wiki/ 里的内容没有基本的掌握，你就不会信任它，也不会使用它。
处理：运行 /lint-wiki，审查最近新建的页面，删除或修正质量不好的。
信号四：CLAUDE.md 超过三个月没有更新
说明：系统没有在进化。你的工作需求在变，但系统规则没有跟上。
处理：花 15 分钟回顾 CLAUDE.md，至少做一处更新。
任何一个"这件事 AI 最近做得不好"的地方，都是值得加进去的规则。
信号五：你开始在系统外处理本应在系统内完成的事
比如：读了一篇好文章，但直接发给朋友，没有剪藏进知识库。
或者：做了一个重要决策，但决策过程没有记录，也没有让知识库参与。
说明：系统和工作之间出现了裂缝，你的工作流程开始绕过系统。
处理：回顾一下最近为什么会绕过系统，是摩擦太大？还是某个步骤不够方便？针对原因调整。
信号六：你感觉知识库"越来越乱，越来越不可信"
说明：质量控制失效。可能是格式不统一，也可能是矛盾积累太多。
处理：运行 /lint-wiki，专门处理格式问题和矛盾问题。
然后回到 CLAUDE.md，加强约束规则。
7.8 一次完整的系统联调测试
在进入 Module 8 的真实项目之前，我需要你先做一次完整的系统联调测试。
目的不是验证每个工具单独能用，而是验证整个数据流从头到尾能通畅地跑一遍。
测试场景
选一个真实的、你最近需要处理的小任务。
不需要是大项目，一篇你想深度消化的文章就足够。
完整测试流程
第一步：输入（book-to-skill 路径）
如果你手边有一本专业书，用 book-to-skill 处理它：
Bash
cd ~/knowledge/vault
claude
/book-to-skill ~/books/your-book.pdf your-slug
等待完成，检查 ~/.claude/skills/your-slug/ 里的文件是否生成正确。
第二步：输入（wiki-ingest 路径）
找一篇相关的文章，用 Web Clipper 剪藏进 raw/，然后：
Bash
/wiki-ingest raw/your-article.md
等待完成，检查 wiki/log.md 确认摄入成功，检查 wiki/ 里新建的页面。
第三步：连接检查
打开 Obsidian，查看 Graph View。
新建的 wiki 页面，和已有内容之间有没有建立链接？
打开 wiki/hot.md，确认热缓存已更新。
第四步：工作时调用（Claudian）
在 Obsidian 里新建一个笔记，模拟你正在做一个工作任务。
打开 Claudian，用 @ 引用刚才的 wiki 页面，以及 book-to-skill 生成的 Skill：
text
@wiki/concepts/[刚才生成的概念页面]
/your-slug基于以上内容，帮我分析 [你正在处理的问题]
检查：AI 是否正确引用了你积累的知识？回答是否基于你的知识库而不是通用知识？
第五步：回流测试
用 Claudian 的内联编辑，在你的笔记里写一个新的洞见：
text
我刚才想到一个重要的点：[你的洞见]
这应该怎么沉淀进知识库？
确认 AI 给了你一个合理的建议，然后执行沉淀。
检查：wiki/ 里有没有新页面或更新？
第六步：健康检查
Bash
/lint-wiki
确认系统状态正常，没有红色警告。
测试完成后的评分
给你的系统联调打一个分：
text
□ Step 1 完成，Skill 文件质量满意（20分）
□ Step 2 完成，wiki 页面生成正确（20分）
□ Step 3 完成，wiki 页面有合理链接（15分）
□ Step 4 完成，Claudian 正确调用知识库（25分）
□ Step 5 完成，洞见成功沉淀进知识库（10分）
□ Step 6 完成，健康检查无红色警告（10分）
满分 100 分。
如果低于 60 分，不要急着进入 Module 8。
先定位断点，修复它，再测试一遍。
Module 8 是真实项目，系统不通畅，项目会很难受。
提前 10 分钟找到问题，比在项目中途发现要好得多。
7.9 整合之后，你的系统是什么样的
我来描述一下，当三个工具真正整合成一个系统之后，你的工作体验会是什么样的。
不是为了让你兴奋，是为了让你知道用对了是什么感觉，这样你才能分辨"现在还没到位"和"已经到位了"。
读到一篇好文章的时候：
你一键剪藏，继续做你的事。
晚些时候，运行 /process-article。
知识库自动更新，不需要你的注意力。
你唯一需要做的判断是：这篇文章值不值得剪藏。
开始一个新项目的时候：
运行 /project-brief，5 分钟内得到一份简报——
你的知识库里有哪些相关内容，有哪些知识缺口，有哪些可以调用的框架。
你的项目从一开始就站在你已有积累的肩膀上，不是从零开始。
面对一个复杂决策的时候：
你不只是在问 AI"怎么做"，你是在问"基于我积累的所有相关知识，这件事应该怎么考虑"。
AI 的回答里，你能认出你读过的书里的框架，你经历过的项目里的案例，你记录过的原则。
这不是一个通用 AI 的回答。
这是一个读过你所有书、见过你所有经历的助手的回答。
项目结束的时候：
你运行 /project-debrief。
这个项目里学到的东西，自动沉淀进知识库。
下一个项目开始，这次的教训已经在里面了。
六个月之后的某一天：
你在处理一个新问题，Claudian 突然引用了一年前你摄入的一篇文章里的一个洞见——
而那个洞见，你自己早就忘了。
但系统没有忘。
那一刻，你会理解：
你建立的不只是一个知识库，你建立了一个比你的记忆更可靠的知识合伙人。
模块作业
作业一：完成系统联调测试（必做）
按照 7.8 节的六步测试流程，完整跑一遍。
记录每一步的结果和评分。
如果有低于 20 分的步骤，找到原因，修复，重新测试。
目标：整体评分达到 80 分再进入 Module 8。
作业二：更新 CLAUDE.md 加入工具协作规则（必做）
按照 7.5 节的内容，在你的 CLAUDE.md 里添加"工具协作规则"模块。
更新版本号，写下为什么添加这个模块。
作业三：设计你自己的节奏表（必做）
根据 7.4 节的框架，设计你个人版本的：
每日节奏（每天花多少时间，具体做什么，绑定到什么触发点） 每周节奏（周几做，花多少时间） 每月节奏（月末做什么）
写进 inbox/my-rhythm.md，不需要很长，但必须是你真正打算执行的版本，不是理想状态。
作业四：重新画那张图（必做）
还记得本讲开始时让你画的那张图吗？
现在，重新画一张。
不要看你之前画的，从头画。
画完，对比两张图：
哪些地方你的理解变深了？ 哪些地方你之前的理解是错的？ 还有哪些地方你觉得还没完全想清楚？
把你的观察，写在 inbox/system-map-reflection.md 里。
本讲总结
text
这一讲你做了什么：□ 理解了完整的数据流，从输入到输出到回流
□ 识别了三个最容易断的接缝，设计了焊合方式
□ 选择了适合你的集成路径（A / B / C）
□ 设计了每日、每周、每月的使用节奏
□ 学会了识别系统退化的六个早期信号
□ 在 CLAUDE.md 里加入了工具协作规则
□ 完成了系统联调测试，确认整体通畅
这一讲你应该建立的认知：
三个工具单独能用，不等于系统在运转。
系统运转的关键，是接缝。
raw/ 积压——输入接缝断了。
知识库没被用——调用接缝断了。
项目洞见流失——回流接缝断了。
每一个断点，都有一个具体的焊合方式。
日常节奏，是接缝自动流通的保障。
不是靠"记住要做这件事"，
而是把它绑定到已有的工作动作上。
当系统真正整合之后，
你感受到的不是"多了一个工具"，
而是"我的工作方式变了"——
知识开始参与你的工作，
而不是存在某个你很少打开的文件夹里。
下一讲，是整门课程最重要的一讲。
我们用一个真实的项目，验证这整套系统的价值。
你会第一次体验到：一个被知识库驱动的项目，和一个没有知识库的项目，产出质量的差别有多大。
不是我告诉你有多大。是你自己做出来，对比，感受到。
带着你调好的系统，进入 Module 8。
Module 7 完 动手时间（联调测试 + CLAUDE.md 更新 + 节奏设计 + 重画图）
认知破点：工具之间的接缝比工具本身更重要；系统不是装好就运转的，是接缝通畅了才运转的；
日常节奏是接缝自动流通的保障
我是【一只阿木木】——公开建造我的 AI 第二大脑。
普通人如何用 AI 搭建自己的知识操作系统？
一个程序员出身的知识工作者，公开记录自己如何用 AI 工具搭建个人知识系统、把读过的书和做过的项目变成可复用资产的全过程。
欢迎加入行动营👇获取更多Obsidian + AI数字大脑实践
我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统
欢迎关注【一只阿木木】🌊