ask

立即执行

问题：$ARGUMENTS

如果未提供问题，请询问用户想了解什么。

执行以下步骤：

1. 对问题分类 — 确定要查询哪些知识库层级（参见下方“问题分类”）
2. 搜索知识库 — 根据分类路由到相应层级
3. 阅读相关主张和文档 — 完整加载 3-7 个最相关的来源（读取多个 ID 时使用 mcp__qmd__multi_get）
4. 检查用户上下文 — 如果问题涉及用户的具体系统，请读取 ops/derivation.md
5. 综合答案 — 将各项主张融会贯通，形成连贯且有明确观点的论述
6. 引用来源 — 引用具体主张和文档，方便用户进一步了解

现在开始。 下文将介绍路由和综合方法。

---

三层知识库

此插件的知识库由三个不同部分组成，各自承担不同功能。有效的回答通常会参考多个层级。

第 1 层：研究图谱（原因）

位置： ${CLAUDE_PLUGIN_ROOT}/methodology/ — 按 kind: research 筛选
内容： 213 条相互关联的研究主张，基于认知科学、知识系统理论和 Agent 认知研究。
用途： 回答有关原则、权衡、事物为何有效以及理论基础的问题。

包含内容：

• 关于知识系统（人类和 Agent）如何运作的主张
• 认知科学基础（工作记忆、注意力、检索）
• 方法论比较（Zettelkasten 与 PARA、原子化与复合式）
• 设计维度（包含两端及决策因素的权衡范围）
• 失效模式和反模式
• Agent 特有的限制（上下文窗口、会话边界）

搜索策略： 对概念性问题使用 mcp__qmd__deep_search（质量最高，由大模型重新排序）。使用 mcp__qmd__vector_search 进行语义探索。对已知术语使用 mcp__qmd__search。所有搜索均使用 methodology 集合。

第 2 层：指导文档（方法）

位置： ${CLAUDE_PLUGIN_ROOT}/methodology/ — 按 kind: guidance 筛选
内容： 9 份操作性文档，涵盖流程、工作流和实施依据。
用途： 回答有关如何执行任务、操作最佳实践和工作流机制的问题。

文档包括：

• 架构强制执行的依据和流程
• 流水线理念和处理工作流
• MOC 方法论和导航模式
• 维护模式和基于条件的触发机制
• 记忆架构和会话管理
• 词汇转换流程
• 失效模式预防模式
• 多领域组合规则
• 入门和演进决策

搜索策略： 使用问题中的关键词，通过 methodology 集合执行 mcp__qmd__search。若要缩小到指导文档范围，可在结果的 grep 过滤器中添加 kind:guidance。

第 3 层：领域示例（实际呈现方式）

位置： ${CLAUDE_PLUGIN_ROOT}/methodology/ — 按 kind: example 筛选
内容： 12 份特定领域的组合示例，展示生成的知识库在实践中的样貌。
用途： 回答如何将方法论应用于特定领域的问题，或为新领域映射提供灵感。

示例涵盖的领域包括：

• 研究知识库（学术文献综述、主张提取）
• 个人助手知识库（生活管理、治疗、健康与养生）
• 项目管理知识库（决策跟踪、利益相关方背景信息）
• 创意知识库（世界构建、角色跟踪）
• 工程、法律、交易、学生学习、人际关系

搜索策略： 在 methodology 集合中使用 mcp__qmd__vector_search 进行语义领域匹配。若要列出所有示例：rg '^kind: example' ${CLAUDE_PLUGIN_ROOT}/methodology/。

参考文档（结构化推导上下文）

位置： ${CLAUDE_PLUGIN_ROOT}/reference/ 内容： 支持推导和系统架构的结构化参考文档。 用途： 深入了解特定架构主题、交叉参考各维度的位置，以及理解交互约束。

核心架构：

• methodology.md — 通用原则和处理流程
• components.md — 组件蓝图和功能模块
• kernel.yaml — 12 项不可妥协的基本要素
• three-spaces.md — self/notes/ops 架构和边界规则

配置与推导：

• dimension-claim-map.md — 哪些研究主张会影响哪些维度
• interaction-constraints.md — 维度选择如何对其他维度造成压力
• tradition-presets.md — 配置空间中的命名点
• vocabulary-transforms.md — 通用术语到领域术语的映射
• derivation-validation.md — 派生系统的验证测试

行为与质量：

• personality-layer.md — 个性推导与编码
• conversation-patterns.md — 完整推导路径的实例
• failure-modes.md — 知识系统如何衰亡及其预防模式

生命周期与运维：

• use-case-presets.md — 常见领域的预设配置
• session-lifecycle.md — 会话节奏、上下文预算、定向-工作-持久化
• evolution-lifecycle.md — 种子化-演进-重新播种、基于条件的维护
• self-space.md — Agent 身份生成、self/ 架构
• semantic-vs-keyword.md — 搜索方式选择指南
• open-questions.md — 尚未解决的研究问题和暂缓处理的事项

另请阅读： claim-map.md — 路由索引，展示各项主张对应的主题。需要快速查找相关主张时，请从这里开始。

---

查询分类

搜索前，先对用户的问题分类，以确定需要查阅哪些层级。

分类规则

问题类型	特征	主要层级	次要层级
WHY（为什么）	“为什么会……”“理由是什么……”“……背后的理论是什么……”“为什么不直接……”	研究图谱	指南文档
HOW（如何）	“我该如何……”“……的工作流程是什么”“我应该如何……”“流程是什么……”	指南文档	研究图谱
WHAT（是什么）	“X 是什么样的……”“给我看个例子……”“……会如何运作”“Y 知识库会是什么样……”	领域示例	指南文档
COMPARE（比较）	“X 与 Y”“……有什么区别”“我该用 X 还是 Y……”“……之间的取舍”	研究图谱	示例
DIAGNOSE（诊断）	“总觉得哪里不对……”“为什么无法正常工作……”“我的系统在应该……时却在做 X……”	指南文档 + 参考文档（failure-modes.md）	研究图谱
CONFIGURE（配置）	“哪个维度……”“我该如何设置……”“……该用什么配置”“哪个预设……”	参考文档（维度、约束）	研究图谱
EVOLVE（演进）	“我该不该更改……”“我的系统已经扩展……”“这已经不再适用……”	参考文档（evolution-lifecycle.md）	指南文档

多层问题

许多问题需要查阅多个层级。上面的分类展示了主要和次要层级。务必确认：结合其他层级的证据是否能让答案更有说服力？

多层路由示例：

问题：“为什么我的系统使用原子笔记，而不是较长的文档？”

1. WHY 层级 — 在研究图谱中搜索有关原子性、粒度和可组合性的论点
2. 参考资料 — 查看 dimension-claim-map.md，了解粒度维度所依据的论点
3. 用户上下文 — 查看 ops/derivation.md，了解用户对粒度的具体立场及其理由
4. WHAT 层级 — 可选：查找示例，了解类似领域中的原子笔记是什么样的

问题：“如何处理篇幅很长的治疗会谈笔记？”

1. HOW 层级 — 搜索有关处理工作流和分块策略的指导
2. WHAT 层级 — 查看治疗或个人领域中面临类似挑战的示例
3. WHY 层级 — 搜索有关上下文退化、分块优势和大型来源处理的论点

---

搜索策略

步骤 1：转到 Claim-Map

首先阅读 ${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md。这是路由索引，展示了哪些主题领域与用户的问题相关，以及应从哪些论点入手。不要跳过这一步，盲目搜索。

步骤 2：搜索相应层级

对于 WHY 问题（研究图谱）：

mcp__qmd__deep_search  query="[user's question rephrased as a search]"  collection="methodology"  limit=10

对于概念性问题，使用 mcp__qmd__deep_search（混合搜索 + LLM 重排），因为最佳关联通常使用与问题不同的词汇。结果会包含各种类型；优先选择 kind: research 的结果。

对于 HOW 问题（指导文档）：

mcp__qmd__search  query="[key terms from question]"  collection="methodology"  limit=5

首先使用关键词搜索，因为指导文档采用一致的术语。若关键词搜索未命中，再使用语义搜索。优先选择 kind: guidance 的结果。

对于 WHAT 问题（领域示例）：

mcp__qmd__vector_search  query="[domain + what the user wants to see]"  collection="methodology"  limit=5

使用语义搜索，查找最相关的领域示例，即使具体领域名称不同也没关系。优先选择 kind: example 的结果。

qmd 查询的回退顺序：

• MCP 工具（mcp__qmd__deep_search、mcp__qmd__vector_search、mcp__qmd__search）
• qmd CLI（qmd query、qmd vsearch、qmd search）
• 直接读取 ${CLAUDE_PLUGIN_ROOT}/methodology/ 和 ${CLAUDE_PLUGIN_ROOT}/reference/ 中的文件，或使用 grep 搜索

对于参考文档： 根据主题阅读特定的参考文档。claim-map 会指出哪些参考文档与问题相关。加载最相关的 2-4 份文档，而不是全部加载。

步骤 3：深入阅读

不要略读搜索结果。对于排名靠前的 3-7 条结果：

1. 阅读完整的论点说明或文档
2. 沿 wiki 链接查看相关论点（1 跳）
3. 留意论点之间如何相互关联并增强答案

深度原则： 引用 10 条论点却浅尝辄止，不如深入阅读较少的来源，并将 4 条论点融入连贯的论述中。少读一些，读得更深入。

步骤 4：检查用户上下文

如果问题涉及用户的具体系统：

1. 阅读推导文档 — ops/derivation.md 包含用户的维度立场、词汇、约束，以及每项配置选择背后的理由
2. 应用词汇 — 使用 ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md，将通用术语转换为用户所在领域的表达。如果用户运行的是治疗系统，应使用“反思”而非“论点”
3. 检查约束 — 参考 ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md，了解其配置是否带来与问题相关的特定压力
4. 引用维度特定研究 — 使用 ${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md，依据支撑其配置的具体论点来作答

步骤 5：检查本地方法论

阅读 ops/methodology/，了解系统特定的自我认知。方法论笔记可能比推导文档更新——它们记录了持续积累的运营经验，而原始推导未能预见这些经验。

# Load all methodology notes
for f in ops/methodology/*.md; do
  echo "=== $f ==="
  cat "$f"
  echo ""
done

当方法论笔记涉及用户的问题时：

• 在引用研究观点时一并引用这些笔记：“您系统的方法论笔记指出了 [X]，这与研究观点 [[Y]] 一致”
• 如果方法论笔记与研究观点矛盾，请指出这种冲突：“您的方法论笔记指出了 [X]，但研究表明 [Y]——这或许值得通过 /{DOMAIN:rethink} 进一步调查”
• 对于“我的系统是如何运作的”这类问题，关于系统行为的方法论笔记比通用研究图谱更具权威性

优先参考方法论的情况：

• 关于“我的系统为什么会执行 X”的问题——方法论笔记记录了具体原因
• 关于行为模式的问题——方法论笔记记录了系统特定的经验
• 关于配置的问题——方法论笔记可能记录了 derivation.md 中未提及的初始化后变更

优先参考研究的情况：

• 关于“为什么 X 通常是个好主意”的问题——研究观点提供了理论基础
• 关于替代方案的问题——研究图谱涵盖了系统未选择的方案
• 关于方法论比较的问题——研究观点系统地比较了不同传统

---

答案综合

结构

每个答案都遵循以下结构：

1. 直接回答——开门见山地给出答案，而不是描述搜索过程。不要说“我搜索了 X 并找到了 Y”。直接说明答案是什么。

2. 研究依据——列出支持该答案的具体观点。按标题引用：“根据 [[claim title]]……”

3. 实际影响——说明这对用户的具体情况意味着什么。如果推导中提供了相关领域的术语，请使用这些术语。

4. 冲突或注意事项——指出尚未解决的冲突、局限，或答案可能不适用的情况。研究中确实存在一些冲突，请如实说明。

5. 进一步探索——列出用户可能想进一步了解的相关观点或主题。这些是探索的起点，不是任务。

6. 参考来源——简要说明使用了哪些知识层：“研究：参考了 [N] 条观点。本地方法论：参考了 [M] 篇笔记。”如果本地方法论与答案相关，请指出具体笔记：“您的方法论笔记 [[title]] 为答案中的[具体部分]提供了依据。”

质量标准

回答应基于具体论据，而非一般知识。 知识库的存在是为了让回答有据可依。如果不查询图谱，而是凭一般知识作答，你就是绕过了工具。

如实说明信息缺口。 如果研究未涵盖某个主题，就说明这一点。“当前研究图谱中没有关于 X 的论据”是合理的回答。不要捏造研究覆盖范围。

区分确定性级别。 有些论据已得到多个论据的充分支持，另一些则只是初步观察或研究方向。论据 frontmatter 中的 confidence 字段表示：

• 没有 confidence 字段 — 标准的既定论据
• confidence: speculative — 初期观察，尚未经过充分评估
• confidence: emerging — 前景良好，但仍需要更多支持
• confidence: supported — 有充分证据支持的论据
• confidence: established — 基础性、广受支持的论据
• status: archived — 已被取代或已解散的论据

明确表达立场。 研究有自己的立场。与其说“有些来源认为 X，另一些则认为 Y”，不如说“研究强烈表明 X，因为……”。如果确实存在分歧，应将其呈现为一种张力，而非虚假的平衡。

结合用户情境进行转化。 如果用户有一套推导过程，就将研究发现应用到他们的系统中。具体应用比泛泛建议更有用。“在你的 therapy vault 中，这意味着……”优于“一般来说，这意味着……”。

示例

示例 1：WHY 问题

问题：“为什么我的系统使用原子笔记，而不是较长的文档？”

**分类：**WHY -> 主要来源：研究图谱。次要来源：参考文档（dimension-claim-map）。

搜索：

1. mcp__qmd__deep_search query="atomic notes vs compound documents granularity" collection="methodology" limit=8
2. 阅读 reference/dimension-claim-map.md — 查找 granularity 维度所依据的论据
3. 阅读 ops/derivation.md — 检查用户对 granularity 的立场

回答：

你的系统采用原子粒度，因为你在对话中表达了“提取论文中的精确论据”的需求。研究表明，原子笔记便于独立链接与重新组合——根据 [[atomic notes maximize recombinable surface area]]，每条笔记都可以从任意上下文中链接，而不会连带无关内容。你的处理流程（extract -> reflect -> reweave -> verify）明确要求采用原子粒度，以维持链接网络，因为 [[verify phase checks link density per note]]，而复合文档会人为抬高链接数量。

这种做法的代价是：原子笔记会产生更多文件，也需要更密集的导航结构。[[flat organization requires semantic search at scale]] 解释了为什么你的系统包含语义搜索——没有它，当扁平的原子结构超过约 50 条笔记时，查找笔记就会变得不切实际。

张力： [[composability and context compete at the note level]] — 笔记写得足够小，才能实现清晰的链接；但有时也会因此变得太小，无法独立承载论证。你的系统通过描述字段和主题图中的上下文短语来应对这一问题。

示例 2：HOW 类问题

问题：“如何处理一篇大型研究论文？”

**分类：**HOW -> 主要：指导文档。次要：研究图谱。

搜索：

1. mcp__qmd__search query="large source processing chunking" collection="methodology" limit=5
2. mcp__qmd__deep_search query="context degradation large documents extraction" collection="methodology" limit=5

回答：

对于超过 2500 行的来源，应将其拆分为 350-1200 行的片段，并使用全新的上下文处理每个片段。[指导：流水线处理工作流] 详细说明了分块策略。

原因在于[[随着对话变长，上下文质量会下降]]——处理一份 3000 行文档时，后面部分的提取质量会明显低于前面部分。每个片段使用全新的上下文，可确保每个部分都能得到你最好的关注。

实用步骤：

1. 运行 /seed 创建提取任务
2. /reduce 会自动检测来源大小并规划分块
3. 每个片段都会独立提取，并在各片段之间维护一份持续更新的重复项列表
4. 最终提取报告会涵盖所有合并后的片段

你的配置中有 processing.depth: standard，这意味着各片段会在当前会话中按顺序处理。如果切换到 deep，每个片段都会使用各自独立的上下文（质量最高，但速度较慢）。

示例 3：WHAT 类问题

问题：“烹饪食谱库会是什么样子？”

**分类：**WHAT -> 主要：领域示例。次要：指导文档。

搜索：

1. mcp__qmd__vector_search query="cooking recipes culinary knowledge system" collection="methodology" limit=5
2. 阅读最接近的领域示例，获取结构方面的灵感

回答：

[根据示例综合得出的回答，展示具体的文件夹结构、笔记示例、主题地图示例，以及烹饪领域特有的词汇选择。引用结构模式最接近的现有领域示例。]

---

反模式

不要这样做

反模式	失败原因	应改为
不搜索就回答	完全绕过知识库	始终进行搜索，即使问题看起来“显而易见”
罗列主张而不加综合	直接倾倒搜索结果，迫使用户自行串联要点	将主张融入连贯的论述
只搜索一个层级	回答 WHY 时遗漏 HOW，反之亦然	检查次要层级能否加强回答
忽略用户的推导记录	明明有具体建议，却给出泛泛而谈的建议	阅读 ops/derivation.md，了解用户上下文
使用通用词汇	用户的系统称其为“反思”，却说成“笔记”	应用词汇转换
编造主张引用	引用图谱中不存在的主张	只引用实际读过的主张
跳过主张映射	没有路由就盲目搜索	先阅读主张映射，了解主题方向
制造虚假的平衡	研究已有明确结论，却说“有人认为 X，也有人认为 Y”	明确表态——分享研究的立场

诚实标准

如果知识库确实没有涵盖某个主题：

1. 明确说明：“当前研究图谱中没有关于 X 的主张。”
2. 提供现有的相关内容：“最接近的相关研究是关于 Y 的，这表明……”
3. 将其标记为缺口：“这可能值得作为一个研究方向进行调查。”

不要从仅有切题关系的主张中大幅度推演。诚实地说“我不知道，但以下是相关内容”，比编造答案更有价值。

---

面向领域的回答

当用户的问题涉及其特定系统（而非抽象方法论）时：

步骤 1：阅读其推导过程

查看 ops/derivation.md，了解：

• 其维度位置（粒度、组织方式、处理深度等）
• 其词汇选择（在其领域中，“notes” 称作什么？）
• 其传统映射（使用了哪种方法论预设（如果有）？）
• 其个性设置（正式/温和、临床/对话式）
• 其约束配置（启用了哪些交互约束？）

步骤 2：应用领域词汇

使用 ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md，将通用术语转换为其领域语言。这并非表面修饰，而是要让答案融入其系统。

通用术语	治疗领域	PM 领域	研究领域
notes	reflections	decisions	claims
topic map	theme map	project map	MOC
reduce	surface	extract	reduce
reflect	connect	link	reflect
inbox	journal	intake	inbox

步骤 3：检查交互约束

参考 ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md，了解其配置是否会带来与问题相关的特定影响。某些维度组合会产生影响答案的张力：

• 高粒度 + 扁平组织 = 需要强大的语义搜索
• 宽松的筛选性 + 深度处理 = 量大、吞吐速度较慢
• 启用自我空间 + 温和个性 = 丰富的身份层

步骤 4：引用维度专项研究

使用 ${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md，以支持其配置选择的具体论据为答案提供依据。这样答案便可追溯：“你的系统之所以执行 X，是因为论据 Y 支持你的配置采用这种做法。”