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. 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 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 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. 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. 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 理解层。

输入层边界

推荐关系：

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 在用户选择的平台生成原文与中文译文归档；只有后续用户要求沉淀长期知识时，再从该 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 为准。
• 无论论文来自 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。本 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 的 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 目录结构

默认项目根目录：

<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

用下面命令创建结构：

scripts/llm_wiki_tools.py init <project>

页面 Frontmatter

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

---
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 追加记录。

摄入前先运行：

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 / 健康检查

运行：

scripts/llm_wiki_tools.py lint <project>

然后修复或记录：

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

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

图谱和洞察

运行：

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。