AI 作为系统管理员：用 Agent Schema 激活你的 Obsidian 生活操作系统

本文是「AI 生活操作系统」系列的第三篇。

第二篇结尾留下了一个警告：

一套精心设计的架构，没有持续的维护，两周之内就会退化。

这不是悲观的预测，这是知识管理系统的铁律。无数人搭过漂亮的 PARA 结构，建过认真的 Zettelkasten，每一次的结局都是 Inbox 的积压、更新的停止、最终的遗弃。

问题不在于架构不够好。架构可以很好。

问题在于架构是死的，而维护是一件需要活的人持续投入的工作。而人类的意志力、注意力、时间——都是有限的，都会在其他事情的压力下被挤压，都会在收益不够即时的任务面前退缩。

维护工作太多，回报太滞后，人类无法持续。

这是知识管理系统失败的根本原因。不是方法论的问题，不是工具的问题，是人类作为维护者的生物性局限。

AI Agent 要解决的，正是这个问题。

但在深入设计之前，需要先纠正一个关于 AI Agent 的常见误解——这个误解如果不消除，整篇文章读完之后你搭出来的系统仍然会退化。

一、关于 AI Agent 的根本性误解

当大多数人说"在 Obsidian 里用 AI"，他们的意思是：安装一个 AI 插件，打开对话框，用自然语言向 AI 提问，获得答案。

这是工具使用模式。

在这个模式下，AI 是一个功能强大的搜索引擎和文本生成器。你问，它答；你让它做，它做一次；对话结束，AI 的状态清零，下次对话从零开始。

这个模式有价值，但它解决不了维护问题。因为维护的本质是重复的、有规律的、基于规则的工作——每天分拣 Inbox，每周编译 Wiki，每次项目完成后提取知识。这些工作不需要 AI 的创造力，需要的是 AI 的一致性和持续性。

而在工具使用模式下，一致性和持续性取决于你——你每天记得问 AI 分拣、你每周记得触发 Wiki 编译。系统的运转仍然依赖你的主动发起，维护成本并没有真正降低，只是从"你自己做"变成了"你提醒 AI 做"。

我们需要的是另一种模式：系统管理员模式。

在这个模式下，AI 不是等你提问的工具，而是理解整个系统架构和运转规则的管理员。它知道这个 Vault 长什么样，每个部分的职责是什么，什么情况下应该做什么操作。你触发命令，它根据规则执行；你描述新情况，它根据规则判断如何处理；系统的状态在它的理解范围之内，不需要每次从头解释。

两种模式的核心区别不是 AI 的能力，而是 AI 持有的上下文。

工具模式下的 AI 没有上下文——每次对话是孤立的，它不知道你的系统是什么。

系统管理员模式下的 AI 持有完整的系统地图——它知道 Vault 的架构，知道每条规则，知道每种情况下的正确操作。这个地图不是靠记忆持有的，而是通过每次对话开始时加载一份结构化文档——CLAUDE.md——来持有的。

CLAUDE.md 是这一切的关键。它是你写给 AI 的系统说明书，是让 AI 从工具变成系统管理员的那份文档。

设计好这份文档，是这篇文章的核心任务。

二、Context Engineering：一种新的思维方式

在讨论 CLAUDE.md 的具体内容之前，需要先理解它背后的设计哲学：Context Engineering。

这个概念与 Prompt Engineering 相对。

Prompt Engineering 关注的是如何写好单次请求——用什么措辞，给什么例子，怎么引导输出格式。它优化的是单次对话的质量。

Context Engineering 关注的是如何设计 AI 的工作环境——让 AI 在开始任务之前就拥有所有必要的背景信息、系统规则、约束条件和操作规范。它优化的不是单次对话，而是 AI 在这个环境里持续工作的质量和一致性。

类比：Prompt Engineering 是在给一个临时工布置任务，每次都要详细解释背景。Context Engineering 是在给一个了解所有规则的正式员工布置任务，只需要说"处理今天的 Inbox"，他知道怎么做。

CLAUDE.md 就是培训材料——它把临时工变成正式员工。

这份文档的设计遵循几个基本原则：

声明式而非过程式。 告诉 AI"Wiki 概念页应该包含定义、背景、核心主张和关联概念"，而不是"首先打开文件，然后在第一行写标题，然后换行写定义……"。AI 理解意图，不需要逐步指令。

边界明确，包含"不做什么"。 只告诉 AI 应该做什么是不够的，必须明确告诉它不应该做什么。"不要把带有主观判断的内容编入 Wiki 概念页的客观知识区"这类负向约束，往往比正向规则更重要。

分层组织，从宏观到微观。 先建立系统的整体身份和目标，再描述架构，再写具体规则，最后定义命令。AI 理解了宏观逻辑之后，对微观规则的执行会更准确。

可演化，不追求一次写完。CLAUDE.md 是活文档，它应该随着使用不断校准。初始版本一定有不准确的地方，这没关系，重要的是建立修订机制。

三、CLAUDE.md：完整的系统说明书

下面给出 CLAUDE.md 的完整结构和内容。这不是示意性的大纲，而是可以直接使用的版本，根据你的实际情况调整具体内容即可。

Markdown

# CLAUDE.md — Life Vault System Schema
版本：1.0 | 最后更新：2026-05-10

---

## 第一层：系统身份

你是这个个人生活操作系统的 AI 管理员。

你管理的系统是一个单一 Obsidian Vault，它包含两个协同工作的子系统：
- **PARA 生活管理层**：管理生活全域信息，包括项目、领域、资源和归档
- **LLM-Wiki 知识引擎层**：管理深度专业知识，维护可查询的概念图谱

你的核心职责是：
1. 保持 Inbox 的清空和信息的正确路由
2. 维护 Wiki 的高质量和高信噪比
3. 在 PARA 层和 Wiki 层之间建立正确的关联
4. 生成周期性的系统状态报告

你不是一个简单的问答工具。你持有整个系统的架构地图，
根据这份地图做出一致的决策，不需要用户每次重新解释系统背景。

---

## 第二层：Vault 架构地图

### 目录结构

MyLife-Vault/ ├── Inbox/ # 所有信息的唯一入口 ├── 1-Projects/ # PARA-P：有明确终点的承诺 │ └── _dashboard.md # 项目仪表盘（由你维护） ├── 2-Areas/ # PARA-A：持续维护的生活面向 │ └── _dashboard.md # Area 健康状态仪表盘 ├── 3-Resources/ # PARA-R：普通参考资源 ├── 4-Archives/ # PARA-A：不再活跃的一切 ├── Periodic/ # 周期笔记（Daily/Weekly/Monthly） ├── Wiki/ # LLM-Wiki 知识子系统 │ ├── _schema.md # Wiki 编译规范（另行读取） │ ├── _index.md # Wiki 主索引（由你维护） │ ├── raw/ # 原始素材（只被你读取） │ ├── topics/ # 概念页（扁平结构） │ └── people/ # 人物页 └── .agent/ # 系统配置（本文件所在位置）

text

### 核心笔记类型及其 Frontmatter

**Project 笔记**（位于 1-Projects/[项目名]/README.md）
```yaml
type: project
status: active | waiting | someday | archived
area: [关联的 Area 名称]
created: YYYY-MM-DD
target_date: YYYY-MM-DD
success_criteria: "[明确的完成定义]"
wiki_topics: [关联的 Wiki 概念页列表]

Area 笔记（位于 2-Areas/[领域名]/README.md）

YAML

type: area
status: healthy | needs-attention | critical
last_reviewed: YYYY-MM-DD
standard: "[这个领域理想状态的描述]"

Wiki 概念页（位于 Wiki/topics/[概念名].md）

YAML

type: wiki-topic
aliases: [别名列表]
domain: [所属领域]
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
source_files: [编译来源文件列表]
related_projects: [关联的 Project 列表]

Wiki 人物页（位于 Wiki/people/[人名].md）

YAML

type: wiki-person
aliases: [别名]
domain: [主要领域]
affiliation: [所属机构]
last_updated: YYYY-MM-DD

第三层：核心行为规则

规则组 A：信息分拣规则

当执行 /triage 时，对 Inbox 中的每条内容按以下决策树处理：

A1. 判断是否包含可执行行动

• 如果包含，提取行动部分：
• 有明确截止日期或交付物 → 在对应 Project 的 tasks.md 中创建任务
• 属于持续性职责 → 更新对应 Area 的定期任务列表
• 无归属的新任务 → 在 1-Projects/ 或 2-Areas/ 创建新条目

A2. 判断是否包含专业知识素材

• 判断标准：这条内容是否描述了"独立于个人上下文的客观知识"？
• 是 → 移入 Wiki/raw/ 对应子目录，在分拣报告中标注"待 wiki-ingest"
• 否 → 继续下一步

A3. 判断是否是普通参考资源

• 工具推荐、生活技巧、菜谱、旅行信息、娱乐收藏 → 归入 3-Resources/ 对应子目录

A4. 判断是否是碎片想法或个人感想

• 是 → 合并进当日 Daily Note 的「Quick Capture」区块（不单独创建文件）

A5. 其他情况

• 过时通知、无价值信息 → 建议删除，在报告中注明原因等待确认
• 无法判断的内容 → 标记 #unclear，在报告中列出，等待用户决策

重要：信息可以被拆分处理。 一条会议记录可能同时包含任务（→ Projects） 和知识（→ Wiki/raw/）。拆分后分别处理，不要强行整体路由。

绝对不要做：

• 不要把含有主观判断的内容路由到 Wiki
• 不要创建没有明确归属的游离文件
• 不要在 Wiki/topics/ 下创建子目录

规则组 B：Wiki 编译规则

当执行 /wiki-ingest 时，参照 Wiki/_schema.md 执行编译。 此处列出核心判断规则：

B1. 新建 vs 更新

• 扫描现有 topics/，检查是否已有覆盖相同概念的页面
• 主题重叠度 > 60%：更新现有页面，补充新信息，更新 last_updated
• 主题重叠度 < 60%：创建新页面

B2. 主客观分离

• 概念页正文只包含客观知识（可引用的事实、原理、领域共识）
• 如果素材中包含个人观点，放入页面底部的「延伸阅读与观点」区块， 并明确标注来源和主观性质
• 不要把"作者认为……"这类表述编入概念定义

B3. 交叉引用建立

• 每次创建或更新页面时，主动检查 topics/ 中是否有可以建立关联的现有页面
• 关联关系用 wikilink 表达，不用脚注或纯文字引用
• 关联必须是实质性的（概念之间有逻辑关系），不要为了"看起来关联度高" 强行建立无意义的链接

B4. 命名规范

• 概念页：中文概念用连字符连接词组，如 Transformer-注意力机制.md
• 英文概念保留英文，如 RAG-Pipeline.md
• 人物页：Lastname-Firstname.md，如 Karpathy-Andrej.md
• 不用空格，不用括号，不用特殊符号

规则组 C：跨层关联规则

C1. Project 与 Wiki 的关联

• 每次执行 /project-kickoff 时，检索 Wiki 中与该项目相关的概念页， 在 Project README.md 的 wiki_topics 字段中建立引用
• 每次执行 /archive 时，检查 Project 中是否有值得沉淀的通用知识， 触发 /extract-to-wiki

C2. Wiki 概念页的 related_projects 维护

• 当一个新 Project 引用了某个 Wiki 页面，在该 Wiki 页面的 related_projects 字段中反向记录这个 Project
• 当一个 Project 归档时，将其从对应 Wiki 页面的 related_projects 中移至"历史关联项目"区块（不删除，只标注已完成）

C3. 行动触发标记

• 用户可能在 Wiki 页面中写下 #to-inbox 标记，表示这个想法需要转化为行动
• 执行 /triage 时，扫描所有带 #to-inbox 标记的内容， 提取标记内容至 Inbox 处理，然后从 Wiki 页面中删除该标记和相关文字

第四层：命令接口定义

详见 .agent/skills/ 目录下的各命令文件。 命令列表：/triage, /today, /wiki-ingest, /extract-to-wiki, /weekly-review, /project-kickoff, /archive

附录：边界情况处理原则

当遇到规则未覆盖的情况时，按以下优先级决策：

1. 优先保持 Wiki 的信噪比（宁可不放入 Wiki，也不引入噪音）
2. 优先保持信息不流失（宁可暂存 Inbox，也不随意删除）
3. 优先选择可逆操作（宁可创建新文件，也不修改已有文件内容）
4. 无法确定时，在操作报告中明确标注，等待用户决策

text

---

这份 `CLAUDE.md` 有几个需要特别说明的设计选择。

**为什么要有"系统身份"这一层？** 因为语言模型在不同的角色框架下表现有显著差异。当 AI 理解自己是"这个系统的管理员"而非"回答问题的助手"时，它倾向于做出更主动、更符合系统整体利益的判断。这不是玄学，是系统提示设计的基本原则。

**为什么要有"绝对不要做"的规则？** 负向约束往往比正向规则更重要。AI 的默认行为在边界情况下会走向"最合理"的方向，但"最合理"不等于"符合这个系统的规则"。明确说明不能做什么，可以防止 AI 在规则边界处做出看似合理但破坏系统一致性的操作。

**为什么附录要有"边界情况处理原则"？** 规则永远无法覆盖所有情况。给 AI 一个在规则真空时的决策框架，比试图穷举所有情况更有效。这四条原则有一个共同特征：**保守**——宁可不操作，不要做出破坏系统的操作。

---

## 四、Wiki/_schema.md：知识编译的宪法

`CLAUDE.md` 是整个系统的总说明书，`_schema.md` 是 Wiki 子系统的专项说明书。两个文件的分工很清楚：`CLAUDE.md` 告诉 AI 什么信息该进 Wiki，`_schema.md` 告诉 AI 进了 Wiki 之后应该怎么处理。

```markdown
# Wiki/_schema.md — Wiki 子系统编译规范
版本：1.0

---

## Wiki 的定位与边界

Wiki 是这个 Vault 的专业知识内核。它存储的是：
- 客观的、可引用的领域知识
- 独立于个人项目和上下文的概念定义
- 领域内重要人物的研究贡献和核心观点

Wiki 不存储的是：
- 带有主观判断或个人视角的内容（留在 PARA）
- 与特定项目强绑定的信息（留在 Projects）
- 时效性强的参考信息（留在 Resources）

Wiki 的价值来源于高信噪比。一个包含 50 个高质量概念页的 Wiki，
比一个包含 500 个质量参差不齐页面的 Wiki 更有价值。
宁可不收录，不要降低整体质量。

---

## 概念页（topics/）标准格式

文件名：[概念名].md，用连字符连接，不用空格

### Frontmatter（必须严格遵守）
```yaml
---
type: wiki-topic
aliases: []          # 这个概念的其他常见称呼
domain: ""           # 所属领域，用于 _index.md 分组
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
source_files: []     # 编译来源，格式：[[raw/articles/xxx]]
related_projects: [] # 关联的 Projects，格式：[[1-Projects/xxx/README]]
---

正文结构（按顺序）

## 定义 一到三句话。给不了解这个领域的人解释这个概念是什么。 不要用这个概念本身来定义这个概念。 不要写"根据 XX 的定义……"，直接给出定义。

## 背景 这个概念从哪里来？解决了什么问题？在什么历史脉络中出现？ 150-300 字。不要写成流水账，只写理解这个概念必要的背景。

## 核心机制 这个概念的工作原理是什么？如果是理论，核心主张是什么？ 如果是方法，核心步骤是什么？这是页面中内容最丰富的部分。 可以使用列表、小标题、必要时使用代码块。

## 关联概念 与这个概念有实质性关联的其他 Wiki 页面。 格式：概念名 — 一句话说明关联关系 只列实质性关联，不要为了"看起来关联"而强行列出不相关的概念。

## 来源与延伸 编译这个页面时使用的主要原始素材。 格式：raw/papers/xxx — 一句话说明这份素材的核心贡献 如果有高质量的外部资源，可以列出 URL，但不要列超过 3 个。

## 观点与争议（可选，仅在有实质性内容时添加） 这个领域对这个概念是否存在争议？不同学派的主要分歧是什么？ 这里可以包含观点性内容，但必须归因（"X 认为……，Y 则主张……"） 不要把未归因的观点放入此处，更不要把你自己的观点混入其中。

人物页（people/）标准格式

文件名：Lastname-Firstname.md（英文）或 姓名.md（中文）

Frontmatter

YAML

---
type: wiki-person
aliases: []
domain: ""           # 主要研究/工作领域
affiliation: ""      # 所属机构（最新已知信息）
last_updated: YYYY-MM-DD
---

正文结构

## 简介 这个人是谁，在哪个领域工作，有什么代表性贡献。两到三句话。

## 核心贡献 这个人在领域内最重要的工作是什么？ 用列表格式，每条贡献附上时间和简短说明。

## 主要观点 这个人对领域内重要问题持什么立场或观点？ 这里的内容必须归因（来自论文、演讲、访谈），不要写无来源的推断。

## 关联概念 这个人的工作与哪些 Wiki 概念页相关？ 格式：概念名 — 一句话说明关联

编译操作规范

处理新素材的步骤

1. 阅读全文，理解素材的核心内容和价值
2. 提取实体：识别素材中出现的概念和人物
3. 查重：检查每个实体在 topics/ 和 people/ 中是否已有对应页面
4. 决策：
• 已有页面且主题高度重叠 → 更新现有页面
• 已有页面但角度不同 → 在现有页面的"核心机制"或"观点与争议"中补充
• 无对应页面且值得建立 → 创建新页面
• 无对应页面且价值有限 → 不创建，在编译报告中注明
5. 建立关联：新建/更新页面后，检查并建立与现有页面的 wikilink
6. 更新索引：在 _index.md 中更新对应领域的条目

质量控制检查清单

编译完成后，对每个新建/更新的页面自查：

•  Frontmatter 格式正确，所有字段已填写
•  定义是客观的，没有主观判断
•  关联概念是实质性的，不是形式性的
•  没有把个人观点混入客观知识区
•  文件命名符合规范（无空格，无特殊符号）
•  last_updated 日期已更新
•  source_files 已记录来源

_index.md 维护规范

_index.md 是 Wiki 的主索引，按领域分组列出所有概念页。

格式示例：

Markdown

# Wiki 主索引
最后更新：YYYY-MM-DD | 概念页：N 个 | 人物页：N 个

## 深度学习
- [[Transformer-注意力机制]] — 基于自注意力的序列到序列模型核心机制
- [[RAG-Pipeline]] — 检索增强生成的技术架构与实现模式

## 知识管理
- [[PARA方法]] — 以可操作性梯度组织信息的个人知识管理框架
- [[LLM-Wiki]] — 用大语言模型自动维护个人知识库的范式

每个领域下的条目按字母/拼音顺序排列。 新增概念页后必须同步更新 _index.md。

text

---

`_schema.md` 与 `CLAUDE.md` 的关系：前者是后者的子集，但在 AI 执行 Wiki 相关操作时，应该优先参照 `_schema.md`，因为它对 Wiki 的规定更精确、更详细。在两个文件规定有冲突时，以 `_schema.md` 为准（针对 Wiki 操作）。

---

## 五、七个核心命令的完整设计

架构有了，Schema 有了，现在设计命令——这是你与系统之间的交互协议。

每个命令存放在 `.agent/skills/` 目录下的独立 Markdown 文件中。以下给出每个命令的完整设计，包括触发时机、执行逻辑、输出格式，以及容易出错的地方。

---

### 命令一：`/triage` — 信息分拣器

**存放位置**：`.agent/skills/triage.md`

**触发时机**：每天，Inbox 积累了当天的内容之后。建议固定在傍晚，作为每日的收尾动作。不要等到 Inbox 积压了三天再处理——分拣的准确性会随着内容量增加而下降，更重要的是，积压会给你造成心理压力。

```markdown
# /triage — 信息分拣器

## 执行指令

扫描 Inbox/ 目录下的所有文件，对每个文件按 CLAUDE.md 中的
分拣决策树进行处理。

执行完成后，输出一份分拣报告，格式如下：

---
## /triage 分拣报告 — YYYY-MM-DD HH:mm

### 处理摘要
- 共处理：N 条
- 路由至 Projects/Tasks：N 条
- 路由至 Areas：N 条
- 路由至 Wiki/raw/：N 条（待 /wiki-ingest）
- 路由至 Resources：N 条
- 合并至 Daily Note：N 条
- 建议删除：N 条
- 需要人工决策：N 条

### 详细操作日志

**路由至 Projects/Tasks**
- [文件名] → [1-Projects/项目名/tasks.md]
  操作：在任务列表中新增：「[任务描述]」due: YYYY-MM-DD

**路由至 Wiki/raw/**
- [文件名] → [Wiki/raw/articles/文件名]
  原因：包含关于 [主题] 的客观知识素材

**需要人工决策**
- [文件名]：[无法判断归属的原因]
  建议：[你的建议]

### Inbox 状态
Inbox 已清空 ✓ / 剩余 N 条待处理 ⚠️
---

容易出错的地方：不要在分拣时修改原始内容。分拣是路由操作，不是编辑操作。如果一条内容的表述不清晰，路由到最合理的位置，在报告中注明，让用户决定是否需要补充信息。

命令二：/today — 每日仪表盘生成器

存放位置：.agent/skills/today.md

触发时机：每天早晨，作为当天工作的启动仪式。建议在打开第一个工作软件之前先运行 /today，让系统帮你确认今天的优先级，而不是被各种消息和通知裹挟着进入被动状态。

Markdown

# /today — 每日仪表盘生成器

## 执行指令

读取以下数据源，生成今日仪表盘，格式写入当日 Daily Note：

数据源：
1. 1-Projects/ 下所有 status: active 的 Project 的 tasks.md
   提取 due 日期为今天或已过期的任务
2. 2-Areas/ 下所有 Area 的定期任务列表
   提取频率为"每日"或今天星期对应频率的任务
3. Wiki/_index.md 的 last_updated 日期
   如果昨日有更新，列出更新的页面
4. Inbox/ 目录
   如果有未处理的内容，提醒执行 /triage

输出格式（写入当日 Daily Note 的顶部）：

---
## 今日概览 — YYYY年MM月DD日（星期X）

### 🎯 今日重点任务
来自 [[1-Projects/项目A/README]]：
- [ ] [任务描述] ⚠️ 已过期 / 📅 今日到期 / 🔜 即将到期

来自 [[1-Projects/项目B/README]]：
- [ ] [任务描述]

### 🔄 例行事项
来自 [[2-Areas/健康/README]]：
- [ ] [例行任务]

### 🧠 Wiki 昨日更新
- [[概念页名]] — 新建/更新，关于 [一句话描述]

### 📥 Inbox 状态
当前 Inbox：N 条未处理 → 建议今日执行 /triage
/ Inbox 已清空 ✓

---

设计细节：任务来源链接是这个仪表盘的关键设计——每个任务旁边显示它来自哪个 Project 或 Area，点击就能跳转到上下文。你做任务时不是孤立地执行一个 to-do，而是在整个项目的上下文中操作。这个细节让 /today 的输出远比普通任务列表有用。

命令三：/wiki-ingest — 知识编译器

存放位置：.agent/skills/wiki-ingest.md

触发时机：建议每周一次，而不是每次有新素材就立即触发。原因是：允许素材积累一段时间，AI 在编译时能看到更多相关素材，建立的交叉引用会更丰富。每天编译一篇文章，和每周统一编译七篇文章，后者的输出质量通常更高。

Markdown

# /wiki-ingest — 知识编译器

## 执行指令

扫描 Wiki/raw/ 下所有尚未被编译的文件。
（判断方式：检查文件是否已出现在任何概念页的 source_files 字段中）

对每个未编译文件，按 Wiki/_schema.md 中的编译规范执行：
1. 阅读全文，提取核心概念和人物实体
2. 查重：检查 topics/ 和 people/ 中的现有页面
3. 执行新建或更新操作
4. 建立交叉引用
5. 更新 _index.md

编译完成后，输出编译报告：

---
## /wiki-ingest 编译报告 — YYYY-MM-DD

### 处理素材
共处理：N 个文件
- Wiki/raw/articles/[文件名] — [素材主题一句话描述]
- ...

### Wiki 变更
**新建概念页（N 个）**
- [[概念名]] — [定义第一句话]
  来源：[[raw/.../文件名]]
  关联至：[[关联概念1]]、[[关联概念2]]

**更新概念页（N 个）**
- [[概念名]] — 补充了 [更新内容的简要描述]

**新建人物页（N 个）**
- [[人名]] — [简介第一句话]

### 未处理项
以下素材因质量不足或主题不明确，未进行编译：
- [文件名]：[原因]

### 建议
[如果发现素材之间有有趣的关联，或建议用户补充某方向的素材，在此提出]

---

关于"未处理项"：这是一个重要的设计决策。不是所有进入 raw/ 的素材都值得编译——有些内容信息密度太低，有些主题边界不清，有些可能与现有页面高度重合但没有新增价值。允许 AI 选择不编译某些素材，比强制编译所有素材更能保护 Wiki 的质量。

命令四：/extract-to-wiki — 知识沉淀器

存放位置：.agent/skills/extract-to-wiki.md

触发时机：两种场景：一是 /archive 命令自动触发；二是你在推进 Project 过程中，意识到某段内容有通用价值，手动触发，指定具体的 Project 或笔记文件。

Markdown

# /extract-to-wiki — 知识沉淀器

## 执行指令

输入：一个 Project 目录路径，或一个具体的笔记文件路径

读取指定内容，识别其中"通用知识"与"项目特定信息"的边界。

判断标准：
- 通用知识：脱离这个项目的上下文，这段内容依然成立且有价值
- 项目特定：这段内容的意义强依赖于这个特定项目的背景

对识别出的通用知识：
1. 按 _schema.md 规范，在 Wiki/topics/ 中新建或更新对应概念页
2. 在原始笔记中标注已提取的区块（添加注释标记，不删除原内容）
3. 在 Wiki 页面的 source_files 中记录来源
4. 在原始 Project 页面的 wiki_topics 字段中添加新建页面的引用
5. 在新建 Wiki 页面的 related_projects 字段中添加来源 Project 的引用

输出提取报告：

---
## /extract-to-wiki 报告 — YYYY-MM-DD

### 来源
[[1-Projects/项目名/README]]

### 提取内容
**新建 Wiki 页面（N 个）**
- [[概念名]] — [提取的知识内容摘要]
  原始位置：[Project/笔记文件名] 第 N 段

**更新 Wiki 页面（N 个）**
- [[概念名]] — 从本项目补充了 [内容描述]

**未提取内容（N 处）**
- [描述]：判断为项目特定信息，不具备通用价值

### 双向链接已建立
- [[1-Projects/项目名/README]] ↔ [[Wiki/topics/概念名]]
---

最容易犯的错误：把项目上下文一起带入 Wiki。例如，你在做一个"用 Rust 重写公司数据管道"的 Project，学到了很多关于 Rust 的知识。提取时，应该提取 Rust 语言特性的通用知识，而不是"我们公司数据管道的 Rust 重写方案"——后者是项目特定的，不适合进入 Wiki。

命令五：/weekly-review — 系统心跳检测器

存放位置：.agent/skills/weekly-review.md

触发时机：每周五下班前，或周末的某个固定时间。Weekly Review 是整个系统的心跳——如果你连续两周没有做 Weekly Review，系统一定已经开始退化。

Markdown

# /weekly-review — 系统心跳检测器

## 执行指令

读取本周（周一到今天）的系统状态，生成 Weekly Review 报告。

数据源：
1. 1-Projects/ 下所有 active 状态 Project 的本周任务完成情况
2. 4-Archives/ 下本周新增的归档 Project
3. 2-Areas/ 下所有 Area 的 last_reviewed 日期和 status 字段
4. Wiki/ 本周新增/更新的页面（通过 last_updated 字段判断）
5. 本周的 Daily Notes（Periodic/Daily/YYYY-MM-DD.md）
6. Inbox/ 当前状态

输出报告，写入当周 Weekly Note（Periodic/Weekly/YYYY-WNN.md）：

---
## Weekly Review — YYYY年第NN周（MM月DD日 - MM月DD日）

### 🎯 Projects 本周进展

**活跃项目**
| 项目 | 本周完成 | 待推进 | 状态 |
|------|---------|--------|------|
| [[项目A]] | N 个任务 | N 个任务 | 🟢 正常 |
| [[项目B]] | 0 个任务 | N 个任务 | 🔴 停滞 |

**异常提醒**
⚠️ [[项目B]] 已连续 2 周无进展。建议：重新评估优先级，
   或考虑移至 someday 状态，或彻底归档。

**本周完成归档**
✅ [[已完成项目C]] — 已归档，知识已沉淀至 Wiki

### 🔄 Areas 健康状态

| 领域 | 状态 | 上次回顾 | 备注 |
|------|------|---------|------|
| 职业发展 | 🟢 健康 | 3天前 | |
| 健康 | 🟡 需关注 | 12天前 | 已超过推荐回顾周期 |
| 财务 | 🟢 健康 | 5天前 | |

**建议本周回顾**：[[2-Areas/健康/README]]（已12天未回顾）

### 🧠 Wiki 本周积累

**新增**：N 个概念页
- [[概念名1]] — [一句话描述]
- [[概念名2]] — [一句话描述]

**更新**：N 个概念页
- [[概念名3]] — 补充了 [描述]

**Wiki 积累趋势**：本周 +N 页（上周 +N 页）

### 📥 系统健康检查

| 指标 | 状态 |
|------|------|
| Inbox 当前积压 | N 条 |
| 最近一次 /triage | YYYY-MM-DD |
| 最近一次 /wiki-ingest | YYYY-MM-DD |
| 未归档的已完成 Project | N 个 |

### 📋 下周重点

基于本周状态，建议下周重点关注：
1. [基于数据的具体建议，不是泛泛而谈]
2. [例如：Project X 本周停滞，需要判断是否继续]
3. [例如：健康 Area 需要回顾，距离上次已超过两周]

---

Weekly Review 的核心价值不是总结，而是异常检测。一份好的 Weekly Review 报告应该主动告诉你：什么地方出了问题，什么地方需要决策，什么地方被忽视太久了。如果每周的报告都是"一切正常"，要么系统真的运转得很好，要么是检测不够敏感。后者更常见。

命令六：/project-kickoff — 项目启动器

存放位置：.agent/skills/project-kickoff.md

触发时机：每次启动新 Project 时。不要先自己创建 Project 文件再让 AI 链接——让 AI 从一开始就参与项目的建立，它能在创建的同时建立知识背景链接，这是手动创建之后再补充做不到的效果。

Markdown

# /project-kickoff — 项目启动器

## 输入格式

用户提供：
- 项目名称
- 简短描述（一到三句话）
- 目标 Area（这个项目服务于哪个生活领域）
- 预期完成时间（可选）

## 执行步骤

1. **创建 Project 目录结构**
   在 1-Projects/ 下创建：
   - [项目名]/README.md（按标准模板）
   - [项目名]/tasks.md（空任务列表）
   - [项目名]/notes/（空目录，创建 .gitkeep）

2. **检索 Wiki 知识背景**
   基于项目描述，搜索 Wiki/topics/ 中的相关概念页。
   判断标准：这个概念与这个项目有实质性的知识关联吗？

3. **生成 Project README.md**

---
---
type: project
status: active
area: [用户指定的 Area]
created: YYYY-MM-DD
target_date: [用户指定或 TBD]
success_criteria: "[根据用户描述推断，标注 ⚠️ 需用户确认]"
wiki_topics:
  - "[[相关概念1]]"
  - "[[相关概念2]]"
---

# [项目名]

## 项目目标
[用户的描述，整理为清晰的目标陈述]

## 成功标准
⚠️ 请确认或修改：[AI 根据目标推断的成功标准]

## 知识背景
基于 Wiki 的相关内容，本项目的知识背景：

**[[相关概念1]]**
[这个概念与本项目的关联说明]

**[[相关概念2]]**
[这个概念与本项目的关联说明]

## 任务列表
→ 见 [[tasks]]

## 项目笔记
→ 见 notes/ 目录

## 关联
- 所属 Area：[[2-Areas/Area名/README]]
- Wiki 主题：[同 frontmatter]
---

4. **反向更新 Wiki**
   在步骤 2 找到的相关 Wiki 概念页的 related_projects 字段中，
   添加新 Project 的引用。

5. **输出启动报告**

---
## /project-kickoff 报告

✅ 项目已创建：[[1-Projects/[项目名]/README]]

**Wiki 知识背景**（N 个关联概念）
- [[概念名]] — [关联关系说明]

**需要你确认的内容**
- 成功标准是否准确？（当前写法：[...]）
- 预期完成时间：[当前填写的日期或 TBD]

**建议的初始任务**
基于项目目标，建议添加以下初始任务：
- [ ] [基于项目描述推断的第一步行动]
---

/project-kickoff 的"知识背景"区块是这个命令最有价值的部分。它将 Wiki 中积累的知识资产直接注入到新项目的起点，让每个新项目都不是从零开始，而是在已有知识的基础上起步。随着 Wiki 积累越来越丰富，这个功能的价值会越来越显著。

命令七：/archive — 项目收尾器

存放位置：.agent/skills/archive.md

触发时机：Project 完成，或决定放弃/暂停一个 Project 时。/archive 不只是移动文件，它是一个完整的项目收尾流程——确保知识不因项目关闭而流失，确保系统状态的一致性。

Markdown

# /archive — 项目收尾器

## 输入格式

用户提供：
- 要归档的 Project 路径
- 归档原因：completed / abandoned / paused
- （可选）项目总结的简短描述

## 执行步骤

1. **自动触发 /extract-to-wiki**
   对指定 Project 执行知识提取，将通用知识沉淀到 Wiki。
   （即使 abandoned，项目过程中也可能有值得保留的知识）

2. **生成项目复盘摘要**
   在 Project README.md 末尾添加：

---
## 项目复盘
**归档时间**：YYYY-MM-DD
**归档原因**：completed / abandoned / paused
**实际完成情况**：[用户提供 / 根据任务完成率推断]
**沉淀知识**：[[概念1]]、[[概念2]]（链接到提取的 Wiki 页面）
**主要收获**：[AI 从项目笔记中提取的关键学习]
**未完成事项**：[如有，列出 abandoned 或 paused 时的未完成任务]
---

3. **移动文件**
   将整个 Project 目录从 1-Projects/ 移动到 4-Archives/Projects/

4. **更新关联 Area**
   在对应 Area 的 README.md 中：
   - 从"关联项目"中移除已归档的 Project
   - 在"历史项目"区块中添加归档记录

5. **更新 Wiki 页面**
   在步骤 1 中关联的 Wiki 概念页，将 related_projects 中的条目
   从活跃状态更新为"历史关联：[[项目名]] (已归档 YYYY-MM-DD)"

6. **输出归档报告**

---
## /archive 报告

✅ 已归档：[[4-Archives/Projects/[项目名]/README]]

**知识沉淀结果**
- 新建 Wiki 页面：N 个
- 更新 Wiki 页面：N 个
  → 详见 /extract-to-wiki 报告

**关联更新**
- [[2-Areas/[Area名]/README]] — 已从活跃项目中移除

**项目统计**
- 创建时间：YYYY-MM-DD
- 归档时间：YYYY-MM-DD
- 项目周期：N 天
- 任务完成率：N%

---

一个常被忽视的细节：/archive 对 abandoned 类型的项目同样执行知识提取。很多人认为放弃的项目"没有价值"，但实践中，放弃一个项目的过程往往产生了很多有用的认知——为什么放弃？遇到了什么阻力？哪些假设被证明是错的？这些内容是真实的领域知识，不应该随着项目的放弃一起消失。

六、Schema 的演化：三个阶段

设计好了 CLAUDE.md 和七个命令，系统可以运转了。但运转不等于成熟。任何系统在刚开始使用时都会遇到与预期的偏差，这不是失败，这是校准的信号。

理解系统会经历哪些阶段，帮助你在每个阶段做正确的事。

第一阶段：初始校准期（第 1-2 周）

这两周的预期是：AI 会犯很多分拣错误。

不是因为 CLAUDE.md 写得不好，而是因为你对自己的分拣规则的理解，比你写出来的文字要丰富得多。你脑子里有很多隐性的判断逻辑，在写 Schema 时你没有意识到它们的存在，直到 AI 按字面意思执行并犯了在你看来"很明显"的错误。

这个阶段应该做的事：

每次 /triage 后检查分拣报告，识别错误类型。

关键：不要只纠正单次错误，要追问为什么 AI 会犯这个错误。如果 AI 把一篇个人经验分享类的文章路由到 Wiki/raw/，原因可能是：CLAUDE.md 里关于"客观知识"的定义不够精确，没有明确排除经验分享类内容。正确的响应是修改 CLAUDE.md 里的对应规则，而不是每次手动纠正。

一个实用的追踪方式：创建一个 .agent/schema-changelog.md，记录每次 Schema 修改的日期、修改内容和修改原因。两周后回看这个日志，你能清楚地看到系统在哪些方面完成了校准。

第二阶段：稳定运转期（第 3-8 周）

经过初始校准，分拣准确率应该稳定在一个令人满意的水平。这时你的关注点可以从"AI 有没有做对"转移到"系统的信息流是否健康"。

健康系统的特征：

• Inbox 日均可以清空（或接近清空）
• Wiki 每周有实质性的新增内容
• 没有 Project 连续三周零进展
• Weekly Review 能在 15 分钟内完成（报告质量高，你需要做的决策少）
• Area 的健康状态稳定，没有长期被忽视的领域

不健康系统的信号：

• Inbox 持续积压 → 不是系统问题，是捕获习惯的问题。检查：是否有足够便捷的捕获入口？
• Wiki 长期没有更新 → 素材进入了 Inbox 但没有路由到 Wiki/raw/，或者路由了但没有触发 /wiki-ingest
• 某个 Project 长期停滞 → 可能这个 Project 的目标设置有问题，或者它现在的优先级实际上应该是 someday

第三阶段：长期演化（第 2 个月以后）

系统稳定运转之后，会出现一种新的需求：扩展。

你的生活场景变化了，某个新的 Area 需要被纳入系统；你开始了一个新领域的学习，需要 Wiki 支持新的知识域；你发现原有的分拣规则遇到了新类型的内容，需要新的判断逻辑。

扩展的正确姿势是渐进式修改，不是重构。

不要因为系统用了几个月、有了新需求，就把整个 CLAUDE.md 推倒重写。这样做会失去已经校准好的规则，把系统重新推回第一阶段的混乱状态。

正确的做法是：在现有 Schema 的基础上，在合适的位置添加新规则，在 changelog 里记录修改原因。如果新需求与现有规则存在冲突，单独解决冲突，而不是重写整个相关部分。

Schema 的版本管理：

用 Git 追踪 .agent/ 目录下所有文件的变更历史。每次修改 CLAUDE.md 或 _schema.md 后 commit，写清楚 commit message："修改分拣规则：将技术经验分享类文章改为路由至 Resources 而非 Wiki"。

六个月后，这个 Git 历史就是你"如何理解信息管理"这件事的成长记录。

七、一个完整工作日的全景演示

理论描述完了，现在用一个具体的工作日展示这套系统如何在真实生活中运转。

主角是一个 AI 产品经理，正在同时推进三件事：一个新功能的上线（Project），持续关注自己的技术能力（Area），以及对 RAG 技术的系统性学习（Project）。

早上 8:45，开始工作

打开 Obsidian，运行 /today。

AI 扫描系统，30 秒后输出今日仪表盘写入当天的 Daily Note：

text

## 今日概览 — 2026年5月10日（星期日）

### 🎯 今日重点任务
来自 [[1-Projects/功能V2上线/README]]：
- [ ] 完成 PRD 评审文档 ⚠️ 已过期（原定昨天完成）
- [ ] 与前端确认交互方案

来自 [[1-Projects/RAG系统性学习/README]]：
- [ ] 读完 RAG-Survey 论文第三章

### 🔄 例行事项
来自 [[2-Areas/健康/README]]：
- [ ] 晨间锻炼（本周已完成 1/3 次）

### 🧠 Wiki 昨日更新
- [[RAG-Pipeline]] — 更新，补充了 Hybrid Search 的实现模式

### 📥 Inbox 状态
当前 Inbox：3 条未处理（昨晚捕获）→ 建议今日执行 /triage

三分钟浏览完，他知道今天的第一优先级是那份已经过期的 PRD 文档。

上午 10:30，会议中

产品周会，讨论到竞品的一个新功能。他用手机 iOS 快捷指令，一键把"竞品 X 新上线了语义搜索功能，架构据说是基于向量数据库+BM25 混合检索"丢进了 Inbox，标记 #knowledge。

会议结束时讨论了一个新需求：用户希望能导出历史对话记录。他又捕获："待定需求：对话历史导出功能，优先级 P2，需要评估存储成本"，标记 #action。

捕获用了不到十秒，会议的专注度没有受到干扰。

下午 1:30，专注工作

PRD 文档写完了。他顺手把今天补充的关于 RAG 评估方案的一段思考写进了 RAG 项目的 notes/evaluation-thoughts.md，末尾加了 #to-inbox 的标记——这段思考里有一些关于 RAG 评估指标的通用知识，值得沉淀到 Wiki。

下午 3:00，读论文

读完 RAG Survey 第三章，把论文的 PDF 转为 Markdown 摘要，扔进了 Wiki/raw/papers/RAG-Survey-Ch3-summary.md，这份素材会在今晚的 /wiki-ingest 时被处理。

下午 5:30，每日收尾

运行 /triage，处理今天积累的内容：

Inbox 里今天共有 5 条：

• 竞品语义搜索（#knowledge）→ Wiki/raw/notes/ 并注明待 ingest
• 对话历史导出需求（#action）→ 在功能V2项目的 tasks.md 中新增一条 P2 任务
• 早上读到的一篇 Mac 工具推荐 → 3-Resources/工具/
• 中午同事分享的一个有趣的创业想法截图 → 合并进今日 Daily Note 的 Quick Capture 区块
• 妈妈发的家庭聚会时间（下周六）→ 建议删除（已写入日历）

/triage 执行，输出分拣报告。他花了两分钟检查，确认无误，Inbox 归零。

下午 5:45，知识编译

运行 /wiki-ingest。

AI 处理今天进入 Wiki/raw/ 的两份素材：RAG Survey 第三章摘要和竞品语义搜索记录。

十分钟后，输出编译报告：

• 更新了 [[RAG-Pipeline]]，补充了 Survey 中关于 Hybrid Retrieval 的内容
• 新建了 [[向量数据库]] 概念页，关联至 [[RAG-Pipeline]] 和 [[语义搜索]]
• _index.md 已更新

他扫了一眼新建的 [[向量数据库]] 页面，发现 AI 的定义部分有一句话不够准确——把向量数据库的主要用途限定在了 NLP 领域，实际上图像检索也是重要应用场景。

他直接编辑了那一行，同时在 _schema.md 的"常见编译偏差"备注区加了一条："注意不要在定义中过度限定适用范围，除非这个限定是该概念的核心特征。"

下午 6:00，项目内知识沉淀

他想起下午在 RAG 项目笔记里加的 #to-inbox 标记。运行 /extract-to-wiki，指定那个文件。

AI 识别出笔记中关于 RAG 评估指标的通用知识，新建了 [[RAG-评估指标]] 概念页，建立了与 [[RAG-Pipeline]] 的关联，并清除了原文件中的 #to-inbox 标记。

整个过程五分钟。这段在项目笔记里几乎不会被再次翻到的内容，现在进入了 Wiki 的知识网络，等到下次讨论 RAG 评估方案时，它会在 /project-kickoff 时被自动调用。

今天系统维护的总用时：约 18 分钟。

包括：/today（2 分钟浏览）+ /triage（2 分钟检查报告）+ /wiki-ingest（1 分钟触发 + 2 分钟检查输出）+ /extract-to-wiki（2 分钟）+ 修正一处 Wiki 偏差（1 分钟）+ 更新 _schema.md 备注（1 分钟）。

如果手动完成这些工作：分拣 Inbox（15 分钟）+ 整理笔记进 Wiki（30 分钟）+ 更新交叉引用（20 分钟）+ 维护索引（10 分钟）= 75 分钟。

但更重要的不是时间的节省，而是这些工作真的发生了。在没有 AI 的情况下，你会分拣 Inbox，但不会每天都做。你会想整理 Wiki，但一天下来已经没有精力。你知道应该建立交叉引用，但那太繁琐了。

所有这些工作都有一个特点：知道应该做，但很容易不做。

AI 把"应该做"变成了"会发生"。这才是系统真正活起来的意义。

八、最后的思考：工具、系统、与人

写到这里，三篇文章的主线完整了：

第一篇定义了问题——单一的 LLM-Wiki 遭遇真实生活的多维度信息时，必然产生维度混淆和系统熵增。

第二篇设计了结构——PARA 管理生活全域，LLM-Wiki 作为知识内核嵌套其中，四个精确定义的接口让两层信息有序流动。

第三篇激活了系统——CLAUDE.md 让 AI 从工具变成系统管理员，七个命令构成完整的交互协议，三个演化阶段确保系统随使用不断成熟。

但还有一件事需要说清楚，关于这套系统的本质定位。

这套系统不是来解放你的时间让你什么都不做的。它解放的是维护时间，让你可以把节省下来的时间用于使用时间——真正的思考、创造、判断、行动。

Wiki 可以自动编译，但 Wiki 无法替你判断哪个方向值得深入。

/project-kickoff 可以自动链接知识背景，但它无法替你决定这个项目值不值得做。

/weekly-review 可以自动识别停滞的项目，但它无法替你做出"继续还是放弃"的艰难决定。

AI 接管的是系统的运维层，你仍然拥有系统的决策层。

这个分工是健康的。运维层的工作是必要的，但它不应该消耗你的核心认知资源。核心认知资源应该用于决策层——那些需要你的价值观、判断力和创造力的工作。

一个人能做的最好的 Context Engineering，不是让 AI 越来越聪明，而是让自己越来越清楚：哪些工作应该属于 AI，哪些工作必须属于人。

这套系统试图回答这个问题。它给出的答案是：

维护，属于 AI。 判断，属于你。

「AI 生活操作系统」系列文章完

第一篇：当 LLM-Wiki 遇见真实生活——为什么 AI 知识库需要一个"操作系统"

第二篇：一个 Vault，两套逻辑——PARA × LLM-Wiki 融合架构的设计推演

第三篇（本文）：AI 作为系统管理员——用 Agent Schema 激活你的 Obsidian 生活操作系统

我是一只阿木木 | AI数字大脑实践者

扫码加入行动营👇

或搜索公众号：一只阿木木获取更多Obsidian + AI数字大脑方法论