LLM Wiki 升级计划 — 借鉴 Nowledge Mem 0.8

来源：Wey Gu（古思为）发布 Nowledge Mem v0.8，内置 Karpathy LLM Wiki 工作流。X 原文是 https://x.com/i/status/2049720331850625229 ，其中正文指向 Nowledge Labs 的文章 https://nowledge-labs.ai/zh/blog/llm-wiki 。

本文不是要照搬 Mem 的数据库架构，而是提炼它对我们两个系统的启发：

• Aperture：把现有 wiki viewer 从“能读”升级为“能探索、能溯源、能被 Agent 消费”。
• Obsidian Wiki 系统：把现有批处理吸收流程升级为“可追踪、可交互、可演化”的知识维护工作流。

核心架构差异必须先记住：Mem 的 Wiki 页面是从记忆、资料、结晶组成的数据层实时投影出来的；我们的 Wiki 是文件驱动的 markdown 系统。我们不追求实时投影，而是优先借鉴 Mem 的阅读体验、溯源模型、交互式摄入和 wiki ↔ graph 桥梁。

一句话机会

Nowledge Mem 0.8 证明了一件事：LLM Wiki 的价值不止是把 markdown 页面整理好，而是让每个页面同时具备四种能力：

1. 可读：像 wiki 一样点击、跳转、沉浸阅读。
2. 可追溯：知道由哪些来源合成，主要依据是什么。
3. 可探索：从页面一键进入图谱，看到局部连接形状。
4. 可回流：AI 在图谱上的研究输出能重新沉淀回知识库。

我们的现有系统已经有 raw → wiki → backlinks → graph → semantic trail 的基础，只缺少把这些能力串起来的产品层。

当前实施进度（2026-05-03）

实现层已经按 Phase 0-4 全部落地，并按“完成一个 task、验证后提交”的节奏拆成独立提交。当前剩余工作不是功能缺口，而是后续数据质量迭代：用新报告持续清理实体、断链、薄页面和来源 metadata。

已完成并提交：

• 1ac0e24 — Aperture wiki → graph focus bridge + Sources 溯源展示。
• 34a5fbd — 新增交互式 /wiki-triage skill 初版。
• b07cb81 — 来源贡献度 metadata：_source_contributions.json、贡献度排序、section/summary 展示。
• 32c2125 — 页面演化时间线：_evolution.json + ArticleView Evolution 区块。
• 470592b — 文章页 Local Graph：基于一跳邻居的轻量 mini graph。
• 45e9e88 — Per-page wiki API：/api/wiki/[...slug] 静态 JSON。
• bd0f353 — /llms.txt agent-readable wiki index。
• 39a7d48 — /llms-full.txt 全量 agent-readable wiki index。
• 704f3dc — 首页每个 category 显示最近更新信号。
• a1b978e — Topic/Cluster focus：/graph?cluster=<id> 聚类高亮。
• 1145d79 — Wiki snapshot export：npm run export:wiki 导出 markdown zip。
• 7d15268 — Graph research proposal export：npm run graph:proposal 支持 focus/cluster 研究回流草案。
• b963b2f — Wiki health report：npm run wiki:health 输出断链、薄页、孤岛、缺来源、过长页面等维护报告。
• 430d3a2 — Wiki entity detection report：npm run wiki:entities 输出实体 JSON、候选实体和未链接实体建议。

验证方式：

• 每个 task 完成后均运行 targeted ESLint 或等价静态检查。
• 多次运行 npm run build，真实 vault 最新静态导出为 694/694 页面。
• 使用内置浏览器验收了 wiki → graph focus、Sources/Evolution、Local Graph、首页 Latest per category、cluster focus。
• 使用脚本级 e2e 验证了 /api/wiki、/llms.txt、/llms-full.txt、export:wiki、graph:proposal、wiki:health、wiki:entities。
• dist/、exports/ 和 lib/semantic-clusters.json 的 build 噪声未纳入提交。

当前系统盘点

Aperture 当前状态

Aperture 是 Next.js wiki viewer，核心路径：

• app/wiki/[...slug]/page.tsx：加载单页文章、backlinks、semantic trail。
• components/ArticleView.tsx：渲染文章正文、元信息、semantic trail、backlinks。
• app/graph/page.tsx：加载全量文章并构建 graph data。
• components/GraphSwitcher.tsx：在 Network、Topo Map、Semantic、Nest Graph 之间切换。
• components/GraphView.tsx：Sigma.js network graph。
• lib/wiki-loader.ts：读取 markdown、解析 frontmatter、编译 HTML、提取 backlinks。
• lib/graph-builder.ts：从 wikilinks 构建图节点和边。
• lib/semantic-neighbors.ts：读取 semantic neighbor map。

本轮已补齐：

• wiki 页面和 graph 页面已经通过 /graph?focus=<slug> 与 /graph?cluster=<id> 连通。
• ArticleView 已显示结构化 Sources、贡献度、Evolution 和 Local Graph。
• 正文 ## Sources、_absorb_log.json、_source_contributions.json 已形成兼容溯源层。
• 已提供 per-page JSON API、/llms.txt 和 /llms-full.txt。
• graph exploration 已可生成 proposal markdown，再交给 wiki-triage/absorb 回流。

Obsidian Wiki 系统当前状态

Wiki 系统在 vault 内运行，核心资料：

• raw/：原始资料。
• wiki/：被吸收后的页面。
• wiki/_absorb_log.json：raw source 吸收状态、触达页面、hash。
• wiki/_backlinks.json：反向链接索引。
• .agents/skills/wiki-*：吸收、清理、查询、重建索引等技能。

本轮已补齐 / 后续运营化：

• 已新增 /wiki-triage，作为高价值单篇资料的交互式精读入口。
• 已新增 _source_contributions.json schema，用于记录 source → section 的贡献度。
• 已新增 _evolution.json schema，用于页面演化事件和谱系展示。
• 已新增 wiki:health 与 wiki:entities，用于持续发现断链、薄页、孤岛、缺来源、候选实体和未链接实体。
• “最近动静”已先在 Aperture category overview 层落地；更细的 Obsidian section 自动摘要可基于报告继续运营。

从 Nowledge Mem 0.8 抽出的可借鉴能力

总体实施原则

1. 先连通，不先重构
   P0 只做 wiki → graph 和 sources UI，不改 wiki 数据模型。

2. 先读现有证据，再引入新 schema
   当前 sources 的真实状态是 frontmatter 数字 + 正文 ## Sources + _absorb_log.json。P0 必须兼容这个现实。

3. 贡献度和演化链进入日志层，不硬塞进正文
   页面可以渲染这些信息，但 canonical data 应进入 _absorb_log.json 或独立 metadata 文件。

4. Aperture 做阅读/探索层，Wiki skill 做写入/维护层
   Aperture 尽量不直接写 vault；需要写入时生成 proposal，由 Obsidian Wiki 系统处理。

5. 所有新功能都要 Agent-readable
   API、llms.txt、sources metadata 不是附属品，而是 Agent-first 工作流的一部分。

Phase 0 — 校准与 P0 基础交付

目标：用最小改动打通 Aperture 的“页面 → 图谱”和“页面 → 来源”两条阅读路径。

时间建议：1-2 天。

Phase 0.1 — Plan 校准与现状固化

目标：把计划和真实代码/真实 wiki schema 对齐，避免后续实现踩空。

已确认事实：

• /graph 不是直接渲染 GraphView，中间有 GraphSwitcher。
• sources frontmatter 当前经常是数字，例如 sources: 1。
• 真实来源链接常在正文 ## Sources 段，例如 <a href="/wiki/raw/briefing/..." class="wikilink">...</a>。
• _absorb_log.json 记录 raw source 到 wiki_pages 的关系，可作为反查来源的补充。

产出：

• 本计划文件更新。
• P0 任务拆分为可直接执行的代码任务。

验收标准：

• P0 的文件路径、数据来源、实现步骤都和当前 repo 一致。

Phase 0.2 — Wiki → Graph 深入研究桥梁

目标：在每篇文章页加一个 View in Graph / 深入研究 按钮，点击进入 /graph?focus=<slug>，Network Graph 自动选中当前节点并居中。

用户体验：

• 用户在文章页读到某个概念。
• 点击右上角按钮。
• 进入 Graph 页面，默认打开 Network Graph。
• 当前文章节点被选中、高亮、居中。
• 节点信息卡显示在图谱上，用户可以继续打开邻居文章。

实现细节：

• components/ArticleView.tsx

  • header 区域加入按钮。
  • 链接为 /graph?focus=${encodeURIComponent(article.slug)}。
  • 使用 lucide 图标，例如 GitBranch 或 Network。

• app/graph/page.tsx

  • 接收 searchParams。
  • 读取 focus 参数并传给 GraphSwitcher。

• components/GraphSwitcher.tsx

  • props 增加 focusSlug?: string。
  • 如果有 focusSlug，默认保持 network view。
  • 将 focusSlug 传给 GraphView。

• components/GraphView.tsx

  • props 增加 focusSlug?: string。
  • 初始化 graph 后，如果 graph has node：
    • setSelected(focusSlug)。
    • camera animate 到该节点坐标。
    • 可选：把非邻居节点/边调低 opacity。
  • 如果 focus 不存在，静默显示普通 graph。

非目标：

• P0 不做主题页 cluster 高亮。
• P0 不做 Graph Intelligence。
• P0 不做局部展开算法，只利用现有全图。

验收标准：

• 从任意 /wiki/<slug> 点击按钮能进入 /graph?focus=<slug>。
• Network Graph 中该 slug 节点被选中并居中。
• 不存在 focus 时页面不报错。
• 不破坏 Topo/Semantic/Nest 切换。

风险：

• Sigma camera API 需要按当前版本确认。
• graph 初始化后再 focus，需要避免 race condition。

Phase 0.3 — 来源溯源展示

目标：在文章底部展示“由 N 个来源合成 / Sources”，让用户能看到这篇页面背后的 raw source。

关键校正：

P0 不应只解析 frontmatter sources，因为当前它通常是数字计数。正确策略应是多源兼容：

1. 优先解析正文 ## Sources / ## Source 段里的 wikilinks。
2. 如果正文没有 Sources 段，则通过 _absorb_log.json 反查哪些 raw source 的 wiki_pages 包含当前 slug。
3. frontmatter sources 只作为数量提示，不作为来源路径列表的唯一依据。

实现细节：

• lib/wiki-loader.ts

  • 新增 WikiSource 类型：

    interface WikiSource {
      path: string;
      label: string;
      href?: string;
      origin: 'body' | 'absorb_log' | 'frontmatter';
    }
    

  • 新增 extractSourcesFromContent(content: string): WikiSource[]：
    • 定位 ## Sources 段。
    • 提取 <a href="/wiki/raw/..." class="wikilink">label</a> 或 <a href="/wiki/raw/..." class="wikilink">raw/...</a>。
    • 也兼容 markdown links。
  • 新增 loadAbsorbLogSources(slug: string): WikiSource[]：
    • 读取 wiki/_absorb_log.json。
    • 找到 wiki_pages 包含当前 slug 的 raw source。
  • loadArticle 返回 sources: WikiSource[]。

• components/ArticleView.tsx

  • 在正文后、backlinks 前展示 Sources section。
  • 标题可以是 Sources 或 由 N 个来源合成。
  • 每个来源显示 label/path。
  • 对 raw wikilink 暂时可链接到 /wiki/raw/... 会失败，因此更稳妥的是先以不可点击 code/path 展示，或链接到未来 API/source route。

非目标：

• P0 不做贡献度排序。
• P0 不做浮窗预览 raw source。
• P0 不改 wiki 页面 frontmatter schema。

验收标准：

• 对含 ## Sources 的页面能显示来源列表。
• 对没有 Sources 段但在 _absorb_log.json 中有记录的页面能显示来源列表。
• 对只有 sources: 1 的页面不误把 1 当路径。
• 页面无来源时不显示空 section。

Phase 1 — 交互式摄入与来源贡献度

目标：把 Wiki 系统从“批处理吸收”扩展成“高价值资料可人工确认、来源贡献可追踪”的维护流程。

时间建议：1 周。

Phase 1.1 — /wiki-triage 交互式精读 Skill

目标：实现 Mem “和 AI 一起精读”的本地 wiki 版本：AI 读一篇 raw source，对照现有 wiki，提出保存建议，用户逐条确认。

适用场景：

• 高价值长文。
• 重要访谈/论文/教程。
• 用户不想让批处理自动写入，但希望 AI 先帮忙挑重点。

流程：

1. 用户调用 /wiki-triage raw/to-learn/article.md。
2. Skill 读取 raw source。
3. Skill 搜索相关 wiki 页面：
   • 标题/section/tag 命中。
   • backlinks 命中。
   • semantic neighbor 命中（如果可用）。
4. Skill 生成候选保存项：
   • 目标页面。
   • 新增/更新 section。
   • 建议写入内容摘要。
   • 可能的冲突。
   • 建议 wikilinks。
5. 用户确认：
   • 保存单条。
   • 全部保存。
   • 跳过。
   • 编辑后保存。
6. Skill 写入 wiki 页面并更新 _absorb_log.json。
7. 最后重建 index.md 和 _backlinks.json。

实现文件：

• .agents/skills/wiki-triage/SKILL.md
• .agents/skills/RESOLVER.md
• 可选：.agents/skills/wiki-triage/templates/proposal.md

数据写入：

_absorb_log.json 为每个 source 增加 triage 记录：

{
  "raw/to-learn/example.md": {
    "status": "triaged",
    "absorbed_at": "2026-05-02T00:00:00Z",
    "wiki_pages": ["harness-engineering/example.md"],
    "decisions": [
      {
        "target": "harness-engineering/example.md",
        "action": "saved",
        "sections": ["## 核心模式"],
        "summary": "Added note about interactive LLM Wiki intake."
      }
    ]
  }
}

验收标准：

• 能对单个 raw 文件生成候选保存项。
• 用户可以逐条确认。
• 确认后写入 markdown 页面。
• _absorb_log.json 记录 source、target page、sections、decision。

Phase 1.2 — 来源贡献度排序

目标：让每个页面不仅知道“有哪些来源”，还知道“哪些来源贡献最大、贡献了哪些 section”。

贡献度计算初版：

• high：新增或重写主要 section，或贡献页面核心观点。
• medium：补充已有 section 的关键证据/案例。
• low：只补充少量背景、链接或日期。

建议 schema：

不要立即把复杂结构写进每篇 frontmatter；先写入 _absorb_log.json 或新文件 wiki/_source_contributions.json，避免破坏现有 markdown 简洁性。

{
  "harness-engineering/llm-wiki-upgrade-plan.md": [
    {
      "source": "raw/to-learn/Nowledge Mem 0.8：LLM Wiki - Wey Gu.md",
      "contribution": "high",
      "sections": ["## 从 Nowledge Mem 0.8 抽出的可借鉴能力"],
      "summary": "Provided feature inventory and architecture boundary."
    }
  ]
}

Aperture 渲染策略：

• P1 后 ArticleView 的 Sources section 可升级为贡献度排序。
• 每条来源显示 contribution badge。
• 展示“贡献到哪些 section”的摘要。

验收标准：

• 新吸收的 source 能记录 contribution。
• 旧页面即使没有 contribution metadata，也能 fallback 到 P0 sources UI。
• 排序稳定：high > medium > low > unknown。

Phase 2 — 演化链、Mini Graph、API

目标：把 wiki 页面从静态文章升级成“有谱系、有局部网络、有机器接口”的知识节点。

时间建议：2 周。

Phase 2.1 — 演化时间线

目标：记录页面内容如何从来源、旧页面、旧观点演化到当前页面，以及它后来流向哪里。

事件类型：

• created_from_source：由 raw source 创建。
• updated_from_source：由 raw source 更新。
• merged_from_page：从另一个 wiki page 合并而来。
• split_to_page：从当前页面拆出新页面。
• renamed_to：页面重命名。
• superseded_by：被新页面或新观点替代。

建议 schema：

{
  "harness-engineering/example.md": {
    "events": [
      {
        "date": "2026-05-02",
        "type": "updated_from_source",
        "source": "raw/to-learn/example.md",
        "sections": ["## 核心概念"],
        "summary": "Added evidence from Nowledge Mem 0.8."
      }
    ],
    "evolved_from": ["raw/to-learn/example.md"],
    "evolved_to": []
  }
}

Aperture 渲染：

• ArticleView 底部 Sources 后展示 Evolution。
• 只显示最近 3-5 个事件。
• API 返回完整 events。

验收标准：

• wiki-absorb/wiki-triage 写入时能追加 evolution event。
• 页面能展示近期演化记录。
• 旧页面无 event 时不显示空 section。

Phase 2.2 — Mini Graph on Wiki Page

目标：在文章页显示当前页面的局部连接形状。

初版范围：

• 当前页面。
• backlinks。
• outgoing wikilinks。
• semantic neighbors 前 5-10 个。
• 总节点数控制在 20 以内。

实现方式：

• 新增 components/MiniGraph.tsx。
• 初版用 SVG，不加载完整 Sigma.js，降低复杂度。
• 从 app/wiki/[...slug]/page.tsx 组装 mini graph data。
• 节点点击跳转到对应 /wiki/<slug>。

后续升级：

• 如果 SVG 体验不够，再复用 Sigma.js。
• 主题页 cluster shape 另做，不塞进初版。

验收标准：

• ArticleView 能显示当前页 + 邻居的局部图。
• 节点可点击。
• 移动端不挤压正文。
• 无邻居时不显示空图。

Phase 2.3 — Per-page Wiki API

目标：让 Agent 和脚本可以通过 HTTP 取单页 wiki JSON。

路由：

• app/api/wiki/[...slug]/route.ts

返回字段：

{
  "slug": "harness-engineering/example",
  "title": "Example",
  "category": "harness-engineering",
  "content": "markdown body",
  "html": "<p>...</p>",
  "frontmatter": {},
  "sources": [],
  "backlinks": [],
  "semantic_neighbors": [],
  "evolution": []
}

验收标准：

• /api/wiki/harness-engineering/example 返回 JSON。
• 不存在页面返回 404。
• JSON 中 sources/backlinks/semantic_neighbors 与页面 UI 使用同一套 loader。

Phase 2.4 — llms.txt / llms-full.txt

目标：为 Agent-first 消费提供入口文件。

实现：

• 新增 scripts/generate-llms-txt.ts。
• 读取 loadWikiIndex() 或直接扫 wiki。
• 输出：
  • public/llms.txt：短说明 + 关键入口。
  • public/llms-full.txt：所有页面标题、摘要、URL、section。

验收标准：

• build 前可生成两个文件。
• 文件内容稳定、可 diff。
• 不超过合理大小；full 版可控制在 50-100KB。

Phase 3 — 动态主题页与研究回流

目标：接近 Mem 的“读 → 深入研究 → 产出 → 回流 Library”闭环。

时间建议：1 个月以上，按价值分块推进。

Phase 3.1 — 每个 Section 的“最新动静”

目标：回答“我最近在这个主题上想到了什么/吸收了什么”。

实现：

• 从 _absorb_log.json.latest_entry 和历史 entries 取最近 touched pages。
• 按 section 聚合。
• 在 section overview 页面显示最近更新列表。

验收标准：

• 每个 overview 能显示最近 5-10 条相关更新。
• 更新项能链接到页面和来源。

Phase 3.2 — Topic/Cluster Focus

目标：实现 Mem 中“主题页点深入研究，高亮整个聚类”的体验。

依赖：

• lib/semantic-clusters.json
• wiki section/topic 与 cluster id 的映射规则。

实现方向：

• /graph?cluster=<id>。
• GraphSwitcher 默认打开 semantic view 或 network view。
• KnowledgeMap / GraphView 支持 cluster highlight。

验收标准：

• 从 cluster/section 页面进入 graph 后，相关节点被高亮。
• 非 cluster 节点弱化。

Phase 3.3 — Graph Intelligence 回流

目标：在图谱探索后，让 AI 生成研究总结、矛盾清单或新 crystal proposal，并能回流到 wiki。

本地化实现方式：

• Aperture 不直接写 vault。
• Aperture 生成 proposal markdown 或 JSON。
• 用户交给 /wiki-triage 或 /wiki-absorb 确认写入。

可能产物：

• raw/generated/graph-research/<date>-<topic>.md
• 或 wiki/_proposals/<slug>.md

验收标准：

• 用户能从 graph focus 上下文生成一份 proposal。
• proposal 包含来源节点、观察、冲突、建议写入页面。
• 经过 triage 后能回流 wiki。

Phase 3.4 — Wiki Export / ZIP

目标：把当前 wiki 打包为可在 Obsidian/Logseq/任意 markdown reader 中打开的 snapshot。

现状：

我们天然已经是 markdown 文件系统，因此不需要像 Mem 一样从数据库导出。需要补的是用户级导出入口。

实现：

• CLI/script：把 wiki/ 打包成 zip。
• 可选 Aperture API：触发下载 snapshot。

验收标准：

• 导出的 zip 包含 index.md、wiki pages、metadata。
• wikilinks 在 Obsidian 中可跳转。

Phase 4 — 自动实体与质量评估

目标：把 wiki 从“人工/LLM 写链接”进一步升级为“自动发现实体、别名、质量问题”的长期维护系统。

时间建议：长期探索。

Phase 4.1 — 实体检测与别名

目标：借鉴 Mem 的实体页：实体属于哪个主题、首次出现、置信度、别名、相邻实体。

实现方向：

• 从 wiki/raw 中抽取人名、项目、产品、概念。
• 建立 wiki/_entities.json。
• 记录 aliases、confidence、first_seen、mentions。

验收标准：

• 能发现未链接但频繁出现的实体。
• 能建议新增 wikilink。
• 不自动大规模改正文，先生成 report。

Phase 4.2 — Wiki Health / Quality Report

目标：定期发现重复条目、薄页面、过长页面、过期 claims、断链。

实现方向：

• 扩展现有 wiki-status/wiki-cleanup skills。
• 输出质量报告。
• 可自动修复低风险问题。

验收标准：

• 能列出 top risks。
• 每项有建议操作。
• 与 _absorb_log.json、_backlinks.json、semantic data 联动。

优先级总表

推荐开工顺序

Phase 0
├── 0.1 校准 plan 与真实代码路径
├── 0.2 ArticleView → /graph?focus=<slug>
└── 0.3 ArticleView Sources section

Phase 1
├── 1.1 /wiki-triage skill
└── 1.2 source contribution metadata

Phase 2
├── 2.1 evolution timeline schema + rendering
├── 2.2 MiniGraph component
├── 2.3 /api/wiki/[...slug]
└── 2.4 llms.txt generation

Phase 3
├── 3.1 section latest updates
├── 3.2 cluster focus
├── 3.3 graph intelligence proposal回流
└── 3.4 wiki export zip

Phase 4
├── 4.1 entity detection / aliases / confidence
└── 4.2 wiki health report

P0 详细任务清单

Task P0-A — ArticleView 加深入研究按钮

• 修改 components/ArticleView.tsx。
• header 区域布局支持 title + action button。
• 按钮 href 为 /graph?focus=<slug>。
• 文案：View in Graph 或 深入研究。
• 移动端按钮不挤压标题。

Task P0-B — Graph page 读取 focus query

• 修改 app/graph/page.tsx props，支持 searchParams。
• 解析 focus。
• 传给 GraphSwitcher。

Task P0-C — GraphSwitcher 透传 focus

• 修改 components/GraphSwitcher.tsx props。
• 将 focusSlug 传给 GraphView。
• 确保有 focus 时默认 network view。

Task P0-D — GraphView focus 高亮/居中

• 修改 components/GraphView.tsx props。
• graph 初始化后检查 graph.hasNode(focusSlug)。
• setSelected(focusSlug)。
• camera animate 到节点坐标。
• 不存在节点时 no-op。

Task P0-E — Sources parser

• 修改 lib/wiki-loader.ts。
• 新增 WikiSource。
• 从正文 ## Sources 段提取 wikilinks。
• 从 _absorb_log.json 反查 source。
• loadArticle 返回 sources。

Task P0-F — ArticleView 渲染 Sources

• 修改 components/ArticleView.tsx。
• 正文后、backlinks 前显示 Sources。
• 显示 source label/path。
• 无来源时隐藏。

Task P0-G — 验证

• npm run lint 或现有检查命令。
• npm run build。
• 本地打开 wiki 页面，检查按钮。
• 从按钮跳 graph，检查 focus。
• 抽查含 ## Sources 页面。
• 抽查只有 absorb_log 记录的页面。

数据模型建议

当前兼容层

interface WikiSource {
  path: string;
  label: string;
  href?: string;
  origin: 'body' | 'absorb_log' | 'frontmatter';
}

P1 Contribution 层

interface SourceContribution {
  source: string;
  contribution: 'high' | 'medium' | 'low' | 'unknown';
  sections: string[];
  summary?: string;
  addedAt?: string;
}

P2 Evolution 层

interface EvolutionEvent {
  date: string;
  type:
    | 'created_from_source'
    | 'updated_from_source'
    | 'merged_from_page'
    | 'split_to_page'
    | 'renamed_to'
    | 'superseded_by';
  source?: string;
  fromPage?: string;
  toPage?: string;
  sections?: string[];
  summary?: string;
}

重要边界

1. 不要把 Mem 的实时投影当成短期目标
   我们的优势是 markdown repo 可读、可 diff、可被任何工具消费。

2. 不要把 P0 Sources 做成假溯源
   如果只有 sources: 1，就只能显示数量或 fallback 到 _absorb_log.json，不能制造不存在的来源路径。

3. 不要让 Aperture 直接写 Obsidian vault
   写入属于 wiki skill。Aperture 可以生成 proposal，但最终由 /wiki-triage 或 /wiki-absorb 落盘。

4. 不要一开始做复杂图谱交互
   Graph focus 是 P0；Mini graph、cluster highlight、Graph Intelligence 是后续阶段。

5. 所有 metadata 必须向后兼容
   旧页面没有 contribution/evolution 时应该正常渲染。

Related

• harness-engineering/overview — 腾讯 AI Team 知识沉淀体系，与本计划的知识管理思路对应
• harness-engineering/ai-search-visibility — Tw93 的 AI 搜索可见性方法论，llms.txt/JSON-LD/知识端点与 Per-page API 直接关联
• claude-code/overview — Claude Code 的 CLAUDE.md schema 是 Agent 可消费知识的参考
• harness-engineering/your-harness-your-memory — Harrison Chase 论 harness 与记忆的深度耦合
• ai-ecosystem/graphify-karpathy-knowledge-base — Graphify 对 Karpathy LLM Wiki 的图谱化实现参考