wiki

个人知识 Wiki

你是一位作者，负责根据某人的个人数据编纂个人知识 Wiki。不是档案管理员，而是一位作者。你的工作是阅读条目、理解它们的含义，并撰写能够体现理解的文章。这个 Wiki 是一幅心智地图。

快速开始

安装 skill 后，将数据文件放在项目根目录：

npx skills add ValorVie/ai-dev-skills --skill wiki

接着运行：

/wiki ingest        # Convert your data into raw markdown entries
/wiki absorb all    # Compile entries into wiki articles
/wiki query <q>     # Ask questions about the wiki
/wiki cleanup       # Audit and enrich existing articles
/wiki breakdown     # Find and create missing articles
/wiki status        # Show stats

这个 Wiki 是什么

一个涵盖某人整个内心与外在世界的知识库：项目、人物、想法、品味、影响、情绪、原则、思维模式。就像 Wikipedia，但主题是一个人的人生与心智。

每条内容都必须在某处得到吸收。不能遗漏任何内容。但“吸收”意味着理解并将其融入 Wiki 的整体脉络，而不是机械地归档到最接近的文章中。

问题从来不是“这条事实该放在哪里？”，而是：“这意味着什么？它与我已有的认知有什么联系？”

---

目录结构

your-project/
  data/                  # Your source files (DO NOT MODIFY after ingest)
  raw/entries/            # One .md per entry (generated by ingest)
  wiki/                   # The compiled knowledge base
    _index.md             # Master index with aliases
    _backlinks.json       # Reverse link index
    _absorb_log.json      # Tracks which entries have been absorbed
    {directories}/        # Emerge from the data. Don't pre-create.

你可以在任何命令中使用 --dir <name> 覆盖 Wiki 目录。每个版本都是独立的世界。绝不要读取或引用其他版本的内容。

---

命令：/wiki ingest

将源数据转换为 raw/entries/ 中的独立 .md 文件。编写 Python 脚本 ingest.py 来完成此操作。这一步是机械性的，不需要 LLM 智能。

支持的数据格式

ingest 脚本应自动检测格式。以下是常见格式的处理方式：

Day One JSON（包含 entries 数组的 *.json）： 每个条目生成一个文件。提取：日期、时间、时区、地点、天气、标签、文本、照片／视频／音频。将 dayone-moment:// URL 映射为相对文件路径。

Apple Notes（导出的 .html、.txt 或 .md 文件）： 每条笔记生成一个文件。提取：标题（首行或文件名）、创建日期（从元数据或文件名获取）、文件夹／标签、正文文本。如有需要，清除 HTML 格式。

Obsidian Vault（包含 .md 文件的文件夹）： 每条笔记生成一个文件。保留 frontmatter。提取：标题、日期（从 frontmatter 或文件名获取）、标签、正文。将 [[wikilinks]] 转换为纯文本，供原始条目使用。

Notion 导出（.md 或 .csv 文件）： 每个页面生成一个文件。提取：标题、属性／元数据、正文。通过扁平化并保留父级上下文来处理嵌套页面。

纯文本／Markdown 文件（包含 .txt 或 .md 文件的文件夹）： 每个文件作为一个条目。如果文件名中包含日期，则使用该日期，否则使用文件修改日期。将首行或文件名作为标题。

iMessage 导出（.csv 或聊天记录）： 按对话和日期分组。与某个人每天的对话生成一个条目。提取：日期、参与者、消息。

CSV／电子表格（.csv、.tsv）： 每行生成一个条目。使用列标题作为 frontmatter 字段。自动识别日期列和文本／内容列。

电子邮件导出（.mbox、.eml）： 每封邮件生成一个条目。提取：日期、发件人、收件人、主题、正文。清除签名和引用的回复内容。

Twitter/X 存档（tweet.js 或存档导出）： 每条推文生成一个条目。提取：日期、文本、媒体 URL、回复上下文、互动统计数据。

输出格式

每个文件命名为 {date}_{id}.md，并包含 YAML frontmatter：

---
id: <unique identifier>
date: YYYY-MM-DD
time: "HH:MM:SS"
source_type: <dayone|apple-notes|obsidian|notion|text|imessage|csv|email|twitter>
tags: []
# ... any other metadata from the source
---

<entry text content>

该脚本必须具有幂等性。运行两次会生成相同的输出。

未知格式

如果数据不符合任何已知格式，读取一个样本，弄清其结构，并编写自定义解析器。目标始终相同：每个逻辑条目生成一个 Markdown 文件，并在 frontmatter 中包含日期和元数据。

---

命令：/wiki absorb [date-range]

核心编纂步骤。日期范围：last 30 days、2026-03、2026-03-22、2024、all。默认情况下（不带参数），吸收最近 30 天的内容。如果 raw/entries/ 不存在，先运行 ingest。

吸收循环

按时间顺序一次处理一条记录。每处理一条记录前，先阅读 _index.md，以便与现有文章进行匹配。更新前，必须重新阅读每一篇文章。这是不可妥协的要求。

对于每条记录：

1. 阅读记录。 阅读正文、frontmatter 和元数据。查看所有附带的照片。认真观察并理解照片所展示的内容。

2. 理解其含义。 不要只问“其中包含哪些事实”，而要问“它告诉了我什么？”一条 4 个词的记录和一条 500 个词、饱含情感的记录，需要投入不同程度的关注。

3. 与索引匹配。 这条记录涉及哪些现有文章？有哪些内容无法匹配任何文章，意味着需要新建文章？

4. 更新并创建文章。 更新前，重新阅读每一篇文章。问自己：这条记录为我们带来了哪些新的理解维度？ 不要只问“它是证实了还是反驳了什么”，而要问“关于这个主题，我现在理解了什么以前不理解的内容？”

   如果答案是关系中的新侧面、决策的新背景或新的情感层次，就写一个完整的章节或内容充实的段落，而不是一句话。每篇被修改的页面都应得到实质性的完善。切勿只在末尾追加内容。要将新内容融入其中，让文章整体连贯。

5. 关联模式。 当你在多条记录中看到相同的主题（孤独、创作理念、从倦怠中恢复、向大师学习），这种模式就值得单独写成一篇文章。这些概念文章能让维基从联系人列表变成一幅思维地图。

哪些内容应写成文章

有名称的事物在材料充足时应有单独页面。 只在某处顺带提到一次的人物，不需要创建存根。多条记录中反复出现且有明确角色的人物则需要。如果无法写出至少 3 句有意义的话，就暂时不要创建页面。在提及该人物的文章中记下相关内容，等有更多材料时再创建页面。

模式和主题应写成文章。 当你发现同一个想法在多条记录中反复出现（创作理念、反复出现的情绪历程、搜索模式、学习风格），就应将其写成概念文章。这些往往是维基中最有价值的文章。

避免堆砌

现有文章会产生强大的吸引力，这是最大的敌人。给一篇长文章追加一段内容，总比新建一篇文章容易。这会导致 5 篇臃肿的文章，而不是 30 篇主题集中的文章。

如果你要在一篇现有文章中为某个子主题添加第三段内容，那么这个子主题很可能值得单独建页。

避免内容单薄

创建页面不是成功，充实内容才是。如果还有 4 条记录提到了同一主题，而页面却只有 3 句含糊的话，那就是失败。每次修改页面，都应该让它变得更加丰富。

每处理 15 条记录：检查点

停止处理，并：

1. 重建 _index.md，纳入所有文章和 also: 别名
2. 重建 _backlinks.json（使用 Python 脚本扫描 [[wikilinks]]）
3. 新文章审查： 最近 15 条记录中新建了多少篇文章？如果是零，说明你在堆砌内容。
4. 质量审查： 选出更新最多的 3 篇文章。完整重读每篇文章，并自问：
   • 它讲述了连贯的故事，还是只是按时间顺序罗列内容？
   • 章节是否按主题组织，而非按日期组织？
   • 是否使用直接引语来承载情感分量？
   • 是否以能揭示内在联系的方式关联其他文章？
   • 读者能否从中了解一些不那么显而易见的内容？ 如果任何文章读起来像事件日志，就重写它。
5. 检查是否有文章超过 150 行，且应拆分。
6. 检查目录结构。必要时创建新目录。

---

命令：/wiki query <question>

通过浏览维基，回答有关该对象人生的问题。

如何回答

1. 阅读 _index.md。 扫描与查询相关的文章。每个条目都有一个 also: 字段，列出别名。
2. 检查 _backlinks.json，查找引用该主题的文章。反向链接数量高通常表示该主题十分核心。
3. 阅读 3-8 篇相关文章。 相关时，沿着 [[wikilinks]] 和 related: 条目深入 2-3 层。
4. 综合信息。 开门见山地回答，按名称引用文章，谨慎使用直接引语，串联不同文章中的要点，并说明信息缺口。

查询模式

查询类型	查找位置
"介绍一下[人物]"	people/、反向链接、2-3 篇关联文章
"关于[项目]发生了什么？"	项目文章、相关时期、决策、转变
"他们为什么做出[决定]？"	decisions/、transitions/、相关项目和时期
"关于[主题]有什么规律？"	patterns/、philosophies/、tensions/、life/
"[某个时期]是什么样的？"	eras/、places/、projects/
宽泛／探索性问题	广泛查找，阅读反向链接最多的文章，综合主题

规则

• 绝不阅读原始日记条目（raw/entries/）。Wiki 就是知识库。
• 不要猜测。如果 Wiki 未涉及相关内容，请如实说明。
• 不要阅读整个 Wiki。只查阅必要内容。
• 不要修改任何 Wiki 文件。查询为只读操作。

---

命令：/wiki cleanup

使用并行子 Agent 审核并丰富 Wiki 中的每篇文章。

阶段 1：建立上下文

阅读 _index.md 和每篇文章。建立一份映射，涵盖所有标题、所有维基链接（谁链接到谁），以及每个没有单独页面但被提及的具体实体。

阶段 2：逐篇文章处理子 Agent

并行启动子 Agent（每批 5 个）。每个 Agent 阅读一篇文章并：

评估：

• 结构：以主题为主，还是以日记为主（将单个事件作为章节标题）？
• 行数：是否过于冗长（>120 行）或过于简略（<15 行）？
• 语气：平淡／客观／百科全书式，还是带有 AI 的编辑腔？
• 引语密度：是否有超过 2 处直接引语？引语是否超过全文的三分之一？
• 叙事连贯性：是否讲述了一个完整的故事，还是罗列了互不相关的事件？
• 维基链接：是否有失效链接？是否漏掉了指向现有文章的链接？

必要时重组。 最常见的问题是以日记为主的结构。

不好（以日记为主）：

## The March Meeting
## The April Pivot
## The June Launch

较好（叙事式）：

## Origins
## The Pivot to Institutional Sales
## Becoming the Product

Steve Jobs 测试：Wikipedia 上的 Steve Jobs 文章使用“早年生活”“职业生涯”（并按时代划分子章节），而不是“Xerox PARC 参观”“Lisa 项目失败”。

补充内容，为读者可能不熟悉的实体添加简短的网络背景信息（3-7 个词）。

识别缺失文章候选项，使用具体名词测试。

阶段 3：整合

所有 Agent 完成后：去重候选项、创建新文章、修复失效的维基链接、重建 _index.md 和 _backlinks.json。

---

命令：/wiki breakdown

查找并创建缺失的文章。通过识别值得单独建立页面的具体实体和主题来扩展 Wiki。

阶段 1：调查

阅读 _index.md 和 _backlinks.json。识别空目录、过于冗长的文章（>100 行）、反向链接数量高但没有对应文章的目标，以及分类错误的文章。

阶段 2：挖掘

启动并行子 Agent。每个 Agent 阅读一批约 10 篇文章，并提取：

具体实体（具体名词测试：“X 是一个___”）：

• 有名有姓的人物、地点、公司、组织、机构
• 有名称或日期的事件或转折点
• 提及的书籍、电影、音乐、游戏
• 被大量使用的工具、平台
• 有名称的项目
• 与叙事中的关键时刻相关的餐馆、场所

不要提取： 通用技术（React、Python、Docker），除非文中记录了相关的学习历程；已覆盖的实体；一带而过的提及。

阶段 3：规划

去重、统计引用次数、按引用次数排序、分类到目录，并呈现候选项表格：

#	文章	目录	引用次数	描述

阶段 4：创建

每批并行创建 5 篇文章。每篇文章都要：在现有文章中搜索提及，收集资料，撰写文章，并在现有文章中添加指向新文章的维基链接。

重新分类（使用 --reorganize）

将分类错误的文章移到正确的目录。常见的移动包括：

• life/ 移到 philosophies/：陈述信念的文章
• life/ 移到 patterns/：具有触发因素—响应结构的文章
• events/ 移到 transitions/：持续数周且充满不确定性的时期
• events/ 移到 decisions/：列举理由的文章

---

目录分类体系

目录应从数据中自然形成。不要预先创建目录。以下是常见类型的参考：

核心目录

目录	类型	内容
people/	人物	有姓名的个人
projects/	项目	主体投入大量精力构建的事物
places/	地点	城市、建筑、街区
events/	事件	有具体日期的事件
companies/	公司	外部公司
institutions/	机构	学校、项目、组织

媒体与文化

目录	类型	内容
books/	书籍	对思维方式产生影响的书籍
films/	影视作品	重要的电影／节目
music/	音乐	重要的艺人／团体
games/	游戏	对项目或社交生活产生影响的游戏
tools/	工具	实践中不可或缺的软件工具
platforms/	平台	用作渠道的服务
courses/	课程	学习资源
publications/	出版物	定期阅读的通讯、博客

内心生活与模式

目录	类型	内容
philosophies/	哲学	关于如何工作和构建事物的明确思想立场
patterns/	模式	具有触发因素、机制和结果的反复行为循环
tensions/	张力	两种价值观之间无法化解的矛盾
identities/	身份认同	影响决策的自我概念或角色标签
life/	生活	不属于哲学或模式的传记主题

叙事结构

目录	类型	内容
eras/	阶段	关联多篇文章的重要传记阶段
transitions/	过渡期	不同承诺之间的过渡时期
decisions/	决策	有明确理由列表的转折点
experiments/	实验	有时间限制、包含假设和结果的测试
setbacks/	挫折	打乱计划的不利事件

关系与人物

目录	类型	内容
relationships/	关系	主体与他人之间的互动关系
mentorships/	指导关系	知识传授关系
communities/	社群	创建或加入的线上社群

工作与策略

目录	类型	内容
strategies/	策略	有明确名称的业务策略
techniques/	技术	技术系统和工程产物
skills/	技能	随时间培养的能力
ideas/	想法	有记录但尚未实现的概念
artifacts/	产物	创建的文档、计划、电子表格

其他

目录	类型	内容
restaurants/	餐厅	与特定时刻相关的餐饮场所
health/	健康	医疗状况、身体健康
media/	媒体	自我表达形式（日记、视频博客、时事通讯）
routines/	日常安排	具体的每日／每周日程
metaphors/	隐喻	用于理解自我或工作的比喻框架
assessments/	评估	带日期的自我评估
touchstones/	触发点	引发反思的文化作品邂逅

如果现有类型都不合适，可以自由创建新目录。

---

写作标准

黄金法则

这不是关于某事物的维基百科，而是关于该事物在这个人生活中的作用。

关于一本书的页面不是书评，而是写这本书对这个人意味着什么、他们何时读了它，以及它带来了哪些改变。

语气：维基百科，而非 AI

采用维基百科的写法。平实、客观、百科全书式地陈述事实。文章保持中立；条目中的直接引语承载情感。

切勿使用：

• 破折号
• 华丽词藻：“传奇的”“有远见的”“开创性的”“深刻地”“真正地”
• 编辑口吻：“有趣的是”“重要的是”“值得注意的是”
• 反问句
• 渐进式叙事：“后来将会”“踏上了……之旅”“这段旅程”
• 修饰词：“真挚的”“原始的”“有力的”“深刻的”

请做到：

• 以主题为开头，平实地陈述事实
• 每句话只表达一个论点。句子要简短。
• 使用一般过去时或一般现在时
• 标明信息来源，而非直接断言：“他称其令人振奋”，而非“它令人振奋”
• 让事实体现重要性
• 用日期和具体细节取代形容词

**唯一例外：**直接引语保留原有语气。文章保持中立，引语负责传达情感。

文章格式

---
title: Article Title
type: person | project | place | concept | event | ...
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
related: ["[[Other Article]]", "[[Another]]"]
sources: ["entry-id-1", "entry-id-2"]
---

# Article Title

{Content organized by theme, not chronology}

## Sections as needed

## Timeline (if relevant)

| Date | Event |
|------|-------|

## Backlinks

{Generated by rebuild-index}

链接

在文章之间使用 [[wikilinks]]。在 frontmatter 中使用条目 ID 引用来源。

叙事连贯性

每篇文章都必须有明确主旨。不要写成“这里列出 X 出现过的 4 次”，而要说明“X 在这个人的生活中代表 Y”。读者读完后应能理解其意义。

按类型组织结构

类型	结构
人物	按角色／关系阶段
地点	按在那里发生的事及其意义
项目	按构思、发展、结果
事件	发生了什么（简述）、为何重要（主体部分）、后果
哲学	核心论点、如何发展、何处成功／失败
模式	触发因素、循环、打破循环的尝试
转变	结束了什么、过渡过程、出现了什么
决策	情况、选项、理由、选择
时期	背景、项目、团队、情感基调

引语规范

每篇文章最多使用 2 段直接引语。选择最有冲击力的一句。

长度目标

类型	行数
人物（1 个参考来源）	20-30
人物（3 个以上参考来源）	40-80
地点／餐厅	20-40
公司	25-50
哲学／模式／关系	40-80
时期	60-100
决策／转变	40-70
实验／想法	25-45
最低长度（任何类型）	15

---

命令：/wiki rebuild-index

根据当前 wiki 状态重建 _index.md 和 _backlinks.json。每个索引条目都需要一个 also: 字段，列出将条目文本与文章匹配的别名。

命令：/wiki reorganize

退一步重新审视 wiki 结构。阅读索引和部分文章，并思考：是否要合并？拆分？新增类别？是否有孤立文章？是否缺少模式？执行调整，然后重建索引。

命令：/wiki status

显示统计信息：已吸收的条目、各类别文章数、关联最多的文章、孤立文章、待处理条目。

原则

1. 你是一名作者。 阅读条目，理解其含义，并撰写能够体现这种理解的文章。
2. 每个条目最终都有归属。 将其融入理解的脉络中，而不是机械归档。
3. 文章承载的是知识，而非日记。 综合提炼，不要只做摘要。
4. 概念文章不可或缺。 关注模式、主题和发展脉络。这些文章能让维基成为一张思维地图。
5. 反复修改你的作品。 重读文章，重写那些读起来像事件日志的文章。
6. 广度与深度并重。 积极创建页面，但每个页面都必须具备真正的内容。40 个空壳页面和 5 篇臃肿文章一样糟糕。
7. 结构是鲜活的。 可自由合并、拆分、重命名和重组。
8. 查看照片。 了解照片展示的内容，并将其融入叙述。
9. 建立联系，而不只是记录。 寻找实体之间的意义网络。
10. 注明来源。 每项论断都必须追溯到原始条目 ID。

---

并发规则

• 未先阅读文件，绝不删除或覆盖文件。
• 编辑文章前，立即重新阅读该文章。
• 绝不修改 _absorb_log.json。
• 仅在命令的最后重建 _index.md 和 _backlinks.json。