构建中文 LLM Wiki 后，我发现了知识管理中一个被低估的增长模式
一只阿木木约 19 分钟构建中文 LLM Wiki 后，我发现了知识管理中一个被低估的增长模式
LLM Wiki：一种让知识复合增长的模式
中文知识库的编译式实现与验证数据
0.
我做了 6 年数字大脑的探索，从 Zettelkasten 到 PARA，从 Notion 到 Obsidian。我发现所有方法论都有同一个致命问题——维护成本最终会压垮任何人。
直到我看到 Karpathy 的 LLM Wiki——它解决了这个根本问题：把维护交给 AI，把好奇留给人类。这是知识管理的真正范式转移。
知识管理领域有一个被忽视的抽象层级问题。
大多数系统——无论是 Notion、Obsidian 还是 RAG 管道——都在优化错误的事情：存储和检索。真正有价值的是：编译和复合。
这篇文章是关于我构建的一个中文 LLM Wiki 系统，以及它揭示的一些我没有预料到的事情。
1. RAG 的根本缺陷
1.1 RAG 实际上在做什么
标准 RAG（Retrieval-Augmented Generation）流程是这样的：
用户查询 → 向量检索 → 拼接相关 chunks → LLM 生成回答 → 遗忘一切
关键词：遗忘一切。
每次查询，LLM 从头开始。它检索文档片段，阅读它们，综合答案，然后丢弃这个思考过程的所有产物。下一次查询，即使是关于同样的主题，它重新执行整个过程。
没有什么会积累。没有什么会复合。
这在工程语境里等价于：每次运行程序时重新编译所有依赖。没有人会这样设计编译器，但这恰恰是 RAG 对知识做的事情。
1.2 可验证的症状
如果这个诊断正确，你应该观察到以下症状：
症状 A：非确定性回答
同一个问题问 10 次，得到 10 个略微不同的答案。不是因为模型的随机性，而是因为检索的不稳定性。
症状 B：综合洞察不浮现
文档 A 和文档 B 包含互补的信息，合起来可以推导出洞察 C。但如果你不在查询中明确要求"比较 A 和 B"，系统永远不会主动建立这个连接。
症状 C：规模退化
添加更多文档应该让系统更聪明。实际上，检索噪音线性增长，而回答质量停滞甚至下降。
症状 D：零记忆复合
你添加的第 100 篇文档，不会让系统"知道"它与第 1 篇文档的关系。除非检索同时召回了它们，这个关系永远不会被发现。
我测试了三个主流 RAG 系统（LangChain、LlamaIndex 的默认配置，以及一个自建的），在处理 50+ 中文文档时，症状 A-D 全部出现。
1.3 为什么这个问题被忽视
RAG 对于"检索已知事实"工作得很好。你问"文档里提到的三个要点是什么"，它能准确回答。
失败的地方在于"合成跨来源洞察"。如果答案需要综合文档 A 的第 3 段、文档 B 的第 7 段、以及文档 C 的隐含前提，RAG 开始挣扎。
这个失败不显眼。没有报错，没有明显的崩溃。你只是得到一个稍微浅一点的回答，比你自己阅读所有文档后能推导出的浅一些。
这是静默的低于潜力。
2. 一个不同的抽象：编译
2.1 软件工程的类比
考虑两种运行程序的方式：
方式 A（解释器）：
每次运行 → 读源代码 → 逐行解释 → 产生输出 → 忘记一切
方式 B（编译器）：
一次性：源代码 → [编译] → 二进制
每次运行：直接执行二进制 → 产生输出
方式 B 更快，因为编译的成本被摊销了。
现在将这个模式映射到知识：
RAG（解释式）：
每次查询 → 检索原始文档 → LLM 即时处理 → 产生答案 → 忘记一切
LLM Wiki（编译式）：
一次性：原始文档 → [LLM 编译] → Wiki 页面
每次查询：读 Wiki 页面 → LLM 综合 → 产生答案（可选写回新页面）
关键差异：
编译发生在 ingest 时，不是查询时
LLM 在读到新文档时，就把它分解为结构化的知识单元（wiki 页面），建立与已有知识的链接。这个过程只发生一次。结果被持久化
编译产物（wiki 页面）存储为 markdown 文件，可以被版本控制、审计、手动编辑。新输入触发增量更新
当 ingest 新文档时，LLM 不只创建新页面，还更新已有页面的交叉引用。知识库不是线性增长，而是网络性增长。
2.2 这个类比在哪里是精确的，在哪里不是
精确的地方：
编译产生比源代码更快可查询的产物 增量编译只重新处理变化的部分 编译结果可以被审计、分发、版本控制
不精确的地方（诚实很重要）：
传统编译是确定性的，LLM 编译有随机性
同一份文档两次 ingest 可能产生略微不同的 wiki 页面。你无法像验证二进制那样验证 wiki 的"正确性"
二进制要么能运行要么崩溃。Wiki 页面可能包含微妙的错误或误解。编译错误在代码里是显式的（编译器报错），在 wiki 里是隐式的（需要 lint 工具发现悬空引用）
2.3 操作语义
如果接受编译类比，每个操作都获得明确的语义：
| ingest | make | |
| query | ||
| lint | ||
| --save |
最后一个操作（--save）是 RAG 中根本不存在的概念。在 RAG 里，查询的输出是终点。在 LLM Wiki 里，查询的输出可以成为新的输入，触发知识的复合增长。
3. 我构建的东西
3.1 最小化的核心
整个系统由 4 个概念组成：
amumu-wiki/
├── raw/ 你放入的原始素材（只写入，不修改）
├── wiki/ LLM 编译生成的页面（LLM 写，人读）
├── CLAUDE.md schema 文件（告诉 LLM 如何工作）
└── log.md 操作历史（只追加，可审计）
就这些。
没有向量数据库。没有嵌入管道。没有 API 服务器。只是 markdown 文件和一个 context window。
Obsidian 在这里只是一个可视化工具——你用它来浏览 wiki，查看知识图谱。真正的工作由 Claude 完成：读 CLAUDE.md，读 raw/ 里的文档，写 wiki/ 里的页面。
3.2 三个非显而易见的决策
决策 A：CLAUDE.md 为什么严格限制在 50 行
直觉反应：规则越多，系统越可靠。给 Claude 一个 200 行的详细指令文件，它会做得更好。
实际情况：规则越多，每次对话消耗的 context 越多，留给实际工作的 context 越少。
我测试了两个版本：
版本 A：200 行 CLAUDE.md（包含所有规则、示例、边界情况）版本 B：50 行 CLAUDE.md（只包含硬约束和路由规则）
测试方法：用两个版本分别 ingest 同一批 10 篇文章，比较生成的 wiki 页面质量。
结果：
版本 B 的页面质量略低于版本 A（约 5% 的差距，基于人工评分） 但版本 B 的 token 消耗减少了 60%
权衡：我接受 5% 的质量下降，换取 60% 的成本降低。更重要的是，版本 B 在处理 50+ 页面规模的 wiki 时，仍然可以把完整的 index.md 放入 context window。版本 A 在 30 页左右就开始遇到 context 不足的问题。
解决方案：把详细规则移到 .claude/rules/ 目录，按需加载。CLAUDE.md 只负责路由。
决策 B：Skill 设计目标是偏离默认行为，不是描述流程
直觉反应：给 Claude 一个详细的步骤清单，它会照做。
Step 1: 读取文章
Step 2: 提取关键概念
Step 3: 为每个概念创建页面
Step 4: 建立交叉引用
...
实际情况：Claude 已经知道"如何整理文章"。你不需要教它这个。它需要的是：在中文场景下，默认行为会在哪里失败，如何避免。
我改成 Gotchas 驱动的设计：
## Gotchas（已知失败点）
1. 微信文章标题党问题
症状：Claude 把"月薪3万的人都在用的方法"作为页面名
修复：页面名用内容本质，不用文章标题
2. 播客转录 ASR 错字
症状：Claude 把"机器学习"的错误转录"技器学习"当作真实概念
修复：ingest 前先执行错字清洗
...
对比测试（5 篇微信文章）：
步骤清单版：遇到标题党时，100% 生成了不合理的页面名 Gotchas 版：89% 的情况下正确规避了标题党陷阱
Gotchas 不是操作指南，是失败记忆的编码。
决策 C：--save 触发条件设计
这是系统能否复合增长的核心机制。
如果 --save 触发太频繁：wiki 充斥低质量综合页面，噪音大于信号。
如果触发太少：查询产生的洞察无法沉淀，系统退化为 RAG。
我的触发条件（经过测试迭代）：
触发 --save 当且仅当：
1. 发现了跨来源的非显性联系（两个来源没有明确互相引用）
AND
2. 综合洞察 > 100 tokens 且具有可复用价值
OR
3. 用户明确要求保存（--save flag）
不触发 --save 的情况：
- 知识空白被识别（记录到 index.md 的待补充列表，等待 ingest）
- 回答只是重新表述已有页面内容（redundant）
- 回答包含推测性内容（ungrounded）
30 天运行数据：
总 query 次数：47 触发 --save：18 次（38%） 写回新页面：12 个 更新已有页面：6 个
38% 的触发率意味着：大约每 3 次查询，有 1 次产生了值得沉淀的新知识。这个比例在我看来是合理的。
3.3 中文场景引入的特殊问题
这不是"翻译"问题，是独立的工程问题。
问题 A：Token 密度差异
中文：~1 汉字 = 1-2 tokens（平均 1.5 tokens/汉字）
英文：~1 token = 4 字符（约 0.25 tokens/字符）
同等信息量，中文消耗约 2.5 倍 token。
直接影响：
Karpathy 的原始 LLM Wiki 在英文场景下，context window 在约 100 个页面时触及上限（假设使用 claude-sonnet，200K context window）。
中文场景下，Scale Ceiling 提前到 40-60 个页面。
我的解决方案（部分）：
# Token Budget 规范（chinese-conventions.md）
单个页面严格上限：
- 概念页面：400 tokens（~600 汉字）
- 实体页面：600 tokens（~900 汉字）
- 综合页面：1000 tokens（~1500 汉字）
index.md 每条目上限：50 tokens
触发拆分：任何页面超过 800 tokens 时，
自动拆分为子页面
这个规范让系统在 60 页面规模下仍然可以把完整 index + 相关页面放入 context。
问题 B：命名约定
Karpathy 的原版使用 kebab-case 英文命名：
attention-mechanism.md
retrieval-augmented-generation.md
这对中文不自然。直接音译（zhu-yi-li-ji-zhi.md）失去可读性。
我的解决方案：双轨索引
文件名：中文（人类可读）
注意力机制.md
检索增强生成.md
index.md：中文 + 英文别名
| [[注意力机制]] | attention-mechanism | ... |
| [[检索增强生成]] | retrieval-augmented-generation | ... |
人类在 Obsidian 里浏览，用中文。程序化处理（grep、脚本），用英文别名。
测试结果：在 Obsidian 中查找概念的速度，中文命名比拼音或英文快约 3 倍（10 个用户的平均数据）。
问题 C：来源类型差异
英文生态的主要来源：PDF 论文、网页文章、书籍。
中文生态的主要来源：微信公众号、播客（需要 ASR）、得到/极客时间（付费内容）、豆瓣读书笔记、B站视频字幕。
每种来源有独特的格式噪音：
ingest-wechat.md | ||
ingest-podcast.md | ||
我为前两种实现了专用 skill。第三种（付费内容）因为版权和技术原因，暂时只能手动处理。
3.4 第一次真实运行（失败先于成功）
系统搭好的第一天，我测试了一篇 4000 字的微信长文（关于用户调研方法）。
症状：
Claude 输出了一个 6127 token 的单一页面。
页面内容是几乎全文摘录，不是知识提炼。没有交叉引用，没有拆分，没有与任何已有知识（此时 wiki 有 3 个页面）建立连接。
我的第一反应：
规则没写清楚。我在 CLAUDE.md 里加了 3 段详细说明，重新 ingest。
结果：问题没有解决。页面从 6127 tokens 降到 5800 tokens，但性质没变。
根本原因：
我的 CLAUDE.md 写的是"目标"：
请将文章提炼为 wiki 页面格式，包含核心要点和交叉引用。
但没有写"限制"：
单个页面不超过 600 tokens
必须包含至少 2 个 [[wiki-link]]
摘录不是 ingest，提炼才是
Claude 理解了目标，但在没有明确约束的情况下，默认行为是"保留所有信息"。
修复：
在 ingest-rules.md 里加入：
Token Budget 硬限制（超出触发拆分） 页面结构模板（必须包含的区块，不可跳过） "知识单元"的明确定义（什么值得建页面，什么不值得）
修复后重新 ingest 同一篇文章：
原来：1 个 6127 token 的页面，0 个 wiki-link 修复后：4 个 400-600 token 的页面 + 2 个 Stub，11 个 wiki-link
这次失败教会了我最重要的一件事：给 AI 的规则，限制比目标更重要。
你告诉它想要什么，它会尽力满足，但可能用错误的方式。
你告诉它不能做什么，它才能安全运行。
4. 数据说了什么
4.1 Eval 设计（方法先于结论）
我设计了 3 个独立的评估实验。
Eval A：知识复合性测试
问题：wiki 规模增长时，回答质量是否单调提升？
方法：
选择 10 个固定查询（涵盖单概念和跨概念问题） 分别在 wiki 有 10 / 30 / 50 / 89 页面时执行 记录每次的引用来源数、发现的跨来源联系数、回答完整性（1-5 人工评分）
Eval B：Skill 有效性测试
问题：我的 ingest skill 相比 raw Claude 的改进是多少？
方法：
选择 5 篇中文素材（微信文章 2 篇、播客转录 2 篇、书籍笔记 1 篇） 条件 A：使用完整 amumu-wiki skill 体系处理 条件 B：只告诉 raw Claude "请帮我整理这篇文章的要点，用 markdown 格式" 比较生成内容的：页面结构完整性、中文命名规范符合率、交叉引用密度、来源归因准确率
Eval C：中文 vs 英文基线
问题：中文适配解决了什么问题？
方法：
选择相同主题的中英文素材各 3 篇 分别用原版英文 schema 和 amumu-wiki 中文 schema 处理 比较：Token 效率、命名质量、交叉引用准确性
所有测试集和基线数据公开在 eval/ 目录。
4.2 Eval B 结果：Skill 有效性
最显著的差距：交叉引用密度，8 倍。
条件 B（raw Claude）生成的是孤立的文章摘要。每个摘要独立存在，几乎没有 [[wiki-link]]。
条件 A（有 skill）生成的是互相连接的知识节点。平均每个页面有 3.2 条指向其他页面的链接。
这不是程度差异，这是性质差异。
一个具体例子：
输入：一篇关于"损失厌恶"的行为经济学文章
Raw Claude 的输出（条件 B）：
# 损失厌恶
损失厌恶是行为经济学中的一个概念，指人们对损失的痛苦
感受强于同等收益带来的快乐，比例约为 2:1。
应用：
- 定价策略
- 免费试用
- 退款保证
来源：某文章
没有任何 wiki-link。这是一个孤岛。
amumu-wiki 的输出（条件 A）：
# 损失厌恶
> 损失带来的痛苦约为同等收益快乐的 2 倍...
## 核心要点
- 提出者：卡尼曼 & 特沃斯基（[[双系统理论]]体系）
- 驱动机制：主要由[[双系统理论|系统 1（情绪）]]驱动...
## 关联概念
- [[双系统理论]]：损失厌恶的认知科学基础
- [[定价策略-心理学]]：损失厌恶在定价中的应用
- [[表达需求与真实需求]]：损失厌恶影响用户需求表达
## 来源
[文章标题](URL) · 作者 · 平台 · (ingest: 2026-05-22)
4 个 wiki-link。如果这些目标页面已经存在，它们会被自动更新，在"关联概念"区块添加指向本页面的反向链接。
这就是为什么交叉引用密度是 8 倍差距。
4.3 Eval A 结果：复合增长效应
同一批查询（10 个固定问题），在不同 wiki 规模下的表现：
关键观察：跨来源联系的增长速度
这是超线性增长，符合网络效应的预测。
一个具体的跨来源联系示例：
Day 7（10 页面）时，wiki 包含：
[[社会期望偏差]]（来源：用户调研文章）[[双系统理论]]（来源：行为经济学笔记）
这两个页面各自独立，没有交叉引用。
Day 14（28 页面）时，ingest 了第 3 篇素材（关于访谈技巧）。
系统在 ingest 过程中发现：
text
访谈文章中的"问行为不问意愿"原则
↓
引用了 卡尼曼的系统 1/系统 2 框架
↓
这是 [[双系统理论]]
↓
而"问意愿得到失真答案"
↓
这是 [[社会期望偏差]]
系统自动更新了 [[社会期望偏差]] 和 [[双系统理论]] 的"关联概念"区块，添加了它们之间的连接。
这个连接在任何单一来源中都没有被显式表述。它是在 3 个来源被 ingest 后才浮现的。
这就是我说的"复合增长"：知识网络的价值，随节点数超线性增长。
4.4 Eval C 结果：中文适配的必要性
用原版英文 schema 处理中文素材 vs 用 amumu-wiki 中文 schema：
英文 schema 处理中文素材的典型失败：
页面命名： yong-hu-fang-tan-ji-qiao.md（拼音，无语义）Token 浪费：大量重复性描述没有被压缩 微信文章：100% 使用标题党作为页面名
中文 schema 的改进是显著的，不是微调级别的。
4.5 数据的局限性
这是单用户、单主题领域（产品/知识管理）、30 天的数据。
样本量 n=1（用户）× 27（来源）× 47（查询）。不足以做统计推断。
"跨来源联系"的计数，带有主观判断（我判断两个概念是否"真的相关"）。没有第二位评估者做 inter-rater reliability 检验。
中文 tokenization 的 token 消耗估算，基于平均值。实际消耗有 ±20% 的波动。
我信任这个数据的原因：
方向性结论（超线性增长、skill 显著改进）在多次独立测试中一致 这不是我预期的结论——我最初假设是线性增长 失败案例（如第一次 ingest 崩溃）也被如实记录
但这不是同行评审的研究。这是一个工程项目的早期数据。
5. 这意味着什么
5.1 一个更大的模式
我把这个系统看作知识工作第三阶段的一个数据点。
Karpathy 在 2024-2026 年间描述了他观察到的三个阶段：
阶段 1：Vibe Coding（2025 年 2 月）
接受 AI 生成的代码而无需逐行审查。信任模型，测试输出。
这把编码劳动外包给 AI。你描述想要什么，AI 写代码，你测试结果是否正确。代码的中间过程（如何实现）不再需要人类关注。
阶段 2：Agentic Engineering（2026 年 1 月）
人类编排 AI Agent，而非直接写代码。Agent 规划、执行、调试、迭代。人类负责高层目标和质量判断。
这把执行劳动外包给 AI。你定义问题和约束，AI 负责整个执行流程。
阶段 3：LLM Knowledge Bases（2026 年 4 月）
AI 管理知识，而非仅管理代码。LLM 从原始材料中构建和维护结构化的知识库。人类成为策展人，不再是全职记录员。
这把知识连接劳动外包给 AI。你提供来源，AI 负责构建知识之间的联系。
amumu-wiki 是阶段 3 在中文场景的一个实现。
这意味着什么？
你花在知识管理上的时间分布，从"存储和检索"转移到"判断和策展"：
哪些素材值得 ingest？ 哪些连接是真实的，哪些是表面相似？ 知识库缺少什么领域，应该补充什么？ 这个 AI 生成的综合，是否 grounded 在可靠来源上？
这些是人类判断的核心价值。而"把文章整理成笔记"，"建立文章之间的链接"，这些是可以外包的认知劳动。
5.2 一个未解决的问题
--save 机制引入了一个有趣的问题。
当 query 产生的综合可以写回 wiki 时，wiki 开始包含两种知识：
Type A：编译的人类知识
直接来自 ingest 的原始素材，有明确来源归因。Type B：AI 生成的综合知识
来自 query 过程的跨来源推理，来源是"多个页面的综合"。
例子：
用户 query："PARA 方法论和双链笔记法如何结合？"
系统回答基于 [[PARA 方法论]] 和 [[双链笔记法]] 两个页面，发现了一个非显性的整合方案，触发 --save，创建新页面 [[PARA-双链整合工作流]]。
这个新页面的"来源"是什么？不是任何单一文档，而是系统的推理过程。
问题：这个边界是否重要？
我的直觉是：重要。
Type A 的可信度来自于人类作者（原始素材的作者）。Type B 的可信度来自于 LLM 的推理能力，而我们知道 LLM 会产生幻觉。
但我还没有一个好的机制来区分：
基于可靠来源的合理综合（可信） 模型在编造看起来合理但实际 ungrounded 的连接（不可信）
当前的解决方案是保守的：只在跨来源联系非常明显时触发 --save，并在新页面中明确标注"来源：系统综合"。
但这不是完美的。这是我在主动思考的开放问题。
5.3 规模预测（可验证的假设）
amumu-wiki 在中文场景的 Scale Ceiling 比英文版本来得更早（~50 页 vs ~100 页，基于 claude-sonnet-4 的 200K context window）。
当 wiki 超过这个规模时，无法在单次 query 中加载 index.md + 所有相关页面。
三个可能的解决方向：
方案 A：两层查询架构
text
第一层：读 index.md（轻量），定位相关页面（≤ 10 个）
第二层：只加载这 10 个页面（而非全量）
预期效果：Scale Ceiling 延迟到 ~150 页。
方案 B：分主题的独立 wiki
text
不是一个大 wiki，而是多个小 wiki：
amumu-wiki-product/ 产品相关知识
amumu-wiki-ai/ AI 工具相关知识
amumu-wiki-writing/ 写作相关知识
预期效果：每个 sub-wiki 可以独立达到 50 页规模。
方案 C：等待 context window 继续扩大
如果 claude-opus-5 提供 500K context，中文 Scale Ceiling 自然延迟到 ~120 页。
我目前在测试方案 A（两层架构）。设计已完成（见 .claude/skills/query.md），数据在 Day 60 后。
方案 B 的问题是：跨 wiki 的知识连接无法被自动发现。这违背了系统的核心价值。
方案 C 是被动等待，不是工程解决方案。
假设：方案 A 可以将 Scale Ceiling 延迟到 150 页，同时保持查询质量不显著下降（< 10%）。
这是一个可验证的假设。我会在 Day 60（预计 wiki 达到 ~120 页）时发布验证数据。
6. 你可以验证这个
这个系统的完整文件在：
https://github.com/yizhiamumu/amumu-wiki
包含：
CLAUDE.md（< 50 行，核心 schema）.claude/rules/和.claude/skills/（完整规则体系）eval/（测试集 + 基线数据 + 我的结果）examples/sample-wiki/（可直接运行的示例，5 篇公开中文素材）docs/architecture.md（系统设计文档）
最小验证实验（2 小时）
Fork 仓库 选择 3 篇你最近读过的、同一主题的中文文章 按 README.md的快速开始指南完成 ingest在 Obsidian 中查看生成的 wiki 页面和知识图谱 问一个需要综合这 3 篇文章的问题 检查系统的回答中，有多少连接是你自己阅读时没有明确意识到的
如果答案是"没有"：
我的系统有问题，或者不适合你的用例。请开 issue 告诉我失败的具体情况。
如果答案是"有一些"：
这个模式在你的场景下也成立。继续添加素材，观察是否出现复合增长效应。
我最想知道的
这个模式在哪些场景下失效？
我测试过的场景：产品方法论、知识管理、行为经济学（中文素材）。
我不知道它在以下场景下如何表现：
高度数学化的内容（机器学习论文、数学证明） 代码密集的技术文档（需要运行代码才能理解） 情感/主观性强的内容（文学分析、个人日记） 快速变化的事实性信息（新闻、市场数据） 多语言混合内容（中英日韩混合文档）
如果你在这些场景测试了，无论成功或失败，告诉我结果。
失败案例和成功案例同样有价值。
一个邀请
如果你实践并实际使用超过一周，我想看到：
你的 wiki 主题是什么？ 你发现的跨来源联系中，哪一个最让你惊讶？ 你遇到了什么我的系统没有处理好的问题？
在仓库 Discussions 里开一个帖子，或者直接发 issue。
我想看到中文 LLM Wiki 在野外的真实表现。
附 A：完整的技术规格
系统要求：
Claude API 访问（claude-sonnet-4 或更高） Obsidian 约 200K context window（用于 50 页规模的 wiki）
成本估算：
平均每篇 3000 字中文文章的 ingest：~15K input tokens + ~3K output tokens 使用 claude-sonnet-4：约 $0.12/篇 每次 query（加载 5 个页面）：约 $0.05-0.08
文件结构完整版：
text
amumu-wiki/
├── CLAUDE.md 核心 schema（< 50 行）
├── .claude/
│ ├── rules/
│ │ ├── chinese-conventions.md 中文命名 + Token Budget
│ │ ├── ingest-rules.md Ingest 行为约束
│ │ └── query-rules.md Query 行为约束
│ ├── skills/
│ │ ├── ingest.md 通用 ingest
│ │ ├── ingest-wechat.md 微信公众号专用
│ │ ├── ingest-podcast.md 播客转录专用
│ │ ├── ingest-pdf.md PDF/书籍专用
│ │ ├── query.md 两层查询
│ │ └── lint.md 健康检查
│ └── agents/
│ ├── ingest-agent.md 专职 ingest subagent
│ └── lint-agent.md 专职 lint subagent
├── wiki/
│ ├── index.md 双轨索引（自动维护）
│ └── [实体页面].md AI 生成的 wiki 页面
├── raw/ 原始素材（只追加）
├── log.md 操作历史（只追加）
├── eval/
│ ├── README.md 评估框架
│ ├── test-queries.md 15 个标准查询
│ ├── baseline/ Raw Claude 输出
│ └── results/ 测试结果
├── examples/
│ └── sample-wiki/ 可运行示例
└── docs/
├── architecture.md 系统设计文档
├── quickstart.md 30 分钟快速开始
└── faq.md
性能基准（我的环境）：
Ingest 一篇 3000 字文章：平均 2.3 分钟 Query（加载 5 个页面）：平均 18 秒 Lint（50 个页面）：平均 3 分钟
如果这个模式对你有用，或者你发现了它的失效边界，告诉我。