Knowledge

知识技能

功能

管理 LifeOS 知识档案库——一个经过整理、类型明确的图谱，包含六个实体领域的笔记：人物、公司、想法、研究、博客和书籍。操作包括搜索、添加、收集、完善、摄取、查找矛盾、图谱遍历、压缩检索，以及从近期对话中挖掘记忆候选项。每篇笔记都附有带类型的 related: 交叉链接，因此档案库是相互关联的图谱，而不是一堆文件。

问题

孤立保存的笔记，往往再也找不到。平铺的事实文件夹无法告诉你两篇笔记是否相互矛盾、新来源是否更新了旧说法，或某个想法是否与你几个月前记录的人物和公司有关联。无法检索或关联的知识终将消亡。这个档案库会强制所有笔记采用带有必需交叉链接的类型化架构，并在摄取时将更新传递到相关笔记中，因此关联在写入时就已建立，无需日后手动重建。

工作方式

在 ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/ 管理 LifeOS 知识档案库。每项操作都会路由到下方的子命令；笔记遵循档案库架构，并附带带类型的交叉链接。

档案库架构： ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/_schema.md

工作流路由

工作流以内联命令章节的形式写在本文件中（没有 Workflows/ 目录）；每一行都会路由到下方对应的 H2 章节。

触发条件	工作流	操作
/knowledge（无参数）	状态	健康状况仪表板
/knowledge <query>	搜索	搜索与查询匹配的笔记
/knowledge search <query>	搜索	显式搜索
/knowledge add <type>	添加	创建新笔记（人物、公司或想法）
/knowledge harvest	收集	对所有来源运行 KnowledgeHarvester
/knowledge develop	完善	找出幼苗笔记并补充内容
/knowledge ingest <url-or-file>	摄取	读取来源、创建笔记，并将更新传递到相关笔记
/knowledge contradictions	矛盾	查找并审阅笔记中的矛盾说法
/knowledge graph	图谱	知识图谱统计与导航
/knowledge graph <slug>	图谱	从某篇笔记开始遍历图谱
/knowledge retrieve <query>	检索	压缩上下文检索
/knowledge mine	挖掘	从近期对话中挖掘记忆候选项

如果 $ARGUMENTS 与任何子命令都不匹配，则将其视为搜索查询。

---

status（默认，无参数）

运行收集器状态命令并显示结果：

bun ~/.claude/LIFEOS/TOOLS/KnowledgeHarvester.ts status

另外显示：

• 各领域的笔记数量摘要
• 孤立的 wikilink
• 过时的幼苗笔记
• 距离上次收集经过的时间

以 NATIVE 模式呈现。

---

search

在知识档案库中搜索与 $ARGUMENTS 匹配的笔记。

步骤 1 — 词法搜索：

rg -i "$ARGUMENTS" ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/ --type md -l

步骤 2 — Frontmatter 搜索（标签和标题）：

rg -i "title:.*$ARGUMENTS|tags:.*$ARGUMENTS" ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/ --type md -l

步骤 3 — Wikilink 搜索：

rg "\[\[.*$ARGUMENTS.*\]\]" ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/ --type md -l

合并三个步骤的结果并去重。对于每个匹配项，读取 frontmatter 的前 5 行，以显示标题、领域、状态和标签。

以表格形式呈现结果：

| Note | Domain | Status | Tags | Relevance |

如果没有找到结果，请说明这一点，并建议检查完整的 MEMORY/ 系统或运行一次收集。

---

add

在指定的实体类型中手动创建一条新笔记。

1. 验证类型是否为以下之一：People、Companies、Ideas、Research
2. 询问标题（或使用 type 后面的剩余参数）
3. 根据标题生成 kebab-case 文件名
4. 必须：先查找 2-3 条相关笔记。 写入新笔记之前，按主题／标签／名称搜索现有 Knowledge 中的相关实体。将其添加到 related: frontmatter 数组中。Knowledge 笔记必须包含有类型的链接。参见下文的规范链接要求。
5. 根据 _schema.md 中的 frontmatter 规范创建笔记——验证器（LIFEOS/TOOLS/KnowledgeSchema.ts ENVELOPE）要求以下 8 项全部齐全：id（通过 mintId(slug, created) 生成——kb_ + 12 位十六进制字符）、type、title、tags（至少 1 个）、quality（0-10）、created、updated、convention: kb-v3——以及类型专属的正文部分。使用旧版六字段列表创建的笔记永远无法通过验证（公开 issue #1678，@christauff）。将 created: 和 updated: 设为今天的日期，使用 date +%Y-%m-%d 获取——这是归档条目的日期，而不是来源的发布日期（公开 PR #1604，@asdf8675309）。
6. 将文件写入 KNOWLEDGE/<Type>/<kebab-case-title>.md——slug 最长 60 个字符
7. 保存前验证 related: 中的每个 slug 均存在于归档中
8. 重新生成该类型的 MOC：

bun ~/.claude/LIFEOS/TOOLS/KnowledgeHarvester.ts index

主题是标签，不是类型。 一条安全见解属于带有 security 标签的 Idea。一家安全公司属于带有 security 标签的 Company。实体类型决定架构；标签决定主题。

规范链接要求（必须遵守）

每条新 Knowledge 笔记都必须包含带类型的交叉链接。 这不是可选项。架构定义见 MEMORY/KNOWLEDGE/Ideas/pai-knowledge-linking-architecture.md（quality 9），规范定义见 _schema.md。

每次写入都必须包含：

1. related: frontmatter 数组——包含 2-4 个带类型的条目，链接到其他 Knowledge 条目（任意领域：People、Companies、Ideas、Research）
2. 正文 wikilinks——在自然的位置（Implications、Evidence 或 Context 部分）融入 1-3 个 [[slug]] 引用

9 种关系类型（选择最准确的类型，优先使用具体类型而非通用类型）：

Type	含义
related	通用关联（仅在没有更合适的类型时使用）
supports	为所链接的笔记提供证据
contradicts	与所链接的笔记相冲突
extends	在所链接的笔记基础上扩展
part-of	属于更大整体的组成部分
instance-of	某种模式的示例
caused-by	是所链接笔记的结果
preceded-by	时间上先于所链接的笔记
derived-from	从所链接的源笔记中提炼而来（例如：博客 → 想法）

Frontmatter 格式：

related:
  - slug: other-note-slug
    type: extends
  - slug: another-note-slug
    type: supports

写入前如何查找相关笔记：

# By topic/keyword
rg -l "TOPIC" ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/ --type md

# By tag overlap
rg "^tags:.*TAG" ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/ --type md -l

# For People/Companies — grep by name
rg -l "Person Name" ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/

强制要求：

• 跳过 related: 的写入是不完整的，必须在 skill/workflow 返回成功前修复
• ingest 工作流会在 ripple pass 中执行此操作
• Algorithm 的 LEARN 阶段会在其知识捕获步骤中执行此操作
• 所有写入 Knowledge 条目的 Agent 都必须遵守此规则——这是规范的一部分，而非可选增强项

---

harvest

运行 KnowledgeHarvester，从所有 LifeOS 来源提取新知识：

bun ~/.claude/LIFEOS/TOOLS/KnowledgeHarvester.ts harvest

显示结果。如果没有提取到任何内容，请说明来源已是最新状态。

可选接受 --source 筛选器：/knowledge harvest work 或 /knowledge harvest memory。

---

develop

每周园艺工作流。展示可供扩充的幼苗笔记。

步骤 1 — 查找幼苗：

rg "^status: seedling" ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/ --type md -l

步骤 2 — 逐个处理幼苗：

• 阅读笔记
• 阅读相关笔记（跟进维基链接，搜索相同标签）
• 检查是否有更新的 WORK/ ISA 或自动记忆条目包含相关上下文
• 扩充笔记：添加上下文、建议维基链接、充实内容

步骤 3 — 向用户展示差异以供批准。

步骤 4 — 如果获批：

• 写入更新后的笔记
• 将状态从 seedling 提升为 budding（若内容全面，则提升为 evergreen）
• 使用 date +%Y-%m-%d 将 updated: 更新为今天的日期；保留 created: 不变
• 重新生成受影响的 MOC

如果不存在幼苗，则报告归档库已整理干净。

---

ingest

将来源导入知识归档库。这是受 Karpathy 启发的关键升级：阅读来源不只是创建一篇笔记，还会逐步更新现有的相关笔记。

**如果未提供参数：**显示用法：/knowledge ingest <url-or-file-path>

步骤 1 — 获取来源

• **URL：**使用 WebFetch 获取并阅读内容。如果 WebFetch 失败，则尝试通过 Bash 使用 curl -sL。
• **文件路径：**使用 Read 工具读取本地文件。

用 2-3 句话总结来源。识别关键实体、主张和见解。

步骤 2 — 分类并创建主笔记

根据 _schema.md 中的分类规则确定实体类型（People、Companies、Ideas 或 Research）。大多数导入的来源属于 Ideas。

使用该类型对应的架构创建主笔记：

• 根据标题生成 kebab-case slug（最多 60 个字符）
• 使用正确的 frontmatter 写入 KNOWLEDGE/<Type>/<slug>.md
• 将 created: 和 updated: 都设为使用 date +%Y-%m-%d 获取的今天日期——两者记录的是笔记进入归档库的时间，而非来源的发布日期。明确注明的发布日期应放在 source_date: 中；绝不能将其填入 created:，也绝不能猜测来源未注明的日期（公开 PR #1604，@asdf8675309）
• 在 frontmatter 中加入 source_url: 或 source_path:
• 必须：加入包含 2-4 个带类型链接的 related: 数组——涟漪检查（步骤 3）会确定这些链接，必须在创建主笔记时写入 frontmatter，不能事后添加

步骤 3 — 涟漪检查（关键创新）

搜索与此新内容相关的现有笔记：

# Search by extracted tags
rg -i "TAG1|TAG2|TAG3" ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/ --type md -l --glob '!_*'

# Search by key entities/concepts mentioned
rg -i "ENTITY1|ENTITY2" ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/ --type md -l --glob '!_*'

对于找到的每篇相关笔记（最多 10 篇）：

1. 阅读笔记
2. 判断新来源是否补充了信息或上下文，或与现有主张相矛盾
3. 如果是，提出具体更新（添加维基链接、添加证据、注明矛盾）

向用户展示涟漪计划：

📥 INGEST RIPPLE PLAN:
  PRIMARY: Ideas/new-note-slug — "Title" (created)
  PRIMARY related: frontmatter links (MANDATORY):
    → Ideas/existing-note-1 — type: extends
    → Ideas/existing-note-2 — type: supports
    → People/person-slug — type: related
  RIPPLE (reverse-direction updates to existing notes):
    → Ideas/existing-note-1 — add body [[new-note-slug]] wikilink + add to its related: array (type: extends)
    → Ideas/existing-note-2 — update Evidence section with new data point + add to related:
    → Ideas/existing-note-3 — ⚠️ CONTRADICTION: new source says X, note says Y — type: contradicts
  NO CHANGE: Ideas/tangentially-related — mentioned same tag but no substantive connection

步骤 4 — 执行涟漪更新

用户批准后（或者你判断更新只是低风险的交叉引用时）：

• 主笔记：确保 related: frontmatter 数组中包含 2-4 个带类型条目——这是必需项，不是可选项
• 相关笔记：在其 frontmatter 中添加反向 related: 条目，并注明适当类型
• 正文维基链接：在自然的现有文字中添加 [[wikilinks]]（不要生硬插入）
• 对已修改的笔记，使用 date +%Y-%m-%d 将 updated: 更新为今天的日期；保留其 created: 不变
• 对于矛盾：添加 > ⚠️ **矛盾：**[note] 声称 X——请参阅 [[new-note]] 中的反证 提示块，并在 related: 数组中添加 type: contradicts

步骤 5 — 记录并编入索引

追加到 KNOWLEDGE/_log.md：

## [YYYY-MM-DD] ingest | Title
- Source: <url or path>
- Primary: <Type>/<slug>
- Ripple: N notes updated, N contradictions flagged

重新生成 MOC：

bun ~/.claude/LIFEOS/TOOLS/KnowledgeHarvester.ts index

以 NATIVE 模式呈现。

---

contradictions

查找并审阅知识笔记中相互矛盾的主张。

步骤 1 — 获取矛盾候选项

运行 KnowledgeHarvester 矛盾查找器：

bun ~/.claude/LIFEOS/TOOLS/KnowledgeHarvester.ts contradictions

这会输出标签重合度较高（共享 2 个或更多标签）的笔记对，并按重合标签数量排序。

步骤 2 — 语义审查

对于每一对（最多选重合度最高的 10 对）：

1. 阅读两条笔记
2. 从每条笔记中提取关键主张（论点、证据、关键事实部分）
3. 检查是否存在：
   • 直接矛盾 — 笔记 A 说 X，笔记 B 说非 X
   • 时间上的取代 — 笔记 B 的较新证据使笔记 A 的主张过时
   • 范围冲突 — 两条笔记都声称对同一主题具有权威性，但结论不同

步骤 3 — 报告

呈现发现：

🔍 CONTRADICTION SCAN:
  Pairs checked: N
  Contradictions found: N
  Superseded claims: N

  ⚠️ CONTRADICTION:
    [[note-a]] claims: "X"
    [[note-b]] claims: "Y"
    Resolution: [suggest which is correct, or flag for the user]

  📅 SUPERSEDED:
    [[older-note]] (2026-01-15): "X was true"
    [[newer-note]] (2026-03-20): "X is no longer true because Y"
    Action: Update older note with correction

步骤 4 — 修正（需批准）

如果用户批准了解决方案：

• 使用更正提示框更新存在矛盾的笔记
• 使用 > 📅 **Updated:** See [[newer-note]] for current information 更新已被取代的笔记
• 更新 updated: 日期
• 重新生成 MOC

以 NATIVE 模式呈现。

---

graph [slug]

以图的形式浏览知识档案。

不带参数 — 统计概览：

bun ~/.claude/LIFEOS/TOOLS/KnowledgeGraph.ts stats

显示节点数、边数、主要集群、连接最多的枢纽和孤立节点。

带 slug — 从一条笔记开始遍历：

bun ~/.claude/LIFEOS/TOOLS/KnowledgeGraph.ts traverse <slug> --hops 2

显示通过标签、wikilink 和类型关系在 2 跳范围内关联的所有笔记。适合探索不同领域的知识如何相互关联。

仅显示相关笔记：

bun ~/.claude/LIFEOS/TOOLS/KnowledgeGraph.ts related <slug>

以 NATIVE 模式呈现。

---

retrieve

使用 BM25-lite 评分，在知识档案中检索压缩后的上下文。

bun ~/.claude/LIFEOS/TOOLS/MemoryRetriever.ts "<query>" --top 5

返回排名靠前的匹配笔记及其压缩摘要，按标题匹配度、标签重合度和内容频率排序。适合加载相关知识上下文，而无需阅读完整文件。

如需未经 LLM 压缩的原始摘录：

bun ~/.claude/LIFEOS/TOOLS/MemoryRetriever.ts "<query>" --raw

以 NATIVE 模式呈现。

---

mine

从近期对话中挖掘可作为记忆的候选内容（决策、偏好、里程碑、问题）。

bun ~/.claude/LIFEOS/TOOLS/SessionHarvester.ts --mine --recent 10

候选内容会写入 KNOWLEDGE/_harvest-queue/ 供审查，绝不会直接写入 KNOWLEDGE/。使用 /knowledge harvest 处理队列。

如需试运行（仅预览）：

bun ~/.claude/LIFEOS/TOOLS/SessionHarvester.ts --mine --recent 10 --dry-run

以 NATIVE 模式呈现。

---

注意事项

• 现在有 4 种实体类型。 人物（人类）、公司（组织）、理念（见解／论点／分析）、研究（采用方法论的多来源调查）。如果不属于其中任何一种，就不算知识，应归入 WORK/ 或 LEARNING/。
• 主题 = 标签，而非领域。 安全见解是带有 security 标签的理念。绝不要创建基于主题的文件夹。
• 查找测试。“用户会按名称查找它吗？”——如果不会，它就不算知识。
• 架构强制执行。 每种实体类型都有 _schema.md 中定义的必填字段。写入前务必先阅读架构。
• 算法的 LEARN 阶段会直接写入。 LEARN 阶段拥有最佳上下文，因此会按照正确架构写入 KNOWLEDGE/。收集器的反思功能已禁用。
• 未经询问，绝不删除笔记。 清理会自动进行（通过收集器在 90 天后让幼苗过期）。手动删除需要用户批准。
• Wikilink 使用严格的 kebab-case。 使用 [[prompt-injection]]，而非 [[Prompt Injection]]。
• 所有收集的笔记最初都是幼苗。 只有 /knowledge develop 会将其升级。
• 时间有效性为可选项。 笔记可以通过 frontmatter 字段 valid_from／valid_until 跟踪事实为真的时间。矛盾检测器会利用这些字段跳过时间范围不重叠的内容。

示例

示例 1：搜索档案

User: "what do we know about prompt injection?"
→ Routes to search — 3-pass (lexical + frontmatter + wikilink) over MEMORY/KNOWLEDGE/
→ Returns table of matching notes with domain, status, tags

示例 2：摄取来源

User: "/knowledge ingest https://example.com/article"
→ Fetches the source, classifies entity type, creates primary note with typed related: links
→ Ripple pass proposes updates to existing related notes; user approves; MOCs regenerated

示例 3：状态检查

User: "knowledge status"
→ Runs KnowledgeHarvester.ts status
→ Shows domain note counts, orphan wikilinks, stale seedlings, time since last harvest