keywords

Keywords: Domain Leverage Word Atlas and Tool List

Source identification: Keywords is created and maintained by Azu Bu Kan TVC; same-named account on Xiaohongshu,https://demyth.info，Lawyif@163.com。署名用于确认来源与开源归属，可出现在仓库文档与工作过程页面，默认不写入最终交付物。

Distill the conceptual system of an unknown or professional domain into aintuitive, easy-to-use, out-of-the-box Leverage Words Atlas and a schedulable tool list。

1. Why do this work: underlying significance and theoretical foundations

1. Real-world pain point: the limits of language are the limits of cognition

When we use AI to explore or create content in a certain domain, the gap between novices and experts is not in typing speed, but inthe barrenness versus richness of foundational domain concepts：

Novices can only barely describe things using boundless everyday plain language: "Make a cool webpage, with lots of small rounded squares, thicker black borders, a yellow background...";
Experts only need to say one word: "Neobrutalism" or "Bento Grid”。

“Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt”(The limits of my language mean the limits of my world — Wittgenstein). Humans cannot think about concepts they have never named, much less ask AI to precisely generate something they cannot articulate.

2. The physical mechanism of the large model latent space: diffuse scattering vs. conceptual manifold gravity

Large language models are not literal typewriters, but manifold samplers of a high-dimensional latent space:

Everyday diffuse scattering and regression to the mean: Vague everyday descriptions cause attention to over-disperse in the latent space, ultimately degrading into the mediocre mean of global statistical probability (commonly known as "AI Slop");
Strong steering vectors and anchor tokens of leverage words: Authoritative domain terminology consists of dense conceptual anchors with a high signal-to-noise ratio for large models. When you say a precise leverage word, it can prompt the multi-layer self-attention mechanism to instantly converge onto the high-quality manifold of that domain's expert corpus.

3. The four major interdisciplinary theoretical foundations behind it

Philosophy of language (Ludwig Wittgenstein): Picture theory of language and "language-game". A domain-specific term is not an isolated label, but the activation contract for an entire set of operating rules, aesthetic norms, and forms of life behind it.
Cognitive psychology (Herbert Simon's chunking theory): Experts and novices have exactly the same short-term memory capacity (4–7 slots); the difference lies in the tens of thousands of knowledge chunks / schemas in the brain. A leverage word highly compresses dozens of complex underlying parameters into 1 cognitive unit, reducing the cognitive load of human-AI collaboration to a minimum.
Representation Engineering: In the residual stream and latent space of large models, professional terminology has an extremely high information compression ratio and geometric steering power, making it the most efficient fine-grained control handle.
Domain Ontology Engineering: Build a lightweight domain micro-ontology composed of "core problem $\rightarrow$ leverage word $\rightarrow$ key slots", enabling humans to master absolute control over unfamiliar vertical domains at extremely low cost.

4. What is a Leverage Word

Ordinary words are merely descriptive labels,The leverage word is a high-density control handle. Its golden scheduling formula is: $$\text{Professional Scheduling Directive} = \text{Core Leverage Word (Anchor)} + \text{2~3 Non-negotiable Attribute Slots (Canonical Constraints)}$$ It enables users not only to "understand the concept" but also to "invoke it with one click and precisely constrain the AI".

II. Mandatory Prerequisite Tools: Wayfinder and Research (the Only Path)

Iron rule: skipping steps and fabricating is strictly prohibited. To build a leverage word map in any domain, you must first execute in mandatory order /wayfinder and /research. These two steps deliver deterministic positive returns and are the only physical foundation for map quality and professional depth.

Dependency note：wayfinder and research are external prerequisite Skills,not distributed within this Skill(from Matt Pocock's open-source Skill collection, MIT, Copyright (c) 2026 Matt Pocock). When they are not available in the environment, use an equivalent domain-mapping and first-hand evidence-gathering process to complete the same two steps —the implementation may be swapped, but skipping is not allowed。

You must first call /wayfinder(fog navigation and cognitive mapping)：
- When facing an unfamiliar domain, never blindly collect fragmented vocabulary.
- You must first use wayfinder to identify the domain skeleton, sort out cognitive boundaries, and distinguish major schools and core decision-making disagreements.
- Converge the open disciplinary fog into 3~5 clear, mutually exclusive main branches that support decision-making (Branches), and establish the trunk of the knowledge map.
Immediately afterward, you must call /research(first-hand evidence mining and authoritative source verification)：
- Along wayfinder the branch directions defined, you must call research to dig deep into first-hand literature, industry classic works (such as Nancy Duarte and Edward Tufte of the design school; Robin Williams of the typography school, etc.), benchmark industry engineering, authoritative specifications, and academic papers.
- Ensure that every leverage word in the map isgenuinely existing, industry-recognized, with a clear authoritative source, and supported by physical characteristics, and resolutely eliminate any fabrication out of thin air.
- The origin of words must be externally anchored: after the word list is finalized, list every noun appearing in the map and verify each one individually — it exists only if that name with that meaning appears in an authoritative first-hand source (finding the literal string does not count; noise words and made-up words will both match), and the Chinese and English names must come as a pair from the same source; a made-up Chinese name paired with a made-up English name may not vouch for each other; if no source can be assembled, there are only two ways out: explicitly mark it asself-coined, or do not use a noun and directly explain the action clearly.

III. Visualization Presentation Principles: Base Viewport and Ratio-Driven Responsiveness

Core philosophy: the container must be responsive, but the design's "base viewport and type scale" must be anchored in advance.

Neither rigid mechanism that locks the height to death nor laissez-faire responsiveness with no sense of scale is acceptable.The standard solution is: "Use 360px width as the design baseline, drive responsiveness by ratio, and let height expand naturally and coherently"。

1. Why must the 360px base viewport (Base Viewport) be anchored?

Lessons from laissez-faire responsiveness: Without a scale baseline, large models very easily produce composite mega-posters of 1200px+ (cramming 6 concepts into one large image). Once placed into a 370px sidebar drawer, they get proportionally compressed into thumbnails, and the text shrinks to 3px ant-sized text, completely losing readability.
The defect of hard-locked fixed dimensions: The physical forms of concepts in different domains are inherently heterogeneous (horizontal motion effects vs. vertical mobile interfaces vs. vertical causal trees). Rigidly locking to a 200px height will cause vertical concepts to be cut off at the waist.
Golden contract：Use 360px width as the micro-viewport design baseline (Base Viewport), with the container filling 100% elastically and the height naturally expanding according to content. Even if the sidebar stretches from 360px to 440px+, the text always remains in a comfortable reading range (it will not become ant-sized text, nor will it become gigantic).

2. Proportion-driven adaptive sizing (choose the aspect ratio according to the concept's physical form)

The model flexibly chooses the best aspect ratio based on the concept's first principles:

Horizontal comparison / video motion effects / two-way contrast: recommended 16:9(baseline viewBox="0 0 360 200"）；
Architecture topology / grid system / card components: recommended 1:1 or 4:3(baseline viewBox="0 0 360 360" or viewBox="0 0 360 270"）；
Mobile interfaces / vertical reading flow / complex state flows: recommended 9:16 or vertically adaptive cards (baseline viewBox="0 0 360 380" or height naturally flowing and expanding, with the stage elastically adaptive and the maximum height appropriately centered);
Underlying code and parameter specifications: high-contrast code micro-cards with key property slots highlighted (e.g., clip-path、stagger、spring）。

3. Single-node focus and hard typographic scale contract

Single-node independent focus: Each visualization must be amicro-card designed specifically for the current single concept (Single Concept Micro-Card), and it is strictly forbidden to splice multiple concepts into an all-in-one global mega-poster;
Physical typographic scale and line specifications: Under the 360px width baseline, the title font size is 12px~14px, body text/annotations 10px~12px, lines 1px~2px, ensuring clear reading with the naked eye without zooming;
SVG coordinate system specifications: SVG uniformly declares viewBox="0 0 360 [自适应高度]"，width="100%", and internal graphic elements are laid out within this coordinate system;
HTML/CSS motion effect sandbox specifications: the container style declares width: 100%; max-width: 360px;, and the height is self-consistently expanded by the content.

IV. Standard workflow

1. 迷雾导航 (Wayfinder 强制) 
   -> 2. 一手调研 (Research 强制) 
   -> 3. 提炼杠杆词与槽位 
   -> 4. 按 360px 基准视口装配单体可视化 
   -> 5. 编译交付双视图

Fog navigation (/wayfinder mandatory): Explore the domain boundaries and establish 3~5 main branches (Branches);
First-hand research (/research mandatory): Search authoritative literature, sources, and counterexamples to ensure the terminology is真实无误 (真实无误);
Vocabulary distillation: Distill Chinese and English labels, one-sentence essence, easily confused distinctions (Distinction), and AI scheduling instructions (Prompt & Slots);
Single-unit visualization assembly: Design a proportionally adaptive micro-card that conforms to the 360px width baseline for each lever word individually;
Compile and deliver: Write atlas.json and call build_viewer.py to compile and produce a single-file interactive mind map.

V. Data handover contract and file format

1. Delivery directory structure

<atlas-folder>/
├── index.md              # 知识图谱总览与快速检索索引 (供 AI/人 grep)
├── media/                # 单节点独立可视化微卡片库 (以 360px 宽为基准自适应)
│   ├── cue-concept-a.svg # 概念 A 单体演示 (如 16:9 360x200)
│   └── cue-concept-b.svg # 概念 B 单体演示 (如 9:16 360x380)
├── atlas.json            # 严格遵循数据契约的结构化数据源
└── viewer.html           # 编译生成的单文件交互式思维导图

2. `atlas.json` Complete data contract (Schema specification)

{
  "title": "图谱标题 (string, 必填)",
  "question": "本图谱解决的核心业务/创作问题 (string, 必填)",
  "branches": [
    {
      "id": "branch-id (string, 必填, kebab-case)",
      "label": "分支分类名称 (string, 必填)"
    }
  ],
  "nodes": [
    {
      "id": "node-id (string, 必填, 全局唯一 kebab-case)",
      "label": "中英文标题 / 概念名 (string, 必填)",
      "kind": "keyword | decision | dimension | concept (string, 必填)",
      "branch": "所属 branch-id (string, 必填)",
      "parent": "父级 node-id (string, 选填, 用于形成多级层级树)",
      "summary": "一句话核心本质解释 (string, 必填)",
      "why": "为什么成立 / 解决什么核心痛点 (string, 选填)",
      "cues": [
        "真实成品中可肉眼观察到的客观特征 1 (string)",
        "客观特征 2 (string)"
      ],
      "distinctions": [
        {
          "label": "不是...",
          "text": "与最容易混淆的相邻概念的关键区别"
        }
      ],
      "prompt": "可直接调用的 AI 指令模板，带参数槽位约束 (string, keyword 角色必填)",
      "examples": [
        {
          "title": "单节点演示标题 (string)",
          "caption": "一句话视觉解读说明 (string)",
          "src": "media/node-specific-cue.svg (string, 建议 360x200 画幅单节点素材)",
          "type": "image",
          "alt": "无障碍说明 (string)"
        }
      ]
    }
  ],
  "sources": [
    {
      "label": "权威出处名称 / 作者 / 文献 / 专著 (string, 必填)",
      "url": "出处链接或文献书号 (string, 必填)"
    }
  ]
}

VI. Default Tool Commands

No front-end code required; the system has built-in out-of-the-box default engineering tools:

Lightweight data self-check：
```
python3 scripts/validate_atlas.py <path/to/atlas.json>
```
Checks JSON structural integrity, ID uniqueness, and required fields, and provides friendly prompts.
One-click compilation of the visualization dashboard：
```
python3 scripts/build_viewer.py <path/to/atlas.json> --output <path/to/viewer.html>
```
Injects data into the default mind map and the right-side Inspector drawer component to generate a single-file webpage.