[[链接]]的一生：LLM Wiki Wikilink解析、渲染与引用重写源码解析

[[链接]]的一生LLM Wiki Wikilink解析、渲染与引用重写源码解析【免费下载链接】llm_wikiLLM Wiki is a cross-platform desktop application that turns your documents into an organized, interlinked knowledge base — automatically. Instead of traditional RAG (retrieve-and-answer from scratch every time), the LLM incrementally builds and maintains a persistent wiki from your sources。项目地址: https://gitcode.com/GitHub_Trending/ll/llm_wikiLLM Wiki 是一款开源的跨平台桌面知识库应用它把文档自动编织成互相链接的持久 Wiki。贯穿其中的一根关键线索就是 Obsidian 风格的 Wikilink正文里的[[链接]]。本文带你追踪一条 LLM Wiki Wikilink 从LLM 生成到渲染成图的完整一生——解析、渲染、引用重写三个阶段看看源码是如何做到的。一、Wikilink 是什么LLM Wiki 的页面互联语法在 LLM Wiki 里每一页 wiki 页面都是本地 Markdown 文件页面之间的引用采用 Obsidian 风格的双中括号语法[[page-name]]链接到名为page-name的页面[[page-name|显示别名]]链接目标不变但显示为自定义文字![[image.png]]嵌入一张图片这种语法对 LLM 特别友好——不需要拼 URL、不需要转义只要记住页面名就能写引用。因此 LLM Wiki 在生成 wiki 页面时就明确要求使用它。LLM 是如何被教会写 Wikilink 的导入文档时的 ingest 提示词中有两条硬性规则见 ingest.tsWikilinks 只允许出现在 BODY正文frontmatter 里只写纯 slug页面之间交叉引用一律使用[[wikilink]]语法。也就是说你导入一篇 PDFLLM 生成的页面摘要里天生就带着指向其他页面的[[…]]种子。二、引用重写保存后的智能补链光靠 LLM 首次生成还不够。LLM Wiki 还有一道保存后增强工序每存一页就让 LLM 回头看看正文里还有哪些术语其实已有对应页面应该补上链接。这套机制在 enrich-wikilinks.ts 中实现设计上非常克制不让 LLM 改写全文旧方案让模型返回插好链接的完整页面结果不少小模型会顺手重写、扩写破坏用户内容。新方案只让 LLM 返回 JSON 列表形如{links: [{term: 原文词, target: 页面名}]}。替换由代码执行只有首次出现处被替换成[[target]]页面其余字节完全不变。更妙的是安全网LLM 给出的target必须能在磁盘上解析到真实页面enrich-wikilinks.ts#L95-L104解析不到就丢弃——模型再怎么发挥也造不出死链。三、解析与重写把[[..]]翻译成标准 Markdown到了渲染环节问题来了ReactMarkdown 等标准渲染器不认识[[..]]只会把它当成方括号乱码显示出来。LLM Wiki 的答案是 wikilink-transform.ts一个纯粹的文本预处理层源语法重写后说明[[foo]][foo](#foo)变成锚点链接避免 webview 外跳[[foo|别名]][别名](#foo)别名作显示文字![[img.png]]alt变成 CommonMark 图片几个值得学习的工程细节顺序敏感必须先处理图片嵌入![[..]]再处理普通链接否则嵌入目标会被误改写成#fragment链接wikilink-transform.ts#L33-L35代码块豁免按 围栏和行内反引号先切分代码示例里的[[skip]]原样保留wikilink-transform.ts#L82-L101边界转义目标名做encodeURIComponent、标签里的方括号加反斜杠转义防止路径中的空格、括号、哈希破坏 Markdown 解析。对应的单元测试覆盖了空别名、未闭合括号、混合代码块等边角情况见 wikilink-transform.test.ts。四、渲染与点击跳转从锚点到真实页面重写后的#foo只是一个占位锚点真正的点击即跳转发生在只读渲染器 wiki-reader.tsx渲染前执行transformWikilinks(transformImageEmbeds(body))wiki-reader.tsx#L52-L55用户点击带#slug的链接时拦截默认行为对 slug 做decodeURIComponent调用 resolveRelatedSlug 把 slug 解析成磁盘上的真实.md路径——它兼容三种历史写法项目相对路径、带.md的文件名、纯 slug解析成功后直接路由到预览面板一次点击完成页面间导航。这里还有一个刻意的取舍Wikilink 只在只读视图里被重写成标准链接。编辑器Milkdown如果也重写用户一保存就会把原始[[…]]源文本覆盖成[label](#slug)所以源码注释里专门写明了只读渲染才是安全区wiki-reader.tsx#L32-L43。另外frontmatter 里偶尔混入的[[…]]值也会被 unwrapWikilink 剥离按 target 查找、按 alias 显示保证元数据面板同样干净。五、终局Wikilink 汇成知识图谱一条 Wikilink 的最后一站是知识图谱。wiki-graph.ts 用正则/\[\[([^\]|]?)(?:\|[^\]]?)?\]\]/g扫描全部.md文件把每对[[..]]变成图里的一条边节点权重即链接数再用 Louvain 社区发现算法自动聚类——主题相近的页面会聚成同一色块。社区聚类的结果就是图谱界面上的话题群落让你一眼看出哪些页面彼此交织此外结构 lint 还会检查本页没有任何 [[wikilink]] 出链这类孤岛页面lint-structural-core.ts#L203提示你补链让知识网络持续长密。六、一条链接的一生小结阶段职责核心文件生成LLM 按提示词在正文写入[[…]]ingest.ts补链保存后 JSON 替换式增强杜绝死链enrich-wikilinks.ts解析重写翻译成标准 Markdown 链接/图片wikilink-transform.ts渲染跳转拦截锚点slug 解析为页面路径wiki-reader.tsx图谱化正则抽边、社区聚类、lint 补链提醒wiki-graph.ts、lint-structural-core.ts可以看到LLM Wiki 对 Wikilink 的设计哲学是生成时宽松LLM 随便写解析时严格代码兜底渲染时翻译落盘时保留原样。这正是它既能兼容 Obsidian 习惯、又能让非程序员用户开箱即互联的底层原因。【免费下载链接】llm_wikiLLM Wiki is a cross-platform desktop application that turns your documents into an organized, interlinked knowledge base — automatically. Instead of traditional RAG (retrieve-and-answer from scratch every time), the LLM incrementally builds and maintains a persistent wiki from your sources。项目地址: https://gitcode.com/GitHub_Trending/ll/llm_wiki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考