一次查询，两个产出

每次你打开 Query 界面问一个问题，实际上得到的是两样东西。

第一样显而易见：答案。LLM 读取你的 Wiki，找到相关页面，返回一段回答。你拿到了想要的信息，关掉面板，继续干活。

第二样很容易被忽略：这个答案本身就是一份值得保存的整合成果。

当 LLM 回答”我的笔记里关于检索增强生成，在不同的源文章中说了什么？“时，它不是做简单的复制粘贴。它会跨多个来源交叉引用实体，识别你不同时间写下的概念之间的联系，产出一份结构化的回答——这份回答在你的 Wiki 中任何一个单独的页面上都不存在。

这份整合就是新的知识。只需要点一下鼠标，你就能把它永久保存为 Wiki 页面。

什么时候该保存查询结果

不是每个查询答案都配得上一个独立页面。下面这些情况值得保存。

跨领域整合。 你问”Transformer 架构跟我之前写的注意力机制有什么关系？“答案引用了三篇不同的源文章，连接了你之前没显式关联过的概念，产生了一个统一的解释。这份整合在你的 Wiki 里其他地方不存在。存它。

对比分析。 “针对我的使用场景，对比一下 DeepSeek V4-Flash 和 Claude Sonnet 4.6。“LLM 根据你自己的笔记权衡优缺点。结果是一份对比文档，以后的查询可以直接引用。存它。

决策追溯。 “根据我写过的内容，我的项目应该用 RAG 还是微调？“答案追踪了你跨多个来源的推理过程，得出一个结论。六个月后你会想重温那段推理。存它。

意外洞见。 有时候价值不在于实用，而在于认知上的启发。一个查询产生了你从未想过的连接。LLM 说”你在 X 和 Y 上的笔记暗示了一个模式：Z 在特定条件下会出现。“这个洞见来自多个来源的组合，不是任何一个单独来源能产生的。存它。

什么时候别保存

大多数查询不需要保存。

查个简单事实。“《Attention Is All You Need》是哪年发表的？“一个事实，一个来源，瞬间回答。建一个页面纯粹是噪音。

**已有记录的信息。**你问”什么是 Transformer 架构？“答案和你现有的 Wiki 页面基本一致。LLM 只是换了个说法复述你已经有的内容。没有创造新知识。

时效性答案。“我上周关于项目截止日期都写了什么？“答案是跟时间绑定的。下周就过时了。建一个永久页面马上就会变得陈旧。

瞎猜。“你觉得 AI 的下一个突破会是什么？“LLM 不知道。它会基于通用知识生成一个听起来合理的回答，而不是基于你的源材料。保存猜测只会用低质量内容污染你的 Wiki。

记住一条简单规则：只有当答案包含的整合内容能让”未来的你”愿意回看时，才保存。 如果今天有用、明天就废，别存。

怎么保存：五个步骤

从查询到 Wiki 页面的完整流程。

第一步：提问。 打开 Query 界面，问一个值得深挖的问题。好的查询会涉及多个来源或概念：“我保存的那些关于注意力机制的论文之间有什么联系？“坏的查询是查单个事实：“Transformer 论文是哪年发表的？”

第二步：阅读答案。 让 LLM 流式输出完整的回答，别中途打断。仔细看看这份整合：是否包含了新的连接？存为独立页面有用吗？

第三步：点击”Save to Wiki”。 Save to Wiki 按钮就在 Query 界面的工具栏上。一键把当前对话保存为 Wiki 里的一个新页面。插件会自动从答案中提取关键实体和概念，加入 Wiki 索引。

第四步：检查保存的页面。 打开 wiki/ 文件夹里新建的页面。LLM 生成的内容已经包含了 [[wiki-links]]，指向它引用的所有源实体和概念。检查一下链接。有需要的话可以自己加笔记。它跟任何 Markdown 文件一样可编辑——不是锁死的。

第五步：验证连接。 打开 Graph View。新页面作为一个节点出现在图中，连接着它引用的所有内容。如果这个页面整合了三个来源，你会看到三条边分别连着那些已有的页面。

语义去重

假如你保存的查询答案和已有的 Wiki 页面内容撞车了怎么办？

插件会做检查。在创建新页面之前，它会用语义相似度对比现有页面。如果新的答案与某个已有页面的重叠超过了一个可配置的阈值，插件会询问你是否要把答案追加到那个页面里，而不是创建一个重复的。

这防止了 Wiki 最常见的一个质量问题：换了个说法把同一件事又写了一遍。Lint 系统的重复检测也会捕获漏网之鱼，但保存时的语义去重是第一道防线。

查询增强回路

这个反馈回路随着时间推移是这样运作的：

摄入——你写一条源笔记，运行 Ingest Sources。Wiki 获得了实体页面、概念页面和交叉链接。
查询——你问一个跨多个实体的综合问题。LLM 整合出新知识。
保存——你把整合结果保存为新的 Wiki 页面。它带着正确的链接进入现有的知识网络。
未来的查询引用它——当有人（包括你自己）以后再问类似话题时，保存下来的整合结果会作为源页面出现在查询上下文中。

这个循环会不断积累。每次保存的查询都会让未来的查询更丰富，因为 LLM 有了更多的材料可供参考。几个月后，那些从查询中诞生的页面会成为你的 Wiki 中被引用最多的页面之一——因为它们天生就是”整合”，而不是原始的笔记碎片。

实操案例

你的 Wiki 里有三份源材料：一篇关于混合专家模型（Mixture of Experts, MoE）架构，一篇关于模型量化技术，一篇关于推理优化策略。它们是三个独立的页面，各自有不同的链接。

你打开 Query 问：“根据我的笔记，MoE 和量化在降低模型推理成本方面，实际中有什么权衡取舍？”

LLM 读取三个来源后返回：

你关于 MoE 的笔记显示，路由开销会使延迟比同等参数量的单一密集模型增加 10-20%。你关于量化的笔记显示，INT8 可以减少 75% 的内存占用，精度损失很小。对于延迟敏感的应用，量化可能比 MoE 更实用。对于内存受限、但对延迟有一定容忍度的部署场景，MoE 则更灵活，因为你可以在运行时调整激活的专家数量。

这个整合在任何单一来源中都不存在。它是组合产生的新知识。你点击 Save to Wiki。插件创建一个新页面，标题为”MoE vs 量化——实践中的权衡”，其中包含指向你现有的 MoE、量化和推理优化页面的 [[wiki-links]]。

三个月后，你在做一个部署项目。你打开 Query 问”降低推理成本需要考虑哪些权衡？“LLM 的上下文中包含了那条保存下来的整合页面。它的回答会更丰富，只因为你当初花了 15 秒保存了那次对话。

配置选项

Save to Wiki 功能在设置中有可配置的行为：

自动保存（关闭时）——开启后，关闭 Query 面板时会自动把对话保存为 Wiki 页面。谨慎使用：你会为每一次查询都生成页面，包括那些一次性的。建议只在你能定期审核和清理时开启。
去重阈值——新答案与已有页面的语义相似度达到多少时触发去重。默认 0.85（85% 相似度）。更低的值能捕获更多重复，但也可能误判。
保存格式——可选择”完整对话（问题和答案）“或”仅答案”。仅答案能减少噪音。
命名规则——自定义保存页面的命名方式。默认使用你问题的截断版本。可选日期前缀、主题前缀或手动命名。

注意事项

三个需要了解的点。

LLM 生成的内容可能包含错误。 LLM 是在整合你的源材料，不是逐字抄写。它可能误解、过度概括或引入细微的不准确之处。在依赖这些页面做重要工作之前，先检查一下。插件会用元数据标记自动生成的页面，所以你随时能分辨哪些来自查询、哪些来自摄入。

保存的查询页面可能过时。 如果你之后删除或大幅修改了当初作为依据的源页面，保存下来的页面可能会引用已不存在或与你当前理解相矛盾的信息。定期重新摄入或手动检查会有帮助。Lint 系统会自动标记死链。

保存的页面增加了 Lint 负担。 Wiki 中的每个页面都要接受 Lint 检查——重复检测、孤立页面检测、死链检测、别名完整性。保存的查询页面增加了总页面数，也就扩大了维护面。对于小型 Wiki（200 页以下），这个影响可以忽略。对于大型 Wiki，保存时要有选择性。

下一步

现在你理解了查询到 Wiki 的反馈回路：每次好的查询如何产生永久知识，什么时候该保存（以及什么时候不该），以及插件如何通过语义去重防止重复。

下一篇：动手实践（二）：日常知识循环——从阅读到内化 —— 从早上的阅读到晚上的回顾，一整套日常知识增长流程。

在 GitHub 上查看

动手实践（一）：保存每一次查询