← Zurück zum Helpfulness-Scoring

Score-Berechnung und Gewichtung

Vier Dimensionen, zielgruppenspezifische Gewichtung, Schwellenwert-Logik und die Tiefenkarte — das vollständige Scoring-System

Auf dieser Seite

01Dimensionen im Detail 02Zielgruppen-Gewichtungsmatrix 03Schwellenwert-Logik 04Transparenz — Die Tiefenkarte

01

Dimensionen im Detail

Der Helpfulness-Score (HS) setzt sich aus vier Dimensionen zusammen, die jeweils von 0 bis 3 bewertet werden. Die Summe ergibt den Roh-Score (0–12), der anschließend pro Zielgruppe gewichtet wird.

🧩

Komplexität (K)

Wie viel Erklärung braucht das Thema, um verstanden zu werden?

0 — Trivial. Ein Satz reicht. „Das Projekt nutzt MIT-Lizenz.“

1 — Ein Absatz. „Installation: npm install, .env anlegen, npm start.“

2 — Mehrere Abschnitte. API-Design mit Conventions, Error Handling, Pagination.

3 — Eigene Seite mit Diagrammen. Auth-System mit OAuth2, JWT, RBAC, Session Management.

🎯

Relevanz (R)

Wie wichtig ist das Thema für das Verständnis des Gesamtsystems?

0 — Nebensächlich. Versteht man das System auch ohne.

1 — Hilfreich, aber nicht essenziell. Logging-Konfiguration.

2 — Wichtig für das Gesamtbild. Datenbank-Schema.

3 — Kernthema. Ohne dieses Thema versteht man das System nicht.

📖

Lernwert (L)

Wie viel lernt die Zielgruppe durch eine ausführliche Erklärung?

0 — Kein Lerneffekt. Standard-Boilerplate.

1 — Leichter Lerneffekt. Kennt man, aber Details sind nützlich.

2 — Guter Lerneffekt. Übertragbare Patterns und Techniken.

3 — Hoher Lerneffekt. Komplexe Konzepte, die ohne Erklärung nicht zugänglich sind.

🔐

Eigenständigkeit (E)

Kann das Thema isoliert erklärt werden, oder hängt es von vielen anderen Themen ab?

0 — Komplett abhängig. Macht nur im Kontext anderer Themen Sinn.

1 — Einige Abhängigkeiten. Braucht Vorwissen aus 2–3 anderen Themen.

2 — Weitgehend eigenständig. Kurze Einführung genügt als Kontext.

3 — Völlig eigenständig. Kann ohne jedes Vorwissen verstanden werden.

Formel: HS = K + R + L + E (Roh-Score: 0–12). Dieser Roh-Score wird anschließend über die Gewichtungsmatrix in einen zielgruppenspezifischen Score transformiert.

02

Zielgruppen-Gewichtungsmatrix

Dasselbe Thema bekommt unterschiedliche Scores je nach Zielgruppe. Ein Thema, das für Entwickler essenziell ist (HS=10), kann für Entscheider irrelevant sein (HS=2). Die Gewichtungsmatrix bildet diesen Unterschied ab.

Beispiel-Heatmap — Typische Score-Bereiche nach Thema und Zielgruppe:

Thema	🔧 Entwickler	👤 Anwender	📊 Entscheider
Implementierungsdetails	7–10	1–3	0–2
UI Workflow	3–5	7–10	4–6
Kosten / ROI	1–3	2–4	8–10
API-Design	8–10	4–6	1–3
Onboarding-Prozess	4–6	8–10	5–7
Security-Architektur	8–10	5–7	7–9
Lizenz	0–1	0–1	3–5
Error Handling	7–10	5–7	1–3

Grün = hoch (7–10) • Orange = mittel (4–6) • Grau = niedrig (0–3)

Konkretes Beispiel: Thema „Error Handling“

🔧 Entwickler

K=2, R=3, L=2, E=1

HS = 8

👤 Anwender

K=1, R=2, L=2, E=2

HS = 7

📊 Entscheider

K=2, R=3, L=2, E=1

HS = 8

Obwohl der Roh-Score ähnlich ist, entscheidet der Schwellenwert pro Zielgruppe, ob eine eigene Seite erstellt wird. Mehr dazu in Abschnitt 03.

03

Schwellenwert-Logik

Der HS bestimmt nicht direkt, was gebaut wird. Dafür gibt es den Entscheidungsbaum: Für jede Kombination aus Thema, Zielgruppe und Level wird geprüft, ob der Score den Schwellenwert erreicht — und ob die Zielgruppe dieses Level überhaupt bekommen darf.

Schwellenwerte pro Level und Zielgruppe:

Level	🔧 Entwickler	👤 Anwender	📊 Entscheider
L0 Erwähnung	≥ 1	≥ 1	≥ 1
L1 Eigenes Modul	≥ 4	≥ 5	≥ 6
L2 Eigene Seite	≥ 6	≥ 7	— (max L1)
L3 Deep-Dive	≥ 8	— (max L2)	— (max L1)

Entscheidungsbaum als Flussdiagramm:

Thema + Zielgruppe + Level

↓

Level ≤ max_level(Audience)?

NEIN

STOP: audience_max_level

JA

↓

HS ≥ threshold[audience][level]?

NEIN

STOP: hs_below_threshold

JA

↓

Tieferer Level möglich?

NEIN

ERSTELLEN + STOP

JA

ERSTELLEN + prüfe nächsten Level

// Schwellenwert-Entscheidung
const THRESHOLDS = {
  dev:  { l0: 1, l1: 4, l2: 6, l3: 8  },
  user: { l0: 1, l1: 5, l2: 7          },  // kein l3
  exec: { l0: 1, l1: 6                  }   // kein l2, l3
}

const MAX_LEVEL = { dev: 3, user: 2, exec: 1 }

function decide_levels(theme, audience):
    hs = calculate_hs(theme, audience)
    levels_to_build = []
    stop_reason = null

    for level in [0, 1, 2, 3]:
        // Gate 1: Audience-Maximum
        if level > MAX_LEVEL[audience]:
            stop_reason = "audience_max_level"
            break

        // Gate 2: Score-Schwellenwert
        level_key = "l" + level
        if hs < THRESHOLDS[audience][level_key]:
            stop_reason = "hs_below_threshold"
            break

        // Beide Gates passiert → Level einplanen
        levels_to_build.push(level)

    // Sonderfall: Wenn kein Level übrig, Thema überspringen
    if levels_to_build.length == 0:
        stop_reason = "below_minimum"

    return {
        theme: theme.id,
        audience: audience,
        hs: hs,
        levels: levels_to_build,
        stop_reason: stop_reason,
        // Metadaten für Tiefenkarte
        max_possible: MAX_LEVEL[audience],
        threshold_at_stop: THRESHOLDS[audience]["l" + (levels_to_build.length)]
    }
            

Der Entscheidungsprozess für jedes Thema/Audience-Paar:

1. Beginne bei Level 0 und arbeite dich hoch.

2. Gate 1: Ist der aktuelle Level noch innerhalb des Audience-Maximums? Entscheider: max L1. Anwender: max L2. Entwickler: max L3. Wenn nicht → STOP.

3. Gate 2: Erreicht der HS den Schwellenwert für diesen Level bei dieser Audience? Entwickler brauchen HS≥6 für L2, Anwender brauchen HS≥7. Wenn nicht → STOP.

4. Wenn beide Gates bestanden → Level wird eingeplant. Weiter zum nächsten Level.

5. Die Schleife stoppt beim ersten Gate-Versagen. Der Stop-Reason wird gespeichert, damit die Tiefenkarte später erklären kann, warum ein Thema nicht tiefer geht.

Wichtig: Ein Thema mit HS=5 für Entwickler bekommt L0+L1 (Schwellenwert 4 erreicht), aber kein L2 (Schwellenwert 6 nicht erreicht). Der Stop-Reason ist „hs_below_threshold“.

04

Transparenz — Die Tiefenkarte

Die Tiefenkarte (Depth Map) ist das Transparenz-Artefakt des Scoring-Systems. Sie zeigt für jedes Thema: welchen Score es bekommen hat, welche Levels erstellt wurden, welche Dateien generiert wurden — und warum es an einer bestimmten Stelle aufgehört hat.

Ausgabeformat der Tiefenkarte:

Thema	Audience	HS	Levels	Dateien	Stop-Reason
Auth	🔧 Dev	10	L0, L1, L2, L3	auth_dev_de.html (L1) auth_dev_de.html (L2) auth_dev_de.html (L3)	complexity_exhausted
Auth	👤 User	7	L0, L1, L2	auth_user_de.html (L1) auth_user_de.html (L2)	audience_max_level
Auth	📊 Exec	9	L0, L1	auth_exec_de.html (L1)	audience_max_level
Setup	🔧 Dev	5	L0, L1	setup_dev_de.html (L1)	hs_below_threshold
Setup	👤 User	8	L0, L1, L2	setup_user_de.html (L1) setup_user_de.html (L2)	audience_max_level
Lizenz	🔧 Dev	1	L0	—	hs_below_threshold

Warum die Tiefenkarte wichtig ist:

Ohne Tiefenkarte ist das Scoring eine Blackbox. Nutzer sehen, dass ein Thema keine L3-Seite hat, aber nicht warum. Die Tiefenkarte macht die Entscheidung nachvollziehbar:

• „audience_max_level“ — Die Zielgruppe darf nicht tiefer. Kein Score-Problem, sondern eine strukturelle Grenze.
• „hs_below_threshold“ — Der Score war zu niedrig. Das Thema war für diese Audience nicht wichtig genug.
• „complexity_exhausted“ — Alle verfügbaren Levels wurden gebaut. Es gibt schlicht nicht mehr zu erklären.

✏️ Wissenstest

Thema „Error Handling“ hat K=2, R=3, L=2, E=1 (HS=8). Für welche Zielgruppen bekommt es eine eigene Seite (mindestens L1)?

Nur 🔧 Entwickler — Schwellenwert ≥4 erreicht

🔧 Entwickler und 👤 Anwender — beide haben Schwellenwerte unter 8

Alle drei — 🔧≥4 ✅, 👤≥5 ✅, 📊≥6 ✅

🧪 Deep-Dive: Schwellenwerte im Detail →

🔧 Entwickler — Alle L2-Seiten

01 Phasen-Detail 02 Score-Berechnung 03 Subagent-Architektur 04 Farbraum & Typografie 05 Hero & Modul-Patterns