structure-note

Structural Note

For design specifications, see ../index-note/references/20260203_索引体系设计规范.md For the structured workflow, see references/结构化流程.md

Positioning

The reading navigation system of the knowledge network. Core idea: A structural note is a "reading list" rather than a "classification"—connecting, arguing, guiding.

Purpose of creation (required reading)

Default reader: your future self—assuming you have forgotten the situation at the time, the project background, and why this structure was made.

Writing principles: A structural note must beself-contained, so that future readers can understand it without relying on memory:

Context at the time: state at the top "when, why, and under what project" it was created
Why this order: every reading item must have a reason, answering "half a year later, when reading here, why is the next step this one?"
Visible argument chain: use Folgezettel thinking (predecessor→this note→successor) to make the trajectory of thought traceable

Luhmann's methodology(strategy level):

Do not ask "which category does it belong to", ask "who is it in dialogue with, and after whom does it come」
Structure = chain of links: Luhmann's "structure" comes from the chain of references between slips, not a classification tree
Desktop solidification: A structural note = the digital solidification of "how this pile is arranged" on Luhmann's desktop
Argument dependency first: first identify conceptual dependencies, argument dependencies, and application dependencies, then arrange the reading order

Quick start

Mode one (create a structural note): identify dependencies → design the logic tree → define the reading order → ensure discoverability.
Mode two (batch organization): specify a directory/file → analyze dependencies one by one → generate a structural note.

Do not ask "which category does it belong to"; ask "how should it be read to understand it". If you need a "lookup entry point" rather than a "reading order", please use index-note skill。

Project conventions (important)

Index vs structural note

Type	Question answered	Metaphor	Core element
Index	I want to find X, where do I enter from?	Library retrieval card catalog	Keyword → entry point
Structural note	I want to understand X, how should I read it?	A planned reading list	A reading order of 1, 2, 3…

Scenarios that trigger a structural note

Preparing to write an article
Need to connect an argument chain
Explaining a complex topic to others
Organizing a project outline
Organizing documents in a certain folder

Structural note design constraints

Naming convention: clearly identify the topic + note type (recommended format:[主题]_结构笔记.md or [主题]结构笔记.md）
The logic tree must have: Reading order + dependencies
Must be discoverable: Add an entry in the relevant index

Structure note lifecycle

Status	Condition	Handling
Active	In use	Normal maintenance
Archived	Project ended/article completed	Mark as archived, keep read-only

Mode 1: Create a structure note

For the detailed structured process, see references/结构化流程.md

Step 1: Define the goal

Content to connect: What content should this structure note connect?
Target reader: The default is "your future self" - it must be self-contained and not rely on current memory
Expected takeaway: What can be gained after reading? (Write it at the top of the structure note for future readers to anchor on)
Context at the time: When, why, and under what project was it created? (Must be written into the structure note for future retrospection)

Step 2: Search and aggregate across the entire library

Search the entire library: Search for existing notes related to the topic
Cluster and filter: Identify core notes (skeleton) and supporting notes (flesh and blood)

Step 3: Execute the structured process

Follow references/结构化流程.md Step 1-5:

Identify dependencies between notes (prerequisite knowledge/core concepts/extended applications)
Design the logic tree (core -> deepening -> application)
Define the reading order (from simple to complex/theory first, then practice)
Ensure discoverability (pointed to by an index)
Readability check after six months: Context at the time + self-contained rationale

Mode 2: Content organization (single/batch)

For the detailed structured process, see references/结构化流程.md

Organize scattered notes into an ordered reading path (Bottom-up).

Applicable scenarios

Single: Just finished writing a note, looking for its place in the existing structure
Batch: Organize project documents / archive scattered notes

Step 1: Determine the input

Single: Directly specify the note path
Batch: Specify the directory path or file list

Step 2: Find the logical position one by one

For each note, think about its role in the sequence (Folgezettel):

Predecessor (Premise): What is it based on? (Whose sequence does it follow)
This position (Argument): What does it say? (Core contribution)
Successor (Function): What does it lead to? (What new topic does it open)

Step 3: Generate sequence suggestions

Single: Find its best insertion point in the logic tree (Insert After X).
Batch: Organize a directed acyclic graph (DAG) based on dependencies, and convert it into a linear reading order.

Step 4: Summary report

See "Output templates" below.

Output templates

Mode 2 (single): Structure insertion suggestion

**文档**：[[笔记名]]

**1. 逻辑定位 (Logic Role)**：
> "它在论证链中扮演什么角色？"
- [ ] **前驱 (Premise)**：基于 [[笔记A]] (铺垫/原理)
- [ ] **本位 (Argument)**：提出核心观点...
- [ ] **后继 (Function)**：为 [[笔记B]] 提供支撑/反例

**2. 序列插入 (Sequence Insertion)**：
> "把它插在阅读清单的哪里？"
- [ ] **插入位置**：在 [[结构笔记_X]] 的 [[笔记A]] 之后
- [ ] **阅读引导**：先读 A，再读本篇（因为...）

**3. 结构补完 (Gap Analysis)**：
- [ ] (可选) 是否缺了中间环节？→ 建议补写 [[笔记C]]

Mode 2 (batch): Content organization report

Document	Logical Role (Role)	Sequence Position (Sequence)	Completion Suggestion (Gap)
[[Note A]]	Core argument	1. As the opening	-
[[Note B]]	A specific case of A	2. Immediately after A	Suggest adding a counterexample

Pattern 1: Structured note format

# [主题]结构笔记

> **所属索引**：[[索引名称]]  
> **更新**：YYYY-MM-DD
>
> **当时语境**（半年后仍能看懂的关键）：YYYY年M月，因 [项目/写文章/解释X] 需要，整理 [主题] 的阅读路径。预期阅读后能 [一句话概括收获]。
>
> **默认读者**：未来的自己——本结构自包含，不依赖记忆。

---

## 逻辑树 (Logic Tree)

① [[核心笔记]] — 框架概述
  └─ [[深化笔记]] — 具体应用
      └─ [[案例笔记]] — 实践例证

---

## 阅读顺序 (Sequence)

> 每个顺序都有「理由」：半年后读到这里，仍能理解为什么下一步是它。

1. **[[笔记A]]** (Premise)
   > 理由：建立基础概念...（接在谁后面？为什么先读它？）
2. **[[笔记B]]** (Argument)
   > 理由：核心机制解析...（依赖 A 的什么？）
3. **[[笔记C]]** (Conclusion)
   > 理由：实战应用与总结...（导向什么？）

---

## 意外发现区（Serendipity）

> 卢曼强调：知识网络的价值在于「意外连接」。虽然不在主阅读路径，但可能带来启发的笔记：

- **[[笔记X]]** — 不同领域但类似模式（跨域类比）
- **[[笔记Y]]** — 反例/对比视角（批判性思考）
- **[[笔记Z]]** — 意外相关的主题（网络漫游）

---

相关索引：[[索引_xxx]]

Common mistakes and failure cases

Common mistakes quick reference table

Mistake	Solution
Structured notes have no reading order (only a list)	Must have an order of 1, 2, 3 + reasons
Structured notes are not pointed to by an index	Add an entry to the relevant index
The logic tree is too flat (no hierarchy)	Distinguish core/deepening/case levels
Structured notes are too long (become an article)	Keep it navigational; do not write content
Does not explain why this order	Every reading item must have a reason
Missing the context at the time	The top must state "when, why, under what project" — otherwise it will be incomprehensible six months later
Reasons are too brief	The reason must answer "six months later, reading here, why is the next step this?"

Failure case: an overly linearized structured note

❌ Before (problem version)：

# 项目X结构笔记

## 阅读顺序

1. [[笔记A]] — 建立基础
2. [[笔记B]] — 深入理解
3. [[笔记C]] — 实践应用

Problem diagnosis：

Missing the context at the time (do not know why this structure was created)
Reasons are vague ("establish a foundation" is too abstract; six months later it is incomprehensible why A is read first)
Missing dependency explanation (what does B depend on in A?)
No unexpected discovery area (over-linearized)

✅ After (revised version)：

# 项目X结构笔记

> **当时语境**：2026年1月，因需要向新团队成员解释项目X的设计逻辑，整理阅读路径。预期阅读后能理解：为什么选择架构A而非B、如何落地执行。
> **默认读者**：未来的自己——本结构自包含，不依赖记忆。

## 阅读顺序

1. **[[笔记A：用户需求分析]]** (Premise)
   > **理由**：需先理解用户的3大核心痛点（来自笔记A第2节），才能理解下一篇的架构设计为什么选择"分布式"而非"单体"。
   > **接下来**：理解了需求后 → [[笔记B]]理解架构选择

2. **[[笔记B：架构设计决策]]** (Argument)
   > **理由**：基于A的痛点2（高并发），本篇解释为什么选择分布式架构。依赖A的"用户规模预测"（10万+）作为决策依据。
   > **前置依赖**：需先读[[笔记A]]，否则看不懂"为什么不用单体架构"
   > **接下来**：理解了架构后 → [[笔记C]]看实践案例

3. **[[笔记C：实践案例]]** (Conclusion)
   > **理由**：B是理论，C是实战——展示架构在真实场景的应用与踩坑经验。

## 意外发现区

- **[[笔记D：反例_单体架构的失败]]** — 对比视角，理解为什么不选单体

Improvement points: ✅ Add the context at the time ✅ Make reasons specific (explain what it depends on and why this order) ✅ Add an unexpected discovery area (counterexample) ✅ Mark prerequisite dependencies and the next reading path

Quality check

Pattern 1 (Create structured notes)

Dependencies of all notes have been identified
The logic tree hierarchy is clear (core → deepening → application)
The reading order has reasons explained (Premise/Argument/Conclusion)
Chained bidirectional links are complete (Next/Previous have been added between notes)
Readable six months later: The top has "the context at the time"; the reason for each reading item lets a reader six months later understand "why the next step is this"

Pattern 2 (Content organization)

Single: The insertion position is explicitly specified (after whom it follows) and links are established
Batch: The generated reading order has no logical gaps and the notes are interlinked
Completeness: All input documents have been assigned a logical role

Design notes (the writing methodology of this skill)

The designs of this skill, such as "creation purpose", "Luhmann methodology", and "readable six months later", follow these writing strategies:

Luhmann thinking strategy: Do not ask about classification, ask about dialogue; structure = chain of links; Folgezettel (predecessor/current/successor) thinking
Prompt Engineering(Karpathy/Context Engineering): specific constraints, example-driven, clear structure, reduce ambiguity
Skill Best Practices(skill-creator): clear contract, progressive disclosure, appropriate degree of freedom, quality checklist