[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-81484":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":15,"stars30d":16,"stars90d":15,"forks30d":15,"starsTrendScore":15,"compositeScore":17,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":20,"hasPages":18,"topics":21,"createdAt":9,"pushedAt":9,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":15,"starSnapshotCount":15,"syncStatus":13,"lastSyncTime":25,"discoverSource":26},81484,"llm-wiki-desktop","Aidenwu0209\u002Fllm-wiki-desktop","Aidenwu0209","Compile your documents into a local, linked, LLM-maintained wiki.",null,"TypeScript",55,11,2,7,0,26,42.84,false,"main",true,[],"2026-06-12 04:01:34","# LLM Wiki Desktop\n\n本仓库是 `open-llm-wiki` 的本地优先桌面端外壳。桌面端负责 vault 管理、导入入口、任务编排、状态展示和错误恢复；知识生成、QA、review queue、writeback approval 等核心边界仍由 `open-llm-wiki` runtime 执行。\n\n## 界面预览\n\n下面的截图来自本地 DeepSeek 论文语料验收流程，已裁掉菜单栏、Dock 和本机绝对路径，只保留软件窗口本身。\n\n![仪表盘](docs\u002Fscreenshots\u002Fdashboard.png)\n\n| 页面 | 作用 |\n| --- | --- |\n| ![原始资料工作台](docs\u002Fscreenshots\u002Fraw-sources.png) | 管理 `raw\u002Finbox\u002F`、source registry、解析 artifact、parser 信息和可追踪性状态。 |\n| ![LLM provider 设置](docs\u002Fscreenshots\u002Fsettings-providers.png) | 配置本地 CLI 或远程 provider 的模型、上下文窗口和推理强度；API key 只通过环境变量或安全路径传入。 |\n| ![问答与写回](docs\u002Fscreenshots\u002Fchat-search.png) | 在 vault 内检索 sources、claims、concepts、reviews 和 writeback proposals，并生成 evidence-first answer draft。 |\n| ![证据图谱](docs\u002Fscreenshots\u002Fevidence-graph.png) | 查看 source、claim、concept、review、proposal 和 warning 之间的 evidence graph。 |\n\nAgent \u002F API 集成必须先通过只读 readiness gate；当前契约见 [`docs\u002Fagent-skill.md`](docs\u002Fagent-skill.md)。通过 gate 后可在 Settings -> Agent API 启动 `127.0.0.1` token-protected read API；在 gate 未通过前，不应启动 localhost API，也不应向 Codex\u002FClaude Code 暴露写入、删除、apply 或后台 ingest 能力。\n\n## 开源治理\n\n- License: Apache-2.0，见 [`LICENSE`](LICENSE)。\n- Contributing: [`CONTRIBUTING.md`](CONTRIBUTING.md)。\n- Security: [`SECURITY.md`](SECURITY.md)。\n- Code of Conduct: [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md)。\n- Changelog: [`CHANGELOG.md`](CHANGELOG.md)。\n- Roadmap: [`ROADMAP.md`](ROADMAP.md)。\n- Issue drafts: [`docs\u002Fissues-to-create.md`](docs\u002Fissues-to-create.md)。\n\nProduct planning and submission scoring docs: [`docs\u002FPRD.md`](docs\u002FPRD.md), [`docs\u002Fscoring-mapping.md`](docs\u002Fscoring-mapping.md).\n\n## 软件使用教程\n\n### 1. 启动桌面端\n\n开发环境中最直接的启动方式：\n\n```bash\ncd \u002Fpath\u002Fto\u002Fllm-wiki-desktop\nnpm ci\nnpm run desktop:dev\n```\n\n已经完成本地打包时，也可以直接打开 macOS app：\n\n```bash\nopen \"src-tauri\u002Ftarget\u002Frelease\u002Fbundle\u002Fmacos\u002FLLM Wiki.app\"\n```\n\n### 2. 创建或打开知识库\n\n首次进入 Welcome 页后，有两种入口：\n\n- `新建项目`：选择项目名称、模板、输出语言和父目录，桌面端会创建一个新的 open-llm-wiki vault。\n- `打开项目`：选择已有 vault。不要选择原始 PDF 文件夹，应该选择已经初始化过的 LLM Wiki vault。\n\nWelcome 页同时展示评委可直接理解的 OCR + ERNIE 演示路径：\n\n```text\nPDF \u002F Image -> PaddleOCR-VL-1.5 -> Markdown \u002F JSON Artifact\n-> LLM Wiki Runtime -> Evidence Map -> ERNIE Answer -> Writeback Proposal\n```\n\n页面上的 5 步导览对应：\n\n1. Create or open a Vault \u002F 创建或打开知识库。\n2. Submit PDFs or images \u002F 提交 PDF 或图片。\n3. Parse with PaddleOCR-VL-1.5 \u002F 使用 PaddleOCR-VL-1.5 解析。\n4. Ask with ERNIE using evidence \u002F 使用文心一言基于证据问答。\n5. Create a writeback proposal \u002F 创建可审核写回提案。\n\n仓库内提供一个合成示例 vault：[`examples\u002Fdemo-vault`](examples\u002Fdemo-vault)。它只包含自造 sample，不包含论文、截图或版权材料。没有可打开的真实 demo vault 时，Welcome 页只显示 `View Demo Tour`，不会假装打开不存在的 vault。\n\n创建或打开后会进入 `仪表盘`。仪表盘会显示 schema、runtime、Obsidian、资料数量、概念数量、审核压力和写回状态。\n\n### 3. 导入论文或资料\n\n进入 `原始资料` 页面：\n\n1. 点击 `导入文件`，选择 PDF、Markdown、txt 或 zip 论文包。\n2. 文件会进入 vault 的 `raw\u002Finbox\u002F`。\n3. 点击 `规划 ingest` 检查哪些资料可解析、哪些已发布、哪些被阻塞。\n4. 选中任一资料，可以在中间预览 artifact，并在右侧查看 path、hash、parser、claims、concepts 和 traceability。\n\n桌面端会按 SHA-256 跳过重复资料。PDF \u002F 图片默认优先使用 PaddleOCR-VL-1.5；未启用 OCR Parser、未配置 endpoint 或所选 API key 环境变量（默认 `PADDLEOCR_API_KEY`）不可见时，ingest plan 会明确阻塞且不会上传 raw document。用户也可以显式切回 `auto\u002Flocal-text` 本地 fallback。\n\n### 4. 运行处理流程\n\n回到 `仪表盘` 或 `原始资料` 页面，点击 `运行 ingest pipeline`。桌面端会串行执行：\n\n```text\nPDF parse -> source discovery -> corpus ingest -> claims -> normalize\n-> semantic QA -> contradictions -> science review -> concept revision\n-> lint -> dashboard refresh\n```\n\n运行期间可以在 `活动` 页面查看任务历史。所有 runtime 日志会写入当前 vault 的：\n\n```text\nlog-archive\u002Fdesktop\u002F\n```\n\n### 5. 浏览结果\n\n处理完成后，常用入口如下：\n\n- `仪表盘`：确认 vault 是否可用、审核压力是否过高、是否存在 P0\u002FP1 阻塞项。\n- `原始资料`：核对每篇论文的解析产物、parser、artifact contract 和证据链。\n- `论断`：查看 claim ledger、QA verdict、needs_review、stale 或 contradicted 状态。\n- `概念`：浏览生成后的知识页面。\n- `审核`：处理 science review queue，但桌面端不会伪造人工批准。\n- `可追踪性`：定位 evidence anchor、claim\u002Fsource 断链和 schema 风险。\n- `证据图谱`：查看 source -> claim -> concept \u002F review \u002F proposal \u002F warning 的关系。\n- `Obsidian`：从桌面端打开生成后的 vault，适合阅读和人工审查。\n\n### 6. 提问与写回\n\n进入 `问答 \u002F 写回` 页面后：\n\n1. 输入研究问题，例如“整理 DeepSeek 的研发思路和决策依据”。\n2. 先查看 evidence map，确认回答引用的是 vault 内 sources、claims、concepts 或 reviews。\n3. 生成 answer draft。没有调用 active provider 时，它只是 evidence draft，不应视为模型最终答案。\n4. 生成 writeback proposal。proposal 会进入 `reviews\u002Fquery-writeback\u002F`。\n5. 未批准前不会写入 `concepts\u002F` 或 `sources\u002F`。\n6. 明确批准并 apply 后，再运行 lint \u002F eval 或对应 runtime validation。\n\n## MVP 能力\n\n- 创建或打开 open-llm-wiki vault；新建 vault 时会拒绝带尾随空格的路径段，避免生成跨设备不稳定的目录名。\n- 将 PDF \u002F Markdown \u002F txt \u002F zip 导入到 `raw\u002Finbox\u002F`，并按 SHA-256 跳过重复文件；zip 会作为 corpus package 进入 plan，先提示解包再进入逐篇解析。\n- 文件夹导入会保留目录上下文，但不会跟随 symlink，避免把未显式选择的外部文件复制进 raw evidence。\n- 生成桌面端 ingest plan：递归扫描 `raw\u002F` 下的显式 evidence 文件与嵌套 `*_markdown\u002Fcombined.md`，按 SHA-256 标记 desktop-only 的 `ready`、`stageable`、`blocked`、`cached`、`published`，并写入 `_state\u002Fdesktop-ingest-plan.json`。\n- 对 Markdown \u002F txt 输入执行本地 staging，生成 `raw\u002F\u003Csource>_markdown\u002Fcombined.md`、`manifest.json` 和 `chunks.jsonl`，再交给 open-llm-wiki runtime。\n- 对 PDF \u002F 图片输入默认走 `paddleocr-vl15` 计划状态；配置齐全后由桌面端读取设置中选择的 API key 环境变量（默认 `PADDLEOCR_API_KEY`），再作为子进程环境覆盖传给 runtime `pdf_to_markdown.py --parser layout-api --api-url \u003CPaddleOCR endpoint>`。未配置时不上传 raw document；用户显式切回 `auto\u002Flocal-text` 才走本地 selectable-text fallback。\n- 一键运行串行 ingest pipeline：PDF parse -> source discovery -> corpus ingest -> claims -> normalize -> semantic QA -> contradictions -> science review -> concept revision -> lint -> dashboard refresh。\n- 成功完成 pipeline 后写入 `_state\u002Fdesktop-ingest-registry.jsonl`，避免未变化输入反复触发整条 ingest 链路。\n- 规划时生成桌面侧核心 contract：`desktop-source-registry.jsonl`、`desktop-artifacts.jsonl`、`desktop-ingest-jobs.jsonl`、`desktop-actions.jsonl`、`desktop-impact-graph.jsonl`。\n- 检测 vault schema、runtime 是否安装、Obsidian profile 是否启用。\n- 调用白名单 runtime 命令：\n  - `pdf_to_markdown.py`\n  - `wiki_lint.py`\n  - `wiki_obsidian_setup.py`\n  - `wiki_status.py`\n  - `wiki_discover_sources.py`\n  - `wiki_ingest_corpus.py`\n  - `wiki_claims.py`\n  - `wiki_normalize_metrics.py`\n  - `wiki_semantic_qa.py`\n  - `wiki_contradictions.py`\n  - `wiki_science_review.py`\n  - `wiki_concept_revision.py`\n  - `wiki_writeback.py` 的 proposal-first contract 在桌面端 writeback 流程中保持一致\n- 浏览 `sources\u002F`、`drafts\u002F`、`concepts\u002F`、`qa-reports\u002F` 和 `raw\u002Finbox\u002F`。\n- 为每个 runtime command 保存可查看的任务日志到 `log-archive\u002Fdesktop\u002F`。\n- 显示 claims、science review queue、growth queue 等 review 状态。\n- 提供 Chat \u002F Search 入口：搜索 sources、claims、concepts、reviews、traceability warnings 和 query writeback proposals，并把带 evidence map 的研究问题转成 proposal。\n- 提供基础 Graph 入口：展示 source -> claim -> concept \u002F review \u002F proposal \u002F warning 的证据关系，并补充 Obsidian `[[wikilink]]`、frontmatter `sources:` \u002F `source_path:` 共享来源关系、共享邻居推荐、同类型页面加权、桥接节点和意外连接 insight，并可把图谱 insight 送到 Query \u002F Writeback 形成可审核研究主题，帮助定位 traceability break、阅读路径和 insight 写回位置。\n\n## 安全边界\n\n- 桌面端不直接把 draft 移到 `sources\u002F`。\n- 桌面端不修改 QA verdict。\n- 桌面端不重写历史 QA report。\n- 桌面端不默认上传 raw documents。\n- 桌面端不静默应用 query writeback；默认写入 `reviews\u002Fquery-writeback\u002F` proposal artifact，写入 `concepts\u002F` 必须先审批。\n- 桌面端只对 Markdown \u002F txt 做可审计 staging；PDF \u002F 图片通过 runtime parser 生成 parsed Markdown artifact。默认 `paddleocr-vl15` 只有在 OCR Parser 已启用、endpoint 已配置且所选 API key 环境变量可见时才会上传到该 endpoint；`auto\u002Flocal-text` fallback 不上传文档。\n- 所有 source page、claim、QA、contradiction、concept 写入都通过 open-llm-wiki 脚本完成，桌面端只保存任务日志、ingest plan、staging manifest、桌面 ingest registry、桌面 action\u002Fqueue\u002Fimpact contract 和 `raw\u002Finbox\u002F` 导入结果。\n\n## Ingest 编排\n\n桌面端的 ingest 编排保持 open-llm-wiki 的 runtime-first 边界：\n\n- SHA-256 plan\u002Fcache：未变化且 artifact 仍匹配的输入会显示为 `cached`；如果 Markdown\u002Ftxt 源文件变化，会重新标记为 `stageable`，避免旧 `combined.md` 被误 ingest；如果 PDF\u002Fparser manifest 的源 hash 与当前文件不同，会回到 `blocked` 要求重新解析。\n- 显式状态：`ready` 表示已有 `combined.md`，`stageable` 表示可本地 staging，`blocked` 表示需要 PDF\u002Fparser 先产出 artifact，`published` 表示当前 source\u002Fartifact hash 已完成过桌面 pipeline。桌面端 pipeline 会对 `parse_required` PDF 先运行本地 parser，再继续 ingest。\n- 串行执行：一键 pipeline 不并发调用 runtime，避免多个任务同时改 `index.md`、`claims\u002F` 或 QA report。\n- 非越权写入：desktop 不发布 source，不改 QA verdict，不直接修改 concept synthesis。\n- 桌面锁：pipeline 运行时会写 `_state\u002Fdesktop-ingest.lock`，防止两个桌面任务同时驱动 runtime。\n- 行动面板：`desktop-actions.jsonl` 将 `parse_required`、`stage_artifact`、`ingest_ready` 等状态转成用户下一步动作。\n- Claim actions：`claims\u002Fclaims.jsonl` 中的 `needs_review`、`stale`、`contradicted` 会进入行动面板，避免 concept synthesis 静默吸收未验证内容。\n- Per-source queue：`desktop-ingest-jobs.jsonl` 为每个输入提供 `queued`、`blocked`、`succeeded` 等任务视图。\n- Artifact contract：`desktop-artifacts.jsonl` 汇总 manifest、chunks、parser、anchors 和 limitations；runtime `local-text` parser manifest 会显示为 parser-owned artifact。\n- Runtime source registry compatibility：桌面端会把 desktop-only 状态保存在 `desktop_status`，写入 runtime-owned `_state\u002Fsource-registry.jsonl` 时只使用 open-llm-wiki 允许的 `candidate`、`parsed`、`published` 等状态，避免 `ready` 进入 runtime lint schema。\n- Impact graph：`desktop-impact-graph.jsonl` 记录 source -> artifact -> chunks 的基础影响边，后续 runtime 可扩展到 claims\u002Fconcepts。\n- Obsidian templates：最小 vault 会写入 `templates\u002Fsource.md` 和 `templates\u002Fconcept.md`，固定 source\u002Fconcept 页面结构和 frontmatter。\n\n## 普通用户启动\n\n本仓库当前以本地源码方式启动桌面端，适合内部试用、DeepSeek corpus 验证和 release candidate 检查。启动前需要 macOS、Node.js\u002Fnpm、Rust\u002FCargo 和 Xcode Command Line Tools。\n\n环境要求：\n\n- Node.js 与 npm。\n- Rust toolchain。\n- Tauri v2 所需的系统依赖。\n\n```bash\ncd \u002Fpath\u002Fto\u002Fllm-wiki-desktop\nnpm install\nnpm run start\n```\n\n等同的脚本入口：\n\n```bash\n.\u002Fscripts\u002Fdev-start.sh\n```\n\n首次打开后，按这个顺序使用：\n\n1. 选择或创建一个 `open-llm-wiki` vault。\n2. 如果 vault 内还没有 runtime，在 UI 中选择本地 `open-llm-wiki` 仓库路径。\n3. 导入 PDF、Markdown、txt 或 zip 论文包到 `raw\u002Finbox\u002F`。\n4. 先查看 ingest plan 和 action panel，再运行 ingest pipeline。\n5. 需要浏览知识库时，从桌面端打开 Obsidian vault，而不是直接打开原始论文目录。\n6. 需要 query writeback 时，先生成 proposal 并检查 diff。没有人工批准时不要 apply 到 `concepts\u002F`。\n\n默认解析体验是 OCR-first 但配置门控：`paddleocr-vl15` 未配置时不会上传 raw document。`layout-api` hosted parser 和外部 LLM\u002FAPI 仍需用户明确选择并批准。\n\n### 中文 ZIP 导入 smoke\n\n本地验证 `deepseek_paper_中文.zip` 时，不要修改原始 zip，也不要提交解压结果。推荐流程：\n\n1. 打开或创建一个临时 generated vault。\n2. 在 `原始资料` 页面选择 `deepseek_paper_中文.zip` 导入到 `raw\u002Finbox\u002F`。\n3. 刷新并运行 `规划 ingest`，确认中文文件名路径保持稳定，嵌套目录结构保留，`__MACOSX`、`.DS_Store`、`._*` 和 helper sidecar 不进入 ingest plan。\n4. 验证完成后删除临时 vault 或保留在 Git 外；不要提交 zip 的解压内容、测试输出或临时 `_state\u002Farchive-import\u002F` 目录。\n\n## 开发者启动\n\n推荐使用 lockfile 安装依赖：\n\n```bash\nnpm ci\nnpm run desktop:dev\n```\n\n常用开发命令：\n\n```bash\nnpm run start\nnpm run desktop:dev\nnpm run dev:web\nnpm test\nnpm run build\nnpm run build:app\n```\n\n脚本约定：\n\n| Command | Purpose |\n| --- | --- |\n| `npm run start` | 启动完整 Tauri 桌面端。 |\n| `npm run desktop:dev` | 启动 Tauri dev shell，内部会按 `tauri.conf.json` 拉起 Vite。 |\n| `npm run dev:web` | 只启动 Vite Web 视图，用于快速 UI 调试，不代表完整桌面能力。 |\n| `npm test` | 运行 TypeScript typecheck 和 Rust tests。 |\n| `npm run build` | 运行 typecheck 并生成前端 `dist\u002F`。 |\n| `npm run build:app` | 运行 Tauri 本地应用打包。 |\n| `.\u002Fscripts\u002Ftest.sh` | shell 入口，等同于 `npm test`。 |\n| `.\u002Fscripts\u002Fbuild-app.sh` | shell 入口，等同于 `npm run build:app`。 |\n\nRelease readiness, local packaging, CI scope and formal distribution requirements are tracked in [`docs\u002Frelease-readiness.md`](docs\u002Frelease-readiness.md).\n\nRust 侧单独检查：\n\n```bash\ncargo test --manifest-path src-tauri\u002FCargo.toml\n```\n\n## macOS 本地打包\n\n本地打包用于验证 `.app` 和 `.dmg` 是否能在当前 Mac 上启动，不等同于签名、notarization 或公开分发。\n\n```bash\nnpm ci\nnpm run build:app\n```\n\n打包完成后检查产物：\n\n```bash\nopen \"src-tauri\u002Ftarget\u002Frelease\u002Fbundle\u002Fmacos\u002FLLM Wiki.app\"\nopen src-tauri\u002Ftarget\u002Frelease\u002Fbundle\u002Fdmg\n```\n\n如果只是验证 release candidate，不要把 notarization 失败和本地启动失败混在一起。公开分发前还需要单独处理 Developer ID signing、hardened runtime、notarization、stapling 和完整图标资产。\n\nRelease mode boundary:\n\n- Local web trial: `npm run dev:web` only starts Vite and does not prove native desktop behavior.\n- Desktop dev mode: `npm run desktop:dev` \u002F `npm run start` runs the full Tauri shell for development.\n- Release candidate: `npm run build` plus `npm run build:app` creates local `.app` \u002F `.dmg` artifacts for current-Mac validation.\n- Formal distribution: requires signing, hardened runtime, notarization, stapling and final icon assets outside this basic local packaging path.\n\n## Tauri 配置状态\n\n当前 `src-tauri\u002Ftauri.conf.json` 的 release 相关配置：\n\n- `productName`: `LLM Wiki`\n- window title: `LLM Wiki`\n- `identifier`: `com.aidenwu.llmwiki.desktop`\n- `bundle.active`: `true`\n- `bundle.targets`: `[\"app\", \"dmg\"]`\n- `bundle.icon`: `src-tauri\u002Ficons\u002Ficon.png`, `src-tauri\u002Ficons\u002Ficon.icns`, `src-tauri\u002Ficons\u002Ficon.ico`\n\n这些字段与 package\u002FCargo 命名保持一致。当前图标资产包含 SVG master、1024\u002F512\u002F256\u002F128\u002F64\u002F32 PNG、macOS `.icns` 和 Windows `.ico`。公开分发前仍需单独做签名和 notarization 检查。\n\n## Release checklist\n\n本 checklist 面向本地 release candidate，不包含 CI\u002FCD。\n\n```bash\nnpm ci\nnpm run build\ncargo test --manifest-path src-tauri\u002FCargo.toml\nnpm run build:app\n```\n\n手动验收：\n\n1. 打开 `src-tauri\u002Ftarget\u002Frelease\u002Fbundle\u002Fmacos\u002FLLM Wiki.app`。\n2. 在 Welcome 页验证 `New Project`、`Open Project`、recent projects 和 DeepSeek demo 入口。\n3. 创建一个新 project，并确认 template、AI output language、parent directory 写入 desktop settings。\n4. 打开一个已有 vault，并确认 runtime path、dashboard\u002Fstatus、review queue 能被识别。\n5. 从桌面端打开 Obsidian，确认打开的是生成后的 vault，不是原始 PDF 文件夹。\n6. 导入一个小样本文件，在 Raw Sources 页确认 Refresh \u002F Import \u002F Folder \u002F details drawer 可用。\n7. 打开 Chat \u002F Search，搜索 source\u002Fclaim，并生成 proposal-first query writeback。\n8. 打开 Graph，确认 source \u002F claim \u002F concept \u002F review \u002F proposal \u002F warning 关系可用于追踪 evidence。\n9. 未获得明确人工批准时，确认 writeback 没有静默写入 `concepts\u002F` 或 `sources\u002F`。\n10. 如批准并 apply 了 proposal，再运行 lint\u002Feval 或对应 runtime validation。\n11. 记录本地 app 路径、vault 路径、Obsidian entry file、writeback proposal 路径和验证命令结果。\n\n## Known limitations\n\n- 本仓库仍是源码级 release candidate；正式分发还需要 Developer ID signing、hardened runtime、notarization 和 clean-profile install smoke test。\n- `Chat \u002F Search` 当前以 vault-local evidence index 和 proposal handoff 为主，不是无证据通用 RAG。\n- `Graph` 当前是 evidence navigation graph，优先可追踪性、断点定位、共享邻居阅读推荐、同类型页面加权、桥接节点、意外连接 insight 和 proposal-first 研究主题 handoff，不追求复杂社区发现或布局算法。\n- 外部模型 provider 只保存 provider\u002Fmodel\u002Fcontext\u002Freasoning 配置，不在 UI 明文保存或展示 API key。\n\n## Runtime 设置\n\n桌面端优先使用当前 vault 内的：\n\n```text\n\u003Cvault>\u002F.open-llm-wiki\u002Fscripts\u002F\n```\n\n如果 vault 还没有 runtime，可以在 UI 里选择 `open-llm-wiki` 仓库路径。创建 vault 时，桌面端会调用：\n\n```bash\npython scripts\u002Fwiki_init.py \u003Cvault> --repo-root \u003Copen-llm-wiki>\n```\n\n如启用 Obsidian，则追加：\n\n```bash\n--obsidian --obsidian-profile \u003Cminimal|research|full>\n```\n\n## 技术边界\n\n- `open-llm-wiki`: runtime-first、安全边界、vault schema、dashboard\u002Fstatus 工作流。\n","LLM Wiki Desktop 是一个将文档编译成本地链接的、由大语言模型维护的维基系统的桌面应用程序。它使用 TypeScript 编写，核心功能包括 vault 管理、导入入口、任务编排、状态展示和错误恢复等，而知识生成、问答、审查队列及写回审批等功能则由 `open-llm-wiki` 运行时处理。该项目支持从 PDF 或图片中解析内容，并通过 LLM 生成基于证据的答案草案，同时提供了详细的证据图谱查看功能。适用于需要在本地环境中构建和管理复杂知识库的场景，特别适合科研人员或团队对文献资料进行整理与分析。","2026-06-11 04:05:13","CREATED_QUERY"]