# LLM Wiki

> 用 Codex 直接维护客制化 LLM Wiki / Markdown 知识库。Use when the user wants Codex to ingest sources, query with citations, lint, analyze knowledge graph, manage review/deep-research queues, or emulate nashsu/llm_wiki without an app, API key, or local model server.

- Skill: `jasperpwang/llm-wiki` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add jasperpwang/llm-wiki`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jasperpwang/llm-wiki/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: jasperpwang (https://skillmd.com/u/jasperpwang)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jasperpwang/llm-wiki

---


# LLM Wiki Skill

## Canonical Chinese Technical Writing Gate

For any generated Chinese wiki page, query answer, clipping distillation, source summary, synthesis, comparison, or Obsidian-ready note, also use [`chinese-technical-writing`](../chinese-technical-writing/SKILL.md). Keep this skill's wiki structure and citation rules, but do not leave avoidable English phrase islands in Chinese prose.

## Canonical Platform Delivery Gate

Use [`research-doc-workflow`](../research-doc-workflow/SKILL.md) whenever a wiki source, meeting note, paper card, deep dive, or review may be delivered to Feishu/Lark, Notion, or Obsidian. For Obsidian/vault writes, also use [`obsidian-doc-workflow`](../obsidian-doc-workflow/SKILL.md) for format and verification; this skill owns the Obsidian/Markdown knowledge model and must not force an Obsidian request through Feishu first.

## Canonical Paper Card Gate

For any paper card / 论文卡片 work, also use [`paper-card-delivery`](../paper-card-delivery/SKILL.md). That skill is the canonical source for official-source verification, fixed format, figure/caption requirements, sorting, and validation. Keep this skill's wiki-specific placement rules, but do not finalize paper cards from this skill alone.

## Canonical Paper Deep Dive Gate

For any single-paper deep dive / 深读 / 详细解析 work, also use [`paper-deep-dive`](../paper-deep-dive/SKILL.md). That skill is the single canonical delivery standard for PDF/HTML extraction, a main entry containing the complete `原文中译稿`, child artifacts `英文原文稿` and `精读稿`, paper-card creation, manuscript fidelity, and completion gates. Keep this skill's Research-Wiki placement rules, but do not define, relax, or finalize deep-dive deliverables from this skill alone.

这个 skill 用来让 Codex 直接维护一个可长期积累的 Markdown wiki：原始资料保持不可变，Codex 增量生成和更新 wiki，Obsidian 只是可选的浏览器。

## 核心约定

- 保持三层结构：`raw/` 原始资料、生成的 `wiki/`、控制文档 `purpose.md` 和 `schema.md`。
- Codex 负责生成和维护 wiki 页面；人类负责选择资料、设定优先级、做关键判断。
- 优先把有长期价值的回答写回 wiki，而不是只留在聊天里。重要回答进入 `wiki/queries/` 或 `wiki/synthesis/`。
- 使用 `[[wikilinks]]`、YAML frontmatter、来源引用、`wiki/index.md`、`wiki/overview.md` 和只追加的 `wiki/log.md`。
- 除非用户明确要求导入、移动或删除 source 文件，否则不要修改 `raw/sources/` 下的原始资料。
- 不把整个 Obsidian vault 自动纳入 wiki。`2-Learnings/EmbodiedWorld/`、`2-Learnings/Courses/`、`0-Daily/`、`1-Meetings/` 是宽输入池；`3-Projects/` 是围绕特定项目组织学习、方案和工作推进的项目层；`4-Research-Wiki/raw/` 是已经决定进入该专题 wiki 的精选证据库；`4-Research-Wiki/wiki/` 是 Codex 编译后的理解层。
- 判断资料是否进入 `raw/`，看它是否值得成为该专题的长期证据，而不是看它有没有 property/frontmatter。

## 原子笔记原则

Research-Wiki 的长期理解层遵循 Zettelkasten / 原子笔记理念：它不是资料堆放处，也不是把 source 改写成另一篇长文，而是把可复用的想法编译成彼此连接的小卡片。

- 一条稳定笔记只承载一个核心想法：一个 concept、claim、question、method、research-practice 或清晰的关系判断。
- `source` 页面可以稍长，用来保存来源上下文；`concept`、`claim`、`question`、`research-practice` 应尽量原子化，不写成无边界综述。
- 写笔记时先问：未来的我会在什么情境下重新需要这个想法？它应该和哪些旧笔记互相发现？
- 不做 source 原文搬运。用自己的话重写理解，同时保留来源引用、PDF/arXiv/网页链接和必要的原句定位。
- 优先创建或更新多条互相链接的小笔记，而不是把多个可独立复用的想法塞进一个大 synthesis。
- 每条 durable note 至少说明：单一想法是什么、来自哪里、连接到哪些旧笔记、还存在哪些待验证问题。
- 每条 durable note 必须能通过 `wiki/index.md`、`wiki/overview.md` 或一条清晰的 wikilink 路径重新找到；孤立笔记不算完成。
- 如果一条内容没有未来复用途径、没有可连接对象，也不能形成概念/主张/问题/方法论，就暂时留在 Daily、Projects 或 raw，不进入 wiki 理解层。

## 输入层边界

推荐关系：

```text
2-Learnings/EmbodiedWorld / 2-Learnings/Courses / 0-Daily / 1-Meetings
= 未筛选或半筛选输入池

3-Projects
= 项目级学习、方案、推进记录和待验证判断

4-Research-Wiki/raw
= 已决定进入世界模型研究语境的证据库

4-Research-Wiki/wiki
= Codex 编译后的概念、主张、问题、综合与方法论
```

操作原则：

- 外层资料池可以宽，`4-Research-Wiki/raw` 必须精选，`4-Research-Wiki/wiki` 必须编译。
- `2-Learnings/EmbodiedWorld/` 不放进 `4-Research-Wiki/` 内部；它是世界模型专题学习层、paper cards 和候选池，不再包一层 `Papers/`。
- `2-Learnings/Courses/` 单独保存课程资料、课件和课程笔记；课程中的稳定概念或方法论应先蒸馏为 study note，再进入 Research-Wiki。
- `0-Daily/` 和 `1-Meetings/` 不全量进入 `raw/`；只把蒸馏后的高价值片段放入 `raw/sources/daily-distillations/` 或 `raw/sources/meeting-extracts/`。
- `3-Projects/` 不保存实验代码、训练日志和论文写作工程；它保存项目目标、方案推理、定向学习、任务拆解、风险判断和阶段总结。
- Projects 中稳定、可复用、跨项目成立的概念、claim、open question 或 research-practice，才进一步蒸馏进入 `4-Research-Wiki/`。
- README 只保留在 vault 根目录下的一级模块中：`0-Daily/README.md`、`1-Meetings/README.md`、`2-Learnings/README.md`、`3-Projects/README.md`、`4-Research-Wiki/README.md`。不要在二级或更深层目录继续散落 README；需要说明时合并进对应一级 README。
- 一份材料进入 `raw/` 前，先问：它是否值得成为 Research-Wiki 的证据？
- 如果不能生成或更新 concept、claim、question、synthesis 或 research-practice，就暂时不要进入 `4-Research-Wiki/wiki/`。
- 进入 `4-Research-Wiki/wiki/` 时，先判断是否应拆成原子笔记：source summary 负责记录来源，长期理解优先拆成可链接的 concept、claim、question 或 research-practice。
- 原始输入文件可以没有 property/frontmatter；生成的 wiki 页面必须有 frontmatter。
- 多机器同步时，skill 源文件保存在 vault 内的 `.tools/skills/llm-wiki-skill/`；每台 Mac 通过 `~/.codex/skills/llm-wiki` 软链接到该目录。新机器按 `Vault Setup.md` 运行 `.tools/setup-vault-mac.sh`，不要手动复制整份 `~/.codex/`。

Daily 输入层包括：

- 文本形式的日常记录：想法、问题、反思、灵感、即时理解。默认写入 `0-Daily/Diary/YYYY-MM-DD.md`；历史研究日记和已整理文本记录保存在 `0-Daily/Diary/Research Diary.md`。注意目录名是大写 `Diary`，不要使用 `0-Daily/diary/` 或旧路径 `0-Daily/Research Diary.md`。
- AI 聊天记录：GPT、Gemini、NotebookLM 等对话。它们是思考痕迹和候选观点，不是默认可靠来源；不需要每天处理，应周期性批量提取核心知识。
- 手机截图：主要来自微信/公众号和小红书。它们默认上下文不完整、来源质量不稳定，需要更强筛选。截图原图放入 `0-Daily/Screenshots/assets/`；整理稿（`0-Daily/Screenshots/YYYY-MM-DD-简短主题.md`）**不放内嵌原图**，结构固定为：**上半「总结」**（主题、要点、与 vault 的衔接、待核验），**下半「全部原文（OCR）」**——将截图中**可见文字尽数转写**（含标题、副标题、段落、列表、小标题、按钮文案、评论等版面文字），并标 `ocr.status`；不是「摘录」或大幅删节。**写作前须校验原图**：若宽高异常（例如宽度仅数十像素的长条），说明导出损坏或误选文件，须请用户重导原图后再 OCR，**禁止**仅凭多模态「读图描述」编造正文。论文线索与判断写在「总结」中即可。B 站内容通常不走截图主流程，更适合以链接或剪藏进入 `0-Daily/Clippings/`。
- Clippings / 剪藏：网页文章、公众号网页、访谈、博客、平台内容等网页剪藏。它们属于 Daily 日常摄取，不等同于已进入 Research-Wiki 的证据；不要把截图整理稿默认放进 `0-Daily/Clippings/`。

如果用户对 clipping / 网页文章 / pasted text 明确要求 `原文`、`提取原文`、`英文原文与中文译文`、English original plus Chinese translation，或强调 `不要总结`，不要进入本 skill 的蒸馏/原子笔记流程。先使用 [`bilingual-source-archive`](../bilingual-source-archive/SKILL.md) 在用户选择的平台生成原文与中文译文归档；只有后续用户要求沉淀长期知识时，再从该 source archive 蒸馏进 Research-Wiki。

处理 Daily 时：

- 不直接把 daily 全量摄入 wiki。
- 每日原始日记主入口是 `0-Daily/Diary/YYYY-MM-DD.md`。如果用户说“写进今天的日记”或“记录到 Daily”，优先写入当天日期文件，而不是写入 `0-Daily/Diary/Research Diary.md`；只有历史整理、跨日合并或用户明确要求时，才维护 `0-Daily/Diary/Research Diary.md`。
- 先生成 `raw/sources/daily-distillations/YYYY-MM-DD.md` 这类蒸馏稿。
- 只有能转化为 concept、claim、question、synthesis 或 research-practice 的部分，才进入 wiki。
- AI 聊天应低频、批量、少手动地处理。不要要求用户每天导出或整理；当用户提供一批 ChatGPT/Gemini/NotebookLM 记录时，只提取核心知识。
- AI 聊天中的事实主张需要追溯到论文、原文、实验或可靠资料；如果暂时无法验证，放入 `reviews.md`。
- 从 AI 聊天中只保留：用户反复追问的问题、被用户认可的判断、概念澄清、研究路线、阅读路线、实验想法、待验证 claim。忽略寒暄、工具性问答、泛泛建议和重复解释。
- 推荐批处理路径：`0-Daily/ai-chats/batches/` 存放定期导出的原始聊天记录，`raw/sources/daily-distillations/YYYY-MM-DD-ai-chats.md` 存放蒸馏后的核心知识。
- 截图内容可以保留启发价值，但事实可靠性需要二次验证。**整理稿**须含可复制检索的 **全文 OCR**（版面文字尽量不漏），且**不嵌原图**，避免体积与检索问题。
- Clippings 先提取正文、元数据、论文线索、核心观点、启发和待验证事实；只有能转化为 concept、claim、question、synthesis 或 research-practice 的内容，才进入 wiki。
- 从 Clippings 提炼长期知识时，不按原文段落机械摘要；先识别可复用的单一想法，再写成原子笔记或更新已有笔记。

截图处理分流：

- 如果截图中识别到论文线索，例如标题、作者、arXiv ID、DOI、会议名、论文页面、论文 PDF 或论文总结，应自动进入论文追踪流程：联网搜索对应论文资源，优先找到 arXiv、DOI、PDF、OpenReview、会议页面、项目页和代码仓库；总结论文内容，并判断它与世界模型研究的相关性。截图整理稿默认写入 `0-Daily/Screenshots/YYYY-MM-DD-简短主题.md`：**不得**用 `![[...]]` 嵌入原图；须按 **总结 / 全部原文（OCR）** 两截书写，原文部分**尽录可见文字**。原图只保留在 `0-Daily/Screenshots/assets/`（整理稿中可用 YAML `source` 指路径，不嵌图）。
- 如果截图是公众号、小红书等普通文章或观点内容，同样：**先**在「全部原文（OCR）」中转写全文，**再**在顶部「总结」中写启发、问题、类比、方法论反思和待验证事实。
- 普通平台内容的事实主张不能直接写成 stable claim；未验证时进入 `reviews.md` 或以 `status: review` 保存。
- 论文资源总结可进入 `raw/sources/papers/`；普通文章截图的蒸馏结果进入 `raw/sources/daily-distillations/`。

论文卡片处理：

- 本 skill 不再定义 paper card 的正文格式、metadata 字段、图像选择、图注标准、排序或验证门槛；这些统一以 [`paper-card-delivery`](../paper-card-delivery/SKILL.md) 为准。
- 无论论文来自 `0-Daily` 截图、clipping、`1-Meetings` 链接、Zotero、`2-Learnings/EmbodiedWorld/` 还是 `3-Projects/`，只要要生成、补全、审核或同步 paper card，都必须先使用 `paper-card-delivery` 的七条固定 bullet 格式与 source-grounded 验证流程。
- 本 skill 只补充 Research-Wiki / local vault 归档边界；本地 Markdown 图片资产、文件命名、相对路径、缺图状态、候选状态等 paper-card 规则也统一按 `paper-card-delivery` 执行。
- 写入或同步到任一平台时，必须同时使用 `research-doc-workflow` 与对应 `*-doc-workflow`；paper-card 的图片位置、图注、布局验证和迁移残留检查按 `paper-card-delivery` 的目标平台分支执行。

Meeting 论文处理完成后，`1-Meetings/assets/` 只保留最终会被 meeting 文档引用的流程图或必要图像；下载的 PDF、整页渲染截图、临时裁图和其他中间文件必须删除。具体 paper-card 图片资产命名和清理规则按 `paper-card-delivery` 执行。

论文处理分层：

- Paper card 和 deep dive 的边界统一以 `paper-card-delivery` 为准：paper card 是阅读全文后的轻量索引，不是全文结构化解析或完整翻译。
- Dive into paper / 深入论文阶段才进行 PDF-to-Markdown 解析。当用户说“深入读这篇论文”“详细解析”“dive into”“转成 md”“逐节分析”“做深读笔记”时，优先把 PDF 转为结构化 Markdown，再基于 Markdown 深读。
- PDF-to-Markdown 优先考虑 MinerU、Docling、Marker、Unstructured、PDFFigures2 这类结构化解析工具；若本机未安装，先用轻量 PyMuPDF / pdfplumber 作为 fallback，不把缺工具作为停止理由。
- 当前 vault **默认**本地主工具为 **MinerU**：便捷脚本 **`.tools/mineru-md.sh INPUT.pdf OUTPUT_DIR`**（默认 `pipeline` 后端，纯 CPU 可跑）。脚本保存在 vault 内，MinerU Python 环境默认保存在本机 `~/Library/Application Support/WorldModelVault/envs/mineru-env/`，不随 iCloud vault 同步。做深读解析时优先使用该脚本；输出目录结构与 MinerU 版本相关，以生成物为准。若仍需 Docling，使用 `.tools/setup-docling-mac.sh` 与 `.tools/docling-md.sh`。
- PDF-to-Markdown 结果是深读中间层，不等同于 Research-Wiki。不要把论文全文 Markdown 全量塞进 `4-Research-Wiki/wiki/`；只把经过提炼的 concept、claim、method、evidence、limitation、open question 或 research-practice 写入 wiki。
- Deep dive 成品遵循用户选择的平台，不再默认放入飞书。若目标是 Obsidian，将完整 deep-dive 包放在独立、稳定的论文阅读目录或用户指定路径，不要把英文原文稿、原文中译稿和整篇论文正文直接塞进 `4-Research-Wiki/wiki/` 的原子理解层。只有长期成立的概念、主张、问题、方法和证据才进一步蒸馏进入 `4-Research-Wiki/raw/sources/papers/` 与 `4-Research-Wiki/wiki/`。
- 结构化解析时保留章节层级、公式/表格占位、figure caption、正文引用线索、参考文献和关键术语；如果解析质量差，需要回到 PDF 原文核验，不得只依赖损坏的 Markdown。

Deep dive 标准只保留在 [`paper-deep-dive`](../paper-deep-dive/SKILL.md)。本 skill 不再维护第二份 deep dive 结构、翻译规则、图表规则或质量门槛，以免和主标准漂移。

当用户在 wiki / Obsidian / Research-Wiki 语境中要求 deep dive：

- 先按 `paper-deep-dive` 在用户选择的平台完成或修复完整 deep-dive 交付包；Obsidian 请求可直接生成 Obsidian 包，不需要经过飞书。
- 不把半成品、结构稿、选摘稿或章节摘要写成 Research-Wiki 的正式 deep-dive 产物。
- Deep dive 完成后，只把仍有长期价值的内容蒸馏为 Research-Wiki 的 concept、claim、question、method、evidence、limitation、open question 或 research-practice。
- 如果需要在 Research-Wiki 中记录 deep dive 来源，只记录目标平台链接或相对路径、论文元信息、关键 source anchors 和蒸馏后的稳定认识，不复制整篇英文原文稿、原文中译稿或主入口精读稿。

Meeting 输入层包括：

- 个人笔记：飞书日期主页上的 PDF 链接、截图/方法图、短 insight、现场判断。整理前必须迁到同日期下的 `notes` 子页，主页留给整理报告。
- 千问纪要与原文：通常是日期页子文件 `纪要_*.docx` 与 `原文_*.docx`。纪要是结构化草稿（常含总览图），原文是带时间戳转写。旧会议可能仍是豆包转写；同类处理。
- 拍摄图像：slides、白板、论文截图、方法图、实验表格等。需要先识别文字和结构。
- 论文链接信息：arXiv、DOI、OpenReview、会议页、代码仓库、项目页等。

证据优先级：个人笔记 > 千问纪要（组织骨架）> 千问原文/豆包转写（核对措辞与补细节）。不要在已有可用千问纪要时只凭原文重做整场总结。

Meeting 总结默认包含两层：**保守纪要** 和 **会后头脑风暴**。保守纪要只写可由笔记、千问纪要/原文、图像、论文链接或原文校验的信息；会后头脑风暴明确标注为研究发散，用来把当天论文、组内项目和更大的研究主线连接起来。

飞书组会整理的页面结构与章节顺序以 [`feishu-doc-workflow`](../feishu-doc-workflow/SKILL.md) 的 Meeting Notes 为准，保持稳定：`组会整理报告`、`Paper Cards`、`保守纪要`、`讨论脉络 / 老师反馈`、`会后头脑风暴`、`TODO`、原始材料链接。千问纪要总览图作为开头内容补充，不新增章节。

Meeting 使用 `research-doc-workflow` 选择目标平台并叠加对应适配器，并保留现有会议库的平台。用户给出 Notion/飞书链接时更新对应平台；给出 vault 路径或明确写 Obsidian 时用 `obsidian-doc-workflow`；无目标时只追问一句目的地，不建立无必要的平行副本。

一次组会、一次文献整理、一次导师讨论或一次科研交流，对应一个按日期组织的 durable meeting page/note。内容保留日期、简述、关键论文/链接/图片、Paper Cards、保守纪要、会后头脑风暴和待办。标题使用 `YYYY-MM-DD 简短主题`，主题应根据当日核心内容命名，不使用无信息量的固定尾缀。Meeting 页面是输入层，不代表已纳入 Research-Wiki。如果材料来自 Zotero collection，而 collection 本身跨越多个日期，应优先按日期子 collection 名或明确记录中的日期拆成多个日期页面；没有日期子 collection 时，再参考条目的 `dateAdded`。不要把导出日期当成组会日期。

平台映射：Feishu 使用 wiki/doc 页面；Notion 使用会议数据库记录或日期子页面；Obsidian 使用既有 `1-Meetings/` 目录、frontmatter、相对资源和 MOC 链接。写后必须按目标平台重新读取并验证标题、日期、图片、Paper Cards、纪要和头脑风暴边界。

处理 Meeting 时：

- 不直接把整场会议记录编译进 wiki，只提取高价值科研片段。
- 先写用户选择平台的 meeting 页面；只有当 meeting 中的内容需要长期进入 Research-Wiki 时，再从该页面蒸馏 `raw/sources/meeting-extracts/YYYY-MM-DD.md`，不要把完整会议纪要复制进 Research-Wiki。
- 如果 meeting 页面已经基于 `个人研究名片` 做了讲者匹配，蒸馏进 Research-Wiki 时保留这个身份锚点，例如 `speaker`、`research_card` 或正文中的人物链接。它用于追溯某个观点/项目/论文线索来自谁，不等于该人物主页，也不替代原始会议证据。
- 如果讲者只由转写或模型推断得到，保留 `讲者待核验` / `可能为 <name>（待核验）`，不要把不确定归因写成 stable claim。缺失的研究名片应进入 meeting TODO，而不是阻塞会议整理。
- 千问纪要/豆包总结中的关键信息需要和图像、论文链接或原论文互相校验。
- 如果图像或链接中识别到论文线索，自动进入论文追踪流程：搜索论文资源，总结论文，判断与世界模型研究的相关性；正式 meeting 文档中的论文应优先按 `paper-card-delivery` 补成 source-grounded paper card。注意是七条固定 bullet，不是六槽位。
- 与世界模型高度相关的论文资源总结可进入 `raw/sources/papers/`；组会启发、科研通法、问题意识进入 `raw/sources/meeting-extracts/`。
- 未验证事实主张进入 `reviews.md` 或以 `status: review` 保存。
- 推荐 meeting 文档结构：frontmatter、简述、论文列表、Paper Cards、保守纪要/讨论脉络、横向结论、会后头脑风暴、待办。飞书正式整理页遵循 `feishu-doc-workflow` 固定章节。
- `会后头脑风暴` 必须与保守纪要分开写，避免把发散判断伪装成已发生讨论或论文事实。开头写清楚“这一节不是保守纪要，而是研究发散”。
- 头脑风暴不只服务 JEPA / world model；它也应主动连接组内其他课题，例如动作理解、长尾识别、3DGS/PBR、PEFT/LoRA/Adapter、机器人策略、多模态融合、实验设计和论文写作方法论。也可以另设“个人兴趣连接”，把音乐生成、折纸艺术等用户长期兴趣作为灵感来源，但不要误写成组内课题。
- 头脑风暴可固定回答这些问题：这篇论文预测的是 pixel、token、latent、object state、reward 还是 action？它的状态表示是隐式还是显式？prediction 是训练期辅助任务还是测试时决策模块？如果改成 JEPA/world-model/PEFT/3DGS/PBR/长尾识别等组内范式，context、target、loss、模块、数据和指标应如何改？它能否转化为组内可做实验？是否能和个人兴趣如音乐生成、折纸艺术形成概念类比或创作灵感？限制来自数据、任务定义、物理假设、评价指标、baseline 还是计算资源？
- 对头脑风暴中的想法分级：`可立即做实验`、`需要补文献`、`概念启发`、`高风险猜想`。只有经过后续验证、可复用且跨项目成立的想法，才进一步蒸馏进 Research-Wiki 的 concept、claim、question 或 research-practice。

## Wiki 目录结构

默认项目根目录：

```text
<project>/
  purpose.md
  schema.md
  raw/sources/
  raw/assets/
  wiki/index.md
  wiki/log.md
  wiki/overview.md
  wiki/entities/
  wiki/concepts/
  wiki/sources/
  wiki/claims/
  wiki/questions/
  wiki/queries/
  wiki/synthesis/
  wiki/comparisons/
  wiki/reviews.md
  wiki/research.md
  .llm-wiki/manifest.json
  .llm-wiki/queue.json
  .llm-wiki/graph.json
  .llm-wiki/lint.json
```

用下面命令创建结构：

```bash
scripts/llm_wiki_tools.py init <project>
```

## 页面 Frontmatter

每个生成的 wiki 页面都必须用下面的 YAML frontmatter 开头：

```yaml
---
title: "Readable title"
type: "source|entity|concept|claim|question|query|synthesis|comparison|overview|index"
status: "seed|draft|review|stable|deprecated"
created: "YYYY-MM-DD"
updated: "YYYY-MM-DD"
sources:
  - "raw/sources/example.md"
tags: []
---
```

说明：

- `sources` 使用相对路径。
- 生成页面文件名使用稳定的小写连字符格式，例如 `large-language-model.md`。
- 长期 wiki 页面正文优先使用中文；字段名和枚举值保持英文，方便脚本和未来工具读取。

## 页面写作规范

- 正文主体用中文。重要英文术语首次出现时写成 `中文（English term）`，后文可按语境使用中文或缩写。
- 数学符号、变量、概率表达式和结构方程必须使用 LaTeX：行内用 `$...$`，块级用 `$$...$$`。行内数学同样需要从官方源校准；不要把 `$x_t$`、`$\pi(a\mid s)$`、`$\mathcal{L}$` 这类符号写成普通文本或翻译成中文词。
- 不要用反引号包裹数学符号或公式，例如不要写 `` `PA_i` ``、`` `P(Y | X=x)` ``；应写成 $\mathrm{PA}_i$、$P(Y \mid X=x)$。
- 反引号只用于文件路径、命令、代码标识符、字段名、枚举值、脚本参数和确实属于代码的片段。
- 论文标题、模型名、数据集名、仓库名和链接保持原文；必要时在中文解释后保留英文括注。

## 工作流

### 初始化

1. 只有当项目目录不明确时才询问用户。
2. 运行 `scripts/llm_wiki_tools.py init <project>`。
3. 如果用户给了领域目标，按领域改写 `purpose.md`。
4. 把 `schema.md` 当作操作契约；当目录、页面类型、引用规则变化时同步更新。

### 摄入资料

采用 `nashsu/llm_wiki` 启发的两步摄入法：

摄入前先确认资料是否应该进入该专题 wiki：

- **一定纳入**：与世界模型直接相关的论文、综述、课程笔记、学习总结；会长期复用的概念；能形成明确 claim 的内容；改变已有理解的材料。
- **选择性纳入**：组会中的高价值片段；daily 中经过蒸馏的科研想法；AI 聊天中被用户认可且可追溯/可验证的观点；截图触发的科研类比、问题意识或方法论启发；低度相关但高启发的材料；可复用科研通法。
- **不纳入**：临时 todo、行政信息、日常流水、只对当天有意义的记录、没有形成问题/概念/claim/方法论启发的摘抄、实验代码、实验日志、论文正文工程、单纯“以后可能有用”的剪藏。

1. **分析**：阅读 source、`purpose.md`、`schema.md`、`wiki/index.md`、`wiki/overview.md` 和相关旧页面。提取实体、概念、主张、证据、矛盾、可能要创建/更新的页面、review 项、deep research 线索。
2. **生成**：创建或更新 source 摘要页，然后把长期价值拆成受影响的 entity/concept/claim/question/research-practice/synthesis 页面。能原子化的内容优先进入小笔记；只有跨多条笔记形成叙事、比较或阶段性判断时，才写 synthesis。更新 `index.md`、`overview.md`、`reviews.md`、`research.md`，并向 `log.md` 追加记录。

摄入前先运行：

```bash
scripts/llm_wiki_tools.py manifest <project>
```

如果 source 没变化，默认跳过，除非用户要求重新摄入。摄入文件夹时保留相对路径，并把文件夹路径当作分类上下文。

Source 摘要页放在 `wiki/sources/`，必须包含：

- 这份资料实际说了什么，而不是泛泛背景介绍
- source 元数据和路径
- 关键主张、证据、结论
- 指向相关页面的 `[[wikilinks]]`
- 开放问题和需要人工判断的 review 项

### 查询

1. 读取 `purpose.md`、`schema.md`、`wiki/index.md` 和 `wiki/overview.md`。
2. 运行 `scripts/llm_wiki_tools.py search <project> "<query>"`。
3. 阅读搜索结果中的高相关页面；必要时再读图谱邻居页面。
4. 回答时引用 wiki 页面和 source 路径。
5. 如果答案有长期价值，把它创建或更新到 `wiki/queries/`、`wiki/synthesis/` 或 `wiki/comparisons/`，然后更新 `index.md` 和 `log.md`。

### Lint / 健康检查

运行：

```bash
scripts/llm_wiki_tools.py lint <project>
```

然后修复或记录：

- 缺失 frontmatter
- 断掉的 `[[wikilinks]]`
- 孤立页面或弱连接页面
- `sources` 过期或缺失
- 重复实体/重复概念
- 与更新或更强来源冲突的 claim
- 被反复提到但没有独立页面的重要概念

Lint 完成后向 `wiki/log.md` 追加记录；不能自动判断的事项放到 `wiki/reviews.md`。

### 图谱和洞察

运行：

```bash
scripts/llm_wiki_tools.py graph <project>
```

使用 `.llm-wiki/graph.json` 识别：

- 直接 `[[wikilinks]]`
- 共享 source 的页面
- Adamic-Adar 风格的共同邻居关联
- 同类型页面关联
- 用 connected components 作为无依赖版 Louvain 替代
- 孤立页面、稀疏社区、桥接页面、意外跨类型连接

如果用户要“图谱视图”，不要假装有 App UI；用 Markdown 表格和 Mermaid 图替代。

### Deep Research / 深度研究

如果需要当前网页信息，并且用户允许或明确要求联网，使用 Codex 浏览网页做研究。否则在 `wiki/research.md` 创建研究任务，包含：

- topic
- 为什么它对 `purpose.md` 重要
- 建议搜索查询
- 相关页面
- 预期输出页面

研究完成后，把结果保存为 `wiki/synthesis/` 或 `wiki/sources/` 页面，并按正常摄入流程更新链接、索引和日志。

### Review Queue / 人工审核队列

用 `wiki/reviews.md` 记录异步人工判断。每个 item 应包含：

- id、date、status
- source/path
- issue
- recommended actions：create page、merge pages、mark conflict、deep research、skip
- 如果需要研究，提前写好 search queries

不要因为主观判断阻塞摄入；保守记录，继续处理确定部分。

## 功能等价说明

这个 skill 可以通过 Codex + 文件系统模拟 `nashsu/llm_wiki` 的大部分信息效果。它不能原生提供桌面 UI、后台文件夹监听、流式聊天持久化、Chrome 扩展、LanceDB 向量搜索、Tauri 系统集成或真正的 Louvain 可视化布局。

替代方案：

- App UI → Markdown 文件、Codex 摘要、Mermaid、JSON 报告。
- 后台 watcher → 每次会话前或用户要求同步时运行 `manifest`。
- 持久队列 → `.llm-wiki/queue.json` 加 `wiki/log.md`。
- 向量搜索 → 关键词搜索加图谱扩展；以后可接入 qmd 或 embedding 工具。
- Louvain → `graph` 里的 connected components 和稀疏社区启发式。
- 网页剪藏 → 把剪藏后的 Markdown 放进 `raw/sources/`，或让 Codex 浏览网页后归档 source 页面。
- 多模态图片/PDF → 能提取文本就先提取；图片只有在作为本地文件或对话附件可见时再用 Codex 视觉能力处理。

## 参考文件

- 当需要判断 `nashsu/llm_wiki` 的某个功能在无 App 工作流里怎么替代时，读取 `references/feature-map.md`。
- 需要确定性维护命令时，运行 `scripts/llm_wiki_tools.py --help`。