ask

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

EXECUTE NOW

立即执行

Question: $ARGUMENTS

If no question provided, ask the user what they want to know.

Execute these steps:

Classify the question — determine which knowledge base tier(s) to consult (see Query Classification below)
Search the knowledge base — route to appropriate tiers based on classification
Read relevant claims and docs — load 3-7 most relevant sources fully (use
```
mcp__qmd__multi_get
```
when reading multiple IDs)
Check user context — read
```
ops/derivation.md
```
if the question involves their specific system
Synthesize an answer — weave claims into a coherent, opinionated argument
Cite sources — reference specific claims and documents so the user can explore further

START NOW. Reference below explains routing and synthesis methodology.

问题：$ARGUMENTS

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

执行以下步骤：

分类问题 —— 确定需要查询哪些知识库层级（参见下方的问题分类）
搜索知识库 —— 根据分类结果将问题路由到对应层级
读取相关结论和文档 —— 完整加载3-7个最相关的来源（读取多个ID时使用
```
mcp__qmd__multi_get
```
）
检查用户上下文 —— 如果问题涉及用户的特定系统，读取
```
ops/derivation.md
```
合成答案 —— 将研究结论整合为连贯、有明确观点的论证
引用来源 —— 标注具体的研究结论和文档，方便用户进一步探索

立即开始。 下方参考内容解释了路由和合成方法论。

The Three-Tier Knowledge Base

三层知识库

The plugin's knowledge base has three distinct parts, each serving a different function. Effective answers often draw from multiple tiers.

该插件的知识库包含三个不同部分，各自承担不同功能。有效的答案通常会结合多个层级的内容。

Tier 1: Research Graph (WHY)

层级1：研究图谱（WHY）

Location:

${CLAUDE_PLUGIN_ROOT}/methodology/

— filter by

kind: research

Content: 213 interconnected research claims grounded in cognitive science, knowledge system theory, and agent cognition research. Use for: Questions about principles, trade-offs, why things work, theoretical foundations.

What it contains:

Claims about how knowledge systems work (human and agent)
Cognitive science foundations (working memory, attention, retrieval)
Methodology comparisons (Zettelkasten vs PARA, atomic vs compound)
Design dimensions (trade-off spectrums with poles and decision factors)
Failure modes and anti-patterns
Agent-specific constraints (context windows, session boundaries)

Search strategy: Use

mcp__qmd__deep_search

(highest quality, LLM-reranked) for conceptual questions. Use

mcp__qmd__vector_search

for semantic exploration. Use

mcp__qmd__search

for known terminology. All searches use the

methodology

collection.

位置：

${CLAUDE_PLUGIN_ROOT}/methodology/

—— 按

kind: research

筛选 内容： 213个相互关联的研究结论，基于认知科学、知识系统理论和Agent认知研究。 适用场景： 关于原理、权衡、事物运作机制、理论基础的问题。

包含内容：

关于知识系统（人类和Agent）运作方式的结论
认知科学基础（工作记忆、注意力、信息检索）
方法论对比（Zettelkasten vs PARA、原子化 vs 复合化）
设计维度（带有两极和决策因素的权衡范围）
失效模式和反模式
Agent特有的约束（上下文窗口、会话边界）

搜索策略： 对于概念类问题，使用

mcp__qmd__deep_search

（最高质量，经LLM重排序）。对于语义探索，使用

mcp__qmd__vector_search

。对于已知术语，使用

mcp__qmd__search

。所有搜索均使用

methodology

集合。

Tier 2: Guidance Docs (HOW)

层级2：指导文档（HOW）

Location:

${CLAUDE_PLUGIN_ROOT}/methodology/

— filter by

kind: guidance

Content: 9 operational documents covering procedures, workflows, and implementation rationale. Use for: Questions about how to do things, operational best practices, workflow mechanics.

Documents include:

Schema enforcement rationale and procedures
Pipeline philosophy and processing workflow
MOC methodology and navigation patterns
Maintenance patterns and condition-based triggers
Memory architecture and session management
Vocabulary transformation procedures
Failure mode prevention patterns
Multi-domain composition rules
Onboarding and evolution decisions

Search strategy:

mcp__qmd__search

with keywords from the question using the

methodology

collection. To narrow to guidance docs, add

kind:guidance

to your grep filter on results.

位置：

${CLAUDE_PLUGIN_ROOT}/methodology/

—— 按

kind: guidance

筛选 内容： 9份操作文档，涵盖流程、工作流和实现原理。 适用场景： 关于操作方法、最佳实践、工作流机制的问题。

包含文档：

模式实施原理和流程
流水线理念和处理工作流
MOC方法论和导航模式
维护模式和基于状态的触发机制
内存架构和会话管理
词汇转换流程
失效模式预防模式
多领域组合规则
入门和演进决策

搜索策略： 使用

mcp__qmd__search

，结合问题中的关键词，在

methodology

集合中搜索。如需缩小到指导文档，可在结果中添加

kind:guidance

作为grep筛选条件。

Tier 3: Domain Examples (WHAT IT LOOKS LIKE)

层级3：领域示例（WHAT IT LOOKS LIKE）

Location:

${CLAUDE_PLUGIN_ROOT}/methodology/

— filter by

kind: example

Content: 12 domain-specific compositions showing what generated vaults look like in practice. Use for: Questions about how to apply methodology to specific domains, inspiration for novel domain mapping.

Examples include domains like:

Research vaults (academic literature reviews, claim extraction)
Personal assistant vaults (life management, therapy, health wellness)
Project management vaults (decision tracking, stakeholder context)
Creative vaults (worldbuilding, character tracking)
Engineering, legal, trading, student learning, relationships

Search strategy: Use

mcp__qmd__vector_search

across the

methodology

collection for semantic domain matching. To list all examples:

rg '^kind: example' ${CLAUDE_PLUGIN_ROOT}/methodology/

位置：

${CLAUDE_PLUGIN_ROOT}/methodology/

—— 按

kind: example

筛选 内容： 12个特定领域的组合示例，展示生成的知识库在实际中的样子。 适用场景： 关于如何将方法论应用于特定领域、为新型领域映射获取灵感的问题。

涵盖领域示例：

研究知识库（学术文献综述、结论提取）
个人助理知识库（生活管理、心理治疗、健康养生）
项目管理知识库（决策跟踪、利益相关者上下文）
创意知识库（世界观构建、角色跟踪）
工程、法律、交易、学生学习、人际关系

搜索策略： 在

methodology

集合中使用

mcp__qmd__vector_search

进行语义领域匹配。如需列出所有示例：

rg '^kind: example' ${CLAUDE_PLUGIN_ROOT}/methodology/

。

Reference Documents (structured derivation context)

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

Location:

${CLAUDE_PLUGIN_ROOT}/reference/

Content: Structured reference documents supporting derivation and system architecture. Use for: Deep dives into specific architectural topics, cross-referencing dimension positions, understanding interaction constraints.

Core Architecture:

```
methodology.md
```
— universal principles and processing pipeline
```
components.md
```
— component blueprints and feature blocks
```
kernel.yaml
```
— the 12 non-negotiable primitives
```
three-spaces.md
```
— self/notes/ops architecture and boundary rules

Configuration & Derivation:

```
dimension-claim-map.md
```
— which research claims inform which dimensions
```
interaction-constraints.md
```
— how dimension choices create pressure on others
```
tradition-presets.md
```
— named points in configuration space
```
vocabulary-transforms.md
```
— universal-to-domain term mapping
```
derivation-validation.md
```
— validation tests for derived systems

Behavioral & Quality:

```
personality-layer.md
```
— personality derivation and encoding
```
conversation-patterns.md
```
— worked examples of full derivation paths
```
failure-modes.md
```
— how knowledge systems die and prevention patterns

Lifecycle & Operations:

```
use-case-presets.md
```
— preset configurations for common domains
```
session-lifecycle.md
```
— session rhythm, context budget, orient-work-persist
```
evolution-lifecycle.md
```
— seed-evolve-reseed, condition-based maintenance
```
self-space.md
```
— agent identity generation, self/ architecture
```
semantic-vs-keyword.md
```
— search modality selection guidance
```
open-questions.md
```
— unresolved research questions and deferred items

Also read:

claim-map.md

— the routing index showing which claims map to which topics. Start here when you need to find relevant claims quickly.

位置：

${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

—— 显示哪些结论映射到哪些主题的路由索引。需要快速找到相关结论时，从这里开始。

Query Classification

问题分类

Before searching, classify the user's question to determine which tier(s) to consult.

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

Classification Rules

分类规则

Question Type	Signals	Primary Tier	Secondary Tier
WHY	"why does...", "what's the reasoning...", "what's the theory behind...", "why not just..."	Research Graph	Guidance Docs
HOW	"how do I...", "what's the workflow for...", "how should I...", "what's the process..."	Guidance Docs	Research Graph
WHAT	"what does X look like...", "show me an example...", "how would this work for...", "what would a Y vault..."	Domain Examples	Guidance Docs
COMPARE	"X vs Y", "what's the difference between...", "should I use X or Y...", "trade-offs between..."	Research Graph	Examples
DIAGNOSE	"something feels wrong...", "why isn't this working...", "my system is doing X when it should..."	Guidance Docs + Reference (failure-modes.md)	Research Graph
CONFIGURE	"what dimension...", "how should I set...", "what configuration for...", "which preset..."	Reference (dimensions, constraints)	Research Graph
EVOLVE	"should I change...", "my system has grown...", "this doesn't fit anymore..."	Reference (evolution-lifecycle.md)	Guidance Docs

问题类型	识别信号	主要层级	次要层级
WHY	"why does...", "what's the reasoning...", "what's the theory behind...", "why not just..."	研究图谱	指导文档
HOW	"how do I...", "what's the workflow for...", "how should I...", "what's the process..."	指导文档	研究图谱
WHAT	"what does X look like...", "show me an example...", "how would this work for...", "what would a Y vault..."	领域示例	指导文档
COMPARE	"X vs Y", "what's the difference between...", "should I use X or Y...", "trade-offs between..."	研究图谱	示例
DIAGNOSE	"something feels wrong...", "why isn't this working...", "my system is doing X when it should..."	指导文档 + 参考文档（failure-modes.md）	研究图谱
CONFIGURE	"what dimension...", "how should I set...", "what configuration for...", "which preset..."	参考文档（维度、约束）	研究图谱
EVOLVE	"should I change...", "my system has grown...", "this doesn't fit anymore..."	参考文档（evolution-lifecycle.md）	指导文档

Multi-Tier Questions

跨层级问题

Many questions require consulting multiple tiers. The classification above shows primary and secondary tiers. Always check: would the answer be stronger with evidence from another tier?

Example multi-tier routing:

Question: "Why does my system use atomic notes instead of longer documents?"

WHY tier — search research graph for claims about atomicity, granularity, composability
Reference — check
```
dimension-claim-map.md
```
for the granularity dimension's informing claims
User context — check
```
ops/derivation.md
```
for their specific granularity position and reasoning
WHAT tier — optionally pull an example showing what atomic notes look like in a similar domain

Question: "How should I handle therapy session notes that are very long?"

HOW tier — search guidance for processing workflow, chunking strategies
WHAT tier — check examples for therapy or personal domains with similar challenges
WHY tier — search for claims about context degradation, chunking benefits, large source handling

许多问题需要查询多个层级。上述分类显示了主要和次要层级。请始终检查：加入其他层级的证据是否能让答案更有说服力？

跨层级路由示例：

问题："Why does my system use atomic notes instead of longer documents?"

WHY层级 —— 在研究图谱中搜索关于原子性、粒度、可组合性的结论
参考文档 —— 查看
```
dimension-claim-map.md
```
中粒度维度的依据结论
用户上下文 —— 查看
```
ops/derivation.md
```
中用户的具体粒度设置和理由
WHAT层级 —— 可选择性地提取一个类似领域的示例，展示原子笔记的实际样子

问题："How should I handle therapy session notes that are very long?"

HOW层级 —— 在指导文档中搜索处理工作流、分块策略
WHAT层级 —— 查看治疗或个人领域中类似挑战的示例
WHY层级 —— 搜索关于上下文退化、分块优势、大源文件处理的结论

Search Strategy

搜索策略

Step 1: Route to Claim-Map

步骤1：路由到结论映射表

Read

${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md

first. This is the routing index — it shows which topic areas are relevant to the user's question and which claims to start with. Do NOT skip this step and search blindly.

首先阅读

${CLAUDE_PLUGIN_ROOT}/reference/claim-map.md

。这是路由索引——它显示了与用户问题相关的主题领域以及应从哪些结论开始查询。请勿跳过此步骤直接盲目搜索。

Step 2: Search the Appropriate Tier

步骤2：查询对应层级

For WHY questions (Research Graph):

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

Use

mcp__qmd__deep_search

(hybrid + LLM reranking) for conceptual questions because the best connections often use different vocabulary than the question. Results will include all kinds; prioritize

kind: research

results.

For HOW questions (Guidance Docs):

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

Use keyword search first since guidance docs use consistent terminology. Fall back to semantic if keyword misses. Prioritize

kind: guidance

results.

For WHAT questions (Domain Examples):

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

Use semantic search to find the most relevant domain examples even if the exact domain name differs. Prioritize

kind: example

results.

Fallback chain for qmd lookups:

MCP tools (

mcp__qmd__deep_search

mcp__qmd__vector_search

mcp__qmd__search

)

qmd CLI (
```
qmd query
```
,
```
qmd vsearch
```
,
```
qmd search
```
)

direct file reads/grep on

${CLAUDE_PLUGIN_ROOT}/methodology/

and

${CLAUDE_PLUGIN_ROOT}/reference/

For Reference documents: Read specific reference documents based on the topic. The claim-map will indicate which reference docs are relevant. Load the 2-4 most relevant — not all of them.

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

mcp__qmd__deep_search  query="[用户问题重述为搜索词]"  collection="methodology"  limit=10

对于概念类问题，使用

mcp__qmd__deep_search

（混合搜索+LLM重排序），因为最佳关联往往使用与问题不同的词汇。结果会包含各类内容，请优先选择

kind: research

的结果。

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

mcp__qmd__search  query="[问题中的关键词]"  collection="methodology"  limit=5

首先使用关键词搜索，因为指导文档使用一致的术语。如果关键词搜索未找到结果，再回退到语义搜索。优先选择

kind: guidance

的结果。

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

mcp__qmd__vector_search  query="[领域 + 用户想查看的内容]"  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
```
）

直接读取/ grep

${CLAUDE_PLUGIN_ROOT}/methodology/

和

${CLAUDE_PLUGIN_ROOT}/reference/

中的文件

对于参考文档： 根据主题读取特定的参考文档。结论映射表会指出哪些参考文档相关。加载2-4个最相关的文档即可，无需全部加载。

Step 3: Read Deeply

步骤3：深度阅读

Do NOT skim search results. For the top 3-7 results:

Read the full claim note or document
Follow wiki links to related claims (1 hop)
Note connections between claims that strengthen the answer

The depth principle: A shallow answer citing 10 claims is worse than a deep answer weaving 4 claims into a coherent argument. Read fewer sources more deeply.

请勿仅浏览搜索结果。对于前3-7个结果：

完整阅读结论笔记或文档
跟随wiki链接查看相关结论（1层深度）
记录结论之间的关联，以强化答案

深度原则： 引用10个结论的浅层答案，不如将4个结论整合为连贯论证的深度答案。少而精地深度阅读来源。

Step 4: Check User Context

步骤4：检查用户上下文

If the question involves the user's specific system:

Read derivation —
```
ops/derivation.md
```
contains their dimension positions, vocabulary, constraints, and the reasoning behind every configuration choice
Apply vocabulary — use
```
${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md
```
to translate universal terms into their domain language. Answer about "reflections" not "claims" if they are running a therapy system
Check constraints — reference
```
${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md
```
to see if their configuration creates specific pressures relevant to the question
Cite dimension-specific research — use
```
${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md
```
to ground answers in the specific claims that inform their configuration

如果问题涉及用户的特定系统：

读取推导文档 ——
```
ops/derivation.md
```
包含用户的维度设置、词汇、约束以及每个配置选择背后的理由
应用词汇转换 —— 使用
```
${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md
```
将通用术语转换为用户的领域语言。如果用户运行的是治疗系统，请使用“reflections”而非“claims”来回答
检查约束 —— 参考
```
${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md
```
，查看用户的配置是否会产生与问题相关的特定影响
引用维度相关研究 —— 使用
```
${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md
```
，将答案建立在为用户配置提供依据的特定结论之上

Step 5: Check Local Methodology

步骤5：检查本地方法论

Read

ops/methodology/

for system-specific self-knowledge. Methodology notes may be more current than the derivation document — they capture ongoing operational learnings that the original derivation did not anticipate.

bash

undefined

读取

ops/methodology/

中的系统特定自我知识。方法论笔记可能比推导文档更新——它们记录了原始推导未预料到的持续运维经验。

bash

undefined

Load all methodology notes

加载所有方法论笔记

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


**When methodology notes address the user's question:**
- Cite them alongside research claims: "Your system's methodology notes say [X], which aligns with the research claim [[Y]]"
- If methodology notes contradict research claims, flag the tension: "Your methodology note says [X], but the research suggests [Y] — this may be worth investigating with /{DOMAIN:rethink}"
- Methodology notes about system behavior are more authoritative for "how does MY system work" questions than the general research graph

**When to prioritize methodology over research:**
- Questions about "why does my system do X" — methodology notes capture the specific rationale
- Questions about behavioral patterns — methodology notes capture system-specific learnings
- Questions about configuration — methodology notes may document post-init changes not in derivation.md

**When to prioritize research over methodology:**
- Questions about "why is X a good idea in general" — research claims provide the theoretical foundation
- Questions about alternative approaches — the research graph covers options the system did not choose
- Questions about methodology comparisons — research claims compare traditions systematically

---

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


**当方法论笔记涉及用户问题时：**
- 将其与研究结论一起引用：“您系统的方法论笔记指出[X]，这与研究结论[[Y]]一致”
- 如果方法论笔记与研究结论矛盾，请标注这种矛盾：“您的方法论笔记指出[X]，但研究建议[Y]——这可能值得通过/{DOMAIN:rethink}进行调查”
- 对于“我的系统如何工作”类问题，关于系统行为的方法论笔记比通用研究图谱更具权威性

**何时优先使用方法论而非研究：**
- 关于“我的系统为什么要做X”的问题——方法论笔记记录了具体理由
- 关于行为模式的问题——方法论笔记记录了系统特定的经验
- 关于配置的问题——方法论笔记可能记录了推导文档中未提及的初始化后变更

**何时优先使用研究而非方法论：**
- 关于“为什么X总体上是个好主意”的问题——研究结论提供了理论基础
- 关于替代方案的问题——研究图谱涵盖了系统未选择的选项
- 关于方法论对比的问题——研究结论系统地对比了不同流派

---

Answer Synthesis

答案合成

Structure

结构

Every answer follows this structure:

Direct answer — Lead with the answer, not the search process. Do not say "I searched for X and found Y." Say what the answer IS.
Research backing — What specific claims support this answer. Cite by title: "According to [[claim title]]..."
Practical implications — What this means for the user's specific situation. Use their domain vocabulary if available from derivation.
Tensions or caveats — Any unresolved conflicts, limitations, or situations where the answer might not hold. The research has genuine tensions — share them honestly.
Further exploration — Related claims or topics the user might want to explore. These are departure points, not assignments.
Sources consulted — Briefly note which knowledge layers were used: "Research: [N] claims consulted. Local methodology: [M] notes consulted." When local methodology was relevant, name the specific note: "Your methodology note [[title]] informed the [specific part] of this answer."

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

直接答案 —— 开门见山给出答案，而非描述搜索过程。不要说“我搜索了X并找到了Y”，直接说明答案是什么。
研究依据 —— 哪些具体结论支持这个答案。按标题引用：“根据[[结论标题]]...”
实际意义 —— 这对用户的具体情况意味着什么。如果推导文档中有领域词汇，请使用该词汇。
矛盾或注意事项 —— 任何未解决的冲突、限制或答案可能不适用的情况。研究中确实存在矛盾，请如实告知。
进一步探索 —— 用户可能感兴趣的相关结论或主题。这些是探索方向，而非任务。
参考来源 —— 简要说明使用了哪些知识层：“研究：参考了[N]个结论。本地方法论：参考了[M]份笔记。”如果本地方法论相关，请注明具体笔记：“您的方法论笔记[[标题]]为答案的[特定部分]提供了依据。”

Quality Standards

质量标准

Ground answers in specific claims, not general knowledge. The knowledge base exists so answers are evidence-based. If you answer from general knowledge without consulting the graph, you are bypassing the tool.

Acknowledge gaps honestly. When the research does not cover something, say so. "The current research graph doesn't have claims about X" is a legitimate answer. Do not fabricate coverage.

Distinguish certainty levels. Some claims are well-established with multiple supporting claims. Others are preliminary observations or research directions. The

confidence

field in claim frontmatter signals this:

No confidence field — standard established claim
```
confidence: speculative
```
— early-stage observation, not fully evaluated
```
confidence: emerging
```
— promising but needs more support
```
confidence: supported
```
— well-evidenced claim
```
confidence: established
```
— foundational, widely supported
```
status: archived
```
— superseded or dissolved claim

Be opinionated. The research has positions. Share them. "The research strongly suggests X because..." is better than "some sources say X, others say Y." If there IS genuine disagreement, present it as a tension, not as false balance.

Translate to user context. When the user has a derivation, apply findings to their system. Generic advice is less useful than specific application. "In your therapy vault, this means..." is better than "in general, this means..."

答案需基于具体研究结论，而非通用知识。 知识库的存在就是为了让答案有证据支持。如果不查询图谱就从通用知识回答，就是在绕过工具。

如实承认知识缺口。 如果知识库确实未涵盖某个主题，请明确说明：“当前研究图谱没有关于X的结论”是合理的答案。请勿编造内容。

区分确定性级别。 有些结论有多个支持结论，已被充分证实。有些则是初步观察或研究方向。结论前置元数据中的

confidence

字段表明了这一点：

无confidence字段——标准已确立的结论
```
confidence: speculative
```
——早期观察，未充分验证
```
confidence: emerging
```
——有前景但需要更多支持
```
confidence: supported
```
——证据充分的结论
```
confidence: established
```
——基础结论，被广泛支持
```
status: archived
```
——已被取代或废弃的结论

要有明确观点。 研究有明确的立场，请分享这些立场。“研究强烈建议X，因为...”比“有人说X，有人说Y”更好。如果确实存在分歧，请将其作为矛盾呈现，而非虚假平衡。

适配用户上下文。 如果用户有推导文档，请将研究结果应用到他们的系统中。通用建议不如具体应用有用。“在您的治疗知识库中，这意味着...”比“总体而言，这意味着...”更好。

Worked Examples

示例

Example 1: WHY Question

示例1：WHY类问题

Question: "Why does my system use atomic notes instead of longer documents?"

Classification: WHY -> Primary: Research Graph. Secondary: Reference (dimension-claim-map).

Search:

mcp__qmd__deep_search  query="atomic notes vs compound documents granularity"  collection="methodology"  limit=8

Read
```
reference/dimension-claim-map.md
```
— find granularity dimension's informing claims
Read
```
ops/derivation.md
```
— check user's granularity position

Answer:

Your system uses atomic granularity because your conversation signaled "precise claims from papers." The research shows that atomic notes enable independent linking and recombination — according to [[atomic notes maximize recombinable surface area]], each note can be linked from any context without dragging unrelated content along. Your processing pipeline (extract -> reflect -> reweave -> verify) specifically requires atomic granularity to maintain the link fabric, because [[verify phase checks link density per note]] and compound documents would inflate link counts artificially.

The trade-off: atomic notes create more files and require denser navigation structures. [[flat organization requires semantic search at scale]] explains why your system includes semantic search — without it, finding notes in a flat atomic structure becomes impractical beyond ~50 notes.

Tension: [[composability and context compete at the note level]] — making notes small enough to link cleanly sometimes makes them too small to carry their own argument. Your system handles this through the description field and topic map context phrases.

问题： "Why does my system use atomic notes instead of longer documents?"

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

搜索：

mcp__qmd__deep_search  query="atomic notes vs compound documents granularity"  collection="methodology"  limit=8

阅读
```
reference/dimension-claim-map.md
```
——找到粒度维度的依据结论
阅读
```
ops/derivation.md
```
——检查用户的粒度设置

答案：

您的系统使用原子粒度，因为您的对话表明需要“从论文中提取精确结论”。研究表明，原子笔记支持独立链接和重组——根据[[原子笔记最大化可重组表面积]]，每个笔记可以从任何上下文链接，而无需附带无关内容。您的处理流水线（提取->反思->重组->验证）特别需要原子粒度来维护链接结构，因为[[验证阶段检查每个笔记的链接密度]]，而复合文档会人为增加链接计数。

权衡：原子笔记会生成更多文件，需要更密集的导航结构。[[扁平化组织在规模上需要语义搜索]]解释了为什么您的系统包含语义搜索——没有它，在扁平化原子结构中查找笔记在超过约50条后会变得不切实际。

矛盾点： [[可组合性和上下文在笔记层面存在竞争]]——为了清晰链接而将笔记做小，有时会导致笔记太小而无法承载自身论点。您的系统通过描述字段和主题图上下文短语来解决这个问题。

Example 2: HOW Question

示例2：HOW类问题

Question: "How do I process a large research paper?"

Classification: HOW -> Primary: Guidance Docs. Secondary: Research Graph.

Search:

mcp__qmd__search  query="large source processing chunking"  collection="methodology"  limit=5

mcp__qmd__deep_search  query="context degradation large documents extraction"  collection="methodology"  limit=5

Answer:

For sources over 2500 lines, chunk into segments of 350-1200 lines and process each chunk with fresh context. [Guidance: pipeline processing workflow] explains the chunking strategy in detail.

The reason is [[context quality degrades as conversation grows]] — your extraction quality in the later sections of a 3000-line document will be measurably worse than in the early sections. Fresh context per chunk ensures each section gets your best attention.

Practical steps:

Run /seed to create the extraction task

/reduce will automatically detect the source size and plan chunks

Each chunk extracts independently with a running duplicate list across chunks

The final extraction report covers all chunks combined
Your config has
processing.depth: standard
, which means chunks process sequentially in the current session. If you switch to
deep
, each chunk would get its own isolated context (maximum quality, but slower).

问题： "How do I process a large research paper?"

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

搜索：

mcp__qmd__search  query="large source processing chunking"  collection="methodology"  limit=5

mcp__qmd__deep_search  query="context degradation large documents extraction"  collection="methodology"  limit=5

答案：

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

原因是[[上下文质量随对话长度增加而下降]]——在3000行文档的后半部分，您的提取质量会明显低于前半部分。为每个片段使用新上下文可确保每个部分都能得到最佳处理。

实际步骤：

运行/seed创建提取任务

/reduce会自动检测源文件大小并规划分块

每个片段独立提取，跨片段维护重复项列表

最终提取报告整合所有片段的内容
您的配置中
processing.depth: standard
，这意味着片段在当前会话中按顺序处理。如果切换为
deep
，每个片段将获得独立的上下文（质量最高，但速度较慢）。

Example 3: WHAT Question

示例3：WHAT类问题

Question: "What would a cooking recipe vault look like?"

Classification: WHAT -> Primary: Domain Examples. Secondary: Guidance Docs.

Search:

mcp__qmd__vector_search  query="cooking recipes culinary knowledge system"  collection="methodology"  limit=5

Read closest domain examples for structural inspiration

Answer:

[Answer synthesized from examples, showing concrete folder structure, note examples, topic map examples, and vocabulary choices specific to a culinary domain. References the closest existing domain example for structural patterns.]

问题： "What would a cooking recipe vault look like?"

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

搜索：

mcp__qmd__vector_search  query="cooking recipes culinary knowledge system"  collection="methodology"  limit=5

阅读最接近的领域示例以获取结构灵感

答案：

[从示例中合成的答案，展示具体的文件夹结构、笔记示例、主题图示例以及针对烹饪领域的特定词汇选择。参考最接近的现有领域示例的结构模式。]

Anti-Patterns

反模式

What NOT to Do

请勿执行以下操作

Anti-Pattern	Why It Fails	Instead
Answer without searching	Bypasses the knowledge base entirely	Always search, even for "obvious" questions
List claims without synthesis	Dumps search results, forces user to connect dots	Weave claims into a coherent argument
Search only one tier	Misses HOW when answering WHY, or vice versa	Check if secondary tier strengthens the answer
Ignore user's derivation	Generic advice when specific is available	Read ops/derivation.md for user context
Use universal vocabulary	Says "notes" when their system says "reflections"	Apply vocabulary transforms
Fabricate claim citations	Cites claims that do not exist in the graph	Only cite claims you actually read
Skip the claim-map	Searches blindly without routing	Read claim-map first for topic orientation
Present false balance	"Some say X, others say Y" when research has a clear position	Be opinionated — share the research's position

反模式	失败原因	正确做法
不搜索直接回答	完全绕过知识库	始终进行搜索，即使是“显而易见”的问题
列出结论但不合成	直接输出搜索结果，让用户自行梳理	将结论整合为连贯的论证
仅搜索一个层级	回答WHY问题时忽略HOW，反之亦然	检查次要层级是否能强化答案
忽略用户的推导文档	提供通用建议而非针对性建议	阅读ops/derivation.md获取用户上下文
使用通用词汇	当用户系统称“reflections”时使用“notes”	应用词汇转换
编造结论引用	引用图谱中不存在的结论	仅引用实际阅读过的结论
跳过结论映射表	盲目搜索无方向	先阅读结论映射表进行主题定位
呈现虚假平衡	当研究有明确立场时说“有人说X，有人说Y”	明确表达研究的立场

The Honesty Standard

诚实原则

If the knowledge base genuinely does not cover a topic:

Say so explicitly: "The current research graph doesn't have claims about X."
Offer what IS available: "The closest related research is about Y, which suggests..."
Flag it as a gap: "This might be worth investigating as a research direction."

Do NOT extrapolate wildly from tangentially related claims. An honest "I don't know, but here's what's adjacent" is more valuable than a fabricated answer.

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

明确说明：“当前研究图谱没有关于X的结论。”
提供可用的相关内容：“最接近的相关研究是关于Y的，这表明...”
将其标记为缺口：“这可能值得作为研究方向进行调查。”

请勿从间接相关的结论中过度推断。诚实的“我不知道，但这里有相关内容”比编造的答案更有价值。

Domain-Aware Answering

领域感知回答

When the user's question involves their specific system (not abstract methodology):

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

Step 1: Read Their Derivation

步骤1：读取用户的推导文档

Check for

ops/derivation.md

to understand:

Their dimension positions (granularity, organization, processing depth, etc.)
Their vocabulary choices (what are "notes" called in their domain?)
Their tradition mapping (which methodology preset, if any?)
Their personality settings (formal/warm, clinical/conversational)
Their constraint profile (which interaction constraints are active?)

检查

ops/derivation.md

以了解：

他们的维度设置（粒度、组织、处理深度等）
他们的词汇选择（在他们的领域中，“notes”被称为什么？）
他们的流派映射（是否使用了方法论预设？）
他们的个性设置（正式/亲切、临床/会话式）
他们的约束配置（哪些交互约束处于激活状态？）

Step 2: Apply Domain Vocabulary

步骤2：应用领域词汇

Use

${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md

to translate universal terms into their domain language. This is not cosmetic — it is about making the answer native to their system.

Universal Term	Therapy Domain	PM Domain	Research Domain
notes	reflections	decisions	claims
topic map	theme map	project map	MOC
reduce	surface	extract	reduce
reflect	connect	link	reflect
inbox	journal	intake	inbox

使用

${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md

将通用术语转换为用户的领域语言。这不是表面功夫——而是让答案与用户系统“原生”适配。

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

Step 3: Check Interaction Constraints

步骤3：检查交互约束

Reference

${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md

to understand whether their configuration creates specific pressures relevant to the question. Some dimension combinations create tensions that affect the answer:

High granularity + flat organization = needs strong semantic search
Permissive selectivity + deep processing = high volume, slower throughput
Self space enabled + warm personality = rich identity layer

参考

${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md

，了解用户的配置是否会产生与问题相关的特定影响。某些维度组合会产生影响答案的矛盾：

高粒度 + 扁平化组织 = 需要强大的语义搜索
宽松筛选 + 深度处理 = 高容量、低吞吐量
启用self空间 + 亲切个性 = 丰富的身份层

Step 4: Cite Dimension-Specific Research

步骤4：引用维度相关研究

Use

${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md

to ground answers in the specific claims that inform their configuration choices. This makes the answer traceable: "Your system does X because claim Y supports it for your configuration."

使用

${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md

，将答案建立在为用户配置选择提供依据的特定结论之上。这让答案可追溯：“您的系统做X是因为结论Y支持您的配置。”