llm-wiki

name	llm-wiki
description	用 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.

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。